Experții răspund cum să înveți să stabilești corect termenele limită pentru finalizarea lucrărilor. Planificare (calculatură) - director tehnic de planificare (calculatură) al centrului de tehnologii și soluții inovatoare „Jet Infosystems”

O versiune comutată a algoritmului anterior este cel mai scurt algoritm de execuție rămas. Conform acestui algoritm, planificatorul selectează de fiecare dată procesul cu cel mai scurt timp de execuție rămas. În acest caz, este, de asemenea, necesar să cunoașteți din timp timpul de finalizare a sarcinii. Când sosește o nouă sarcină, timpul total de execuție al acesteia este comparat cu timpul de execuție rămas al sarcinii curente. Dacă timpul de execuție al noii sarcini este mai scurt, procesul curent este suspendat și controlul este transferat noii sarcini. Această schemă vă permite să deserviți rapid cererile scurte.

Planificare pe trei niveluri

Sistemele de procesare în loturi permit programarea pe trei niveluri, așa cum se arată în figură. Pe măsură ce sarcini noi ajung în sistem, acestea sunt mai întâi plasate într-o coadă stocată pe disc. Admisie programator de acces selectează o sarcină și o transferă în sistem. Sarcinile rămase rămân în coadă.

De îndată ce un job intră în sistem, un proces corespunzător va fi creat pentru acesta și poate începe imediat să concureze pentru accesul la procesor. Cu toate acestea, este posibil să existe prea multe procese și să nu încapă toate în memorie, apoi unele dintre ele vor fi paginate pe disc. Al doilea nivel de programare determină ce procese pot fi stocate în memorie și care pot fi stocate pe disc. Acesta este ceea ce face el programator de memorie .

Programatorul de memorie analizează periodic procesele de pe disc pentru a decide pe care să le mute în memorie. Printre criteriile utilizate de planificator se numără următoarele:

1. Cât timp a trecut de când procesul a fost schimbat pe disc sau încărcat de pe disc?

2. Cât timp folosește procesorul?

3. Care este dimensiunea procesului (procesele mici nu interferează)?

4. Care este importanța procesului?

Al treilea nivel de programare este responsabil pentru a permite proceselor aflate în starea pregătită să acceseze procesorul. Când vorbim despre un „programator”, de obicei ne referim programator CPU . Acest planificator folosește orice algoritm potrivit pentru situație, atât cu cât și fără întrerupere. Ne-am uitat deja la unii dintre acești algoritmi și ne vom familiariza cu alții mai târziu.

Planificare în sisteme interactive.

Planificare ciclică.

Unul dintre cele mai vechi, mai simple, mai corecte și mai frecvent utilizate este algoritmul de programare ciclică. Fiecărui proces i se acordă o anumită perioadă de timp a procesorului, așa-numitul interval de timp. Dacă procesul încă rulează la sfârșitul intervalului de timp, acesta este încheiat și controlul este transferat către alt proces. Desigur, dacă procesul se blochează sau se termină mai devreme, în acest moment are loc o tranziție de control. Implementarea programării round-robin este simplă. Planificatorul trebuie doar să mențină o listă de procese într-o stare pregătită. Când un proces și-a atins limita de timp, este trimis la sfârșitul listei.

Singurul aspect interesant al acestui algoritm este lungimea cuantumului. Trecerea de la un proces la altul durează ceva timp - este necesară salvarea și încărcarea registrelor și hărților de memorie, actualizarea tabelelor și listelor, salvarea și reîncărcarea memoriei cache etc. Concluzia poate fi formulată după cum urmează: un cuantum prea mic va duce la comutarea frecventă a proceselor și o eficiență mică, dar un cuantum prea mare poate duce la un răspuns lent la cererile interactive scurte. O valoare cuantică de aproximativ 2 0 -5 0 ms este adesea un compromis rezonabil.

Planificare prioritară.

Programarea „round robin” are o presupunere importantă că toate procesele sunt egale. În situația unui computer cu un număr mare de utilizatori, acesta poate să nu fie cazul. De exemplu, la o universitate ar trebui serviți mai întâi decanii, apoi profesorii, secretarii, curățătorii și abia apoi studenții. Necesitatea de a lua în considerare astfel de factori externi conduce la planificarea prioritară. Ideea de bază este simplă: fiecărui proces i se atribuie o prioritate, iar controlul este transferat procesului gata cu cea mai mare prioritate.

Mai multe cozi.

Unul dintre primele programatoare de prioritate a fost implementat în sistemul CTSS (sistem compatibil în timp partajat).Principala problemă a sistemului CTSS a fost că comutarea procesului era prea lentă, deoarece computerul IBM 7094 putea să dețină un singur proces în memorie. Fiecare comutare însemna descărcarea procesului curent pe disc

și citirea noului proces de pe disc. Dezvoltatorii CTSS și-au dat seama rapid că eficiența ar fi mai mare dacă proceselor limitate de procesor li s-ar acorda o porțiune de timp mai mare decât dacă li s-ar oferi intervale de timp mici, dar adesea. Pe de o parte, acest lucru va reduce numărul de transferuri de pe memorie pe disc și, pe de altă parte, va duce la o deteriorare a timpului de răspuns, așa cum am văzut deja.

Ca urmare, a fost dezvoltată o soluție cu clase prioritare. Proceselor din clasa cu cea mai mare prioritate li sa alocat un cuantic, proceselor din clasa următoare li sa alocat doi cuanti, proceselor din clasa următoare li sa alocat patru cuanti etc. clasă.

Ca exemplu, luați în considerare un proces care trebuie să calculeze peste 100 de cuante. Mai întâi, i se va da un cuantic, apoi va fi pompat pe disc. Data viitoare primește 2 cuante, apoi 4, 8,16, 32, 64, deși din 64 folosește doar 37. În acest caz, vor fi necesare doar 7 transferuri (inclusiv încărcarea inițială) în locul celor 100 care ar fi necesare folosind algoritmul round-robin. În plus, pe măsură ce ajunge din ce în ce mai adânc în coada de priorități, procesul va începe din ce în ce mai rar, dând CPU-ului procese mai scurte.

„Cel mai scurt proces este următorul”

Deoarece algoritmul Shortest Task First minimizează timpul mediu de răspuns în sistemele de procesare în loturi, ar dori să îl utilizați și în sistemele interactive. Într-o anumită măsură acest lucru este posibil. Procesele interactive urmează cel mai adesea tiparul „așteptați o comandă, executați o comandă, așteptați o comandă, executați o comandă...” Dacă tratați execuția fiecărei comenzi ca pe o sarcină separată, puteți minimiza răspunsul mediu general. timp executând mai întâi sarcina cea mai scurtă. Singura problemă este

este să înțelegem care dintre procesele de așteptare este cel mai scurt.

O metodă se bazează pe estimarea lungimii procesului pe baza comportamentului anterior al procesului. În acest caz, este lansat procesul cu cel mai scurt timp estimat. Să presupunem că timpul de execuție așteptat al comenzii este T 0 și următorul timp de execuție așteptat este T 1 . Este posibil să se îmbunătățească estimarea timpului luând suma ponderată a acestor timpi aT 0 + (1 - a)T 1 . Alegând valoarea potrivită pentru a, putem face ca algoritmul de estimare să uite rapid de rulările anterioare sau, dimpotrivă, să le amintim mult timp. Luând a = 1/2, obținem o serie de estimări:

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.

