Dom > Implementacija > Proces izračunavanja preostalog vremena. Najmanje preostalo vrijeme izvršenja. Tehnički direktor Centra za inovativne tehnologije i rješenja, Jet Infosystems


Proces izračunavanja preostalog vremena. Najmanje preostalo vrijeme izvršenja. Tehnički direktor Centra za inovativne tehnologije i rješenja, Jet Infosystems




Verzija za prebacivanje prethodnog algoritma je algoritam najmanje preostalog vremena izvođenja. Prema ovom algoritmu, planer svaki put bira proces sa najmanjim preostalim vremenom izvršenja. U tom slučaju je također potrebno unaprijed znati vrijeme za izvršenje zadataka. Kada stigne novi zadatak, njegovo ukupno vrijeme izvršenja se upoređuje s preostalim vremenom izvršenja trenutnog zadatka. Ako je vrijeme izvršenja novog zadatka kraće, trenutni proces se obustavlja i kontrola se prenosi na novi zadatak. Ova šema vam omogućava brzo posluživanje kratkih zahtjeva.

Planiranje na tri nivoa

Sistemi grupne obrade omogućavaju vam da implementirate planiranje na tri nivoa, kao što je prikazano na slici. Kako novi zadaci ulaze u sistem, oni se prvo stavljaju u red pohranjen na disku. Ulaz planer pristupa bira posao i šalje ga sistemu. Ostali poslovi ostaju u redu.

Čim posao uđe u sistem, za njega će se kreirati odgovarajući proces i on može odmah ući u borbu za pristup procesoru. Ipak, moguće je da ima previše procesa i da svi ne stanu u memoriju, a onda će neki od njih biti prebačeni na disk. Drugi nivo planiranja određuje koji procesi se mogu držati u memoriji, a koji na disku. Radi to planer memorije .

Planer memorije povremeno gleda procese koji se nalaze na disku kako bi odlučio koji će premjestiti u memoriju. Među kriterijima koje koristi planer su sljedeći:

1. Koliko je vremena prošlo otkako je proces prebačen na disk ili učitan sa diska?

2. Koliko dugo proces koristi CPU?

3. Koja je veličina procesa (mali procesi ne smetaju)?

4. Koja je važnost procesa?

Treći nivo planiranja je odgovoran za pristup procesoru u stanju pripravnosti. Kada govorimo o "planeru", obično mislimo tačno cpu planer . Ovaj planer koristi bilo koji algoritam koji odgovara situaciji, sa ili bez prekida. Već smo razmotrili neke od ovih algoritama, a sa ostalima ćemo se upoznati.

Planiranje u interaktivnim sistemima.

Ciklično planiranje.

Jedan od najstarijih, najjednostavnijih, najpoštenijih i najčešće korištenih je algoritam cikličkog rasporeda. Svakom procesu je dat određeni interval procesorskog vremena, takozvani vremenski odsjek. Ako proces još uvijek radi na kraju vremenskog kvanta, on se prekida i kontrola se prenosi na drugi proces. Naravno, ako se proces blokira ili završi rano, prijelaz se događa u tom trenutku. Implementacija kružnog rasporeda je jednostavna. Planer samo treba da drži listu procesa u stanju spremnosti. Kada proces dostigne svoje vremensko ograničenje, šalje se na dno liste.

Jedina zanimljiva tačka ovog algoritma je kvantna dužina. Prebacivanje s jednog procesa na drugi traje određeno vrijeme – potrebno je spremiti i učitati registre i memorijske mape, ažurirati tabele i liste, spremiti i ponovo učitati memorijsku keš memoriju, itd. Zaključak se može formulirati na sljedeći način: premali kvantni će dovesti do čestih prebacivanje procesa i mala efikasnost, ali preveliki kvant može dovesti do sporog odgovora na kratke interaktivne zahtjeve. Kvantna vrijednost od oko 20 -50 ms je često razuman kompromis.

Prioritetno planiranje.

U algoritmu kružnog rasporeda postoji važna pretpostavka da su svi procesi ekvivalentni. U računarskoj situaciji sa velikim brojem korisnika to možda nije slučaj. Na primjer, na fakultetu prije svega treba da budu dekani, zatim profesori, sekretarice, čistačice, pa tek onda studenti. Potreba da se uzmu u obzir takvi vanjski faktori vodi do prioritetnog planiranja. Osnovna ideja je jednostavna: svakom procesu se dodjeljuje prioritet, a kontrola se prenosi na proces najvišeg prioriteta koji je spreman za pokretanje.

Više redova.

Jedan od prvih prioritetnih raspoređivača implementiran je u kompatibilni sistem s podjelom vremena (CTSS).Glavni problem sa CTSS sistemom bio je u tome što je prebacivanje procesa bilo presporo, jer je samo jedan proces mogao biti u memoriji IBM 7094 računara. Svaki prekidač je značio zamjenu trenutnog procesa na disk.

i čitanje novog procesa sa diska. Programeri CTSS-a su brzo shvatili da bi efikasnost bila veća ako bi procesima vezanim za procesor bio dat veći vremenski odsjek nego da im se daju male vremenske isječke, ali često. S jedne strane, to će smanjiti broj swap-ova sa memorije na disk, a s druge strane će dovesti do lošijeg vremena odziva, kao što smo već vidjeli.

Kao rezultat, razvijeno je rješenje sa prioritetnim klasama. Procesi klase sa najvećim prioritetom dobili su jedan kvant, procesi sledeće klase - dva kvanta, sledeće - četiri kvanta, itd. Kada je proces koristio sve vreme koje mu je dodeljeno, prešao je u klasu ispod.

Kao primjer, razmotrite proces koji treba da izvrši proračune za 100 kvanta. Prvo će mu biti dat jedan kvant, a zatim će biti pumpan na disk. Sljedeći put dobije 2 kvanta, zatim 4, 8.16, 32, 64, iako od 64 koristi samo 37. U ovom slučaju će biti potrebno samo 7 pumpi (uključujući početno opterećenje) umjesto 100, koliko bi bilo potrebno ako koristite kružni algoritam. Osim toga, kako zaronite u prioritetni red, proces će se izvoditi rjeđe, ostavljajući procesor kraćim procesima.

“Najkraći proces je sljedeći”

Pošto algoritam Najkraći zadatak minimizira prosječno vrijeme obrade u sistemima za grupnu obradu, željeli bismo ga koristiti iu interaktivnim sistemima. U određenoj mjeri to je moguće. Interaktivni procesi najčešće prate obrazac “čekaj na komandu, izvrši komandu, čekaj komandu, izvrši komandu...” Uzimajući u obzir izvršenje svake komande kao poseban zadatak, ukupno prosečno vreme odgovora možete minimizirati pokretanjem najkraćeg zadatka prvo. Jedini problem je

je otkriti koji od procesa čekanja je najkraći.

Jedna metoda se oslanja na procjenu dužine procesa na osnovu prethodnog ponašanja procesa. Ovo započinje proces s najkraćim procijenjenim vremenom. Pretpostavimo da je procijenjeno vrijeme izvršenja naredbe T 0, a procijenjeno vrijeme sljedećeg izvođenja T 1 . Možete poboljšati procjenu vremena uzimanjem ponderisane sume ovih vremena aT 0 + (1 - a)T 1 . Odabirom odgovarajuće vrijednosti a, možemo učiniti da algoritam procjene brzo zaboravi na prethodna izvođenja ili, obrnuto, da ih pamti dugo vremena. Uzimajući a = 1/2, dobijamo niz procjena:

