në shtëpi > Zbatimi > Procesi i llogaritjes së kohës së mbetur. Koha më e vogël e mbetur e ekzekutimit. Drejtor Teknik i Qendrës për Teknologji dhe Zgjidhje Inovative, Jet Infosystems


Procesi i llogaritjes së kohës së mbetur. Koha më e vogël e mbetur e ekzekutimit. Drejtor Teknik i Qendrës për Teknologji dhe Zgjidhje Inovative, Jet Infosystems




Versioni i ndërrimit të algoritmit të mëparshëm është algoritmi më pak i mbetur i kohës së ekzekutimit. Sipas këtij algoritmi, planifikuesi çdo herë zgjedh procesin me kohën më të vogël të mbetur të ekzekutimit. Në këtë rast, është gjithashtu e nevojshme të dihet paraprakisht koha për të përfunduar detyrat. Kur arrin një detyrë e re, koha totale e ekzekutimit të saj krahasohet me kohën e mbetur të ekzekutimit të detyrës aktuale. Nëse koha e ekzekutimit të detyrës së re është më e vogël, procesi aktual pezullohet dhe kontrolli transferohet në detyrën e re. Kjo skemë ju lejon të shërbeni shpejt kërkesa të shkurtra.

Planifikimi me tre nivele

Sistemet e përpunimit të grupeve ju lejojnë të zbatoni planifikimin në tre nivele, siç tregohet në figurë. Ndërsa detyrat e reja hyjnë në sistem, ato fillimisht vendosen në një radhë të ruajtur në disk. Hyrja programuesi i aksesit zgjedh një punë dhe e dërgon atë në sistem. Pjesa tjetër e vendeve të punës mbeten në radhë.

Sapo një punë të ketë hyrë në sistem, do të krijohet një proces përkatës për të dhe mund të hyjë menjëherë në luftën për qasje në procesor. Sidoqoftë, është e mundur që të ketë shumë procese dhe të gjitha të mos përshtaten në memorie, atëherë disa prej tyre do të shfaqen në disk. Niveli i dytë i planifikimit përcakton se cilat procese mund të mbahen në memorie dhe cilat mund të mbahen në disk. E bën atë programuesi i memories .

Planifikuesi i memories shikon periodikisht proceset që janë në disk për të vendosur se cilin prej tyre do të zhvendoset në memorie. Ndër kriteret e përdorura nga planifikuesi janë këto:

1. Sa kohë ka kaluar që kur procesi u faqos në disk ose u ngarkua nga disku?

2. Sa kohë ka që procesi përdor CPU-në?

3. Cila është madhësia e procesit (proceset e vogla nuk pengojnë)?

4. Cila është rëndësia e procesit?

Niveli i tretë i planifikimit është përgjegjës për aksesin e proceseve në gjendje gatishmërie tek procesori. Kur flasim për "planifikues", zakonisht nënkuptojmë saktësisht programuesi i procesorit . Ky planifikues përdor çdo algoritëm që i përshtatet situatës, me ose pa ndërprerje. Ne kemi shqyrtuar tashmë disa nga këto algoritme dhe do të njihemi me të tjerët.

Planifikimi në sisteme ndërvepruese.

Planifikimi ciklik.

Një nga më të vjetrit, më të thjeshtët, më të drejtët dhe më të përdorurit është algoritmi ciklik i planifikimit. Çdo procesi i jepet një interval i caktuar i kohës së procesorit, i ashtuquajturi pjesë kohore. Nëse procesi vazhdon të funksionojë në fund të kuantumit kohor, ai përfundon dhe kontrolli transferohet në një proces tjetër. Sigurisht, nëse procesi bllokohet ose përfundon herët, tranzicioni ndodh në atë pikë. Zbatimi i planifikimit të rrumbullakët është i thjeshtë. Planifikuesi duhet vetëm të mbajë listën e proceseve në gjendje gati. Kur një proces ka arritur kufirin e tij kohor, ai dërgohet në fund të listës.

E vetmja pikë interesante e këtij algoritmi është gjatësia kuantike. Kalimi nga një proces në tjetrin kërkon pak kohë - ju duhet të ruani dhe të ngarkoni regjistrat dhe hartat e memories, të përditësoni tabelat dhe listat, të ruani dhe ringarkoni cache-in e memories, etj. Përfundimi mund të formulohet si më poshtë: kuanti shumë i vogël do të çojë në frekuencë ndërrimi i proceseve dhe efikasiteti i vogël, por një kuant shumë i madh mund të çojë në përgjigje të ngadaltë ndaj kërkesave të shkurtra interaktive. Një vlerë kuantike prej rreth 20 -50 ms është shpesh një kompromis i arsyeshëm.

Planifikimi me prioritet.

Ekziston një supozim i rëndësishëm në algoritmin e planifikimit të rrumbullakët që të gjitha proceset janë ekuivalente. Në një situatë kompjuterike me një numër të madh përdoruesish, kjo mund të mos jetë kështu. Për shembull, në një universitet në radhë të parë duhet të shërbehen dekanët, pastaj profesorët, sekretarët, pastruesit dhe më pas studentët. Nevoja për të marrë parasysh faktorë të tillë të jashtëm çon në planifikimin prioritar. Ideja bazë është e thjeshtë: çdo procesi i caktohet një prioritet dhe kontrolli transferohet në procesin me prioritet më të lartë që është gati për të ekzekutuar.

Radhë të shumta.

Një nga programuesit e parë me prioritet u implementua në sistemin e përputhshëm me kohë të përbashkët (CTSS).Problemi kryesor me sistemin CTSS ishte se ndërrimi i procesit ishte shumë i ngadalshëm, pasi vetëm një proces mund të ishte në memorien e kompjuterit IBM 7094. Çdo ndërprerës nënkuptonte shkëmbimin e procesit aktual në disk.

dhe leximi i një procesi të ri nga disku. Zhvilluesit e CTSS e kuptuan shpejt se efikasiteti do të ishte më i lartë nëse proceseve të lidhura me procesor do t'u jepej një pjesë më e madhe kohore sesa nëse do t'u jepeshin pjesë të vogla kohore, por shpesh. Nga njëra anë, kjo do të zvogëlojë numrin e shkëmbimeve nga memorja në disk, dhe nga ana tjetër, do të çojë në një kohë më të keqe përgjigjeje, siç e kemi parë tashmë.

Si rezultat, u zhvillua një zgjidhje me klasa prioritare. Proceseve të klasës me përparësinë më të madhe iu dha një kuantike, proceseve të klasës tjetër - dy kuantike, tjetra - katër kuantike, e kështu me radhë. më poshtë.

Si shembull, merrni parasysh një proces që duhet të kryejë llogaritjet për 100 kuanta. Së pari, do t'i jepet një kuant, pastaj do të pompohet në disk. Herën tjetër ai merr 2 kuanta, pastaj 4, 8.16, 32, 64, megjithëse nga 64 ai përdor vetëm 37. Në këtë rast, do të nevojiten vetëm 7 pompa (përfshirë ngarkesën fillestare) në vend të 100, që do të nevojiteshin. nëse përdorni një algoritëm të rrumbullakët. Përveç kësaj, ndërsa zhyteni në radhën prioritare, procesi do të funksionojë më rrallë, duke e lënë procesorin në procese më të shkurtra.

“Procesi më i shkurtër është ai i radhës”

Meqenëse algoritmi Shortest Task First minimizon kohën mesatare të kthimit në sistemet e përpunimit të grupeve, dikush do të donte ta përdorte atë edhe në sistemet interaktive. Në një farë mase kjo është e mundur. Proceset ndërvepruese më së shpeshti ndjekin modelin “prit komandën, ekzekuto komandën, prit komandën, ekzekuto komandën...” Duke e konsideruar ekzekutimin e secilës komandë si detyrë më vete, mund të minimizosh kohën mesatare të përgjithshme të përgjigjes duke ekzekutuar detyrën më të shkurtër së pari. Problemi i vetëm është

është të kuptojmë se cili nga proceset e pritjes është më i shkurtër.

Një metodë mbështetet në vlerësimin e kohëzgjatjes së një procesi bazuar në sjelljen e mëparshme të procesit. Kjo fillon procesin me kohën më të shkurtër të parashikuar. Supozojmë se koha e parashikuar e ekzekutimit të komandës është T 0 dhe koha e parashikuar e ekzekutimit të ardhshëm është T 1 . Ju mund të përmirësoni vlerësimin e kohës duke marrë shumën e ponderuar të këtyre kohëve në T 0 + (1 - a)T 1. Duke zgjedhur një vlerë të përshtatshme të a, ne mund ta bëjmë algoritmin e vlerësimit të harrojë shpejt ekzekutimet e mëparshme ose, anasjelltas, t'i mbajë mend ato për një kohë të gjatë. Duke marrë a = 1/2, marrim një seri vlerësimesh:

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.