După trei rulări, ponderea lui T 0 în estimare va scădea la 1/8.

Metoda de estimare a valorii următoare dintr-o serie printr-o medie ponderată a valorii anterioare și a estimării anterioare se numește adesea îmbătrânire. Această metodă este aplicabilă în multe situații în care este necesară estimarea din valorile anterioare. Cel mai simplu mod de a implementa îmbătrânirea este la a = 1/2. La fiecare pas de care ai nevoie

adăugați o nouă valoare estimării curente și împărțiți suma la jumătate (deplasând la dreapta cu 1 bit).

Planificare garantata.

O abordare fundamental diferită a planificării este de a face promisiuni reale utilizatorilor și apoi de a le respecta. Iată o promisiune care este ușor de spus și ușor de respectat: dacă partajați un procesor cu n utilizatori, vi se va oferi 1/n din puterea procesorului.

Și într-un sistem cu un utilizator și n procesoare care rulează, fiecare va primi 1/n cicluri de procesor.

Pentru a îndeplini această promisiune, sistemul trebuie să țină evidența alocării CPU între procese din momentul în care fiecare proces este creat. Sistemul calculează apoi cantitatea de resurse CPU la care are dreptul procesul, cum ar fi timpul de la creare împărțit la n. Acum putem calcula raportul dintre timpul acordat procesului și timpul la care are dreptul. Valoarea rezultată de 0,5 înseamnă că procesul a primit doar jumătate din suma alocată, iar 2,0 înseamnă că procesul a primit de două ori mai mult decât trebuia. Apoi se începe procesul cu cel mai mic raport, până când

nu va deveni mai mare decât cea a celui mai apropiat vecin.

Planificarea loteriei.

Algoritmul se bazează pe distribuirea tichetelor de loterie către procese pentru acces la diverse resurse, inclusiv la procesor. Când planificatorul trebuie să ia o decizie, un bilet de loterie este selectat la întâmplare, iar proprietarul său are acces la resursă. În ceea ce privește accesul la CPU, „loteria” se poate întâmpla de 50 de ori pe secundă, câștigătorul primind 20 ms de timp CPU.

Procesele mai importante pot primi bilete suplimentare pentru a crește probabilitatea de câștig. Dacă există doar 100 de bilete și 20 dintre ele sunt într-un singur proces, atunci va primi 20% din timpul procesorului. Spre deosebire de planificatorul cu prioritate, în care este foarte greu de evaluat ce înseamnă, să zicem, prioritatea 40, în programarea la loterie totul este evident. Fiecare proces va primi un procent de resurse aproximativ egal cu procentul de bilete de care dispune.

Planificarea loteriei are mai multe proprietăți interesante. De exemplu, dacă în timpul creării un proces primește mai multe bilete, atunci la următoarea loterie șansele sale de câștig sunt proporționale cu numărul de bilete.

Procesele de comunicare pot schimba bilete dacă este necesar. Deci, dacă un proces client trimite un mesaj către un proces de server și apoi se blochează, acesta își poate transmite toate tichetele procesului server pentru a crește șansa de pornire a serverului. Când procesul de server se termină, acesta poate returna toate biletele înapoi.

Planificare corectă.

Până acum am presupus că fiecare proces este controlat independent de cine este proprietarul său. Prin urmare, dacă utilizatorul 1 creează 9 procese, iar utilizatorul 2 - 1 proces, atunci folosind programarea round-robin sau în cazul priorităților egale, utilizatorul 1 va primi 90% din procesor, iar utilizatorul 2 doar 10.

Pentru a evita astfel de situații, unele sisteme acordă atenție proprietarului procesului înainte de programare. În acest model, fiecare utilizator primește o anumită cotă din procesor, iar planificatorul selectează un proces în funcție de acest fapt. Dacă în exemplul nostru fiecare utilizator avea

au promis 50% din procesor, atunci vor primi 50% din procesor, indiferent de numărul de procese.

Planificare în sisteme în timp real.

În sistemele de timp real, timpul joacă un rol esențial. Cel mai adesea, unul sau mai multe dispozitive fizice externe generează semnale de intrare, iar computerul trebuie să răspundă adecvat la acestea într-o anumită perioadă de timp.

Sistemele în timp real sunt împărțite în sisteme dure în timp real , ceea ce înseamnă prezența unor termene stricte pentru fiecare sarcină (trebuie respectate) și sisteme flexibile în timp real , în care încălcările orarului sunt nedorite, dar acceptabile. În ambele cazuri, programul este împărțit în mai multe procese, fiecare dintre ele previzibile. Aceste procese sunt cel mai adesea scurte și își termină activitatea într-o secundă. Când apare un semnal extern, planificatorul este cel care trebuie să se asigure că programul este menținut.

Evenimentele externe la care sistemul trebuie să răspundă pot fi împărțite în periodic(care apar la intervale regulate) si neperiodică(care are loc în mod imprevizibil). Pot exista mai multe fluxuri periodice de evenimente pe care sistemul trebuie să le proceseze. În funcție de timpul necesar procesării fiecărui eveniment, este posibil ca sistemul să nu poată procesa toate evenimentele în timp util.

Informații conexe.

Adesea, dezvoltatorii, în special cei fără experiență, devin confuzi atunci când li se cere să stabilească termene limită pentru finalizarea sarcinilor. Cu toate acestea, capacitatea de planificare este o abilitate foarte utilă și necesară, care ajută nu numai în muncă, ci și în viață. Am decis să întrebăm experții cum să învețe să planificăm corect și să livrăm proiectele la timp.

Scurte concluzii pot fi găsite la sfârșitul articolului.

De obicei, un dezvoltator trebuie să ia în considerare mai mulți parametri simultan pentru a estima timpul necesar pentru a finaliza o sarcină:

1. Experiență în realizarea unor astfel de sarcini și lucrul cu această stivă de tehnologie. Dacă trebuie să faci ceva fundamental nou, trebuie să fii deosebit de atent cu evaluarea ta.
2. Experiență de lucru cu acest client. Cunoscând clientul, puteți prezice aproximativ câteva cerințe suplimentare și amploarea modificărilor.
3. Calitatea codului cu care veți lucra. Acesta este cel mai influent factor, din cauza căruia totul poate dura mult timp și, în general, nu merge conform planului. Dacă proiectul are teste, există doar dependențe explicite peste tot și funcționalitatea este bine izolată, totul nu este atât de înfricoșător. Este mult mai rău dacă ai de-a face cu cod vechi fără teste sau cu cod supraîncărcat cu dependențe implicite. Lucruri precum „funcțiile magice” (când este greu să vedeți stiva finală de apeluri din cod) și duplicarea codului (când trebuie să editați mai multe secțiuni independente pentru a schimba unele funcționalități) pot complica, de asemenea, lucrurile.

Pentru a învăța cum să estimați în mod adecvat termenele limită de lucru, trebuie să exersați în mod constant. La începutul muncii mele, am făcut exact asta: am estimat timpul necesar pentru a finaliza orice sarcină primită, chiar dacă nimeni nu mi-a cerut acest lucru, apoi m-am uitat la cât de exact am reușit să intru în estimarea mea. În timp ce a finalizat sarcina, el a notat care acțiuni au durat mai mult. Daca ceva a crescut semnificativ perioada, mi-am amintit de acest moment si l-am luat in calcul in urmatoarele evaluari.