T 0, T 0/2 + T 1/2, T 0/4 + T 1/4 + T 2/2, T 0/8 + T 1/8 + T 2/4 + T 3/2.

Nakon tri izvođenja, težina T 0 u procjeni će se smanjiti na 1/8.

Metoda procjene sljedeće vrijednosti u nizu kroz ponderirani prosjek prethodne vrijednosti i prethodne procjene često se naziva starenjem. Ova metoda je primjenjiva u mnogim situacijama kada je potrebno procijeniti iz prethodnih vrijednosti. Najlakši način za implementaciju starenja je kada je a = 1/2. Na svakom koraku, sve što vam treba je

dodajte novu vrijednost trenutnoj procjeni i podijelite zbroj na pola (pomak udesno za 1 bit).

Zagarantovano planiranje.

Suštinski drugačiji pristup planiranju je davanje stvarnih obećanja korisnicima, a zatim njihovo ispunjenje. Evo jednog obećanja koje je lako izgovoriti i koje je lako održati: ako n korisnika dijeli CPU s vama, dobit ćete 1/n CPU snage.

A u sistemu sa jednim korisnikom i n procesora koji rade, svaki dobija 1/n ciklusa procesora.

Da bi ispunio ovo obećanje, sistem mora pratiti alokaciju CPU-a između procesa od trenutka kreiranja svakog procesa. Sistem zatim izračunava količinu CPU resursa na koje proces ima pravo, kao što je vrijeme od kreiranja podijeljeno sa n. Sada možemo izračunati odnos vremena dodeljenog procesu i vremena na koje on ima pravo. Rezultirajuća vrijednost 0,5 znači da je procesu dodijeljena samo polovina onoga što je trebalo, a 2,0 znači da je proces dobio dvostruko više nego što je trebalo. Zatim se započinje proces sa najnižim omjerom do

neće postati veći od onog svog najbližeg susjeda.

planiranje lutrije.

Algoritam se zasniva na distribuciji lutrijskih listića procesima za pristup različitim resursima, uključujući i procesor. Kada planer treba da donese odluku, srećka se nasumično bira i njen vlasnik dobija pristup resursu. Što se tiče pristupa CPU-u, "lutrija" se može dogoditi 50 puta u sekundi, a pobjednik dobija 20ms CPU vremena.

Važnijim procesima se mogu dati dodatni tiketi kako bi se povećale šanse za pobjedu. Ako postoji samo 100 tiketa i 20 ih drži jedan proces, tada će dobiti 20% vremena procesora. Za razliku od raspoređivanja prioriteta, gdje je vrlo teško procijeniti šta znači, recimo, prioritet 40, u rasporedu lutrije je sve jasno. Svaki proces će dobiti procenat resursa koji je otprilike jednak procentu tiketa koje ima.

Planiranje lutrije ima nekoliko zanimljivih svojstava. Na primjer, ako proces dobije nekoliko listića tokom kreiranja, tada su u sljedećoj lutriji njegove šanse za dobitak proporcionalne broju tiketa.

Procesi saradnje mogu po potrebi zamijeniti karte. Dakle, ako klijentski proces pošalje poruku serverskom procesu, a zatim blokira, on može proslijediti sve svoje tikete serverskom procesu kako bi povećao šanse za pokretanje servera. Kada se proces servera završi, on može vratiti sve tikete nazad.

Pošteno planiranje.

Do sada smo pretpostavljali da se svaki proces upravlja, bez obzira ko je njegov vlasnik. Stoga, ako korisnik 1 kreira 9 procesa, a korisnik 2 kreira 1 proces, tada će korištenjem round robin ili u slučaju jednakih prioriteta korisnik 1 dobiti 90% procesora, a korisnik 2 samo 10.

Kako bi izbjegli ovakve situacije, neki sistemi obraćaju pažnju na vlasnika procesa prije zakazivanja. U takvom modelu, svaki korisnik dobiva dio procesora, a planer odabire proces prema toj činjenici. Ako je u našem primjeru svaki od korisnika imao

obećali 50% procesora, oni će dobiti 50% procesora, bez obzira na broj procesa.

Planiranje u sistemima u realnom vremenu.

Vrijeme igra važnu ulogu u sistemima u realnom vremenu. Najčešće, jedan ili više vanjskih fizičkih uređaja generira ulazne signale, a računalo mora adekvatno odgovoriti na njih u datom vremenskom periodu.

Sistemi u realnom vremenu se dele na tvrdi sistemi u realnom vremenu , što znači da za svaki zadatak postoje strogi rokovi (moraju se poštovati), i fleksibilni sistemi u realnom vremenu , u kojem su kršenja vremenskog rasporeda nepoželjna, ali prihvatljiva. U oba slučaja, program je podijeljen u nekoliko procesa, od kojih je svaki predvidljiv. Ovi procesi su najčešće kratki i završavaju svoj posao u roku od jedne sekunde. Kada se pojavi vanjski signal, planer je taj koji mora primijeniti raspored.

Eksterni događaji na koje sistem mora odgovoriti mogu se podijeliti na periodični(pojavljuje se u redovnim intervalima) i neperiodični(nastaje nepredvidivo). Može postojati više periodičnih tokova događaja koje sistem mora obraditi. U zavisnosti od vremena potrebnog za obradu svakog događaja, možda neće biti moguće da sistem obradi sve događaje na vreme.


Slične informacije.


(vrijeme od rada postaje omogućeno dok se ne završi u slučaju povremene aktivnosti, ili dok sistem ne odgovori i korisnik prvi izađe iz ruke u slučaju interaktivne aktivnosti); ili maksimiziranje pravda(jednaka količina CPU vremena za svaki proces, ili općenito odgovarajućih trenutaka u vremenu prema prioritetu i radnom opterećenju svakog procesa). U praksi, ovi ciljevi se često sukobljavaju (na primjer, propusnost naspram kašnjenja), tako da će planer napraviti odgovarajući kompromis. Preferencija se mjeri bilo kojim od gore navedenih pitanja, ovisno o potrebama i ciljevima korisnika.

OS/360 i nasljednici

AIX

U AIX verziji 4, postoje tri moguće vrijednosti za politiku raspoređivanja niti:

  • Prvi, prvi izlaz: Kada je nit sa ovom politikom zakazana, ona se pokreće do završetka, osim ako nije blokirana, dobrovoljno prepušta kontrolu nad procesorom ili se nit višeg prioriteta šalje. Samo niti fiksnog prioriteta mogu imati FIFO politiku raspoređivanja.
  • Round Robin: Ovo je slično kružnom rasporedu sheme rasporeda AIX verzije 3 zasnovano na vremenskim isječcima od 10 ms. Kada PP nit ima kontrolu na kraju vremenskog slota, ona se pomiče na rep reda niti s istim prioritetom. Samo niti fiksnog prioriteta mogu imati politiku rasporeda Round Robin.
  • OSTALO: Ovu politiku definira POSIX1003.4a u implementaciji. U AIX verziji 4, ova politika je definirana kao ekvivalentna RR, osim što se primjenjuje na niti s nefiksnim prioritetom. Ponovno izračunavanje vrijednosti prioriteta pokrenute niti na svakom prekidu znači da nit može izgubiti kontrolu jer je njena vrijednost prioriteta porasla više od druge niti. Ovo je ponašanje AIX verzije 3.