Pas tre vrapimeve, pesha e T 0 në vlerësim do të ulet në 1/8.

Metoda e vlerësimit të vlerës së ardhshme në një seri përmes mesatares së ponderuar të vlerës së mëparshme dhe vlerësimit të mëparshëm shpesh quhet plakje. Kjo metodë është e zbatueshme në shumë situata ku është e nevojshme të vlerësohen nga vlerat e mëparshme. Mënyra më e lehtë për të zbatuar plakjen është kur a = 1/2. Në çdo hap, gjithçka që ju nevojitet është

shtoni një vlerë të re në vlerësimin aktual dhe ndani shumën në gjysmë (duke u zhvendosur djathtas me 1 bit).

Planifikimi i garantuar.

Një qasje thelbësisht e ndryshme ndaj planifikimit është t'u japësh premtime reale përdoruesve dhe më pas t'i përmbushësh ato. Këtu është një premtim që është i lehtë për t'u thënë dhe i lehtë për t'u mbajtur: nëse n përdorues ndajnë CPU-në me ju, do t'ju jepet 1/n e fuqisë së CPU-së.

Dhe në një sistem me një përdorues dhe n procesorë në punë, secili merr 1/n cikle procesori.

Për të përmbushur këtë premtim, sistemi duhet të mbajë gjurmët e alokimit të CPU-së ndërmjet proceseve që nga momenti i krijimit të secilit proces. Sistemi më pas llogarit sasinë e burimeve të CPU-së që i takon procesit, si p.sh. koha që nga krijimi, pjesëtuar me n. Tani mund të llogarisim raportin e kohës së dhënë procesit me kohën në të cilën ai ka të drejtë. Vlera rezultuese prej 0.5 do të thotë se procesit iu nda vetëm gjysma e asaj që duhej, dhe 2.0 do të thotë se procesi mori dy herë më shumë se sa ishte menduar. Pastaj fillon procesi me raportin më të ulët deri në

nuk do të bëhet më i madh se ai i fqinjit më të afërt.

planifikimi i lotarisë.

Algoritmi bazohet në shpërndarjen e biletave të lotarisë në procese për qasje në burime të ndryshme, duke përfshirë procesorin. Kur planifikuesi duhet të marrë një vendim, një biletë lotarie zgjidhet rastësisht dhe pronari i saj ka akses në burim. Për sa i përket aksesit të CPU-së, "llotaria" mund të ndodhë 50 herë në sekondë dhe fituesi merr 20 ms kohë CPU.

Proceseve më të rëndësishme mund t'u jepen bileta shtesë për të rritur mundësinë për të fituar. Nëse ka vetëm 100 bileta dhe 20 prej tyre mbahen nga një proces, atëherë ai do të marrë 20% të kohës së procesorit. Ndryshe nga planifikimi me prioritet, ku është shumë e vështirë të vlerësohet se çfarë do të thotë, le të themi, prioriteti 40, gjithçka është e qartë në caktimin e lotarisë. Çdo proces do të marrë një përqindje burimesh afërsisht të barabartë me përqindjen e biletave që ka.

Planifikimi i lotarisë ka disa karakteristika interesante. Për shembull, nëse një proces merr disa bileta gjatë krijimit, atëherë në shortin e ardhshëm shanset e tij për të fituar janë proporcionale me numrin e biletave.

Proceset e bashkëpunimit mund të shkëmbejnë bileta sipas nevojës. Pra, nëse një proces klienti dërgon një mesazh në një proces serveri dhe më pas bllokon, ai mund t'i kalojë të gjitha biletat e tij në procesin e serverit për të rritur mundësinë e fillimit të serverit. Kur procesi i serverit përfundon, ai mund t'i kthejë të gjitha biletat.

Planifikimi i drejtë.

Deri më tani, ne kemi supozuar se çdo proces menaxhohet, pavarësisht se kush është pronari i tij. Prandaj, nëse përdoruesi 1 krijon 9 procese dhe përdoruesi 2 krijon 1 proces, atëherë duke përdorur round-robin ose në rastin e prioriteteve të barabarta, përdoruesi 1 do të marrë 90% të procesorit, dhe përdoruesi 2 vetëm 10.

Për të shmangur situata të tilla, disa sisteme i kushtojnë vëmendje pronarit të procesit përpara se të planifikojnë. Në një model të tillë, çdo përdorues merr një pjesë të procesorit dhe planifikuesi zgjedh procesin sipas këtij fakti. Nëse në shembullin tonë secili prej përdoruesve kishte

premtuar 50% të procesorit, ata do të marrin 50% të procesorit, pavarësisht nga numri i proceseve.

Planifikimi në sisteme në kohë reale.

Koha luan një rol të rëndësishëm në sistemet në kohë reale. Më shpesh, një ose më shumë pajisje fizike të jashtme gjenerojnë sinjale hyrëse dhe kompjuteri duhet t'u përgjigjet në mënyrë adekuate atyre brenda një periudhe të caktuar kohore.

Sistemet në kohë reale ndahen në sisteme të vështira në kohë reale , që do të thotë se ka afate të rrepta për çdo detyrë (ato duhet të respektohen), dhe sisteme fleksibël në kohë reale , në të cilat shkeljet e orarit janë të padëshirueshme, por të pranueshme. Në të dyja rastet, programi ndahet në disa procese, secili prej të cilave është i parashikueshëm. Këto procese janë më shpesh të shkurtra dhe përfundojnë punën e tyre brenda një sekonde. Kur shfaqet një sinjal i jashtëm, është planifikuesi ai që duhet të zbatojë orarin.

Ngjarjet e jashtme të cilave sistemi duhet t'u përgjigjet mund të ndahen në periodike(ndodhin në intervale të rregullta) dhe jo periodike(që lind në mënyrë të paparashikueshme). Mund të ketë rrjedha të shumta periodike të ngjarjeve që sistemi duhet të përpunojë. Në varësi të kohës që duhet për të përpunuar çdo ngjarje, mund të mos jetë e mundur që sistemi të përpunojë të gjitha ngjarjet në kohën e duhur.


Informacione të ngjashme.


(koha nga puna aktivizohet derisa të përfundojë në rast aktiviteti me ndërprerje, ose derisa sistemi të përgjigjet dhe të dalë duart e para të përdoruesit në rast aktiviteti interaktiv); ose maksimizimi drejtësisë(një sasi e barabartë e kohës së CPU-së për çdo proces, ose në përgjithësi pikat korresponduese në kohë sipas prioritetit dhe ngarkesës së secilit proces). Në praktikë, këto qëllime shpesh bien ndesh (për shembull, xhiroja kundrejt vonesës), kështu që planifikuesi do të bëjë një kompromis të duhur. Preferenca matet me ndonjë nga çështjet e përmendura më sipër, në varësi të nevojave dhe objektivave të përdoruesit.

OS/360 dhe pasuesit

AIX

Në versionin AIX 4, ekzistojnë tre vlera të mundshme për politikën e planifikimit të fillesave:

  • Së pari, fillimi: Pasi të planifikohet një bashkëbisedim me këtë politikë, ai përfundon deri në përfundimin, nëse nuk bllokohet, ai jep vullnetarisht kontrollin e procesorit ose filli me prioritet më të lartë dërgohet. Vetëm fijet me përparësi fikse mund të kenë një politikë planifikimi FIFO.
  • Round Robin: Kjo është e ngjashme me skemën e planifikuesit AIX Version 3 të rrumbullakët bazuar në feta kohore 10 ms. Kur një thread PP ka kontroll në fund të hapësirës kohore, ai lëviz në fund të radhës së thread-eve me të njëjtin prioritet. Vetëm temat me prioritet fiks mund të kenë një politikë planifikimi Round Robin.
  • TË TJERA: Kjo politikë është përcaktuar nga POSIX1003.4a në zbatim. Në versionin 4 të AIX, kjo politikë përkufizohet si ekuivalente me RR, me përjashtim të faktit që zbatohet për fijet me përparësi jo fikse. Rillogaritja e vlerës së prioritetit të një thread në çdo ndërprerje do të thotë që një thread mund të humbasë kontrollin sepse vlera e tij e përparësisë është rritur më e lartë se një thread tjetër. Kjo është sjellja e AIX Version 3.

Thread-et janë kryesisht me interes për aplikacionet që aktualisht përbëhen nga procese të shumta asinkrone. Këto aplikacione mund të imponojnë një ngarkesë të lehtë në sistem nëse konvertohen në një strukturë me shumë fije.