La o evaluare obiectivă a timpului necesar exclusiv pentru muncă, ar trebui adăugată o marjă mică pentru a acoperi situațiile de forță majoră. Este adesea evaluat ca procent din îndeplinirea sarcinii principale, dar este diferit pentru toată lumea: unii adaugă 20% din timp, alții - 10% și alții - 50%.

De asemenea, este util să se analizeze motivele pentru nerespectarea termenelor limită după fiecare încălcare gravă a termenului limită. Dacă nu aveți calificări, trebuie să vă lucrați la punctele slabe. Dacă problema a fost organizatorică, înțelegeți ce a împiedicat-o să funcționeze normal.

Promovați retrogradarea

, director tehnic al centrului de tehnologii și soluții inovatoare „Jet Infosystems”

Un număr mare de articole sunt dedicate metodelor de evaluare a intensității muncii a unui proiect, inclusiv duratei muncii și sarcinilor individuale. Cu toate acestea, acest lucru provoacă în continuare conflicte atât în ​​cadrul echipei de proiect, cât și atunci când se comunică cu clientul.

Asistentul principal în evaluare este experiența. Încercați să comparați cumva noua sarcină cu cele deja făcute. Dacă faceți un raport, uitați-vă la cât timp a durat un raport similar în trecut. Dacă faceți ceva nou, încercați să-l împărțiți în părți cunoscute și să le evaluați. Dacă sarcina este complet nouă, alocă-ți timp pentru studiu (și mai bine, coordonează acest timp cu persoana care stabilește sarcina).

Acordați atenție etapelor însoțitoare - dacă aveți nevoie să dezvoltați un serviciu, atunci evaluarea trebuie să includă și testarea unitară (și poate nu numai testarea unitară), pregătirea datelor de testare va dura ceva timp. Ar trebui să luați în considerare integrarea cu alte servicii etc. Acordați timp pentru corectarea defectelor pe care le găsiți singur sau cu ajutorul testerilor. Se poate pierde mult timp pe sarcini „invizibile”. De exemplu, există o evaluare pentru dezvoltare și există o evaluare pentru testare, dar transferul unui artefact pentru testare poate implica desfășurarea standurilor. Prin urmare, este important să vizualizați mental întregul proces pentru a nu pierde nimic.

După determinarea complexității, este necesar să includeți noi lucrări în calendar, fără a uita de alte sarcini și activități care merg în paralel.

Și nu uitați că planurile sunt inutile, dar planificarea nu are preț. Învățați să ajustați planurile în timp util, să informați pe toți cei implicați și să escaladați în timp util, astfel încât termenele nerespectate să nu fie o surpriză pentru nimeni.

Promovați retrogradarea

O întrebare la care nu se poate răspunde într-o formă scurtă. Dacă ar fi simplu, atunci problema lipsei termenelor nu ar exista.

Pentru a face termenele de dezvoltare mai previzibile, trebuie mai întâi să înțelegem motivele pentru care programatorii greșesc tot timpul.

Primul motiv este că majoritatea sarcinilor pe care le face un programator sunt unice într-o măsură sau alta. Adică, cel mai probabil, programatorul va face o sarcină similară pentru prima dată. Nu are o idee bună despre cât timp va dura această muncă. Dacă acesta este un programator cu experiență solidă și a trebuit să îndeplinească o sarcină similară, evaluarea lui va fi mai aproape de realitate.

Să folosim o analogie simplă - dacă nu ați săpat niciodată șanțuri, nu puteți spune exact cât timp vă va dura să săpați un șanț de 30 cm lățime, 60 cm adâncime și 20 de metri lungime. Dacă ați săpat înainte, estimarea dumneavoastră a timpului de lucru va fi mult mai aproape de durata reală a lucrării.

Al doilea motiv este că programatorii sunt optimiști prin natura lor. Adică, atunci când ia în considerare o sarcină, selectează o opțiune de implementare pentru aceasta și evaluează îmbunătățirile, dezvoltatorul se așteaptă ca totul să funcționeze așa cum se așteaptă. Și nu se gândește la problemele pe care le va întâmpina pe parcurs. Adesea nu le poate prevedea. De exemplu, există o sarcină pe care un programator o poate implementa folosind o bibliotecă de software open-source terță parte. În etapa de evaluare, l-a găsit pe Internet, i-a citit descrierea - i se potrivește. Și chiar a estimat corect cantitatea de muncă pe care ar trebui să o facă pentru a construi în utilizarea acestei biblioteci. Dar nu a prevăzut deloc că va apărea o eroare în această bibliotecă în mediul produsului său software.

Dezvoltatorul va trebui nu numai să includă utilizarea bibliotecii în codul său, ci și să remedieze o eroare în bibliotecă în sine. Și adesea, dezvoltatorul nu oferă timp pentru a-și corecta erorile. Statisticile arată că testarea și remedierea erorilor poate ocupa aproximativ 50% din timpul petrecut cu codificare. Cifra depinde de calificările dezvoltatorului, de mediu și de practicile de dezvoltare utilizate (de exemplu, testele unitare reduc semnificativ acest timp, iar durata finală/intensitatea muncii a sarcinii de dezvoltare este mai mică).

Daca revenim la analogia cu sapatorul, sapatorul nu se astepta ca i se rupe lopata si va trebui sa petreaca doua ore in cautarea unei noi taieri.

Al treilea motiv este cerințele neprevăzute. În niciun alt domeniu al producției de materiale, cu care clienții sunt atât de pasionați de a compara dezvoltarea de software, nu există un astfel de flux de noi cerințe. Imaginează-ți trecerea unui săpător care a săpat 19 metri din 20 și a auzit de la client dorința ca șanțul să nu meargă în linie dreaptă, ci într-un șarpe cu o lungime a brațului de 97 de centimetri.

Cum să faci față tuturor acestor lucruri și cum să trăiești în condiții de o asemenea incertitudine? Reducerea incertitudinii și construirea rezervelor de timp.

Cel mai simplu mod de a vă aduce așteptările mai aproape de realitate este să utilizați regula de bază Pi jucăușă. După ce ați primit o estimare de la dezvoltator (în termeni de timp sau intensitate a muncii), trebuie să o înmulțiți cu Pi (= 3,14159). Cu cât dezvoltatorul a efectuat evaluarea mai experimentat, cu atât acest raport poate fi mai mic.

Practica descompunerii problemei inițiale în sarcini mici de cel mult 4 ore este obligatorie. Cu cât descompunerea este mai detaliată, cu atât sunt mai mari șansele ca estimarea să se apropie de complexitatea/durata reală.
Dacă revenim la alocarea rezervei, acest timp ar trebui să fie alocat la finalul proiectului. Este o practică proastă să faceți o rezervă și să o includeți pentru fiecare sarcină. Legea Parkinson „Munca se umple tot timpul alocat” este respectată cu strictețe.

Pentru a rezuma pe scurt, pentru a stabili corect termenele de finalizare a lucrării, vor fi utile următoarele acțiuni:

• efectuați o descompunere a lucrării, împărțind sarcina în pași cât mai detaliați posibil;
• realizarea prototipurilor;
• limitează implementarea cerințelor neprevăzute anterior. Acest lucru nu înseamnă că nu trebuie făcute, dar este recomandabil să evidențiezi aceste cerințe și să convingi cu clientul asupra modificărilor în timpul și costul implementării lor;
• luați în considerare timpul necesar pentru a stabiliza soluția;
• utilizați practici pentru a îmbunătăți calitatea codului, cum ar fi scrierea de teste unitare;
• constituie o rezervă generală.