Niti su prvenstveno od interesa za aplikacije koje se trenutno sastoje od više asinhronih procesa. Ove aplikacije mogu nametnuti malo opterećenje sistemu ako se pretvore u strukturu sa više navoja.

AIX 5 implementira sljedeće politike raspoređivanja: FIFO, round robin i fair round robin. FIFO politika se sastoji od tri različite implementacije: FIFO, FIFO2 i FIFO3. Politika round robin se zove SCHED_RR na AIX-u, a poštena kružna shema se zove SCHED_OTHER.

linux

Linux 2.4

Brain Fuck Scheduler (BFS), koji je također kreirao Kolivas, alternativa je CFS-u.

FreeBSD

FreeBSD koristi red povratnih informacija na više nivoa sa prioritetima u rasponu od 0-255. 0-63 su rezervirani za prekide, 64-127 za gornju polovinu kernela, 128-159 za korisničke niti u realnom vremenu, 160-223 za korisničke niti koje dijele vrijeme i 224-255 za neaktivne korisničke niti. Također, kao i Linux, koristi postavku aktivnog reda, ali ima i neaktivni red.

Često se programeri, posebno neiskusni, izgube kada se od njih traži da odrede rokove za zadatke. Međutim, sposobnost planiranja je vrlo korisna i neophodna vještina koja pomaže ne samo u poslu, već i u životu. Odlučili smo da od stručnjaka naučimo kako pravilno planirati i isporučiti projekte na vrijeme.

Kratke zaključke možete pronaći na kraju članka.

Programer obično mora uzeti u obzir nekoliko parametara odjednom kako bi procijenio vrijeme za dovršetak zadatka:

  1. Iskustvo u obavljanju ovakvih zadataka i radu sa ovim tehnološkim stekom. Ako morate učiniti nešto suštinski novo, morate biti posebno pažljivi s procjenom.
  2. Iskustvo sa ovim klijentom. Poznavajući kupca, možete okvirno predvidjeti neke dodatne zahtjeve i količinu izmjena.
  3. Kvalitet koda za rad. To je najutjecajniji faktor, zbog kojeg se sve može razvući i općenito ne ići po planu. Ako u projektu postoje testovi, posvuda samo eksplicitne zavisnosti, a funkcionalnost je dobro izolirana, nije sve tako strašno. Mnogo je gore ako imate posla sa naslijeđenim kodom bez testova ili kodom koji je zasićen implicitnim ovisnostima. Stvari kao što su "magične funkcije" (kada je iz koda teško vidjeti konačni stek poziva) i dupliciranje koda (kada je potrebno urediti nekoliko nezavisnih odjeljaka da bi se promijenila neka funkcionalnost) također mogu zakomplicirati stvari.

Da biste naučili kako adekvatno procijeniti uslove rada, morate stalno vježbati. Na početku svog rada radio sam upravo ovo: procijenio sam vrijeme da završim bilo koji nadolazeći zadatak, čak i ako to niko nije zahtijevao, a onda sam pogledao koliko sam tačno uspio ući u svoju procjenu. U procesu izvršavanja zadatka, napomenuo je za koje radnje je potrebno više vremena. Ako je nešto uvelike povećalo vrijeme, zapamtio sam ovaj trenutak i uzeo u obzir u sljedećim procjenama.

Objektivnoj procjeni vremena potrebnog isključivo za rad, treba dodati malu marginu za pokrivanje situacija više sile. Često se procjenjuje kao postotak izvršenja glavnog zadatka, ali je za svakog drugačije: neko dodaje 20% vremena, neko - 10%, a neko - 50%.

Takođe je korisno analizirati razloge kašnjenja nakon svakog težeg kršenja roka. Ako nemate dovoljno kvalifikacija, morate poraditi na svojim slabim tačkama. Ako je problem bio organizacioni - shvatiti šta je spriječilo normalan rad.

Nadogradite na stariju verziju

, Tehnički direktor Centra za inovativne tehnologije i rješenja, Jet Infosystems

Veliki broj članaka posvećen je metodama za procjenu složenosti projekta, uključujući trajanje rada i pojedinačne zadatke. Međutim, to je i dalje uzrok sukoba kako unutar projektnog tima tako i u komunikaciji s klijentom.

Glavni pomoćnik u procjeni je iskustvo. Pokušajte nekako uporediti novi zadatak sa već obavljenim. Ako radite izvještaj, pogledajte koliko je dugo trajao sličan izvještaj u prošlosti. Ako radite nešto novo, pokušajte to rastaviti na poznate dijelove i procijeniti ih. Ako je zadatak potpuno nov, odvojite vrijeme za učenje (još bolje - koordinirajte ovo vrijeme s onim koji postavlja zadatak).

Obratite pažnju na prateće korake - ako trebate razviti uslugu, tada u procjenu mora biti uključeno i testiranje jedinica (a možda i ne samo jedinica), priprema testnih podataka će potrajati. Trebali biste razmisliti o integraciji sa drugim servisima itd. Dajte vremena da sami ili uz pomoć testera popravite nedostatke koje pronađete. Mnogo vremena se može izgubiti na „nevidljive“ zadatke. Na primjer, postoji procjena za razvoj i postoji procjena za testiranje, ali prijenos artefakta na testiranje može biti povezan sa postavljanjem štandova. Stoga je važno mentalno zamisliti cijeli proces kako ništa ne bi propustili.

Nakon određivanja intenziteta rada potrebno je u kalendar uključiti nove poslove, ne zaboravljajući na druge zadatke i aktivnosti koje idu paralelno.

I ne zaboravite da su planovi bezvrijedni, ali planiranje je neprocjenjivo. Naučite ispravljati planove na vrijeme, informirati sve zainteresirane strane i eskalirati na vrijeme kako propušteni rokovi ne bi nikoga iznenadili.

Nadogradite na stariju verziju

Pitanje na koje se ne može odgovoriti u kratkom obliku. Da je jednostavno, onda ne bi postojao problem kršenja rokova.

Da biste rokove razvoja učinili predvidljivijim, prvo morate razumjeti razloge zašto programeri stalno griješe.

Prvi razlog je taj što je većina zadataka koje programer obavlja jedinstvena u jednom ili drugom stepenu. Odnosno, najvjerovatnije će programer prvi put obaviti takav zadatak. On nema dobru ideju o tome koliko će ovaj posao trajati. Ako se radi o programeru sa solidnim iskustvom i morao je obaviti sličan zadatak, njegova procjena će biti bliža stvarnosti.

Upotrijebimo jednostavnu analogiju – ako nikada niste iskopali jarak, ne možete tačno reći koliko će vam vremena trebati da iskopate rov širine 30 cm, dubine 60 cm i dužine 20 metara. Ako ste ranije kopali, vaše procijenjeno vrijeme rada bit će mnogo bliže stvarnom vremenu rada.

Drugi razlog je taj što su programeri po prirodi optimisti. Odnosno, uzimajući u obzir zadatak, birajući opciju implementacije za njega, dajući procjenu poboljšanja, programer očekuje da će sve raditi kako on očekuje. I ne razmišlja o problemima koje će naići na putu. Većinu vremena on ih ne može predvidjeti. Na primjer, postoji zadatak koji programer može implementirati koristeći softversku biblioteku otvorenog koda treće strane. U fazi evaluacije pronašao ju je na internetu, pročitao njen opis - odgovara mu. I čak je ispravno procijenio količinu svog rada da bi ugradio korištenje ove biblioteke. Ali on uopće nije predvidio da će doći do greške u ovoj biblioteci u okruženju njegovog softverskog proizvoda.