AIX 5 zbaton politikat e mëposhtme të planifikimit: FIFO, raundi i rrumbullakët dhe panair i rrumbullakët. Politika FIFO përbëhet nga tre zbatime të ndryshme: FIFO, FIFO2 dhe FIFO3. Politika e rrumbullakëta të panairit quhet SCHED_RR në AIX dhe panairet e rrumbullakëta quhet SCHED_OTHER.

linux

Linux 2.4

Brain Fuck Scheduler (BFS), i krijuar gjithashtu nga Kolivas, është një alternativë ndaj CFS.

FreeBSD

FreeBSD përdor një radhë reagimesh me shumë nivele me prioritete që variojnë nga 0-255. 0-63 janë të rezervuara për ndërprerjet, 64-127 për gjysmën e sipërme të kernelit, 128-159 për thread-et e përdoruesve në kohë reale, 160-223 për thread-et e përdoruesit me ndarje në kohë dhe 224-255 për thread-et e përdoruesit bosh. Gjithashtu, si Linux, ai përdor një cilësim të radhës aktive, por gjithashtu ka një radhë të papunë.

Shpesh, zhvilluesit, veçanërisht ata të papërvojë, humbasin kur u kërkohet të caktojnë afate për detyrat. Megjithatë, aftësia për të planifikuar është një aftësi shumë e dobishme dhe e nevojshme që ndihmon jo vetëm në punë, por edhe në jetë. Ne vendosëm të mësojmë nga ekspertët se si të mësojmë se si të planifikojmë dhe dorëzojmë siç duhet projektet në kohë.

Përfundime të shkurtra mund të gjenden në fund të artikullit.

Një zhvillues zakonisht duhet të marrë parasysh disa parametra njëherësh në mënyrë që të vlerësojë kohën për të përfunduar një detyrë:

  1. Përvojë në kryerjen e detyrave të tilla dhe punës me këtë grumbull teknologjie. Nëse duhet të bëni diçka thelbësisht të re, duhet të jeni veçanërisht të kujdesshëm me vlerësimin.
  2. Eksperiencë me këtë klient. Duke e njohur klientin, mund të parashikoni përafërsisht disa kërkesa shtesë dhe sasinë e modifikimeve.
  3. Cilësia e kodit për të punuar. Ky është faktori më me ndikim, për shkak të të cilit gjithçka mund të zvarritet dhe në përgjithësi të mos shkojë sipas planit. Nëse ka teste në projekt, vetëm varësi të qarta kudo, dhe funksionaliteti është i izoluar mirë, gjithçka nuk është aq e frikshme. Është shumë më keq nëse keni të bëni me kod të trashëguar pa teste, ose kod që është i ngopur me varësi të nënkuptuara. Gjëra të tilla si "funksionet magjike" (kur është e vështirë të shikosh grupin përfundimtar të thirrjeve nga kodi) dhe dyfishimi i kodit (kur disa seksione të pavarura duhet të modifikohen për të ndryshuar disa funksionalitete) gjithashtu mund t'i komplikojnë gjërat.

Për të mësuar se si të vlerësoni në mënyrë adekuate kushtet e punës, duhet të praktikoni vazhdimisht. Në fillim të punës sime, bëra pikërisht këtë: vlerësova kohën për të përfunduar çdo detyrë hyrëse, edhe nëse askush nuk e kërkonte atë, dhe më pas shikoja se sa saktë arrita të futesha në vlerësimin tim. Në procesin e përfundimit të detyrës, ai vuri në dukje se cilat veprime kërkojnë më shumë kohë. Nëse diçka e rriti shumë kohën, e kujtoja këtë moment dhe e mora parasysh në vlerësimet e radhës.

Për një vlerësim objektiv të kohës së nevojshme thjesht për punë, duhet t'i shtohet një diferencë e vogël për të mbuluar situatat e forcës madhore. Shpesh vlerësohet si përqindje e përfundimit të detyrës kryesore, por është e ndryshme për të gjithë: dikush shton 20% të kohës, dikush - 10%, dhe dikush - 50%.

Është gjithashtu e dobishme të analizohen arsyet e vonesave pas çdo shkeljeje serioze të afatit. Nëse nuk keni kualifikime të mjaftueshme, duhet të punoni në pikat tuaja të dobëta. Nëse problemi ishte organizativ - për të kuptuar se çfarë e pengonte punën normale.

Përmirëso Degrade

, Drejtor Teknik i Qendrës për Teknologji dhe Zgjidhje Inovative, Jet Infosystems

Një numër i madh artikujsh i kushtohen metodave për vlerësimin e kompleksitetit të një projekti, duke përfshirë kohëzgjatjen e punës dhe detyrat individuale. Megjithatë, ky është ende shkaku i konflikteve si brenda ekipit të projektit ashtu edhe kur komunikoni me klientin.

Asistenti kryesor në vlerësim është përvoja. Mundohuni të krahasoni disi detyrën e re me ato të kryera tashmë. Nëse jeni duke bërë një raport, shikoni sa kohë ka marrë një raport i ngjashëm në të kaluarën. Nëse jeni duke bërë diçka të re, përpiquni ta zbërtheni në pjesë të njohura dhe t'i vlerësoni ato. Nëse detyra është krejtësisht e re, ndani kohë për të studiuar (edhe më mirë - koordinojeni këtë kohë me atë që vendos detyrën).

Kushtojini vëmendje hapave shoqërues - nëse keni nevojë të zhvilloni një shërbim, atëherë testimi i njësisë gjithashtu duhet të përfshihet në vlerësim (dhe ndoshta jo vetëm një njësi), përgatitja e të dhënave të testit do të marrë pak kohë. Ju duhet të konsideroni integrimin me shërbime të tjera, etj. Lini kohë për të rregulluar defektet që gjeni vetë ose me ndihmën e testuesve. Mund të humbet shumë kohë në detyra "të padukshme". Për shembull, ekziston një vlerësim për zhvillim dhe ka një vlerësim për testim, por transferimi i një objekti për testim mund të shoqërohet me vendosjen e stendave. Prandaj, është e rëndësishme të imagjinoni mendërisht të gjithë procesin në mënyrë që të mos humbisni asgjë.

Pas përcaktimit të intensitetit të punës, është e nevojshme të përfshini punë të reja në kalendar, duke mos harruar detyrat dhe aktivitetet e tjera që shkojnë paralelisht.

Dhe mos harroni se planet janë të pavlera, por planifikimi është i paçmuar. Mësoni të korrigjoni planet në kohë, mbani të informuar të gjithë palët e interesuara dhe përshkallëzoni në kohën e duhur, në mënyrë që afatet e humbura të mos jenë surprizë për askënd.

Përmirëso Degrade

Një pyetje që nuk mund të përgjigjet në një formë të shkurtër. Nëse do të ishte e thjeshtë, atëherë problemi i shkeljes së afateve nuk do të ekzistonte.

Për t'i bërë afatet e zhvillimit më të parashikueshëm, së pari duhet të kuptoni arsyet pse programuesit vazhdimisht bëjnë gabime.

Arsyeja e parë është se shumica e detyrave që bën një programues janë unike në një shkallë ose në një tjetër. Kjo do të thotë, ka shumë të ngjarë, programuesi do të bëjë një detyrë të tillë për herë të parë. Ai nuk e ka idenë e mirë se sa do të zgjasë kjo punë. Nëse ky është një programues me përvojë solide dhe duhet të kryejë një detyrë të ngjashme, vlerësimi i tij do të jetë më afër realitetit.

Le të përdorim një analogji të thjeshtë - nëse nuk keni hapur kurrë një hendek, nuk mund të thoni saktësisht se sa kohë do t'ju duhet për të gërmuar një kanal 30 cm të gjerë, 60 cm të thellë dhe 20 metra të gjatë. Nëse keni gërmuar më parë, koha juaj e vlerësuar e funksionimit do të jetë shumë më afër kohës aktuale të ekzekutimit.

Arsyeja e dytë është se programuesit janë optimistë nga natyra. Kjo do të thotë, duke marrë parasysh detyrën, duke zgjedhur një opsion zbatimi për të, duke dhënë një vlerësim të përmirësimeve, zhvilluesi pret që gjithçka të funksionojë ashtu siç pret. Dhe ai nuk mendon për problemet që do të takojë rrugës. Në shumicën e rasteve, ai nuk mund t'i parashikojë ato. Për shembull, ekziston një detyrë që një programues mund ta zbatojë duke përdorur një bibliotekë softuerësh me burim të hapur të palëve të treta. Në fazën e vlerësimit, ai e gjeti atë në internet, lexoi përshkrimin e tij - i përshtatet atij. Madje ai e vlerësoi saktë sasinë e punës së tij për të përfshirë përdorimin e kësaj biblioteke. Por ai nuk e kishte parashikuar fare se do të ndodhte një gabim në këtë bibliotekë në mjedisin e produktit të tij softuer.