Ei bine, amintiți-vă că, dacă un fapt depășește estimarea dvs. cu 30%, atunci acesta este un rezultat foarte bun.

Promovați retrogradarea

Pentru cea mai precisă evaluare, aveți nevoie de experiență în dezvoltarea reală și, în special, într-un anumit domeniu. Dar există și reguli generale care vă vor ajuta să evitați greșelile de planificare și problemele la livrarea lucrării către client. Aș descrie astfel aceste reguli.

În primul rând, trebuie să înțelegeți problema. Acest lucru pare evident și nu are legătură directă cu estimările de timp, dar de fapt este un punct cheie. Chiar și în proiectele mari serioase, unul dintre principalii factori de eșec și întârziere este problema definirii cerințelor. Pentru dezvoltatorii începători, din păcate, aceasta este o problemă serioasă - nu citesc specificațiile tehnice sau citesc și înțeleg foarte selectiv (din zece puncte, și-au amintit și au completat cinci și și-au amintit restul când au trimis rezultatul). Este clar că o sarcină neînțeleasă nu poate fi implementată corect la timp.

Următorul este să estimați timpul de dezvoltare în sine. Particularitatea programării este că nu există sarcini absolut identice. Acest lucru face munca noastră mai interesantă, dar estimarea termenelor limită este mai dificilă. Descompunerea funcționează bine aici, de exemplu. împărțirea unei probleme complexe, unice, într-o secvență de subsarcini mici, familiare. Și fiecare dintre ele poate fi deja evaluat în ore destul de adecvat. Să adunăm estimările subsarcinilor și să obținem o estimare pentru întreaga sarcină.

De regulă, o astfel de estimare include doar costurile de codificare în sine. Aceasta este, desigur, cea mai importantă parte a dezvoltării, dar departe de a fi singura (și adesea nu cea mai voluminoasă). Finalizarea completă a sarcinii include, de asemenea, citirea și clarificarea caietului de sarcini, întâlniri cu colegii sau clientul, depanare și testare, întocmirea documentației, livrarea rezultatului (demonstrație către client și posibile modificări pe baza comentariilor acestuia). Doar experiența vă va spune exact cât timp vă va dura să finalizați aceste acțiuni. La început, este important, cel puțin, să nu uitați să le luați în considerare în calcule, și puteți cere colegilor mai experimentați o estimare aproximativă a timpului.

Deci, luăm o estimare a costurilor forței de muncă pentru codificare, adăugăm o estimare a costurilor muncii suplimentare - și obținem estimarea necesară a timpului pentru finalizarea sarcinii. Dar asta nu este tot! Trebuie să indicați data planificată de finalizare a sarcinii. Ar fi o greșeală să împărțim pur și simplu costurile cu forța de muncă (în ore) la 8 ore și să le adăugați la data curentă. În practică, un dezvoltator nu lucrează niciodată (bine, aproape niciodată) 100% din timp la o anumită sarcină. Cu siguranță vei petrece timp cu alte lucrări - importante, dar nu legate direct de cea principală. De exemplu, ajutarea colegilor, instruirea, redactarea rapoartelor etc. De obicei, la planificare, se crede că 60-70% din timpul de lucru este alocat direct lucrând la proiectul curent. În plus, trebuie să țineți cont de posibilele întârzieri care vă vor împiedica să lucrați continuu la sarcină. De exemplu, dacă pentru aceasta trebuie să interacționați cu alte persoane (colegi, clienți), atunci țineți cont de disponibilitatea acestora, programul de lucru etc.

Iată care sunt regulile de bază care, după părerea mea, îl vor ajuta pe dezvoltator să evite problemele în estimarea și respectarea termenelor limită. În plus, cheia este să acumulați propria experiență atât în ​​implementarea sarcinilor, cât și în evaluare. De exemplu, este foarte util după finalizarea unei sarcini să comparați estimarea inițială cu termenele limită efective și să trageți concluzii pentru viitor. Și, desigur, merită să studiezi experiențele altora. Aș recomanda cărțile pe tema lui S. McConnell „Cât costă un proiect software” și S. Arkhipenkov „Prelegeri despre managementul proiectelor software”.

Promovați retrogradarea

Când estimați și planificați termenele limită, trebuie să:

1. Descompuneți sarcina în bucăți funcționale mici, astfel încât să existe o înțelegere clară a cât timp va dura pentru a dezvolta fiecare astfel de piese.
2. În paralel cu descompunerea, vor apărea cu siguranță întrebări suplimentare cu privire la funcționalitatea care nu a fost descrisă în enunțul problemei. Este necesar să se obțină răspunsuri la astfel de întrebări, deoarece acestea se referă în mod direct la domeniul de activitate și, prin urmare, la timp.
3. Adăugați un anumit procent de riscuri la evaluarea finală. Aceasta este determinată empiric. Puteți începe, de exemplu, cu riscuri de 10–15%.
4. Înțelegeți câte ore pe zi este dispus să dedice un programator pentru îndeplinirea unei sarcini.
5. Împărțim estimarea finală la numărul de ore pe care le alocăm pe zi și obținem numărul de zile necesare implementării.
6. Ne concentrăm pe calendar și pe numărul necesar de zile de finalizat. Luăm în considerare weekendurile și alte zile în care programatorul nu va putea lucra la sarcină, precum și data de începere a lucrului (dezvoltatorul nu este întotdeauna pregătit să preia sarcina în aceeași zi). Astfel, obținem data de început și de sfârșit a lucrării.

Promovați retrogradarea

În compania noastră, planificarea sarcinilor trece întotdeauna prin mai multe etape. Pe partea de business, formulăm 5-6 obiective strategice pentru anul. Acestea sunt sarcini de nivel înalt, de exemplu, creșterea unui parametru cu atât de multe procente. În continuare, diverse divizii ale companiei formulează sarcini de afaceri pentru toate echipele IT. Termenele limită pentru aceste sarcini primesc o estimare inițială brută, care este adesea formată de toți membrii echipei - manager, analist, dezvoltator și tester. Odată ce afacerea primește această evaluare, prioritizează sarcinile pe baza obiectivelor strategice ale companiei. Obiectivele strategice transversale ajută în acest sens; cu ele, devine evident că toți lucrăm pentru o cauză comună; nu există o astfel de situație când cineva trage doar în propria direcție. Colectăm sprinturi din sarcini estimate cu precizie în termeni limită. Pentru unele echipe sunt trimestriale, pentru altele sunt lunare. Pentru mai multe sarcini care, conform estimărilor preliminare, vor cădea în următorul sprint, echipele oferă o estimare precisă. Sarcinile mari sunt împărțite în altele de nivel inferior, pentru fiecare dintre ele este responsabil un anumit executant și el este cel care oferă o evaluare precisă.