Programer će morati ne samo da ugradi upotrebu biblioteke u svoj kod, već i da ispravi grešku u samoj biblioteci. I često programer ne daje vremena da ispravi svoje greške. Statistike pokazuju da testiranje i ispravljanje grešaka može zauzeti do 50% vremena utrošenog na kodiranje. Brojka ovisi o kvalifikaciji programera, okruženju, korištenim razvojnim praksama (na primjer, jedinični testovi značajno skraćuju ovo vrijeme i ukupno trajanje/radni intenzitet razvojnog zadatka je manji).

Ako se vratimo na analogiju sa kopačem, onda kopač nije očekivao da će mu se lopata slomiti i da će morati dva sata tražiti novu sječu.

Treći razlog su nepredviđeni zahtjevi. Ni u jednom drugom području proizvodnje materijala, s kojim kupci razvoja softvera toliko vole da uspoređuju, ne postoji toliki tok novih zahtjeva. Zamislite prolaz kopača koji je iskopao 19 metara od 20 i čuo od kupca želju da jarak ne ide pravolinijski, već u zmiji dužine ramena od 97 centimetara.

Kako se nositi sa svim tim i kako živjeti u uslovima takve neizvjesnosti? Smanjenje neizvjesnosti i osiguravanje vremena.

Najlakši način da svoja očekivanja približite stvarnosti je da koristite razigrano "Pi" pravilo. Nakon što ste dobili procjenu od programera (u smislu vremena ili intenziteta rada), potrebno ga je pomnožiti brojem Pi (= 3,14159). Što je programer iskusniji napravio procjenu, taj koeficijent može biti niži.

Obavezno je uvježbati razlaganje originalnog zadatka na male zadatke ne veće od 4 sata. Što je dekompozicija detaljnija, veće su šanse da će procjena biti bliska stvarnoj složenosti/trajanju.
Ako se vratimo na raspodjelu rezerve – ovo vrijeme treba izdvojiti na kraju projekta. Loša praksa je napraviti rezervu i uključiti je za svaki zadatak. Parkinsonov zakon „Rad ispunjava sve vreme koje mu je određeno“ strogo se poštuje.

Ako sumiramo kratko "ukupno", tada će za pravilno određivanje vremena rada biti korisne sljedeće radnje:

  • izvršiti dekompoziciju posla, razbiti zadatak na što je moguće detaljnije korake;
  • izvršiti izradu prototipa;
  • ograničiti implementaciju ranije nepredviđenih zahtjeva. To ne znači da ih ne treba raditi, ali je preporučljivo istaknuti ove zahtjeve i dogovoriti se sa kupcem o promjenama u vremenu i cijeni za njihovu implementaciju;
  • uzeti u obzir vrijeme za stabilizaciju rješenja;
  • koristiti prakse poboljšanja kvaliteta koda, kao što je pisanje jediničnih testova;
  • napraviti opštu rezervu.

Pa, zapamtite da ako činjenica premašuje vašu procjenu za 30%, onda je ovo vrlo dobar rezultat.

Nadogradite na stariju verziju

Za najprecizniju procjenu potrebno vam je iskustvo u stvarnom razvoju, a ono je in specifično područje. Ali postoje i opća pravila koja će pomoći da se izbjegnu greške u planiranju i problemi pri predaji posla kupcu. Ovako bih opisao ova pravila.

Prvo, morate razumjeti problem. Čini se da je to očigledno i da se ne odnosi direktno na tajming, ali u stvari je ključna tačka. Čak i kod ozbiljnih velikih projekata, jedan od glavnih faktora neuspjeha i kašnjenja je problem u određivanju zahtjeva. Za programere početnike, nažalost, ovo je ozbiljan problem - ne čitaju tehničke specifikacije ili čitaju i razumiju vrlo selektivno (od deset tačaka, pet je zapamćeno i završeno, a ostali su zapamćeni već prilikom slanja rezultata) . Jasno je da se pogrešno shvaćeni zadatak ne može pravilno implementirati na vrijeme.

Dalje - za procjenu vremena za razvoj. Posebnost programiranja je da ne postoje apsolutno identični zadaci. To čini naš rad zanimljivijim, ali je procjenjivanje rokova teže. Ovdje dobro funkcionira razgradnja, tj. dijeljenje složenog jedinstvenog zadatka u niz malih poznatih podzadataka. I svaki od njih se već može sasvim adekvatno procijeniti u satima. Hajde da sumiramo procjene podzadataka - i dobijemo procjenu cijelog zadatka.

U pravilu, takva procjena uključuje samo troškove samog kodiranja. Ovo je svakako najvažniji dio razvoja, ali daleko od toga da je jedini (a često ne i najobimniji). Potpuni završetak zadatka također uključuje čitanje i pojašnjenje TOR-a, sastanak sa kolegama ili kupcem, otklanjanje grešaka i testiranje, sastavljanje dokumentacije, isporuku rezultata (demonstracija kupcu i moguće izmjene prema njegovim komentarima). Koliko će vam vremena trebati za ove radnje, samo će iskustvo pokazati. U početku je, barem, važno da ih ne zaboravite uzeti u obzir u proračunima, a možete zatražiti od iskusnijih kolega grubu procjenu vremena.

Dakle, uzimamo procjenu troškova kodiranja, dodajemo procjenu troškova dodatnog rada - i dobivamo željenu procjenu vremena za završetak zadatka. Ali to nije sve! Morate navesti planirani datum završetka zadatka. Bila bi greška jednostavno uzeti i podijeliti troškove rada (u satima) sa 8 sati i dodati trenutni datum. U stvarnoj praksi, programer nikada (pa, skoro nikada) ne radi 100% vremena na jednom određenom zadatku. Definitivno ćete potrošiti vrijeme na druge poslove - važne, ali nisu direktno povezane s glavnim. Na primjer, pomoć kolegama, obuka, izvještavanje itd. Obično se pri planiranju smatra da 60-70% radnog vremena ide direktno na rad na tekućem projektu. Osim toga, morate uzeti u obzir moguća kašnjenja koja će vas spriječiti da kontinuirano radite na zadatku. Na primjer, ako za to trebate komunicirati s drugim ljudima (kolegama, kupcima), onda uzmite u obzir njihovo zaposlenje, raspored rada itd.

Evo osnovnih pravila koja će, po mom mišljenju, pomoći programeru da izbjegne probleme u procjeni i poštivanju rokova. Osim toga, ključno je akumulacija vlastitog iskustva kako u realizaciji zadataka tako i u evaluaciji. Na primjer, nakon dovršetka zadatka, vrlo je korisno uporediti svoju početnu procjenu sa stvarnim vremenskim okvirom i izvući zaključke za budućnost. I, naravno, vrijedi proučiti tuđe iskustvo. Preporučio bih knjigu S. McConnell-a "Koliko košta softverski projekat" i S. Arkhipenkova "Predavanja o upravljanju softverskim projektima" na tu temu.

Nadogradite na stariju verziju