Zhvilluesi do të duhet jo vetëm të ndërtojë përdorimin e bibliotekës në kodin e tyre, por edhe të rregullojë gabimin në vetë bibliotekën. Dhe shpesh zhvilluesi nuk jep kohë për të korrigjuar gabimet e tyre. Statistikat tregojnë se testimi dhe rregullimi i gabimeve mund të marrë deri në 50% të kohës së shpenzuar për kodim. Shifra varet nga kualifikimi i zhvilluesit, mjedisi, praktikat e zhvillimit të përdorura (për shembull, testet e njësisë e zvogëlojnë ndjeshëm këtë kohë dhe kohëzgjatja totale / intensiteti i punës i detyrës së zhvillimit është më i vogël).

Nëse i kthehemi analogjisë me fadromin, atëherë fadromi nuk e priste që do t'i thyhej lopata dhe do t'i duhej të kalonte dy orë duke kërkuar një prerje të re.

Arsyeja e tretë janë kërkesat e paparashikuara. Në asnjë fushë tjetër të prodhimit të materialeve, me të cilën klientët e zhvillimit të softuerit janë aq të dashur të krahasohen, nuk ka një rrjedhë të tillë kërkesash të reja. Imagjinoni kalimin e një fadromi që gërmoi 19 metra nga 20 dhe dëgjoi nga klienti dëshirën që hendeku të mos shkonte në vijë të drejtë, por në një gjarpër me një gjatësi supe 97 centimetra.

Si të përballeni me gjithë këtë dhe si të jetoni në kushte të tilla pasigurie? Reduktimi i pasigurisë dhe sigurimi i vonesës së kohës.

Mënyra më e lehtë për t'i afruar pritshmëritë tuaja realitetit është të përdorni rregullin e gjallë "Pi". Pasi të keni marrë një vlerësim nga zhvilluesi (për sa i përket kohës ose intensitetit të punës), është e nevojshme ta shumëzoni atë me numrin Pi (= 3.14159). Sa më me përvojë zhvilluesi të bëjë vlerësimin, aq më i ulët mund të jetë ky koeficient.

Është e detyrueshme të praktikohet zbërthimi i detyrës origjinale në detyra të vogla me madhësi jo më të madhe se 4 orë. Sa më i detajuar të jetë dekompozimi, aq më të larta janë shanset që vlerësimi të jetë afër kompleksitetit/kohëzgjatjes aktuale.
Nëse i kthehemi ndarjes së rezervës - kjo kohë duhet të ndahet në fund të projektit. Është praktikë e keqe të bësh një rezervë dhe ta përfshish atë për çdo detyrë. Ligji i Parkinsonit "Puna mbush gjithë kohën e caktuar për të" respektohet rreptësisht.

Nëse përmbledhim një "total" të shkurtër, atëherë për të përcaktuar saktë kohën e punës, veprimet e mëposhtme do të jenë të dobishme:

  • kryeni zbërthimin e punës, ndajeni detyrën në hapa sa më të detajuar;
  • të kryejë prototipimin;
  • kufizojnë zbatimin e kërkesave të paparashikuara më parë. Kjo nuk do të thotë se ato nuk duhen bërë, por këshillohet që të theksohen këto kërkesa dhe të bihet dakord me klientin për ndryshimet në kohën dhe koston për zbatimin e tyre;
  • merrni parasysh kohën për të stabilizuar zgjidhjen;
  • përdorni praktika të përmirësimit të cilësisë së kodit, të tilla si shkrimi i testeve të njësive;
  • bëni një rezervë të përgjithshme.

Epo, mbani mend se nëse fakti e tejkalon vlerësimin tuaj me 30%, atëherë ky është një rezultat shumë i mirë.

Përmirëso Degrade

Për vlerësimin më të saktë, ju duhet përvojë në zhvillim real, dhe është në zonë specifike. Por ka edhe rregulla të përgjithshme që do të ndihmojnë për të shmangur gabimet në planifikim dhe problemet gjatë dorëzimit të punës tek klienti. Unë do t'i përshkruaj këto rregulla në këtë mënyrë.

Së pari ju duhet të kuptoni problemin. Kjo duket të jetë e qartë dhe nuk lidhet drejtpërdrejt me kohën, por në fakt është një pikë kyçe. Edhe në projektet serioze të mëdha, një nga faktorët kryesorë të dështimit dhe vonesës është problemi në përcaktimin e kërkesave. Për zhvilluesit fillestarë, për fat të keq, ky është një problem serioz - ata nuk i lexojnë specifikimet teknike ose lexojnë dhe kuptojnë në mënyrë shumë selektive (nga dhjetë pika, pesë u kujtuan dhe plotësuan, dhe pjesa tjetër u kujtua tashmë kur paraqiti rezultatin) . Është e qartë se një detyrë e keqkuptuar nuk mund të zbatohet saktë në kohë.

Më tej - për të vlerësuar kohën për zhvillim. E veçanta e programimit është se nuk ka detyra absolutisht identike. Kjo e bën punën tonë më interesante, por vlerësimi i afateve është më i vështirë. Dekompozimi funksionon mirë këtu, d.m.th. ndarja e një detyre komplekse unike në një sekuencë nën-detyrash të vogla të njohura. Dhe secila prej tyre tashmë mund të vlerësohet në orë mjaftueshëm. Le të përmbledhim vlerësimet e nëndetyrave - dhe të marrim vlerësimin e të gjithë detyrës.

Si rregull, një vlerësim i tillë përfshin vetëm kostot e vetë kodimit. Kjo është sigurisht pjesa më e rëndësishme e zhvillimit, por larg nga e vetmja (dhe shpesh jo më voluminozja). Përfundimi i plotë i detyrës përfshin gjithashtu leximin dhe sqarimin e TOR-së, takimin me kolegët ose klientin, korrigjimin dhe testimin, përpilimin e dokumentacionit, dërgimin e rezultatit (demonstrimi tek klienti dhe ndryshimet e mundshme sipas komenteve të tij). Sa kohë do t'ju duhet për të kryer këto veprime, vetëm përvoja do ta tregojë. Në fillim, është e rëndësishme, të paktën, të mos harroni t'i merrni parasysh ato në llogaritjet dhe mund të kërkoni nga kolegët më me përvojë një vlerësim të përafërt të kohës.

Pra, ne marrim një vlerësim të kostos së kodimit, shtojmë një vlerësim të kostos së punës shtesë - dhe marrim vlerësimin e dëshiruar të kohës për të përfunduar detyrën. Por kjo nuk është e gjitha! Ju duhet të tregoni datën e planifikuar të përfundimit të detyrës. Do të ishte gabim thjesht të merresh dhe të ndash kostot e punës (në orë) me 8 orë dhe t'i shtosh datës aktuale. Në praktikën reale, një zhvillues nuk punon kurrë (mirë, pothuajse kurrë) 100% të kohës në një detyrë specifike. Ju patjetër do të kaloni kohë në punë të tjera - të rëndësishme, por jo të lidhura drejtpërdrejt me atë kryesore. Për shembull, ndihma e kolegëve, trajnimi, raportimi, etj. Zakonisht, gjatë planifikimit, konsiderohet se 60-70% e kohës së punës shkon drejtpërdrejt për të punuar në projektin aktual. Për më tepër, duhet të merrni parasysh vonesat e mundshme që do t'ju pengojnë të punoni vazhdimisht në detyrë. Për shembull, nëse për këtë ju duhet të ndërveproni me njerëz të tjerë (kolegë, klientë), atëherë merrni parasysh punësimin e tyre, orarin e punës, etj.

Këtu janë rregullat themelore që, për mendimin tim, do të ndihmojnë zhvilluesin të shmangë problemet në vlerësimin dhe përmbushjen e afateve. Për më tepër, çelësi është akumulimi i përvojës vetjake si në zbatimin e detyrave ashtu edhe në vlerësim. Për shembull, pas përfundimit të një detyre, është shumë e dobishme të krahasoni vlerësimin tuaj fillestar me afatin kohor aktual dhe të nxirrni përfundime për të ardhmen. Dhe, natyrisht, ia vlen të studiohet përvoja e dikujt tjetër. Unë do të rekomandoja librin e S. McConnell-it "Sa kushton një projekt softuerësh" dhe "Leksionet mbi menaxhimin e projekteve softuerike" të S. Arkhipenkov-it për këtë temë.

Përmirëso Degrade