În această etapă, este important să nu uitați să adăugați o rezervă de timp pentru a remedia erorile, deoarece numai cei care nu fac nimic nu greșesc. Atât proprietarii de produse, cât și clienții de afaceri înțeleg acest lucru foarte bine. În același timp, timpul necesar trebuie să fie adecvat: nimeni nu va înțelege un dezvoltator care stabilește un termen limită pentru o sarcină simplă care este prea lungă; i se va cere să justifice decizia. Cel mai dificil lucru este să explici afacerii de ce este nevoie de timp pentru refactorizare. Suntem recunoscători companiei noastre pentru faptul că din când în când reușim acest lucru, pentru că în cele din urmă refactorizarea duce la simplificarea infrastructurii și punerea în ordine a codului, ceea ce crește stabilitatea sistemului și poate accelera semnificativ dezvoltarea. de noi funcţii.

Uneori încă apar erori de evaluare. În opinia mea, este imposibil ca departamentul de dezvoltare din companiile mari cu infrastructură dezvoltată să evite complet acest lucru. În acest caz, este important ca dezvoltatorul să-și informeze prompt managerul despre ceea ce se întâmplă, iar el, la rândul său, reușește să avertizeze afacerea și să „relueze” ceva în planurile generale ale companiei. Lucrul în acest mod este mult mai corect decât încercarea frenetică de a face în 3 zile ceea ce durează 5, și apoi înecul într-un număr mare de erori apărute din cauza unei astfel de grabe.

Promovați retrogradarea

Răspunsul corect la ambele părți ale întrebării [cum să învățați cum să planificați corect și să livrați un proiect la timp - Ed.] - experiență. Nu există alte modalități de a „cunoaște Zen”. Conform teoriei deciziei, orice concluzie precisă poate fi trasă numai pe baza analizei unui număr de date deja disponibile. Și cu cât sunt mai multe date, cu atât sunt mai precise prognoza și evaluarea finală.

În cuvintele lui Herbert Shaw: „Experiența este școala în care un om învață ce prost a fost înainte.” Acest lucru duce la o concluzie destul de simplă: dacă un programator are deja experiență care se corelează cu sarcina în cauză, se poate baza pe ea; dacă nu, se poate baza pe experiența „colegilor” săi.

În continuare, trebuie să înțelegeți că planificarea directă a termenelor limită este o sarcină căreia oamenii o fac foarte, foarte prost, mai ales în dezvoltare. La estimarea termenelor scadente, este considerată o bună practică să se introducă „factori de ajustare” la estimarea inițială. Această metrică poate varia de la 1,5 la 3, în funcție de experiența dezvoltatorului și de totalitatea gradelor de incertitudine a sarcinilor care se rezolvă în cadrul proiectului.

Promovați retrogradarea

Este important să luați în considerare mulți factori atunci când stabiliți termenele limită.

De exemplu, experiență în muncă. Cât de clar înțelegeți scopul lucrării care urmează? Ați mai făcut așa ceva înainte? Este clar că cu cât mai multă experiență, cu atât mai repede va fi finalizată munca.

O specificație tehnică bine scrisă joacă un rol important în stabilirea termenelor limită. Lucrurile sunt foarte dificile cu asta în zona noastră. De multe ori clientul însuși nu știe ce vrea, așa că te sfătuiesc să petreci o zi sau două în plus, dar să faci o idee clară de la client despre rezultatul dorit. Este important ca această înțelegere să fie reciprocă. Și numai după aceasta puteți începe să negociați suma și termenii.

De asemenea, includeți întotdeauna riscurile. Pentru începători, recomand înmulțirea timpului estimat de finalizare cu două. La urma urmei, este mai bine să livrați un proiect înainte de termen și să creșteți ca specialist în ochii clientului, decât să-l livrați mai târziu și să vă distrugeți reputația.

Promovați retrogradarea

O recomandare generală este ca dezvoltatorul trebuie să învețe cum să descompună corect sarcinile, să caute întotdeauna posibile capcane, să se bazeze pe propria experiență și să nu uite să avertizeze clienții și colegii în timp util dacă sarcina nu poate fi rezolvată în timpul specificat. cadru.

Construirea unui plan clar este mult mai dificilă decât determinarea termenului limită pentru finalizarea unei singure sarcini. În același timp, este important nu doar să livrați proiectul la timp, ci și să vă asigurați că sistemul pe care îl dezvoltați rezolvă corect problemele de afaceri. Aici, echipele IT sunt ajutate de diverse metodologii de dezvoltare software: de la RUP și MSF la SCRUM și alte formate Agile. Alegerea instrumentelor este foarte extinsă, iar mulți dintre clienții noștri doresc să înțeleagă în avans cum vom lucra cu ei în proiect, la ce principii aderăm.

Apropo, subiectul Agile de astăzi devine din ce în ce mai aproape atât de business, cât și chiar de proiecte individuale pentru sectorul public, deoarece principiile acestei metodologii fac posibilă implementarea proiectelor foarte rapid, gestionând așteptările clienților la fiecare iterație. De exemplu, într-o echipă Agile nu există practic discuții prelungite cu clientul. Uitați de zeci de pagini care descriu detalii tehnice inutile, cum ar fi cât de repede apare o listă derulantă. Oferiți clientului posibilitatea de a încerca o versiune intermediară a sistemului, apoi vă va deveni mult mai ușor să vă înțelegeți.

Echipa Agile planifică totul împreună și determină nivelul optim de muncă care va fi necesar pentru a rezolva o anumită problemă. De exemplu, una dintre tehnici se numește „Poker Planning”, în care fiecare participant își dă anonim evaluarea costurilor de muncă necesare pentru o anumită sarcină. După aceasta, echipa determină greutatea medie a sarcinii în puncte de poveste sau ore-om și distribuie sarcinile conform principiului „cui îi place ce”. În același timp, în fiecare zi, echipa se adună pentru o întâlnire de 15 minute, când toată lumea vorbește despre starea sarcinilor lor curente în câteva minute, inclusiv raportând orice dificultăți care au apărut. Echipa remediază rapid problema detectată, astfel încât clientul să se uite la următoarea etapă a muncii programatorului cât mai repede posibil. Dezvoltatorii nu întârzie finalizarea sarcinilor din cauza reticenței de a deranja din nou echipa sau a încercărilor zadarnice de a-și da seama singuri, ucigând timp prețios. Apropo, la astfel de mini-state, dezvoltatorii au dorința de a-și arăta cea mai bună latură, de a arăta că abordezi munca cu responsabilitate. Chiar motivează și se autodisciplinează.

(timpul de la locul de muncă devine inclus până când este finalizat în cazul activității periodice, sau până când sistemul răspunde și predă primul utilizator de ieșire în cazul activității interactive); sau maximizare justiţie(o cantitate egală de timp CPU pentru fiecare proces sau, în general, timpi corespunzători în funcție de prioritatea și volumul de lucru al fiecărui proces). În practică, aceste obiective sunt adesea în conflict (de exemplu, debit versus latență), astfel încât planificatorul va face un compromis adecvat. Preferința este măsurată prin oricare dintre aspectele menționate mai sus, în funcție de nevoile și obiectivele utilizatorului.

OS/360 și succesori

AIX

În AIX Versiunea 4, există trei setări posibile pentru politica de planificare a firelor de execuție:

• În primul rând, în primul rând: odată ce un fir cu această politică este programat, acesta rulează până la finalizare, cu excepția cazului în care este blocat, renunță voluntar la controlul procesorului sau un fir cu prioritate mai mare devine dispecerabil. Numai firele cu prioritate fixă ​​pot avea o politică de programare FIFO.
• Round Robin: Acesta este similar cu programatorul de circuite AIX Versiunea 3, care circulă pe baza intervalelor de timp de 10 ms. Când un fir PP are control la sfârșitul unui interval de timp, acesta se deplasează la coada cozii de fire cu aceeași prioritate. Numai firele cu prioritate fixă ​​pot avea o politică de programare Round Robin.
• ALTE: Această politică este definită de implementare de POSIX1003.4a. În AIX Versiunea 4, această politică este definită ca echivalentă cu RR, cu excepția faptului că se aplică firelor de execuție cu prioritate nefixată. Recalcularea valorii de prioritate a unui fir de execuție pentru fiecare întrerupere înseamnă că un fir de execuție poate pierde controlul deoarece valoarea sa de prioritate a crescut mai mult decât un alt fir. Acesta este comportamentul AIX Versiunea 3.

Threadurile sunt de interes în primul rând pentru aplicațiile care constau în prezent din mai multe procese asincrone. Aceste aplicații pot impune o sarcină ușoară sistemului dacă sunt convertite într-o structură cu mai multe fire.

AIX 5 implementează următoarele politici de programare: FIFO, round-robin și fair round-robin. Politica FIFO constă din trei implementări diferite: FIFO, FIFO2 și FIFO3. Politica round-robin a robin se numește SCHED_RR în AIX, iar politica round-robin echitabil se numește SCHED_OTHER.

Linux

Linux 2.4

Brain Fuck Scheduler (BFS), creat și de Kolivas, este o alternativă la CFS.

FreeBSD

FreeBSD folosește o coadă de feedback pe mai multe niveluri cu priorități în intervalul 0-255. 0-63 sunt rezervate pentru întreruperi, 64-127 pentru jumătatea superioară a nucleului, 128-159 pentru firele de execuție de utilizator în timp real, 160-223 pentru firele de execuție de utilizator și 224-255 pentru firele de execuție de utilizator inactiv. De asemenea, ca și Linux, folosește o configurare activă a cozii de așteptare, dar are și o coadă inactivă.

Introducere

Scopul atelierului de organizare a producției este extinderea și aprofundarea cunoștințelor teoretice, insuflarea abilităților necesare pentru rezolvarea problemelor cel mai frecvent întâlnite în practică privind organizarea și planificarea producției.

Atelierul include sarcini pentru secțiunile principale ale cursului. La începutul fiecărei teme sunt prezentate scurte instrucțiuni metodologice și informații teoretice, probleme tipice cu soluții și probleme pentru rezolvare independentă.

Prezența instrucțiunilor metodologice și a scurtelor informații teoretice în fiecare subiect vă permite să utilizați acest atelier pentru învățământul la distanță.

Calculul duratei ciclului de producție

Durata ciclului de producție servește ca indicator al eficienței procesului de producție.

Ciclul de producție– perioada de şedere a obiectelor de muncă în procesul de producţie din momentul lansării materiilor prime până în momentul eliberării produselor finite.

Ciclul de producție constă în ore de lucru, timp în care se cheltuiește forța de muncă și timpi de pauză. Pauzele, în funcție de motivele care le-au cauzat, pot fi împărțite în:

1) pe natural sau tehnologice - sunt determinate de natura produsului;

2) organizatoric(pauze între ture).

Durata ciclului de producție constă din următoarele componente:

Ciclul T = t acelea + t mănâncă + t tr + t k.k. + t m.o. + t m.ts.

Unde t acestea– timpul operațiunilor tehnologice;

mănâncă - timpul proceselor naturale (uscare, răcire etc.);

t tr – timpul de transport al obiectelor de muncă;

t k.k. – timpul de control al calității;

t m.o – timpul de îngrijire interoperatorie;

t m.c. – timp de depozitare în depozite inter-shop;

(t Trei t k.k. poate fi combinat cu t m.o).

Calculul timpului ciclului de producție depinde de tipul de producție. În producția de masă, durata ciclului de producție este determinată de momentul în care produsul este în producție, adică.

Ciclul T = t in m,

Unde t V– cursa de eliberare;

M- numărul de locuri de muncă.

Sub cursa de eliberare este necesar să se înțeleagă intervalul de timp dintre lansarea unui produs fabricat și următorul produs.

Cursa de eliberare este determinată de formulă

t in = Teff /V,

Unde Tef– fondul efectiv de timp al lucrătorului pentru perioada de facturare (schimb, zi, an);

ÎN– volumul producției pentru aceeași perioadă (în unități naturale).

Exemplu: T cm = 8 ore = 480 min; T per = 30 min; → Teff = 480 – – 30 = 450 min.

B = 225 buc; → t in = 450/225 = 2 min.

În producția de serie, în care prelucrarea se realizează în loturi, durata ciclului tehnologic este determinată nu pe unitatea de produs, ci pentru întregul lot. Mai mult, în funcție de metoda de lansare a unui lot în producție, obținem timpi de ciclu diferiți. Există trei moduri de deplasare a produselor în producție: secvențial, paralel și mixt (serie-paralel).

eu. La secvenţial La mutarea pieselor, fiecare operație ulterioară începe numai după ce cea anterioară s-a terminat. Durata ciclului pentru mișcarea secvențială a pieselor va fi egală cu:

Unde n – numărul de părți ale lotului care se procesează;

t buci- rata de timp pentru o operație;

C i– numărul de locuri de muncă per i operațiunea;

m– numărul de operaţii de proces tehnologic.

Se oferă un lot de produse format din 5 bucăți. Lotul este trecut secvenţial prin 4 operaţii; durata primei operații este de 10 minute, a doua este de 20 de minute, a treia este de 10 minute, a patra este de 30 de minute (Fig. 1).

Poza 1

T ciclu = T ultimul = 5·(10+20+10+30) = 350 min.

Metoda secvențială a pieselor în mișcare are avantajul că asigură funcționarea echipamentului fără timpi de nefuncționare. Dar dezavantajul său este că durata ciclului de producție în acest caz este cea mai lungă. În plus, la șantierele de lucru sunt create stocuri semnificative de piese, ceea ce necesită spațiu suplimentar de producție.

II. La paralelÎn timpul deplasării lotului, piesele individuale nu sunt reținute la posturile de lucru, ci sunt transferate individual la următoarea operațiune imediat, fără a aștepta finalizarea procesării întregului lot. Astfel, odată cu deplasarea paralelă a unui lot de piese, la fiecare loc de muncă se efectuează simultan diverse operații pe diferite părți ale aceluiași lot.

Timpul de procesare al unui lot cu mișcare paralelă a produselor este redus brusc:

dl .

Unde n n– numărul de piese în transfer lot(lot de transport), i.e. numărul de produse transferate simultan de la o operațiune la alta;

Lungime – cel mai lung ciclu de funcționare.

La lansarea în paralel a unui lot de produse, părțile întregului lot sunt prelucrate continuu doar la acele locuri de muncă în care operațiunile lungi urmează operațiunilor scurte. În cazurile în care operațiunile scurte urmează operațiunilor lungi, de ex. mai lung (în exemplul nostru, a treia operație), aceste operații sunt efectuate discontinuu, adică. echipamentul este inactiv. Aici, un lot de piese nu poate fi procesat imediat, fără întârzieri, deoarece operația anterioară (lungă) nu permite acest lucru.

În exemplul nostru: n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; Cu= 1.

T abur = 1·(10+20+10+30)+(5-1)·30=70+120 = 190 min.

Să luăm în considerare diagrama mișcării paralele a pieselor (Fig. 2):