Prilikom ocjenjivanja i zakazivanja potrebno je:

  1. Rasporedite zadatak na male funkcionalne dijelove na takav način da postoji jasno razumijevanje koliko će dugo trajati razvoj svakog takvog dijela.
  2. Paralelno sa dekompozicijom, sigurno će se pojaviti dodatna pitanja o funkcionalnosti koja nije opisana u opisu problema. Neophodno je dobiti odgovore na ovakva pitanja, jer se to direktno odnosi na obim posla, a samim tim i na vrijeme.
  3. Dodajte određeni postotak rizika konačnoj procjeni. To se određuje iskustvom. Možete početi, na primjer, s rizicima od 10-15%.
  4. Shvatite koliko sati dnevno je programer spreman posvetiti izvršavanju zadatka.
  5. Konačnu procjenu podijelimo sa brojem sati koje izdvajamo po danu i dobijemo broj dana potrebnih za implementaciju.
  6. Fokusiramo se na kalendar i potreban broj dana za završetak. Uzimamo u obzir vikende i druge dane kada programer neće moći da radi na zadatku, kao i datum početka rada (programer nije uvek spreman da preuzme zadatak na posao istog dana). Tako dobijamo datum početka i završetka rada.

Nadogradite na stariju verziju

U našoj kompaniji planiranje zadataka uvijek prolazi kroz nekoliko faza. S poslovne strane formuliramo 5-6 strateških ciljeva za godinu. To su zadaci visokog nivoa, na primjer, povećati bilo koji parametar za toliko posto. Nadalje, različiti odjeli kompanije formiraju poslovne zadatke za sve IT timove. Rokovi za ove zadatke dobijaju početnu grubu procenu, koju često formiraju svi članovi tima – menadžer, analitičar, programer i tester. Dobivši ovu ocjenu, poslovanje daje prioritet zadacima, uzimajući u obzir strateške ciljeve kompanije. U tome pomažu i unakrsni strateški ciljevi, sa njima postaje očito da svi radimo za neki zajednički cilj, nema te situacije kada neko vuče samo u njihovom pravcu. Prikupljamo sprintove od precizno procijenjenih zadataka po rokovima. Za neke ekipe su tromjesečne, za neke - mjesečne. Nekoliko zadataka, prema preliminarnoj procjeni, koji spadaju u naredni sprint, ekipe daju tačnu procjenu. Veliki zadaci podijeljeni su na niže razine, za svaki od njih je odgovoran određeni izvođač, on je taj koji daje tačnu procjenu.

U ovoj fazi, važno je ne zaboraviti dodati marginu vremena za ispravljanje grešaka, jer samo oni koji ništa ne rade ne prave greške. Ovo dobro razumiju i vlasnik proizvoda i poslovni korisnici. Istovremeno, potrebna vremenska granica mora biti adekvatna: niko neće razumjeti programera koji postavlja jednostavan zadatak na predug rok, od njega će se tražiti da opravda odluku. Najteže je objasniti poslu zašto je potrebno vrijeme za refaktoriranje. Zahvalni smo našoj kompaniji na činjenici da povremeno uspijevamo, jer na kraju refaktoring dovodi do olakšanja infrastrukture i dovođenja stvari u red u kodu, što povećava stabilnost sistema i može značajno ubrzati razvoj novih funkcije.

Ponekad se dešavaju greške u procjeni. Po mom mišljenju, nemoguće je da odjel razvoja u velikim kompanijama sa razvijenom infrastrukturom to u potpunosti izbjegne. U ovom slučaju, važno je da programer na vrijeme obavijesti svog menadžera o tome šta se dešava, a on, zauzvrat, ima vremena da upozori poslovanje i "ponovno igra" nešto u općim planovima kompanije. U ovom načinu rada je puno ispravnije nego bjesomučno pokušavati u 3 dana napraviti ono što je potrebno 5, a zatim se utopiti u veliki broj grešaka koje su nastale zbog takve žurbe.

Nadogradite na stariju verziju

Tačan odgovor na oba dijela pitanja [kako naučiti kako pravilno planirati i isporučiti projekat na vrijeme - Crveni.] - iskustvo. Ne postoje drugi načini da se "zna zen". Prema teoriji odlučivanja, bilo kakvi tačni zaključci mogu se izgraditi samo na osnovu analize većeg broja već dostupnih podataka. I što je više ovih podataka, to je tačnija konačna prognoza i procjena.

Po riječima Herberta Shawa: "Iskustvo je škola u kojoj čovjek uči kakva je budala bio prije." Iz ovoga slijedi prilično jednostavan zaključak: ako programer već ima iskustvo koje je u korelaciji sa zadatkom, može se osloniti na njega, ako ne, na iskustvo "kolega u radnji".

Zatim, morate shvatiti da je direktno zakazivanje zadatak koji ljudi rade vrlo, vrlo loše, posebno u razvoju. Kada se procjenjuju rokovi dospijeća, smatra se dobrom praksom da se u prvobitnu procjenu uvedu "faktori prilagođavanja". Ova metrika može se kretati od 1,5 do 3, ovisno o iskustvu programera i ukupnosti stepena neizvjesnosti zadataka koji se rješavaju u okviru projekta.

Nadogradite na stariju verziju

Prilikom određivanja vremena važno je uzeti u obzir mnoge faktore.

Na primjer radno iskustvo. Koliko jasno zamišljate obim posla koji predstoji? Jeste li već radili nešto slično? Jasno je da što više iskustva, to će se posao brže obaviti.

Dobro napisan tehnički zadatak igra značajnu ulogu u određivanju vremena. To je veoma teško na našim prostorima. Često klijent sam ne zna šta želi, pa savjetujem da potrošite dan-dva viška, ali da od klijenta dobijete jasnu predstavu o željenom rezultatu. Važno je da ovo predstavljanje bude obostrano. I tek nakon toga možete početi pregovarati o iznosu i uslovima.

Takođe, uvek rizikujte. Za početnike preporučujem da procijenjene rokove pomnožite sa dva. Na kraju krajeva, bolje je predati projekat prije roka i rasti kao stručnjak u očima kupca, nego ga predati kasnije i uništiti svoju reputaciju.

Nadogradite na stariju verziju

Opšta preporuka je da programer treba da nauči kako pravilno dekomponovati zadatke, uvijek tražiti moguće zamke, oslanjati se na vlastito iskustvo i ne zaboraviti na vrijeme upozoriti kupce i kolege ako se zadatak ne može riješiti u zadanom roku.

Izgraditi jasan plan je mnogo teže nego odrediti rok za završetak jednog zadatka. Istovremeno, važno je ne samo da isporučite projekat na vrijeme, već i da se pobrinete da sistem koji ste razvili ispravno rješava poslovne probleme. Ovdje IT timovima pomažu različite metodologije razvoja softvera: od RUP-a i MSF-a do SCRUM-a i drugih Agile formata. Izbor alata je veoma širok, a mnogi naši kupci žele unapred da razumeju kako ćemo sa njima raditi u projektu, kojih principa se pridržavamo.

Inače, tema Agile-a danas postaje bliska poslovanju, pa čak iu pojedinačnim projektima javnom sektoru, budući da principi ove metodologije omogućavaju da projekte implementirate vrlo brzo, upravljajući očekivanjima kupaca na svakoj iteraciji. Na primjer, u Agile timu praktički nema dugotrajnih razgovora s klijentom. Zaboravite na desetine stranica koje opisuju nepotrebne tehničke detalje, kao što je brzina pojavljivanja padajuće liste. Dajte kupcu priliku da isproba srednju verziju sistema, tada će vam biti mnogo lakše da se razumete.