Gjatë vlerësimit dhe planifikimit, është e nevojshme që:

  1. Zbërthejeni detyrën në pjesë të vogla funksionale në mënyrë të tillë që të ketë një kuptim të qartë se sa kohë do të zgjasë zhvillimi i secilës pjesë të tillë.
  2. Paralelisht me dekompozimin, do të ketë patjetër pyetje shtesë në lidhje me funksionalitetin që nuk u përshkrua në deklaratën e problemit. Është e nevojshme të merren përgjigje për pyetje të tilla, pasi kjo lidhet drejtpërdrejt me fushën e punës dhe, rrjedhimisht, kohën.
  3. Shto një përqindje të caktuar të rreziqeve në vlerësimin përfundimtar. Kjo përcaktohet nga përvoja. Ju mund të filloni, për shembull, me rreziqe 10-15%.
  4. Kuptoni sa orë në ditë një programues është i gatshëm t'i kushtojë për të përfunduar një detyrë.
  5. Ne e ndajmë vlerësimin përfundimtar me numrin e orëve që ndajmë në ditë dhe marrim numrin e ditëve të nevojshme për zbatim.
  6. Ne fokusohemi në kalendarin dhe numrin e kërkuar të ditëve për të përfunduar. Ne marrim parasysh fundjavat dhe ditët e tjera kur programuesi nuk do të jetë në gjendje të punojë me detyrën, si dhe datën e fillimit të punës (zhvilluesi nuk është gjithmonë i gatshëm të marrë detyrën në punë në të njëjtën ditë). Kështu, marrim datat e fillimit dhe mbarimit të punës.

Përmirëso Degrade

Në kompaninë tonë, planifikimi i detyrave kalon gjithmonë nëpër disa faza. Nga ana e biznesit, ne formulojmë 5-6 synime strategjike për vitin. Këto janë detyra të nivelit të lartë, për shembull, për të rritur çdo parametër me kaq shumë përqind. Më tej, departamente të ndryshme të kompanisë formojnë detyra biznesi për të gjitha ekipet e IT. Afatet për këto detyra marrin një vlerësim fillestar të përafërt, i cili shpesh formohet nga të gjithë anëtarët e ekipit - menaxheri, analisti, zhvilluesi dhe testuesi. Pas marrjes së këtij vlerësimi, biznesi i jep prioritet detyrave, duke marrë parasysh qëllimet strategjike të kompanisë. Qëllimet strategjike ndërsektoriale ndihmojnë për këtë, me to bëhet e qartë se ne të gjithë po punojmë për ndonjë kauzë të përbashkët, nuk ekziston një situatë e tillë kur dikush tërhiqet vetëm në drejtimin e tyre. Ne mbledhim sprinte nga detyrat e vlerësuara saktësisht sipas afateve. Për disa ekipe ato janë tremujore, për disa - mujore. Disa detyra, sipas vlerësimit paraprak, duke rënë në sprintin e radhës, ekipet japin një vlerësim të saktë. Detyrat e mëdha ndahen në ato të nivelit më të ulët, për secilën prej të cilave një interpretues specifik është përgjegjës, është ai që jep një vlerësim të saktë.

Në këtë fazë, është e rëndësishme të mos harroni të shtoni një diferencë kohe për të rregulluar defektet, sepse vetëm ata që nuk bëjnë asgjë nuk bëjnë gabime. Kjo kuptohet mirë nga pronari i produktit dhe klientët e biznesit. Në të njëjtën kohë, diferenca e kërkuar e kohës duhet të jetë e përshtatshme: askush nuk do ta kuptojë një zhvillues që vendos një detyrë të thjeshtë për një afat shumë të gjatë, atij do t'i kërkohet të justifikojë vendimin. Gjëja më e vështirë është t'i shpjegosh biznesit pse duhet kohë për të rifabrikuar. Ne i jemi mirënjohës kompanisë sonë për faktin që kemi sukses periodikisht, sepse në fund, rifaktorimi çon në lehtësimin e infrastrukturës dhe rregullimin e gjërave në kod, gjë që rrit stabilitetin e sistemit dhe mund të përshpejtojë ndjeshëm zhvillimin e të rejave. funksione.

Ndonjëherë ndodhin gabime në vlerësim. Për mendimin tim, është e pamundur që departamenti i zhvillimit në kompanitë e mëdha me një infrastrukturë të zhvilluar ta shmangë plotësisht këtë. Në këtë rast, është e rëndësishme që zhvilluesi të informojë menaxherin e tij për atë që po ndodh me kohë, dhe ai, nga ana tjetër, ka kohë të paralajmërojë biznesin dhe të "riprodhojë" diçka në planet e përgjithshme të kompanisë. Në këtë mënyrë, të punosh është shumë më korrekte sesa të përpiqesh furishëm të bësh në 3 ditë atë që kërkon 5, dhe më pas të mbytesh në një numër të madh gabimesh që lindën për shkak të një nxitimi të tillë.

Përmirëso Degrade

Përgjigja e saktë për të dy pjesët e pyetjes [si të mësoni se si të planifikoni dhe dorëzoni siç duhet një projekt në kohë - E kuqe.] - përvojë. Nuk ka mënyra të tjera për të "njohur Zenin". Sipas teorisë së vendimeve, çdo përfundim i saktë mund të ndërtohet vetëm në bazë të një analize të një numri të dhënash tashmë të disponueshme. Dhe sa më shumë këto të dhëna, aq më i saktë është parashikimi dhe vlerësimi përfundimtar.

Sipas fjalëve të Herbert Shaw: "Përvoja është një shkollë në të cilën një njeri mëson se çfarë budallai ishte më parë." Një përfundim mjaft i thjeshtë rrjedh nga kjo: nëse programuesi tashmë ka përvojë që lidhet me detyrën, ai mund të mbështetet në të, nëse jo, në përvojën e "kolegëve në dyqan".

Më pas, duhet të kuptoni se planifikimi i drejtpërdrejtë është një detyrë që njerëzit e bëjnë shumë, shumë keq, veçanërisht në zhvillim. Kur vlerësohen datat e duhura, konsiderohet praktikë e mirë futja e "faktorëve të rregullimit" në vlerësimin origjinal. Kjo metrikë mund të variojë nga 1.5 në 3, në varësi të përvojës së zhvilluesit dhe tërësisë së shkallëve të pasigurisë së detyrave të zgjidhura brenda projektit.

Përmirëso Degrade

Gjatë përcaktimit të kohës, është e rëndësishme të merren parasysh shumë faktorë.

Për shembull, përvojë pune. Sa qartë e imagjinoni qëllimin e punës përpara? Keni bërë diçka të ngjashme më parë? Është e qartë se sa më shumë përvojë, aq më shpejt do të kryhet puna.

Një detyrë teknike e shkruar mirë luan një rol të rëndësishëm në përcaktimin e kohës. Kjo është shumë e vështirë në zonën tonë. Shpesh vetë klienti nuk e di se çfarë dëshiron, ndaj ju këshilloj të kaloni një ose dy ditë shtesë, por të merrni një ide të qartë nga klienti për rezultatin e dëshiruar. Është e rëndësishme që ky përfaqësim të jetë i ndërsjellë. Dhe vetëm pas kësaj mund të filloni të negocioni shumën dhe kushtet.

Gjithashtu, merrni gjithmonë rreziqe. Për fillestarët, unë rekomandoj shumëzimin e afateve të vlerësuara me dy. Në fund të fundit, është më mirë ta dorëzoni projektin përpara afatit dhe të rriteni si specialist në sytë e klientit, në vend që ta dorëzoni më vonë dhe të prishni reputacionin tuaj.

Përmirëso Degrade

Rekomandimi i përgjithshëm është që një zhvillues duhet të mësojë se si të zbërthejë saktë detyrat, të kërkojë gjithmonë kurthe të mundshme, të mbështetet në përvojën e tij dhe të mos harrojë të paralajmërojë klientët dhe kolegët në kohë nëse detyra nuk mund të zgjidhet brenda kornizës kohore të specifikuar.

Ndërtimi i një plani të qartë është shumë më i vështirë sesa përcaktimi i afatit për përfundimin e një detyre të vetme. Në të njëjtën kohë, është e rëndësishme jo vetëm të dorëzoni projektin në kohë, por edhe të siguroheni që sistemi që keni zhvilluar të zgjidhë saktë problemet e biznesit. Këtu, ekipet e TI-së ndihmohen nga metodologji të ndryshme të zhvillimit të softuerit: nga RUP dhe MSF tek SCRUM dhe formate të tjera Agile. Zgjedhja e mjeteve është shumë e gjerë, dhe shumë nga klientët tanë duan të kuptojnë paraprakisht se si do të punojmë me ta në projekt, cilat parime i përmbahemi.