Figura 2

III. Pentru a elimina întreruperile în procesarea părților individuale ale unui lot în toate operațiunile, utilizați paralel-serial sau amestecat o metodă de lansare în care piesele (după prelucrare) sunt transferate la următoarea operație una câte una, sau sub formă de loturi „de transport” (mai multe piese) în așa fel încât executarea operațiunilor să nu fie întreruptă la niciun loc de muncă. În metoda mixtă, continuitatea prelucrării este preluată din metoda secvenţială, iar trecerea piesei de la exploatare la exploatare imediat după prelucrarea acesteia este preluată din metoda paralelă. Cu o metodă mixtă de lansare în producție, durata ciclului este determinată de formulă

miez .

unde este cor. – cel mai scurt ciclu de funcționare (din fiecare pereche de operații adiacente);

m-1 – număr de combinații.

Dacă operația ulterioară este mai lungă decât cea anterioară sau egală în timp, atunci această operație este începută individual, imediat după prelucrarea primei părți în operația anterioară. Dacă, dimpotrivă, operația ulterioară este mai scurtă decât cea anterioară, atunci aici apar întreruperi în timpul transferului piesei. Pentru a le preveni, este necesar să se acumuleze o rezervă de transport de un asemenea volum care să fie suficientă pentru a asigura lucrul la operațiunea ulterioară. Pentru a găsi practic acest punct pe grafic, este necesar să transferați ultima parte a lotului și să mutați durata execuției acestuia la dreapta. Timpul de procesare pentru toate celelalte părți din lot este reprezentat în stânga graficului. Începutul procesării primei părți indică momentul în care restanța de transport din operațiunea anterioară trebuie transferată la această operațiune.

Dacă operațiunile adiacente au aceeași durată, atunci doar una dintre ele este considerată scurtă sau lungă (Fig. 3).

Figura 3

T ultimele perechi = 5·(10+20+10+30)-(5-1)·(10+10+10) = 350-120 = 230 min.

Principalele modalități de a reduce timpul ciclului de producție sunt:

1) Reducerea intensității forței de muncă a produselor de fabricație prin îmbunătățirea fabricabilității designului fabricat, utilizarea computerelor și introducerea proceselor tehnologice avansate.

2) Organizarea rațională a proceselor de muncă, amenajarea și întreținerea locurilor de muncă pe bază de specializare și cooperare, mecanizare extensivă și automatizare a producției.

3) Reducerea diferitelor pauze planificate și neplanificate la locul de muncă pe baza utilizării raționale a principiilor organizării științifice a procesului de producție.

4) Accelerarea reacțiilor ca urmare a creșterii presiunii, temperaturilor, trecerii la un proces continuu etc.

5) Îmbunătățirea proceselor de transport, depozitare și control și combinarea lor în timp cu procesul de prelucrare și asamblare.

Reducerea duratei ciclului de producție este una dintre sarcinile serioase ale organizării producției, deoarece afectează cifra de afaceri a fondului de rulment, reducerea costurilor cu forța de muncă, reducerea spațiului de depozitare, nevoia de transport etc.

Sarcini

1 Determinați durata ciclului de prelucrare a 50 de părți cu tipuri de mișcare secvențială, paralelă și serial-paralelă în procesul de producție. Procesul de prelucrare a pieselor constă din cinci operații, a căror durată este, respectiv, de min: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5 =3. A doua operație se efectuează pe două mașini, iar fiecare dintre celelalte pe una. Dimensiunea lotului de transfer este de 4 bucăți.

2 Determinați durata ciclului de prelucrare a 50 de piese cu tipuri de mișcare secvențială, paralelă și serial-paralelă în procesul de producție. Procesul de prelucrare a pieselor constă din patru operații, a căror durată este, respectiv, de min: t 1 =1; t 2 =4; t 3 =2; t 4 =6. A patra operație se efectuează pe două mașini, iar fiecare dintre celelalte pe una. Dimensiunea lotului de transfer este de 5 bucăți.

3 Un lot de piese de 200 de bucăți este prelucrat cu mișcare paralelă-secvențială în timpul procesului de producție. Procesul de prelucrare a pieselor constă din șase operații, a căror durată este, respectiv, de min: t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6 =20. A treia operație este efectuată pe trei mașini, a șasea pe două și fiecare dintre operațiunile rămase pe o singură mașină. Determinați cum se va schimba durata ciclului de procesare pentru un lot de piese dacă versiunea paralelă-secvențială a mișcării în producție este înlocuită cu una paralelă. Dimensiunea lotului de transfer este de 20 de bucăți.

4 Un lot de piese de 300 de bucăți este prelucrat cu mișcare paralelă-secvențială în timpul procesului de producție. Procesul de prelucrare a pieselor constă din șapte operații, a căror durată este, respectiv, de min: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7 =6. Fiecare operație este efectuată pe o singură mașină. Lot transfer – 30 buc. Ca urmare a îmbunătățirii tehnologiei de producție, durata celei de-a treia operațiuni a fost redusă cu 3 minute, a șaptea - cu 2 minute. Determinați cum se modifică ciclul de procesare al unui lot de piese.

5 Se oferă un lot de semifabricate format din 5 bucăți. Lotul trece prin 4 operații: durata primei este de 10 minute, a doua este de 20 de minute, a treia este de 10 minute, a patra este de 30 de minute. Determinați durata ciclului prin metode analitice și grafice cu mișcare secvențială.

6 Se oferă un lot de semifabricate format din patru piese. Lotul trece prin 4 operații: durata primei este de 5 minute, a doua este de 10 minute, a treia este de 5 minute, a patra este de 15 minute. Determinați durata ciclului prin metode analitice și grafice cu mișcare paralelă.

7 Se oferă un lot de semifabricate format din 5 bucăți. Lotul trece prin 4 operații: durata primei este de 10 minute, a doua este de 20 de minute, a treia este de 10 minute, a patra este de 30 de minute. Determinați durata ciclului prin metode analitice și grafice pentru mișcarea în serie-paralelă.

8 Determinați durata ciclului tehnologic pentru prelucrarea unui lot de produse de 180 de bucăți. cu variante paralele şi secvenţiale ale mişcării sale. Construiți grafice ale procesului de procesare. Dimensiunea lotului de transfer este de 30 buc. Standardele de timp și numărul de locuri de muncă din operațiuni sunt după cum urmează.

Tot ceea ce a fost descris în mai multe secțiuni anterioare a fost mai mult orientat către cercetări ulterioare asupra problemei timpului propriu al procesului și într-o măsură mult mai mică asupra aplicațiilor practice. Umplând acest gol, vom schița una dintre modalitățile de a calcula timpul adecvat al unui proces pe baza datelor statistice privind evoluția acestuia.