Agilni tim sve zajedno planira i određuje optimalan nivo rada koji će biti potreban za rješavanje određenog problema. Na primjer, jedna od tehnika se zove "Poker Planning", gdje svaki učesnik anonimno daje svoju procjenu potrebnih troškova rada za određeni zadatak. Nakon toga, tim određuje prosječnu težinu zadatka u poenima priče ili radnim satima i raspoređuje slučajeve po principu „ko šta voli“. Istovremeno, svaki dan se tim okuplja na 15-minutnom skupu, kada svi pričaju o statusu svojih trenutnih zadataka za nekoliko minuta, uključujući i izvještaje o nastalim poteškoćama. Tim brzo otklanja uočeni problem, tako da kupac u najkraćem mogućem roku sagleda sljedeću fazu rada programera. Programeri ne odgađaju rokove za izvršavanje zadataka zbog svoje nespremnosti da još jednom povuku tim ili uzaludnih pokušaja da to sami shvate, ubijajući dragocjeno vrijeme. Inače, na takvim mini statusima programeri imaju želju da se dokažu sa najbolje strane, da pokažu da odgovorno pristupate poslu. To zaista motivira i samodisciplinira.

Sve o čemu se govorilo u prethodnih nekoliko sekcija više se fokusiralo na dalja istraživanja problema pravilnog vremena procesa, a mnogo manje na praktične primjene. Popunjavajući ovu prazninu, predstavljamo jednu od metoda za izračunavanje pravog vremena procesa na osnovu statističkih podataka o njegovoj evoluciji.

Razmotrimo jednodimenzionalni proces čije stanje karakteriše realna varijabla x. Pretpostavimo da se posmatranja dinamike procesa vrše u astronomskom vremenu t, tako da su t = t k i x = x k , k =1, ..., n fiksni momenti posmatranja i odgovarajuće vrijednosti procesa države. Postoji mnogo različitih matematičkih metoda koje omogućavaju da se konstruišu takve krive koje ili prolaze kroz tačke (t k , Xk) ili im se približavaju na „najbolji način“. Rezultirajuće funkcije x = x(t) stvaraju u našem umu utisak da proces koji se razmatra zavisi od mehaničkog kretanja nebeskih tela i da se stoga njegovo stanje izražava u terminima astronomskog vremena t. Sa takvim se zaključkom moglo računati; da nije bilo stalnih poteškoća u pokušaju da se predvidi dalji tok procesa. Za veliki broj različitih procesa koji nisu direktno povezani sa mehaničkim kretanjem nebeskih tela, teorijska predviđanja dobijena upotrebom funkcije x = x(t) izvan intervala posmatranja počinju značajno da odstupaju od naknadnih eksperimentalnih podataka. Razlog nesklada između teorije i eksperimenta obično se objašnjava neuspješno odabranom metodom obrade, ali to možda nije suština stvari.

Svaki proces koji nas zanima odvija se u Univerzumu. On, naravno, "oseća" uticaj kretanja nebeskih tela. Međutim, ovaj uticaj se može pokazati kao „meki“, neodlučujući. To se posebno može manifestirati u činjenici da u određenim intervalima toka astronomskog vremena stanje procesa ostaje nepromijenjeno. S tim u vezi, prisjetimo se prethodno navedenog primjera sa zatvorenom praznom prostorijom, izoliranom od vanjskog svijeta. Pustićemo samo jednog živog da uleti u sobu. U roku od nekoliko dana promjene stanja sistema "soba - muva" ovisit će o kretanju muhe, jer se promjene u stanju prostorije ne mogu očekivati. Istovremeno, teško je zamisliti da je ponašanje muve striktno povezano sa tokom astronomskog vremena.

Nakon što smo napravili tako dugu digresiju, pređimo na opis algoritma za izračunavanje vlastitog vremena procesa.

U ovom algoritmu, jedinica za izračunavanje lokalnih maksimuma se bira kao prirodna mjera vremena. Osim toga, uzimaju se u obzir mogući dijelovi stacionarnog stanja procesa, na kojima se, kao što je ranije navedeno, pravo vrijeme zaustavlja. Pošto se o istovetnosti dva stanja može govoriti samo u granicama tačnosti merenja, onda se u daljem tekstu koristi određeni pozitivan broj e – dozvoljena greška merenja.

Dakle, ulazni podaci za algoritam su prirodni broj n, pozitivan broj 8, nizovi (tk) i (x k ), k = 1, ..., n. Radi praktičnosti programiranja, algoritam je predstavljen u obliku četiri uzastopno izvršavana modula.