Nga rruga, tema e Agile sot po bëhet e afërt me biznesin, madje edhe në projekte individuale për sektorin publik, pasi parimet e kësaj metodologjie ju lejojnë të zbatoni projekte shumë shpejt, duke menaxhuar pritjet e klientëve në çdo përsëritje. Për shembull, në një ekip Agile praktikisht nuk ka diskutime të zgjatura me klientin. Harrojeni rreth dhjetëra faqe që përshkruajnë detaje teknike të panevojshme, të tilla si shpejtësia me të cilën shfaqet një listë rënëse. Jepini klientit mundësinë për të provuar një version të ndërmjetëm të sistemit, atëherë do të bëhet shumë më e lehtë për ju të kuptoni njëri-tjetrin.

Ekipi i shkathët planifikon gjithçka së bashku dhe përcakton nivelin optimal të punës që do të nevojitet për të zgjidhur një problem të caktuar. Për shembull, një nga teknikat quhet "Planifikimi i Pokerit", ku secili pjesëmarrës jep në mënyrë anonime vlerësimin e tij për kostot e nevojshme të punës për një detyrë specifike. Pas kësaj, ekipi përcakton peshën mesatare të detyrës në pikat e tregimit ose në orë pune dhe shpërndan rastet sipas parimit "kush çfarë pëlqen". Në të njëjtën kohë, çdo ditë ekipi mblidhet për një miting 15-minutësh, kur të gjithë flasin për statusin e detyrave të tyre aktuale në disa minuta, përfshirë raportet e vështirësive që kanë lindur. Ekipi eliminon shpejt problemin e zbuluar, kështu që klienti shikon në fazën tjetër të punës së programuesit sa më shpejt që të jetë e mundur. Zhvilluesit nuk i vonojnë afatet për përfundimin e detyrave për shkak të mosgatishmërisë së tyre për të tërhequr edhe një herë ekipin ose përpjekjeve të kota për ta kuptuar atë vetë, duke vrarë kohën e çmuar. Nga rruga, në mini-statuse të tilla, zhvilluesit kanë dëshirë të provojnë veten nga ana më e mirë, për të treguar se keni një qasje të përgjegjshme ndaj punës. Me të vërtetë motivon dhe vetëdisiplinon.

Gjithçka që është diskutuar në seksionet e mëparshme është fokusuar më shumë në kërkime të mëtejshme mbi problemin e kohës së duhur të procesit dhe shumë më pak në aplikimet praktike. Duke plotësuar këtë boshllëk, ne paraqesim një nga metodat për llogaritjen e kohës së duhur të një procesi bazuar në të dhënat statistikore mbi evoluimin e tij.

Konsideroni një proces njëdimensional gjendja e të cilit karakterizohet nga një ndryshore reale x. Le të supozojmë se vëzhgimet e dinamikës së procesit kryhen në kohën astronomike t, në mënyrë që t = t k dhe x = x k, k =1, ..., n janë momente fikse vëzhgimi dhe vlerat përkatëse të procesit shteteve. Ka shumë metoda të ndryshme matematikore që bëjnë të mundur ndërtimin e kthesave të tilla që ose kalojnë nëpër pikat (t k , Xk) ose u afrohen atyre në "mënyrën më të mirë". Funksionet që rezultojnë x = x(t) krijojnë në mendjet tona përshtypjen se procesi në shqyrtim varet nga lëvizja mekanike e trupave qiellorë dhe, për rrjedhojë, gjendja e tij shprehet në termat e kohës astronomike t. Një përfundim i tillë mund të llogaritet me; nëse nuk do të kishte vështirësi të vazhdueshme në përpjekjen për të parashikuar ecurinë e mëtejshme të procesit. Për një numër të madh procesesh të ndryshme që nuk lidhen drejtpërdrejt me lëvizjet mekanike të trupave qiellorë, parashikimet teorike të marra duke përdorur funksionin x = x(t) jashtë intervalit të vëzhgimit fillojnë të devijojnë ndjeshëm nga të dhënat e mëvonshme eksperimentale. Arsyeja e mospërputhjes midis teorisë dhe eksperimentit zakonisht shpjegohet me një metodë përpunimi të zgjedhur pa sukses, por kjo mund të mos jetë thelbi i çështjes.

Çdo proces me interes për ne zhvillohet në Univers. Ai, natyrisht, "ndjen" ndikimin e lëvizjes së trupave qiellorë. Megjithatë, ky ndikim mund të rezultojë të jetë "i butë", jo përcaktues. Kjo, në veçanti, mund të manifestohet në faktin se në intervale të caktuara të rrjedhës së kohës astronomike, gjendja e procesit mbetet e pandryshuar. Në lidhje me këtë, le të kujtojmë shembullin e dhënë më parë me një dhomë të mbyllur bosh, të izoluar nga bota e jashtme. Do të lejojmë vetëm një të gjallë të fluturojë në dhomë. Brenda pak ditësh, ndryshimet në gjendjen e sistemit "room - fly" do të varen nga lëvizja e mizës, pasi ndryshimet në gjendjen e dhomës nuk mund të priten. Në të njëjtën kohë, është e vështirë të imagjinohet se sjellja e një mize është e lidhur rreptësisht me rrjedhën e kohës astronomike.

Pasi kemi bërë një digresion kaq të gjatë, le të vazhdojmë me përshkrimin e algoritmit për llogaritjen e kohës së vetë procesit.

Në këtë algoritëm, njësia e llogaritjes së maksimumeve lokale zgjidhet si matës natyror i kohës. Përveç kësaj, merren parasysh seksionet e mundshme të gjendjes së palëvizshme të procesit, në të cilat, siç u përmend më herët, ndalon koha e duhur. Meqenëse mund të flasim për identitetin e dy gjendjeve vetëm brenda kufijve të saktësisë së matjes, atëherë në atë që vijon përdoret një numër i caktuar pozitiv e - gabimi i lejueshëm i matjes.

Pra, të dhënat hyrëse për algoritmin janë një numër natyror n, një numër pozitiv 8, vargje (tk) dhe (x k ), k = 1, ..., n. Për lehtësi programimi, algoritmi paraqitet në formën e katër module të ekzekutuara në mënyrë sekuenciale.

Moduli 1, duke përdorur të dhënat n, e, t k), (x k), në rastin e përgjithshëm, formon vargje të reja 7 = (7+ X=(X t) dhe një grup shoqërues mjaft specifik Р = (?), ku 1 = 1, ..., t, dhe t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Moduli 1 përfshin procedurat e mëposhtme:

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

Në p.p. Prezantohen 1, 2 numërues me vlera fillestare specifike:

Në p.p. 3, 4, numëruesit rriten me 1.

Kontrollo gjendjen k^n. Nëse përmbushet, atëherë shkoni në hapin 6, përndryshe shkoni në hapin 11.

Kontrolloni pabarazinë x k --x k = e. Nëse qëndron, atëherë shkoni në hapin 7, përndryshe shkoni në hapin 9.

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

Kjo procedurë do të thotë që nëse vlerat e Xk dhe Xk 1 janë të padallueshme brenda gabimit, atëherë të gjitha kohët duke filluar nga tk zvogëlohen me shumën tki-tk.

p = p. Kthehuni në pikën 4.

Tv = t k; Xv:=x k ; p = p v = v+l., d.m.th. formohen elementet e vargjeve T, X, P dhe caktohet vlera e radhës v.

  • 10. Merrni (t k , ..., t n AND (Xk, - X n) si vargje origjinale të dimensionit n--k 1 + 1 dhe më pas kthehuni në hapin 2.
  • 11. Shtypni m, (T), (X,) dhe (P,), ku i = l, ..., d.m.th. Fund.

Le të shpjegojmë kuptimin e elementeve të grupit shoqërues P. Nga teksti i mëparshëm rezulton se vlera e pk është e barabartë me numrin e atyre elementeve të grupit (xk) që pasojnë menjëherë dhe ndryshojnë nga x pi+ ... +, + me më pak se e. Vini re gjithashtu se pi+ ... +p m = n.

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

  • 27, 30, 32, 33, 34, 35, 36) dhe (x,) = (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , pesë,
  • 5, 4, 3), shih fig. 9, a.

Si rezultat i ekzekutimit të modulit 1, fitohet 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), shih fig. 9, b.