Să considerăm un proces unidimensional, a cărui stare este caracterizată de o variabilă reală x. Să presupunem că observațiile dinamicii procesului sunt efectuate în timpul astronomic t, astfel încât t = t k și x = x k, k =1, ..., n sunt momente fixe de observație și valorile corespunzătoare ale starea procesului. Există multe metode matematice diferite care fac posibilă construirea de curbe care fie trec prin puncte (t k, Xk) fie „cea mai bună abordare” a acestora. Funcțiile x = x(t) astfel obținute dau naștere în mintea noastră la impresia că procesul luat în considerare depinde de mișcarea mecanică a corpurilor cerești și, prin urmare, starea acestuia se exprimă prin timpul astronomic t. Această concluzie ar putea fi luată în considerare; dacă dificultăţile constante nu au apărut atunci când s-a încercat să prezică cursul ulterior al procesului. Pentru un număr mare de procese diferite care nu sunt direct legate de mișcările mecanice ale corpurilor cerești, predicțiile teoretice obținute folosind funcția x = x(t) în afara intervalului de observație încep să se abate semnificativ de la datele experimentale ulterioare. De obicei, ei încearcă să explice motivul discrepanței dintre teorie și experiment printr-o metodă de procesare selectată fără succes, dar aceasta poate să nu fie esența problemei.

Orice proces care ne interesează are loc în Univers. El cu siguranță „simte” influența mișcării corpurilor cerești. Cu toate acestea, această influență se poate dovedi a fi „nerigidă”, nedeterminantă. Acest lucru, în special, se poate manifesta prin faptul că la anumite intervale de timp astronomic starea procesului rămâne neschimbată. În acest sens, să ne amintim exemplul anterior al unei încăperi goale închise, izolată de lumea exterioară. Să lăsăm un singur viu să zboare în cameră. Pe parcursul mai multor zile, schimbările în starea sistemului „room-fly” vor depinde de mișcările muștei, deoarece nu se pot aștepta modificări ale stării camerei. În același timp, este dificil de imaginat că comportamentul unei muște este strict legat de cursul timpului astronomic.

După ce am făcut o digresiune atât de lungă, să trecem la descrierea algoritmului pentru calcularea timpului propriu al procesului.

În acest algoritm, unitatea de calcul a maximelor locale este aleasă ca măsură naturală a timpului. În plus, sunt luate în considerare posibilele secțiuni ale stării staționare a procesului, la care, după cum sa menționat mai devreme, timpul potrivit se oprește. Deoarece identitatea a două stări poate fi spusă numai în limitele preciziei măsurătorii, în cele ce urmează se utilizează un anumit număr pozitiv e - eroarea de măsurare admisă.

Deci, datele de intrare pentru algoritm sunt numărul natural n, numărul pozitiv 8, matrice (tk) și (x k), k = 1, ..., n. Pentru ușurința programării, algoritmul este prezentat sub forma din patru module executate secvenţial.

Modulul 1, folosind datele p, e, t k), (x k), în cazul general, formează noi matrice 7 = (7+ X = (X t) și o matrice de însoțire foarte specifică P = (?), unde 1 = 1, ..., t și t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Modulul 1 include următoarele proceduri:

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

În pp. Se introduc 1, 2 contoare cu valori inițiale specifice:

În pp. 3, 4 valorile contorului cresc cu 1.

Verificați starea k^n. Dacă este finalizat, treceți la pasul 6, în caz contrar treceți la pasul 11.

Verificați inegalitatea x k --x k = e. Dacă este valabilă, mergeți la pasul 7, în caz contrar treceți la pasul 9.

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

Această procedură înseamnă că, dacă valorile lui Xk și Xk 1 nu se pot distinge în cadrul erorii, atunci toate punctele de timp care încep de la tk sunt reduse cu suma tki-tk.

r = r. Reveniți la punctul 4.

Tv = t k ; X v:=x k; p = p v = v+l., adică. Se formează elemente ale tablourilor T, X, P și se atribuie următoarea valoare v.

• 10. Luați (t k, ..., t n AND (Xk, - X n) ca șirurile originale de dimensiune n--k 1 + 1 și apoi reveniți la pasul 2.
• 11. Tipăriți m, (T), (X,) și (P,), unde i = l, ..., t. Sfârșit.

Să explicăm semnificația elementelor tabloului însoțitor P. Din textul anterior rezultă că valoarea lui pk este egală cu numărul acelor elemente ale tabloului (xk) care urmează direct și diferă de x pi+ ... +, + cu mai puțin decât e. De asemenea, observăm că pi+ ... +p m = n.

Exemplul 1. Dat: 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 , 5,
• 5, 4, 3), vezi fig. 9, a.

Ca rezultat al executării modulului 1, se obține m = 11,

(G) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

i(d.) = (2, 4, 1, 1, 1.3, 2, 1.3, 1, 1), vezi fig. 9, b.

Modulul 2. Datele de intrare pentru acesta sunt un număr natural m, precum și matrice (7+ (X L), = 1, ..., m. Acest modul din matrice (TJ identifică momente de timp [TM a], 1 = 1 m (ml

Exemplul 2. Valorile m, (Ть) și (X,] sunt împrumutate din exemplul anterior. După finalizarea modulului 2, obținem ml = 3, m2 = 8, (Ш,) = (3, 8, 17). ), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), vezi și Fig. 9, b.

Modulul 3. Date de intrare ml, m2, (TM n), 1 = 1, ..., ml, (G*), /2 = 1, ..., gn2.

Acest modul este conceput pentru a construi o matrice (t(-r) folosind formula

Unde este TV 6 [TMp, TMn+i]

Variabila t este timpul propriu generat de modificarea variabilei x. Măsura sa naturală este unitatea de calcul a maximelor locale.

Exemplul 3. Datele inițiale pentru T 2) sunt aceleași cu valorile ml, m2 ITM și în exemplul 2. . După calculele corespunzătoare, obținem Н = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Modulul 4. Generează rezultatul rezultatelor stabilind o corespondență între valorile lui m și elementele x din tabloul (xk).

Exemplul 4. Pe baza datelor din exemplele 2 și 3, se produce următorul rezultat, vezi fig. 9, în:

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

x: 6; 3; 2; 4; 3T 0 2;

Astfel, algoritmul considerat ne permite să dezvoltăm conceptul de timp propriu al procesului pe baza informațiilor despre modificările stării procesului înregistrate pe scara de timp astronomică. Este destul de clar că puteți utiliza alți algoritmi, bazați, de exemplu, pe calcularea unei secvențe de minime locale sau a unei secvențe mixte constând din maxime și minime locale. La procesarea datelor experimentale, probabil că ar trebui testate diferite opțiuni. Dacă, dintr-un motiv oarecare, experimentatorul a ales unul dintre timpii corespunzători specifici și a primit tablouri (t4 și (xk), atunci în etapa următoare ar trebui să folosească câteva metode matematice pentru a aproxima punctele experimentale (t*, x) o linie mondială aproximativă a procesul x = x(t).Extrapolând această linie dincolo de perioada de observație inițială, el poate face predicții despre cursul ulterioar al procesului.

Este interesant de menționat un experiment de calcul menit să evalueze perspectivele utilizării algoritmului propus. Datele privind debitele anuale ale râurilor au fost alese ca material experimental. Vakhsh (Tadjikistan) în ultimii 40 de ani. În aceeași perioadă de timp, au fost preluate informații despre dinamica numărului Wolf - cel mai frecvent utilizat indice integral al activității solare. Acesta din urmă a stat la baza dezvoltării timpului adecvat al procesului de activitate solară. Până în vremurile moderne, informațiile despre cheltuielile fluviale au fost transformate. Vakhsh și apoi, în timpul perioadei de observație, a fost dată o dependență teoretică a debitului de apă în funcție de timpul adecvat al activității solare. O trăsătură caracteristică a graficului rezultat este comportamentul aproape periodic al cheltuielilor maxime și minime. Costurile, însă, nu rămân constante.