Modul 1, koristeći podatke n, e, t k), (x k) , u opštem slučaju, formira nove nizove 7 = (7+ X=(X t) i sasvim specifičan prateći niz R = (?), gdje je 1 = 1, ..., t, i t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Modul 1 uključuje sljedeće procedure:

p:=1, t:=0, k:=1.

U p.p. 1, 2 brojači se uvode sa određenim početnim vrijednostima:

U p.p. 3, 4, brojači se povećavaju za 1.

Provjerite stanje k^n. Ako je ispunjeno, idite na korak 6, u suprotnom idite na korak 11.

Provjerite nejednakost x k --x k = e. Ako vrijedi, idite na korak 7, u suprotnom idite na korak 9.

7. tii = ti - (tkl - tk), i = k1, ..., n.

Ovaj postupak znači da ako se vrijednosti Xk i Xk 1 ne mogu razlikovati unutar greške, tada se sva vremena počevši od tk smanjuju za iznos tki-tk.

p = p. Vratite se na tačku 4.

Tv = t k ; Xv:=x k ; p = p v = v+l., tj. formiraju se elementi nizova T, X, P i dodjeljuje se sljedeća vrijednost v.

  • 10. Uzmite (t k , ..., t n I (Xk, - X n) kao originalne nizove dimenzije n--k 1 + 1 i zatim se vratite na korak 2.
  • 11. Ispisati m, (T), (X,) i (P,), gdje je i = l, ..., tj. Kraj.

Objasnimo značenje elemenata pratećeg niza P. Iz prethodnog teksta proizilazi da je vrijednost pk jednaka broju onih elemenata niza (xk) koji slijede odmah i razlikuju se od x pi+... +, + za manje od e. Imajte na umu da je pi+ ... +p m = n.

Primjer 1 Dato: n = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

  • 27, 30, 32, 33, 34, 35, 36) i (x,) = (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , pet,
  • 5, 4, 3), vidi sl. 9, a.

Kao rezultat izvođenja modula 1, dobija se m = 11,

(D) \u003d (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) \u003d (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

u(e) = (2, 4, 1, 1, 1,3, 2, 1,3, 1, 1), vidi sl. 9, b.

Modul 2. Ulazni podaci za njega su prirodni broj m, kao i nizovi (7+ (X L ), = 1, ..., m. Ovaj modul u nizu (TJ) detektuje vremenske tačke [TM a ], 1 = 1 m (ml

Primjer 2. Vrijednosti m, (Tb) i (X,] su posuđene iz prethodnog primjera. Nakon izvršavanja modula 2, ml = 3, m2 = 8, (W,) = (3, 8, 17), (T*) = (3, 4, 6, 8, 11, 12, 15, 17), vidi i sl. 9b.

Modul 3 Ulazni podaci ml, m2, (TM n ), 1 = 1, ..., ml, (G*), /2=1, ..., r2.

Ovaj modul je dizajniran za izgradnju niza (t (-r) prema formuli

Gdje je TV 6 [TMP, TMn+i]

Varijabla m je pravo vrijeme generirano promjenom varijable x. Njegova prirodna mjera je jedinica za izračunavanje lokalnih maksimuma.

Primjer 3. Početni podaci za T 2) su isti kao vrijednosti ml, m2 ITM, au primjeru 2. . Nakon odgovarajućih proračuna, dobijamo N = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Modul 4 Formira izlaz rezultata uspostavljanjem korespondencije između vrijednosti m i elemenata x iz niza (xk).

Primer 4. Na osnovu podataka iz primera 2 i 3, dobijen je sledeći rezultat, vidi sl. 9, u:

t: 0; 0,2; 0,6; 1; 1.33; 1.44;

x: 6; 3; 2; četiri; 3T 0 2;

Dakle, razmatrani algoritam omogućava razvoj koncepta pravog vremena procesa na osnovu informacija o promeni stanja procesa zabeleženih na astronomskoj vremenskoj skali. Sasvim je jasno da se mogu koristiti i drugi algoritmi zasnovani, na primjer, na izračunavanju niza lokalnih minimuma ili mješovitog niza koji se sastoji od lokalnih maksimuma i minimuma. Prilikom obrade eksperimentalnih podataka vjerovatno bi trebalo testirati različite opcije. Ako je iz nekog razloga eksperimentator odabrao jedno od određenih pravih vremena i primio nizove (m4 i (xk), onda bi u sljedećoj fazi trebao koristiti neke matematičke metode da aproksimira eksperimentalne tačke (m*, x) neki približni svijet linija procesa x = x(t) Ekstrapolacijom ove linije izvan granica početnog intervala posmatranja, on može dati predviđanja o daljem toku procesa.

Zanimljivo je spomenuti računski eksperiment namijenjen procjeni mogućnosti korištenja predloženog algoritma. Kao eksperimentalni materijal odabrani su podaci o godišnjem oticanju rijeke. Vakhsh (Tadžikistan) za prethodnih 40 godina. U istom periodu uzete su informacije o dinamici Vukovog broja – najčešće korištenog integralnog indeksa sunčeve aktivnosti. Ovo posljednje je uzeto kao osnova za razvoj pravog vremena procesa solarne aktivnosti. Do novog vremena, informacije o troškovima rijeke su pretvorene. Vakhsh, a zatim, u intervalu posmatranja, data je teorijska zavisnost protoka vode kao funkcija pravog vremena sunčeve aktivnosti. Karakteristična karakteristika rezultujućeg grafa je skoro periodično ponašanje maksimalnih i minimalnih troškova. Troškovi, međutim, ne ostaju konstantni.

Uvod

Svrha radionice o organizaciji proizvodnje je proširenje i produbljivanje teorijskih znanja, usađivanje potrebnih vještina za rješavanje najčešćih zadataka u praksi na organizaciji i planiranju proizvodnje.

Radionica uključuje zadatke za glavne dijelove kursa. Na početku svake teme daju se kratke smjernice i teorijske informacije, tipični zadaci sa rješenjima i zadaci za samostalno rješavanje.

Prisutnost u svakoj temi smjernica i kratkih teorijskih informacija omogućava vam da ovu radionicu koristite u učenju na daljinu.


Proračun trajanja proizvodnog ciklusa

Trajanje proizvodnog ciklusa služi kao pokazatelj efikasnosti proizvodnog procesa.

Proizvodni ciklus- period boravka predmeta rada u procesu proizvodnje od trenutka puštanja u promet sirovina do trenutka puštanja gotovog proizvoda u promet.

Proizvodni ciklus se sastoji od radno vrijeme, tokom kojeg se troši rad, i pauze. Pauze, ovisno o razlozima koji su ih izazvali, mogu se podijeliti na:

1) uključeno prirodno ili tehnološki - nastaju zbog prirode proizvoda;

2) organizaciono(pauze između smjena).

Trajanje proizvodnog ciklusa sastoji se od sljedećih komponenti:

T ciklus = t one + t jedi + t tr + t k.k. + t m.o. + t m.c.

gdje t one– vrijeme tehnoloških operacija;

ne jedem - vrijeme prirodnih procesa (sušenje, hlađenje, itd.);

t tr - vrijeme prevoza predmeta rada;

t c.c. - vrijeme kontrole kvaliteta;

t m.o - interoperativno vrijeme čekanja;

t m.c. - vrijeme provedeno u međuprodajnim skladištima;

(t tri t k.k. može se kombinovati sa t m.o).

Proračun trajanja proizvodnog ciklusa zavisi od vrste proizvodnje. U masovnoj proizvodnji, trajanje proizvodnog ciklusa je određeno vremenom kada je proizvod u toku, tj.

T ciklus = t u M,

gdje t in- hod otpuštanja;

M- broj radnih mjesta.

Ispod izduvni hod treba shvatiti kao vremenski interval između puštanja u promet jednog proizvedenog proizvoda i proizvoda koji slijedi nakon njega.

Ciklus oslobađanja je određen formulom

t u \u003d T eff / V,

gdje T ef- efektivni fond radnog vremena za obračunski period (smjena, dan, godina);

AT- obim proizvodnje za isti period (u prirodnim jedinicama).

Primjer: T cm = 8 sati = 480 minuta; T traka = 30 min; → T eff = 480 - - 30 \u003d 450 min.

H = 225 kom; → t c = 450/225 = 2 min.

U serijskoj proizvodnji, gdje se obrada vrši u serijama, trajanje tehnološkog ciklusa se ne određuje za jedinicu proizvodnje, već za cijelu seriju. Štaviše, u zavisnosti od načina puštanja serije u proizvodnju, dobijamo različita vremena ciklusa. Postoje tri načina kretanja proizvoda u proizvodnji: serijski, paralelno i mješovito (serijsko-paralelno).


I. At dosljedan pokretnih dijelova, svaka sljedeća operacija počinje tek nakon završetka prethodne. Trajanje ciklusa sa sekvencijalnim kretanjem dijelova bit će jednako:

gdje n - broj delova serije koja se obrađuje;

t komi- dionica vremena za operaciju;

C i- broj poslova i-th operacija;

m– broj operacija tehnološkog procesa.

S obzirom na seriju proizvoda, koja se sastoji od 5 komada. Grupa se preskače uzastopno kroz 4 operacije; trajanje prve operacije je bilo 10 min, druge 20 min, treće 10 min i četvrte 30 min (sl. 1).

Slika 1

T petlja = T zadnji = 5 (10+20+10+30) = 350 min.

Prednost sekvencijalnog načina pomicanja dijelova je što održava opremu u radu bez zastoja. Ali njegov nedostatak je što je trajanje proizvodnog ciklusa u ovom slučaju najveće. Osim toga, na radnim mjestima stvaraju se značajne zalihe dijelova, što zahtijeva dodatni proizvodni prostor.

II. At paralelno U kretanju serije pojedinačni delovi se ne zadržavaju na radnim mestima, već se deo po deo prebacuju na sledeću operaciju odmah, bez čekanja da se završi obrada cele serije. Dakle, uz paralelno kretanje serije dijelova na svakom radnom mjestu, različite operacije se istovremeno izvode na različitim dijelovima iste serije.

Vrijeme obrade serije s paralelnim kretanjem proizvoda drastično je smanjeno:

dl .

gdje n n- broj delova u transfer party(transportna stranka), tj. broj proizvoda koji se istovremeno prenose iz jedne operacije u drugu;

Dužina - najduži radni ciklus.

Uz paralelno lansiranje serije proizvoda, obrada dijelova cijele serije vrši se kontinuirano samo na onim radnim mjestima gdje duge operacije slijede kratke. U slučajevima kada kratke operacije slijede duge, tj. duže (u našem primjeru treća operacija), izvršavanje ovih operacija se vrši s prekidima, tj. oprema u stanju mirovanja. Ovdje se serija dijelova ne može obraditi odmah, bez odlaganja, jer prethodna (duga) operacija to ne dozvoljava.

U našem primjeru: n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; With= 1.

T para \u003d 1 (10 + 20 + 10 + 30) + (5-1) 30 \u003d 70 + 120 \u003d 190 min.

Razmotrite šemu paralelnog kretanja dijelova (slika 2):

Slika 2

III. Za otklanjanje prekida u obradi pojedinih delova serije u svim operacijama, primeniti paralelno-serijski ili mješovito start-up metoda u kojoj se dijelovi (nakon njihove obrade) prenose u sljedeću operaciju pojedinačno, ili u obliku „transportnih“ zaostalih predmeta (više komada) na način da se operacije ne prekidaju ni na jednom radnom mjestu. U mješovitoj metodi kontinuitet obrade uzima se iz sekvencijalnog, a prijelaz dijela iz operacije u operaciju neposredno nakon njegove obrade uzima se iz paralelnog. Kod mješovitog načina puštanja u proizvodnju, vrijeme ciklusa se određuje po formuli

jezgro .

gdje kor. - najkraći radni ciklus (od svakog para susednih operacija);

m-1 – broj kombinacija.

Ako je sljedeća operacija duža od prethodne, ili joj je vremenski jednaka, tada se ova operacija pokreće pojedinačno, odmah nakon što je prvi dio obrađen u prethodnoj operaciji. Ako je, naprotiv, sljedeća operacija kraća od prethodne, ovdje dolazi do prekida prilikom prijenosa komada. Da bi se one spriječile, potrebno je akumulirati transportni zaostatak takvog volumena koji je dovoljan da osigura rad u narednoj operaciji. Da bi se ova tačka praktično pronašla na grafikonu, potrebno je preneti poslednji detalj serije i izdvojiti trajanje njenog izvođenja udesno. Vrijeme obrade svih ostalih dijelova serije je ucrtano na grafikonu lijevo. Početak obrade prvog dijela pokazuje trenutak kada zaostatak transporta iz prethodne operacije treba prenijeti u ovu operaciju.

Ako su susedne operacije iste po trajanju, onda se samo jedna od njih prihvata kao kratka ili duga (slika 3).

Slika 3

T zadnji par = 5 (10 + 20 + 10 + 30) - (5-1) (10 + 10 + 10) = 350-120 \u003d 230 min.

Glavni načini za smanjenje trajanja proizvodnog ciklusa su:

1) Smanjenje radnog intenziteta izrade proizvoda poboljšanjem obradivosti proizvedene konstrukcije, upotrebom računara i uvođenjem naprednih tehnoloških procesa.

2) Racionalna organizacija procesa rada, uređenje i održavanje radnih mesta na bazi specijalizacije i kooperacije, obimne mehanizacije i automatizacije proizvodnje.

3) Smanjenje raznih planiranih i neplaniranih pauza u radu na osnovu racionalnog korišćenja principa naučne organizacije proizvodnog procesa.