Moduli 2. Të dhënat hyrëse për të janë një numër natyror m, si dhe vargje (7+ (X L ), = 1, ..., m. Ky modul në grup (TJ) zbulon pikat kohore [TM a ], 1 = 1 m (ml

Shembulli 2. Vlerat m, (Tb) dhe (X,] janë huazuar nga shembulli i mëparshëm. Pas ekzekutimit të modulit 2, ml = 3, m2 = 8, (W,) = (3, 8, 17), (T*) = (3, 4, 6, 8, 11, 12, 15, 17), shih gjithashtu Fig. 9b.

Moduli 3 Të dhënat hyrëse ml, m2, (ТМ n ), 1 = 1, ..., ml, (Г*), /2=1, ..., r2.

Ky modul është krijuar për të ndërtuar një grup (t (-r) sipas formulës

Ku është TV 6 [TMP, TMn+i]

Ndryshorja m është koha e duhur e gjeneruar nga ndryshimi në ndryshoren x. Masa e saj natyrore është njësia e llogaritjes së maksimumeve lokale.

Shembulli 3. Të dhënat fillestare për T 2) janë të njëjta me vlerat ml, m2 ITM, dhe në shembullin 2. . Pas llogaritjeve të duhura, marrim N = (0; 0.2; 0.6; 1; 1,33; 1,78; 2).

Moduli 4 Formon daljen e rezultateve duke vendosur një korrespondencë midis vlerave të m dhe elementeve x nga grupi (xk).

Shembulli 4. Bazuar në të dhënat e shembujve 2 dhe 3, rezulton rezultati i mëposhtëm, shih fig. 9, në:

t: 0; 0.2; 0,6; 1; 1,33; 1,44;

x: 6; 3; 2; katër; 3T 0 2;

Kështu, algoritmi i konsideruar bën të mundur zhvillimin e konceptit të kohës së duhur të procesit bazuar në informacionin mbi ndryshimin e gjendjes së procesit të regjistruar në shkallën kohore astronomike. Është mjaft e qartë se mund të përdoren algoritme të tjera të bazuara, për shembull, në llogaritjen e një sekuence minimale lokale ose një sekuence të përzier që përbëhet nga maksimumi dhe minimumi lokal. Gjatë përpunimit të të dhënave eksperimentale, ndoshta duhet të testohen opsione të ndryshme. Nëse, për ndonjë arsye, eksperimentuesi zgjodhi një nga kohët e duhura specifike dhe mori vargje (m4 dhe (xk), atëherë në fazën tjetër ai duhet të përdorë disa metoda matematikore për të përafruar pikat eksperimentale (m*, x) një botë të përafërt vija e procesit x = x(t) Duke e ekstrapoluar këtë vijë përtej kufijve të intervalit fillestar të vëzhgimit, ai mund të japë parashikime për ecurinë e mëtejshme të procesit.

Është interesante të përmendet një eksperiment llogaritës që synon të vlerësojë perspektivat e përdorimit të algoritmit të propozuar. Si material eksperimental u zgjodhën të dhënat për rrjedhjen vjetore të lumit. Vakhsh (Taxhikistan) për 40 vitet e mëparshme. Për të njëjtën periudhë kohore, u mor informacion mbi dinamikën e numrit të Ujkut - indeksi integral më i përdorur i aktivitetit diellor. Kjo e fundit u mor si bazë për zhvillimin e kohës së duhur të procesit të aktivitetit diellor. Në kohën e re, informacioni mbi shpenzimet e lumit u konvertua. Vakhsh dhe më pas, mbi intervalin e vëzhgimit, jepet një varësi teorike e shpejtësisë së rrjedhës së ujit në funksion të kohës së duhur të aktivitetit diellor. Një tipar karakteristik i grafikut që rezulton është sjellja pothuajse periodike e kostove maksimale dhe minimale. Megjithatë, kostot nuk mbeten konstante.

Prezantimi

Qëllimi i seminarit për organizimin e prodhimit është zgjerimi dhe thellimi i njohurive teorike, futja e aftësive të nevojshme për të zgjidhur detyrat më të zakonshme në praktikë për organizimin dhe planifikimin e prodhimit.

Punëtoria përfshin detyra për seksionet kryesore të kursit. Në fillim të çdo teme janë paraqitur udhëzime të shkurtra dhe informacione teorike, detyra tipike me zgjidhje dhe detyra për zgjidhje të pavarur.

Prania në secilën temë të udhëzimeve dhe informacionit të shkurtër teorik ju lejon të përdorni këtë punëtori në mësimin në distancë.


Llogaritja e kohëzgjatjes së ciklit të prodhimit

Kohëzgjatja e ciklit të prodhimit shërben si tregues i efikasitetit të procesit të prodhimit.

Cikli i prodhimit- periudha e qëndrimit të objekteve të punës në procesin e prodhimit nga momenti i lëshimit të lëndëve të para deri në momentin e lëshimit të produktit të përfunduar.

Cikli i prodhimit përbëhet nga Koha e punes, gjatë së cilës shpenzohet puna dhe kohët e pushimit. Pushimet, në varësi të arsyeve që i shkaktuan ato, mund të ndahen në:

1) në natyrore ose teknologjike - ato janë për shkak të natyrës së produktit;

2) organizative(ndërprerjet ndërmjet turneve).

Kohëzgjatja e ciklit të prodhimit përbëhet nga komponentët e mëposhtëm:

Cikli T = t ato + t ha + t tr + t k.k. + t m.o. + t m.c.

ku t ato– koha e operacioneve teknologjike;

mos ha - koha e proceseve natyrore (tharje, ftohje, etj.);

t tr - koha e transportit të objekteve të punës;

t c.c. - koha e kontrollit të cilësisë;

t m.o - koha e pritjes ndëroperative;

t m.c. - koha e kaluar në magazinat intershop;

(t tre t k.k. mund të kombinohet me t m.o).

Llogaritja e kohëzgjatjes së ciklit të prodhimit varet nga lloji i prodhimit. Në prodhimin masiv, kohëzgjatja e ciklit të prodhimit përcaktohet nga koha kur produkti është në rrjedhë, d.m.th.

Cikli T = t në m,

ku t në- lëshimi i goditjes;

M- numri i vendeve të punës.

Nën goditje e shkarkimit duhet të kuptohet si intervali kohor ndërmjet lëshimit të një produkti të prodhuar dhe produktit pas tij.

Cikli i lëshimit përcaktohet nga formula

t në \u003d T eff / V,

ku T ef- fondi efektiv i kohës së punës për periudhën e faturimit (ndërrimi, dita, viti);

AT- vëllimi i prodhimit për të njëjtën periudhë (në njësi natyrore).

Shembull: T cm = 8 orë = 480 minuta; Korsia T = 30 min; → T eff \u003d 480 - - 30 \u003d 450 min.

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

Në prodhimin serik, ku përpunimi kryhet në tufa, kohëzgjatja e ciklit teknologjik përcaktohet jo për një njësi prodhimi, por për të gjithë grupin. Për më tepër, në varësi të metodës së lëshimit të grupit në prodhim, marrim kohë të ndryshme cikli. Ekzistojnë tre mënyra të lëvizjes së produkteve në prodhim: serike, paralele dhe e përzier (seri-paralele).


I. Në konsistente pjesët lëvizëse, çdo operacion i mëpasshëm fillon vetëm pasi të përfundojë ai i mëparshmi. Kohëzgjatja e ciklit me lëvizjen vijuese të pjesëve do të jetë e barabartë me:

ku n - numri i pjesëve të grupit që përpunohet;

t copëi- përqindja e kohës për operacionin;

C i- numri i vendeve të punës i- operacioni;

m– numri i operacioneve të procesit teknologjik.

Jepet një grup produktesh, i përbërë nga 5 copë. Grupi anashkalohet në mënyrë sekuenciale përmes 4 operacioneve; Kohëzgjatja e operacionit të parë ishte 10 minuta, e dyta 20 minuta, e treta 10 minuta dhe e katërt 30 minuta (Fig. 1).

Foto 1

T lak = T e fundit = 5 (10+20+10+30) = 350 min.

Mënyra sekuenciale e lëvizjes së pjesëve ka përparësinë që mban pajisjen të funksionojë pa ndërprerje. Por disavantazhi i tij është se kohëzgjatja e ciklit të prodhimit në këtë rast është më e madhja. Përveç kësaj, në vendet e punës po krijohen rezerva të konsiderueshme të pjesëve, gjë që kërkon hapësirë ​​​​shtesë të prodhimit.

II. Në paralele Në lëvizjen e grupit, pjesët individuale nuk mbahen në vendet e punës, por transferohen pjesë-pjesë në operacionin tjetër menjëherë, pa pritur që të përfundojë përpunimi i të gjithë grupit. Kështu, me lëvizjen paralele të një grupi pjesësh në çdo vend pune, operacione të ndryshme kryhen njëkohësisht në pjesë të ndryshme të së njëjtës grumbull.

Koha e përpunimit të një grupi me lëvizje paralele të produkteve zvogëlohet në mënyrë drastike:

dl .

ku n n- numri i pjesëve në palë e transferimit(partia e transportit), d.m.th. numri i produkteve të transferuara njëkohësisht nga një operacion në tjetrin;

Gjatësia - cikli më i gjatë i funksionimit.

Me nisjen paralele të një grupi produktesh, përpunimi i pjesëve të të gjithë serisë kryhet vazhdimisht vetëm në ato vende pune ku operacionet e gjata pasojnë ato të shkurtra. Në rastet kur operacionet e shkurtra pasojnë ato të gjata, d.m.th. më gjatë (në shembullin tonë, operacioni i tretë), ekzekutimi i këtyre operacioneve kryhet me ndërprerje, d.m.th. pajisje boshe. Këtu, një grup pjesësh nuk mund të përpunohet menjëherë, pa vonesë, pasi operacioni i mëparshëm (i gjatë) nuk e lejon këtë.

Në shembullin tonë: n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; Me= 1.

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

Konsideroni skemën e lëvizjes paralele të pjesëve (Fig. 2):

Figura 2

III. Për të eliminuar ndërprerjet në përpunimin e pjesëve individuale të grupit në të gjitha operacionet, aplikoni paralel-serial ose të përziera një metodë e fillimit në të cilën pjesët (pas përpunimit të tyre) transferohen në operacionin tjetër individualisht, ose në formën e mbetjeve të "transportit" (disa pjesë) në mënyrë të tillë që operacionet të mos ndërpriten në asnjë vend pune. Në metodën e përzier, vazhdimësia e përpunimit merret nga ajo sekuenciale, dhe kalimi i pjesës nga funksionimi në funksionim menjëherë pas përpunimit të saj merret nga ajo paralele. Me një metodë të përzier të nisjes në prodhim, koha e ciklit përcaktohet nga formula

bërthamë .

ku kor. - ciklin më të shkurtër të funksionimit (nga çdo palë operacionesh ngjitur);

m-1 – numri i kombinimeve.

Nëse operacioni i mëpasshëm është më i gjatë se ai i mëparshmi, ose i barabartë me të në kohë, atëherë ky operacion fillon individualisht, menjëherë pasi pjesa e parë të jetë përpunuar në operacionin e mëparshëm. Nëse, përkundrazi, operacioni i mëpasshëm është më i shkurtër se ai i mëparshmi, këtu ndodhin ndërprerje gjatë transferimit të pjesës. Për t'i parandaluar ato, është e nevojshme të grumbullohet një ngarkesë transporti e një vëllimi të tillë që është i mjaftueshëm për të siguruar punën në një operacion të mëvonshëm. Për të gjetur praktikisht këtë pikë në grafik, është e nevojshme të transferoni detajin e fundit të grupit dhe të lini mënjanë kohëzgjatjen e ekzekutimit të tij në të djathtë. Koha e përpunimit të të gjitha pjesëve të tjera të grupit paraqitet në grafikun në të majtë. Fillimi i përpunimit të pjesës së parë tregon momentin kur duhet të transferohet në këtë operacion sasia e mbetur e transportit nga operacioni i mëparshëm.

Nëse operacionet ngjitur janë të njëjta në kohëzgjatje, atëherë vetëm njëri prej tyre pranohet si i shkurtër ose i gjatë (Fig. 3).

Figura 3

Tçifti i fundit \u003d 5 (10 + 20 + 10 + 30) - (5-1) (10 + 10 + 10) \u003d 350-120 \u003d 230 min.

Mënyrat kryesore për të reduktuar kohëzgjatjen e ciklit të prodhimit janë:

1) Reduktimi i intensitetit të punës së produkteve të prodhimit duke përmirësuar aftësinë e prodhimit të strukturës së prodhuar, përdorimin e kompjuterëve dhe futjen e proceseve të avancuara teknologjike.

2) Organizimi racional i proceseve të punës, rregullimi dhe mirëmbajtja e vendeve të punës në bazë të specializimit dhe bashkëpunimit, mekanizimit të gjerë dhe automatizimit të prodhimit.

3) Reduktimi i pushimeve të ndryshme të planifikuara dhe të paplanifikuara në punë bazuar në përdorimin racional të parimeve të organizimit shkencor të procesit të prodhimit.

4) Përshpejtimi i rrjedhës së reaksioneve si rezultat i rritjes së presionit, temperaturave, kalimit në një proces të vazhdueshëm etj.

5) Përmirësimi i proceseve të transportit, magazinimit dhe kontrollit dhe kombinimi i tyre në kohë me procesin e përpunimit dhe montimit.

Zvogëlimi i kohëzgjatjes së ciklit të prodhimit është një nga detyrat serioze të organizimit të prodhimit, sepse. ndikon në qarkullimin e kapitalit qarkullues, duke ulur kostot e punës, duke zvogëluar hapësirën e magazinimit, nevojën për transport etj.

Detyrat

1 Përcaktoni kohëzgjatjen e ciklit të përpunimit të 50 pjesëve me lloje lëvizjesh serike, paralele dhe serike-paralele në procesin e prodhimit. Procesi i përpunimit të pjesëve përbëhet nga pesë operacione, kohëzgjatja e të cilave, përkatësisht, është, min: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5=3. Operacioni i dytë kryhet në dy makina, dhe secila nga të tjerat në një. Madhësia e lotit të transferimit është 4 copë.

2 Përcaktoni kohëzgjatjen e ciklit të përpunimit të 50 pjesëve me lëvizje serike, paralele dhe serike-paralele në procesin e prodhimit. Procesi i përpunimit të pjesëve përbëhet nga katër operacione, kohëzgjatja e të cilave, përkatësisht, është min: t 1 =1; t 2 =4; t 3 =2; t 4=6. Operacioni i katërt kryhet në dy makina, dhe secila nga të tjerat në një. Madhësia e lotit të transferimit është 5 copë.

3 Një grup pjesësh prej 200 copësh përpunohet me lëvizjen e tij paralele-sekuenciale gjatë procesit të prodhimit. Procesi i përpunimit të pjesëve përbëhet nga gjashtë operacione, kohëzgjatja e të cilave, përkatësisht, është min. t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6=20. Operacioni i tretë kryhet në tre makina, i gjashti në dy dhe secili nga operacionet e tjera në një makinë. Përcaktoni se si do të ndryshojë koha e ciklit për përpunimin e një grupi pjesësh nëse versioni paralel-sekuencial i lëvizjes në prodhim zëvendësohet nga një paralel. Madhësia e lotit të transferimit është 20 copë.

4 Një grup pjesësh prej 300 copësh përpunohet me lëvizjen e tij paralele-sekuenciale gjatë procesit të prodhimit. Procesi i përpunimit të pjesëve përbëhet nga shtatë operacione, kohëzgjatja e të cilave, përkatësisht, është min: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7=6. Çdo operacion kryhet në një makinë. Grup transferimi - 30 copë. Si rezultat i teknologjisë së përmirësuar të prodhimit, kohëzgjatja e operacionit të tretë u zvogëlua me 3 minuta, e shtatë - me 2 minuta. Përcaktoni se si ndryshon cikli i përpunimit të një grupi pjesësh.

5 Jepet një grup boshllëqesh, të përbërë nga 5 pjesë. Grupi anashkalohet përmes 4 operacioneve: kohëzgjatja e të parit është 10 minuta, e dyta është 20 minuta, e treta është 10 minuta, e katërta është 30 minuta. Përcaktoni kohëzgjatjen e ciklit me metoda analitike dhe grafike për lëvizjen sekuenciale.

6 Jepet një grup boshllëqesh, të përbërë nga katër pjesë. Festa anashkalohet përmes 4 operacioneve: kohëzgjatja e të parit është 5 minuta, e dyta është 10 minuta, e treta është 5 minuta, e katërta është 15 minuta. Përcaktoni kohëzgjatjen e ciklit me metoda analitike dhe grafike me lëvizje paralele.

7 Jepet një grup boshllëqesh, të përbërë nga 5 pjesë. Grupi anashkalohet përmes 4 operacioneve: kohëzgjatja e të parit është 10 minuta, e dyta është 20 minuta, e treta është 10 minuta, e katërta është 30 minuta. Përcaktoni kohëzgjatjen e ciklit me metoda analitike dhe grafike për lëvizjen serike-paralele.

8 Përcaktoni kohëzgjatjen e ciklit teknologjik për përpunimin e një grupi produktesh nga 180 copë. me variante paralele dhe sekuenciale të lëvizjes së tij. Ndërtoni grafikët e procesit të përpunimit. Madhësia e pjesës së transferimit - 30 copë. Normat e kohës dhe numrit të vendeve të punës në operacione janë si më poshtë.