4) Ubrzanje toka reakcija kao rezultat povećanja pritiska, temperature, prelaska u kontinuirani proces itd.

5) Unapređenje procesa transporta, skladištenja i kontrole i njihovo blagovremeno kombinovanje sa procesom obrade i montaže.

Smanjenje trajanja proizvodnog ciklusa jedan je od ozbiljnih zadataka organizacije proizvodnje, jer. utiče na promet obrtnih sredstava, smanjenje troškova rada, smanjenje skladišnog prostora, potrebu za transportom itd.

Zadaci

1 Odrediti trajanje ciklusa obrade 50 delova sa serijskim, paralelnim i serijsko-paralelnim tipovima kretanja u procesu proizvodnje. Proces obrade dijelova sastoji se od pet operacija, čije trajanje je min: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5=3. Druga operacija se izvodi na dvije mašine, a svaka na jednoj. Veličina paketa za prijenos je 4 komada.

2 Odrediti trajanje ciklusa obrade 50 delova sa serijskim, paralelnim i serijsko-paralelnim tipovima kretanja u procesu proizvodnje. Proces obrade dijelova sastoji se od četiri operacije, čije trajanje je min: t 1 =1; t 2 =4; t 3 =2; t 4=6. Četvrta operacija se izvodi na dvije mašine, a svaka druga na jednoj. Veličina paketa za prijenos je 5 komada.

3 Serija delova od 200 komada obrađuje se svojim paralelnim sekvencijalnim kretanjem tokom procesa proizvodnje. Proces obrade dijelova sastoji se od šest operacija, čije trajanje je min: t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6=20. Treća operacija se izvodi na tri mašine, šesta na dve, a svaka od ostalih operacija na jednoj mašini. Odredite kako će se promijeniti vrijeme ciklusa za obradu serije dijelova ako se paralelno-sekvencijalna verzija kretanja u proizvodnji zamijeni paralelnom. Veličina paketa za prijenos je 20 komada.

4 Serija delova od 300 komada obrađuje se svojim paralelnim sekvencijalnim kretanjem tokom procesa proizvodnje. Proces obrade dijelova sastoji se od sedam operacija, čije trajanje je min: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7=6. Svaka operacija se izvodi na jednoj mašini. Transfer serija - 30 komada. Kao rezultat poboljšane tehnologije proizvodnje, trajanje treće operacije smanjeno je za 3 minute, sedme - za 2 minute. Odredite kako se mijenja ciklus obrade serije dijelova.

5 S obzirom na seriju praznina, koja se sastoji od 5 komada. Grupa se preskače kroz 4 operacije: trajanje prve je 10 minuta, druge 20 minuta, treće 10 minuta, četvrte 30 minuta. Odrediti trajanje ciklusa analitičkim i grafičkim metodama za sekvencijalno kretanje.

6 S obzirom na seriju praznina, koja se sastoji od četiri komada. Zabava se preskače kroz 4 operacije: trajanje prve je 5 minuta, druge 10 minuta, treće 5 minuta, četvrte 15 minuta. Odrediti trajanje ciklusa analitičkim i grafičkim metodama uz paralelno kretanje.

7 S obzirom na seriju praznina, koja se sastoji od 5 komada. Grupa se preskače kroz 4 operacije: trajanje prve je 10 minuta, druge 20 minuta, treće 10 minuta, četvrte 30 minuta. Odrediti trajanje ciklusa analitičkim i grafičkim metodama za serijsko-paralelno kretanje.

8 Odrediti trajanje tehnološkog ciklusa za obradu serije proizvoda od 180 kom. sa paralelnim i uzastopnim varijantama njegovog kretanja. Napravite grafikone procesa obrade. Veličina paketa za prijenos - 30 kom. Norme vremena i broja poslova u pogonu su slijedeće.