Ce poți găti din calmar: rapid și gustos

Implementarea

Este dificil să dai sfaturi cu privire la implementarea codului modulului, deoarece fiecare dezvoltator are anumite obiceiuri și propriul stil de dezvoltare a codului. Atunci când implementați un proiect, este important să coordonați echipele de dezvoltare. Toți dezvoltatorii sunt supuși unor reguli stricte de control al testării sursei. Echipa de dezvoltare, după ce a primit proiectul tehnic, începe să codifice modulele, iar în acest caz sarcina principală este să înțeleagă specificația. Designerul specifică ce trebuie făcut, iar dezvoltatorul stabilește cum să facă acest lucru.

În etapa de dezvoltare, există o interacțiune strânsă între designeri, dezvoltatori și echipele de testare. În cazul dezvoltării intensive, testerul este literalmente „legat” la dezvoltator, fiind de fapt un membru al echipei de dezvoltare.

Designerul în această etapă funcționează ca o „carte de referință pe jos”, deoarece răspunde constant la întrebările dezvoltatorilor cu privire la specificațiile tehnice.

Cel mai adesea, interfețele utilizatorului se schimbă în timpul etapei de dezvoltare. Acest lucru se datorează, printre altele, faptului că modulele sunt demonstrate periodic clientului. Solicitările de date se pot schimba, de asemenea, semnificativ.

De menționat că trebuie să existe un spațiu de lucru dedicat pentru asamblarea întregului proiect. Aceste module sunt trimise pentru testare. Interacțiunea dintre un tester și un dezvoltator fără transferul centralizat al unor părți ale proiectului este acceptabilă, dar numai dacă este necesar să se verifice urgent unele modificări. De foarte multe ori etapa de dezvoltare și etapa de testare sunt interconectate și rulează în paralel. Sistemul de urmărire a erorilor sincronizează acțiunile testatorilor și dezvoltatorilor.

În timpul dezvoltării, ar trebui să fie organizate depozite actualizate constant de module de proiect gata făcute și biblioteci care sunt utilizate la asamblarea modulelor. Este recomandabil ca procesul de actualizare a stocării să fie controlat de o singură persoană. Unul dintre depozite ar trebui să fie pentru modulele care au trecut testele funcționale, iar celălalt pentru modulele care au trecut testele de conectivitate. Prima dintre acestea este schițele. Al doilea este ceva din care este deja posibil să asamblați un kit de distribuție al sistemului și să îl demonstrați clientului pentru efectuarea testelor de control sau trecerea oricăror etape de lucru.

Documentația este creată pe tot parcursul procesului de dezvoltare. Odată ce un modul a trecut testarea legăturii, acesta poate fi descris în documentație. Dacă modulele se schimbă frecvent, descrierea începe doar atunci când modulul devine mai mult sau mai puțin stabil.

Prelucrarea rezultatelor de proiectare

În stadiul de dezvoltare, de regulă, se verifică din nou atomicitatea funcțiilor, precum și absența dublării.

Este de dorit ca în etapa de proiectare să fi fost deja construită o matrice „funcție-entitate”. Este în esență o reprezentare oficială a ceea ce firma încearcă să facă (funcții) și ce informații trebuie procesate pentru a obține un rezultat (entitate). O astfel de matrice vă permite să verificați următoarele puncte:

fiecare entitate are un constructor - o funcție care creează instanțe ale entității (create);
există referințe la această entitate, adică este această entitate folosită oriunde (referințe);
dacă există modificări la această entitate (actualizare);
fiecare entitate are un destructor - o funcție care șterge instanțe ale entității (șterge).

Adesea rolul unui destructor este îndeplinit de un set de programe de arhivare a datelor. Adesea în sistemele informaționale informațiile sunt pur și simplu acumulate. Acest lucru este permis numai dacă pe întreaga perioadă de acumulare de informații (și de fapt pe întreaga activitate de viață sistem informatic) caracteristicile sale de performanță îndeplinesc cerințele clienților. În practică, aceasta este o coincidență extrem de rară. Acest lucru se datorează în principal creșterii volumelor de informații procesate. Trebuie remarcat faptul că, în acest caz, nu vă puteți baza doar pe puterea DBMS sau a hardware-ului, deoarece metode atât de extinse de creștere a productivității dau o creștere estimată scăzută a vitezei. De fapt, sarcina de a reacționa sistemul sau părțile sale individuale la o creștere a volumului de date procesate este cea mai probabilă sarcină de testare. În acest caz, grupul de testare creează un modul pentru generarea de date (chiar abstracte), selectează un set de interogări pentru care caracteristicile de viteză sunt critice, apoi efectuează măsurători și trasează dependența vitezei de execuție de volumul de date pentru fiecare dintre interogări. . O astfel de acțiune simplă vă va permite să evitați greșelile grave atât în proiectarea, cât și în implementarea sistemului informațional.

Specificarea modulelor trebuie finalizată în stadiul de proiectare, căruia de multe ori pur și simplu nu i se acordă importanță în proiectele reale. Și în zadar - pentru că din cauza implementării neconsiderate a modulelor, orice avantaj al schemei bazei de date poate fi pierdut. Astfel, neglijând specificațiile modulelor, riscați să introduceți în sistemul informațional:

creșterea necontrolată a volumelor de date;
fire de execuție cu o probabilitate inerent mare de conflict sau fire de execuție care vor rula „pentru totdeauna” (încercați să executați un fir, să detectați un conflict și să anulați toate acțiunile, să încercați din nou etc.) din cauza unor fire de execuție conflictuale cu acestea;
sistem de amestecare și module de interfață;
duplicarea modulelor;
erori în plasarea logicii de afaceri;
lipsa implementării sau implementarea incompletă a funcțiilor sistemului cerute de client.

Aceasta nu este o listă completă a problemelor care vor fi descoperite fie în etapa de testare cuprinzătoare, fie la punerea în funcțiune a sistemului și poate chiar în timpul funcționării sistemului (când modulele încep efectiv să fie utilizate).

În plus, lipsa specificațiilor modulelor nu vă va permite să evaluați cu exactitate complexitatea fiecărui modul și, ca urmare, să determinați secvența creării modulelor și să distribuiți corect sarcina de personal. Situația obișnuită într-un astfel de caz este „cineva așteaptă pe cineva”, în timp ce procesul de creare a unui sistem informațional se oprește.

Module de sistem

Adesea trebuie să luați în considerare un număr mare de servicii sau procese auxiliare care nu sunt direct legate de funcția de afaceri formulată. De regulă, acestea sunt funcții de sistem găsite în orice sistem informațional, cum ar fi:

manager de cozi sau programator de sarcini;
manager de tipărire;
instrumente pentru accesarea datelor și crearea de interogări ad-hoc (deseori acestea sunt generatoare de rapoarte);
gestionarea directoarelor și a altor resurse ale sistemului de fișiere;
backup automat;
recuperare automată după defecțiunea sistemului;
mijloace pentru reglarea accesului utilizatorilor la sistem (constând dintr-un mijloc de creare a utilizatorilor și un mijloc de atribuire a privilegiilor acestora);
un instrument pentru configurarea mediului pentru utilizatorul sistemului informatic;
un mijloc prin care utilizatorul își poate schimba setările (inclusiv parola);
instrument de gestionare a aplicațiilor;
mediu de administrator al sistemului informatic.

Unele dintre aceste funcții trebuie să fie efectuate de sistemul de operare, dar dacă rulează într-un mediu eterogen, atunci nu există nicio garanție că utilizatorilor le va plăcea prezența diferitelor interfețe în diferite sisteme de operare. În mod ideal, toate aplicațiile client ar trebui să ruleze pe același sistem de operare, dar, în practică, dezvoltatorii trebuie adesea să se ocupe de o întreagă „grădină zoologică” de diferite stații de lucru la client - rezultatul mai multor încercări de a automatiza afacerea. Scopul dezvoltatorului este de a aduce sistemul la cea mai omogenă stare sau de a asemăna cel puțin stațiile de lucru ale utilizatorului final.

Sarcina de a crea un sistem informațional într-un mediu eterogen crește semnificativ cerințele pentru dezvoltatorii de cod și pentru instrumentul de dezvoltare selectat. Acest lucru este valabil mai ales pentru dezvoltarea modulelor de sistem. Trebuie acordată atenție modulelor a căror implementare a codului depinde de sistemul de operare. Astfel de module trebuie alocate separat pentru fiecare sistem de operare în grupuri, de exemplu Win98, WinNT etc. Modulele fiecărui grup trebuie să aibă interfețe de schimb stricte - datele pe care le transmit și le primesc sunt strict definite, iar orice abatere de la specificație se pedepsește. Niciunul dintre modulele din afara acestui grup nu poate folosi alte apeluri decât interfețele de schimb. În acest fel, modulele care depind de sistemul de operare sunt izolate de alte module.

În general vorbind, practica izolării modulelor de sistem prin reglementarea strictă a interfețelor lor de comunicație minimizează semnificativ costurile de corectare a erorilor și suport al sistemului. În plus, acest lucru facilitează testarea, și anume detectarea erorilor și depanarea. Cealaltă parte a problemei este că cerințele pentru codul de interfață de schimb al modulului de sistem cresc brusc. Acesta este ceea ce este depanat mai întâi și ar trebui să funcționeze foarte clar.

Instrumente de monitorizare a sistemului informatic

Dacă sistemul informațional este mare, atunci ar trebui să luați în considerare sarcina de a-l administra de la o singură stație de lucru. Este necesar să aveți grijă nu numai de utilizatorul final al sistemului informațional, ci și de personalul care îl va deservi. O atenție deosebită trebuie acordată monitorizării zonelor critice ale sistemului informațional, deoarece o defecțiune este adesea mai ușor de prevenit decât de corectat consecințele acesteia.

Monitorizarea se referă la acele sarcini pe care clientul, de regulă, nu se gândește la necesitatea de a le rezolva și care lipsesc de obicei în studiul analitic și chiar în proiectare. Necesitatea instrumentelor de monitorizare devine evidentă abia în etapa punerii în funcțiune a sistemului, iar această nevoie este mai mare, cu cât sistemul este mai complex și cu atât mai multe secțiuni critice pe care le conține.

Dezvoltatorii și designerii ar trebui să evalueze complexitatea sistemului. Dacă se ia decizia de a scrie un instrument cuprinzător de administrare și monitorizare care nu este prevăzut în specificațiile tehnice, atunci în acest caz specificațiile tehnice ar trebui modificate și să nu urmeze exemplul clientului. Într-un sistem complex, va trebui totuși să monitorizați procesele critice. Este foarte dificil să implementați astfel de instrumente într-un sistem gata făcut, deoarece monitoarele primesc adesea date inițiale de la modulele de sistem de un nivel destul de scăzut. De asemenea, este puțin probabil ca acest lucru să fie posibil fără modificări ale schemei bazei de date și nu există nicio garanție că o astfel de modificare nu va degrada performanța sistemului.

Dezvoltarea monitoarelor este o clasă destul de specifică de sarcini: pe de o parte, trebuie să proceseze o cantitate suficientă de informații, pe de altă parte, nu trebuie să afecteze în mod semnificativ funcționarea altor componente ale sistemului informațional. Acest lucru îi obligă pe dezvoltatori să fie deosebit de atenți atunci când proiectează monitoare și scriu cu mare atenție codul modulelor lor.

Interfețe

Interfețele pentru utilizatorul final sunt ceea ce clientul critică cel mai mult, datorită faptului că aceste părți ale sistemului informațional le poate evalua mai mult sau mai puțin competent - de obicei sunt singurele pe care le vede. Aceasta înseamnă că interfețele sunt elementul cel mai frecvent schimbat al unui sistem informațional în etapa de implementare.

fiecare cerere este codificată cu un identificator sau „închisă” de o anumită funcție de sistem;
dezvoltatorul interfeței nu știe nimic despre cererea de date, cu excepția parametrilor atributelor de selecție - tipul acestora și, eventual, numărul de rânduri din selecție;
tratarea erorilor în cererile de date este un modul separat;
tratarea erorilor în interpretarea rezultatului cererii este, de asemenea, un modul separat.

Atunci când se prelucrează rezultatele interogărilor de date, trebuie acordată o atenție deosebită problemelor de corespondență dintre tipurile de limbă gazdă și SGBD, inclusiv problemele de acuratețe a tipurilor numerice, deoarece reprezentarea lor variază semnificativ între diferitele SGBD. De asemenea, fiți conștienți de interogările de date care utilizează funcții specifice sistemului de operare, cum ar fi funcțiile de octeți și cuvinte ale unei valori de atribut (de exemplu, aceste funcții vor funcționa diferit pe Intel și SUN SPARC). Tipurile de date pot fi turnate fie în mod explicit în cerere, utilizând funcții de turnare și funcții încorporate în DBMS, fie în funcțiile programului de aplicație. Nu pentru toate SGBD-urile, conversia implicită de tip dă același rezultat, așa că dacă un sistem informațional folosește date din mai multe baze de date gestionate de SGBD-uri diferite, atunci este mai bine să se evite conversiile implicite de tip.

De asemenea, ar trebui să stabiliți reguli destul de stricte pentru apariția interfețelor cu utilizatorul. Ar trebui creată impresia unui singur stil pentru toate componentele sistemului informațional.

Versiuni de baze de date

În cele mai multe cazuri, prima versiune a bazei de date a proiectului este creată destul de rapid - aceasta este implementarea unei structuri complet normalizate, care se obține în etapa de analiză. Scopul principal al acestei baze de date este de a oferi prototipuri, demonstrații și unele experimente de către dezvoltatori și designeri.

Scripturile pentru crearea unei baze de date și completarea acesteia cu date de pornire sunt, de asemenea, codul sursă al sistemului informațional și i se aplică regulile de control al versiunilor. Trebuie remarcat faptul că menținerea versiunilor de baze de date la nivel de script este încă mai ușoară decât la nivelul instrumentelor de descărcare și încărcare a datelor furnizate de SGBD în sine, deoarece în marea majoritate a cazurilor astfel de instrumente nu pot oferi câteva funcții simple, dar necesare:

controlați ce obiecte de date și date au loc în obiectele de încărcare A și B și încărcați numai „diferența” dintre A și B în baza de date (efectuați o actualizare a versiunii);
verificați dacă modificările care au loc în obiectele de încărcare C și D nu intră în conflict în comparație cu obiectul de încărcare A (unește versiunile).

Instrumentele CASE au controlul versiunii schemei bazei de date, iar unele au setări care vă permit să controlați și datele de pornire. Acest lucru face posibilă utilizarea acestor instrumente pentru a oferi controlul versiunii bazei de date.

Este mai fiabil să controlați versiunile codului sursă al declanșatorilor și procedurilor stocate prin utilizarea aceluiași sistem de control al versiunilor care este adoptat pentru stocarea codului sursă al proiectului însuși.

Plasarea logicii de procesare

Una dintre problemele importante de proiectare este modul de plasare a logicii de afaceri pentru prelucrarea datelor: plasați-o (și ce parte) fie pe server sub formă de proceduri stocate, pachete, declanșatoare, alte constrângeri de integritate direct pe serverul bazei de date, fie sub formă de funcții pe client (în software-ul client). Locația regulilor de interfață și a regulilor de date este specificată cu precizie: primele sunt întotdeauna localizate pe client, cele din urmă - pe server. Regulile logicii de afaceri în SGBD-urile moderne pot fi plasate atât pe client, cât și pe server. Să ne uităm la un exemplu de regulă simplă de afaceri:

Valoarea din câmpul de afișare este introdusă de utilizator, mai degrabă decât selectată dintr-o listă, dar setul de valori valide este strict limitat (de exemplu, două sau trei valori diferite).

Pe de o parte, utilizatorul necesită un răspuns imediat din partea sistemului la o eroare de introducere a datelor, pe de altă parte, valorile dintr-un câmp al bazei de date care diferă de cele specificate (două sau trei) sunt inacceptabile. Există de fapt două reguli care trebuie implementate în această situație. Regula de date în acest caz va fi organizată sub forma unei constrângeri de verificare, iar regula de interfață care interzice introducerea altor valori decât cele specificate va repeta exact regula de date, dar va fi implementată la nivel de interfață cu utilizatorul. S-ar părea că implementarea unui formular cu o listă în acest caz este soluția ideală, dar majoritatea operatorilor preferă tipul din formular, mai ales dacă lungimea valorii de intrare este mică. Formularele cu un număr mare de liste sunt destul de dificil de procesat de către utilizatorii finali. În cazul unui set de valori într-o formă, trebuie avut grijă și la convertirea șirurilor de caractere (acolo unde majusculele nu sunt semnificative) în litere mari sau mici, la nivelul interfeței programului aplicației.

Șabloane

Utilizarea șabloanelor și bibliotecilor pentru a construi module „similare” este o practică destul de comună. Ce să utilizați în acest caz - obiecte și clase sau biblioteci - este decis de un grup specific de dezvoltatori. În cele mai multe cazuri, dictarea unei metode de dezvoltare este inutilă, deoarece dezvoltatorul scrie codul așa cum știe sau este obișnuit. Aceste momente sunt de obicei controlate de managerul de proiect.

În orice proiect, copierea codului este interzisă, deoarece aceasta duce la apariția unor versiuni diferite ale aceluiași cod în diferite fragmente ale programului de aplicație și, ca urmare, la erori greu de detectat și corectat. Ar trebui stabilită o regulă strictă: se folosește un apel de funcție, și nu o copie a acestuia în cod; orice abatere de la această regulă este pedepsită.

Testare

După cum sa menționat mai sus, grupurile de testare pot fi implicate deja în fazele incipiente ale dezvoltării proiectului. Testarea cuprinzătoare în sine ar trebui să fie într-adevăr separată într-o etapă de dezvoltare separată. În funcție de complexitatea proiectului, testarea și remedierea erorilor pot ocupa o treime, jumătate sau mai mult din timpul de dezvoltare al întregului proiect.

Cu cât proiectul este mai complex, cu atât este mai mare nevoia de a automatiza sistemul de urmărire a erorilor. Un astfel de sistem oferă următoarele funcții:

stocarea unui mesaj de eroare (cu informații obligatorii despre ce componentă a sistemului se referă la eroarea, cine a găsit-o, cum să o reproducă, cine este responsabil pentru remedierea acesteia și când ar trebui remediată);
sistem de notificare despre apariția unor noi erori, despre modificările stării erorilor cunoscute în sistem (de regulă, acestea sunt notificări de către e-mail);
rapoarte privind erorile curente pe componente ale sistemului, pe intervale de timp, pe grupuri de dezvoltare și dezvoltatori;
informații despre istoricul erorii (inclusiv urmărirea erorilor similare, urmărirea reapariției erorii);
reguli de accesare a erorilor din anumite categorii;
interfață de acces limitat la sistemul de urmărire a erorilor pentru utilizatorul final al sistemului informatic, care este utilizată ca interfață pentru schimbul de informații între utilizator și serviciul de suport tehnic al sistemului.

Astfel de sisteme elimină multe probleme organizaționale, în special problema notificării automate a erorilor.

Testele de sistem în sine pot fi împărțite în mai multe categorii:

teste de module autonome - sunt utilizate deja în stadiul de dezvoltare a componentelor sistemului și vă permit să urmăriți erorile componentelor individuale;
teste de conectare a componentelor sistemului - utilizate atât în etapa de dezvoltare, cât și în etapa de testare și vă permit să monitorizați interacțiunea corectă și schimbul de informații între componentele sistemului;
testul sistemului este principalul criteriu de acceptare a sistemului. De regulă, acesta este un grup de teste care include teste autonome, teste de conectare și modele. Acest test trebuie să reproducă funcționarea tuturor componentelor și funcțiilor sistemului; scopul său principal este acceptarea internă a sistemului și evaluarea calității acestuia;
test de acceptare - utilizat la predarea sistemului către client. Aici, dezvoltatorii scad adesea cerințele de sistem în comparație cu testul de sistem și, în general, este clar de ce acest lucru este justificat;
testele de performanță și de sarcină sunt incluse în testul sistemului, dar merită o mențiune specială, deoarece acest grup de teste este principalul pentru evaluarea fiabilității sistemului.

Testele fiecărui grup includ în mod necesar teste de modelare a eșecului. Aici se verifică reacția unei componente, a unui grup de componente sau a sistemului în ansamblu la defecțiuni de următorul tip:

defectarea unei componente separate a sistemului informatic;
defecțiunea unui grup de componente ale sistemului informațional;
defectarea principalelor module ale sistemului informatic;
defecțiune a sistemului de operare;
defecțiune „hard” (cădere de curent, defecțiune hard disk).

Aceste teste fac posibilă evaluarea calității subsistemului pentru restabilirea stării corecte a sistemului informațional și servesc drept sursă principală de informații pentru elaborarea strategiilor de prevenire a consecințelor negative ale defecțiunilor în timpul funcționării industriale. De obicei, aceasta este clasa de teste pe care dezvoltatorii le neglijează și apoi se luptă cu consecințele eșecurilor asupra sistemului de producție.

Un alt punct important al programului de testare a sistemelor informatice este disponibilitatea generatoarelor de date de testare. Acestea sunt utilizate pentru a efectua atât teste de funcționalitate a sistemului, teste de fiabilitate a sistemului, cât și teste de performanță a sistemului. Sarcina de a evalua caracteristicile dependenței performanței unui sistem informațional de creșterea volumelor de informații prelucrate nu poate fi rezolvată fără generatori de date.

Operare și întreținere

exploatarea torturii prevalează asupra procesului de testare. De regulă, sistemul nu este pus pe deplin în funcțiune, ci treptat.

Punerea în funcțiune trece prin cel puțin trei etape:

acumularea de informații;

atingerea capacităţii de proiectare.

Încărcarea inițială a informațiilor inițiază o gamă destul de restrânsă de erori - în principal acestea sunt probleme de nepotrivire a datelor în timpul încărcării și erorile proprii ale încărcătoarelor, adică ceea ce nu a fost urmărit în datele de testare. Astfel de erori trebuie corectate cât mai repede posibil. Nu fi leneș să instalați o versiune de depanare a sistemului (dacă, desigur, aveți voie să implementați întregul complex de software care însoțește depanarea sistemului informațional la fața locului). Dacă este imposibil să depanați datele „pe live”, atunci va trebui să simulați situația și rapid. Acest lucru necesită testeri foarte calificați.

În perioada de acumulare a informațiilor va apărea cel mai mare număr de erori făcute în timpul realizării sistemului informațional. De regulă, acestea sunt erori legate de accesul multi-utilizator. Adesea, în etapa de testare, unor astfel de erori nu li se acordă atenția cuvenită - aparent din cauza complexității modelării și a costului ridicat al instrumentelor de automatizare a proceselor testarea sistem informaţional în condiţii de acces multi-utilizator. Unele erori vor fi destul de greu de corectat deoarece sunt erori de proiectare. Niciun proiect bun nu este imun la ei. Aceasta înseamnă că, pentru orice eventualitate, trebuie să rezervați timp pentru localizarea și corectarea unor astfel de erori.

În perioada de acumulare de informații, s-ar putea să întâlniți faimoasa „bază a căzut”. În cel mai rău caz, se dovedește că SGBD nu poate rezista fluxului de informații. Dacă este bine, parametrii de configurare sunt pur și simplu incorecți. Primul caz este periculos, deoarece este destul de dificil să influențezi producătorul DBMS, iar clientului chiar nu-i plac link-urile către serviciul de asistență tehnică DBMS. Nu producătorul va trebui să rezolve problema eșecului DBMS, ci tu - schimbați schema, reduceți fluxul de solicitări, modificați cererile în sine; în general - există multe opțiuni. Este bine dacă timpul de recuperare de bază se încadrează în cel planificat.

Atingerea capacității de proiectare a sistemului într-o combinație reușită de circumstanțe înseamnă corectarea unui număr de erori minore și, ocazional, erori grave.

Alte abordări de dezvoltare a aplicațiilor

În mod obișnuit, utilizatorii finali și managementul cred că procesul de proiectare nu a dat rezultate, deoarece nu există componente disponibile pe raft de „atins”. Adesea, clientul insistă să efectueze etapa de implementare a proiectului înainte de termen pentru a obține un anumit rezultat și a-l demonstra cât mai repede posibil. În acest caz, este foarte tentant să alegeți Accelerated Application Development (AAD) sau Collaborative Application Development (CAD). Astfel de metode implică dezvoltarea unui prototip funcțional și apoi demonstrarea lui utilizatorilor. Utilizatorii comentează ce le place și ce nu. Designerul rafinează prototipul ținând cont de comentariile făcute, iar apoi demonstrează din nou ce s-a întâmplat. Și așa mai departe. Procesul se repetă până când utilizatorilor le place ceea ce văd, iar prototipul devine o aplicație funcțională. De obicei, există o limită de timp și un număr de iterații, altfel utilizatorii vor îmbunătăți prototipul pentru totdeauna.

În teorie, acest lucru vă permite să obțineți sistemul de care au nevoie utilizatorii.
În practică, această abordare a dezvoltării aplicațiilor ridică probleme serioase.
Toată atenția este concentrată asupra formelor de ecran, iar ceea ce privește regulile de prelucrare a datelor și funcțiile sistemului rămâne în spatele scenei. Există tentația de a începe lucrul cu rapoarte, în timp ce un raport nu este un produs de pornire, ci un produs derivat al unui sistem informațional.
Utilizatorii presupun că dacă versiunea prototip este convenită, atunci modulul este gata. De fapt, aceasta poate fi doar o imagine cu un set de „stubs” pentru apelarea funcțiilor sistemului și interacțiunea cu alte module.
Documentația atunci când se utilizează metoda URP, de regulă, este absentă sau, mai degrabă, se uită necesitatea de a documenta sistemul, deoarece se creează iluzia că utilizatorul înțelege deja ce se întâmplă. Când o aplicație începe să funcționeze diferit decât se așteaptă utilizatorul, apar o mulțime de probleme.
Situațiile de excepție sunt tratate diferit pentru fiecare modul.
Un sistem complet, de regulă, nu funcționează, cel mai probabil, va fi un anumit set de stații de lucru automate, conectate în grabă între ele.

Metodele URP și SRP nu pot fi folosite întotdeauna, ci numai dacă:

Sfera de aplicare a proiectului și cerințele de afaceri sunt clar definite, nu se modifică, iar proiectul în sine este mic;
proiectul nu depinde de alte instrumente de automatizare a afacerii numărul de interfețe externe de care va trebui tratat este limitat;
sistemul este axat pe formulare de ecran, procesarea datelor și funcțiile sistemului reprezintă o parte nesemnificativă, comoditatea formularelor de ecran este în primele cinci cei mai importanți factori succesul proiectului;
utilizatorii sunt înalt calificați și evaluează a priori pozitiv ideea de a crea un nou software.

Cu toate acestea, este mai bine să dezvoltați părți mici și, de preferință, autonome ale proiectului folosind metoda URP.

În prezent, s-a încercat să se introducă o altă modalitate de a scrie rapid un proiect - metoda de programare extremă. Principiile acestei abordări vor fi discutate mai jos.

Joc de planificare. Pe baza evaluărilor făcute de programatori, clientul stabilește funcționalitatea și perioada de implementare a versiunilor de sistem. Programatorii implementează numai acele caracteristici care sunt necesare pentru caracteristicile selectate într-o iterație dată.

Ca urmare a acestei decizii, dezvoltarea sistemului rămâne „în spatele scenei”, drept care în timpul dezvoltării este nevoie de a construi „stubs” și de a rescrie codul. Nu este clar de ce termenul limită de implementare este determinat de client, deoarece de fapt aceasta este responsabilitatea directă a echipei de proiectare. Clientul, în general, își poate exprima doar dorințele în ceea ce privește termenele limită („Îmi doresc până la o astfel de dată”), dar numai proiectantul poate stabili termenul limită („se poate face în nu mai puțin de așa și așa timp").

Schimbări frecvente ale versiunilor (lansări mici). Sistemul este pus în funcțiune în decurs de câteva luni de la începerea implementării, fără a aștepta rezolvarea definitivă a tuturor problemelor ridicate. Noile versiuni pot fi lansate la intervale de la zilnic la lunar.

Totul este bine, cu excepția unui singur lucru: este imposibil să testezi o componentă mai mult sau mai puțin complexă într-o astfel de perioadă. Clientul acționează de fapt ca un tester beta. În acest caz, el poate vedea că dezvoltatorii lucrează din greu și chiar remediază erori. Cu toate acestea, apar întrebări rezonabile: merită introducerea clientului în procesul de lucru și este necesar să se efectueze experimente pe sistem de lucru? În plus față de cele de mai sus, trebuie remarcat faptul că un astfel de principiu este puțin probabil să fie implementat pentru părți ale proiectului care necesită funcționare 24x7.

Metaforă. Aspectul general al sistemului este determinat folosind o metaforă sau un set de metafore la care clientul și programatorii lucrează împreună.

Pe de o parte, acest postulat pare destul de bun, dar, pe de altă parte, are sens să inițiezi clientul în afacerile interne ale grupului de dezvoltare? Ceea ce privește aspectul general (interfețe, rapoarte etc.) poate fi într-adevăr de competența clientului, dar atunci când despre care vorbim despre specificul implementării anumitor componente, clientul poate fi cu greu util din cauza lipsei de cunoștințe necesare.

Design simplu. În fiecare moment, sistemul dezvoltat efectuează toate testele și suportă toate relațiile definite de programator, nu are duplicate de cod și conține numărul minim posibil de clase și metode. Această regulă poate fi exprimată pe scurt după cum urmează: „Formulează fiecare gând o dată și o singură dată”.

Această idee este, de asemenea, bună, dar nu se potrivește tocmai cu principiul scrierii rapide a codului. Poate ar trebui să vă gândiți mai întâi cum să faceți acest sau acel modul, un grup de module și abia apoi să începeți să scrieți cod?

Teste. Programatorii scriu teste unitare tot timpul. Luate împreună, aceste teste ar trebui să funcționeze corect. Pentru etapele dintr-o iterație, clienții scriu teste funcționale, care trebuie să funcționeze și corect. Cu toate acestea, în practică, acest lucru nu este întotdeauna realizabil. A accepta decizia corectă, este necesar să înțelegeți cât va costa livrarea unui sistem cu un defect cunoscut anterior și să comparați acest lucru cu costul întârzierii corectării defectului.

Când scrieți teste de către programatori înșiși (mai ales în condiții munca suplimentara) aceste teste nu sunt pe deplin funcționale și, cu siguranță, nu țin cont de particularitățile muncii cu mai mulți utilizatori. De obicei, dezvoltatorii nu au suficient timp pentru teste mai avansate. Puteți, desigur, să construiți un sistem de dezvoltare, astfel încât aceiași oameni să se ocupe de totul, dar totuși nu ar trebui să transformați proiectul într-un analog al emisiunii TV „Propriul director”. Este necesar să adăugăm la cele de mai sus că testarea sistemului nu se limitează la testarea componentelor (unităților); Testele de interacțiune dintre ele nu sunt mai puțin importante și același lucru este valabil și pentru testele de fiabilitate. Cu toate acestea, metoda de programare extremă nu prevede crearea de teste din această clasă. Acest lucru se explică prin faptul că astfel de teste în sine pot reprezenta un cod destul de complex (acest lucru este valabil mai ales pentru testele care simulează funcționarea reală a sistemului). De asemenea, această tehnologie nu ține cont de o altă clasă importantă de teste - testele comportamentului sistemului atunci când volumul de informații procesate crește. Cu o rată mare de modificări de versiune, este imposibil din punct de vedere tehnologic să se efectueze un astfel de test, deoarece implementarea sa necesită un cod de proiect stabil și neschimbat, de exemplu, într-o săptămână. Astfel de termene, în general, nu sunt garantate din cauza modificărilor frecvente ale versiunilor. În acest caz, va trebui fie să suspendați dezvoltarea componentelor, fie să creați o versiune paralelă a proiectului în timpul testului, care va rămâne neschimbată, în timp ce a doua se va modifica. Apoi va trebui să efectuați procesul de îmbinare a codului. Dar, în acest caz, testul va trebui creat din nou, deoarece metodele de programare extremă pur și simplu nu prevăd dezvoltarea de instrumente care să permită prezicerea comportamentului sistemului la anumite modificări.

Refactorizarea sistemului. Arhitectura sistemului este în continuă evoluție. Proiectul actual este transformat, asigurându-se în același timp că toate testele sunt efectuate corect.

Aici începe distracția. Extreme Programming se bazează pe premisa că este întotdeauna posibil să o refaceți și fără prea multe cheltuieli. Cu toate acestea, practica arată contrariul.

Programare pereche. Tot codul proiectului este scris de două persoane care folosesc același sistem desktop.

Se pune întrebarea: a văzut cineva doi programatori complet identici, fiecare dintre care, la sfârșitul zilei de lucru, ar avea timp să scrie documentație pentru partenerul său? Este posibil să găsim programatori gemeni care sunt de acord cu totul?

Și cel mai important, de ce avem nevoie de o astfel de pereche de programatori? Motivul, în general, este simplu: nu toată lumea poate rezista ritmului ridicat de lucru impus de programarea extremă, iar o ieșire de personal este inevitabilă. Un astfel de cuplu poate oferi un fel de asigurare - dacă unul renunță, atunci poate că al doilea va duce treaba până la sfârșit. Adevărat, cel rămas se va încadra într-un interval de timp și mai strâns - la urma urmei, cantitatea de muncă va rămâne aceeași și nu va exista nicio rezervă, cel puțin pentru ceva timp. Ceea ce urmează este un proces natural de transfer de informații către noul substudent, care din nou necesită timp. Și așa mai departe la nesfârșit.

Integrare continuă. Noul cod este integrat în sistemul existent în câteva ore. După aceasta, sistemul este reasamblat într-un singur întreg și se execută toate testele. Dacă cel puțin unul dintre ele nu este efectuat corect, modificările efectuate sunt anulate.

Acest postulat este cel puțin controversat, deoarece nu este clar cine va corecta erorile, nu numai cele locale, ci și induse cod greșit. La urma urmei, nu se așteaptă să fie efectuate teste complexe în această etapă, în plus, modificările rămân chiar dacă este detectată o eroare. În același timp, metoda Extreme Programming nu prevede un sistem de urmărire a erorilor.

Proprietatea colectivă. Fiecare programator are posibilitatea de a îmbunătăți orice parte a codului din sistem în orice moment dacă consideră că este necesar.

Asta nu vă amintește de anarhie? Cum să găsiți autorul modificărilor în acest caz? A întâlnit cineva vreodată un astfel de „joc de toate meserii” în timpul dezvoltării unui proiect mare și cât timp ar putea un astfel de „mânuitor” să reziste la locul de muncă? Așa e, nu prea mult.

Client la fața locului. Un client care face parte din echipa de dezvoltare în timpul perioadei de lucru la sistem.

Acest lucru, desigur, este bun, dar scopul este neclar: fie să-l lamurească pe client asupra esenței problemei, fie să-l facă un coautor? Este puțin probabil ca doar clientul să aibă un specialist atât de înalt calificat.

săptămâni de 40 de ore. Volumul orelor suplimentare nu poate depăși o săptămână lucrătoare ca durată. Chiar și cazurile izolate de ore suplimentare, repetate prea des, sunt semnul unor probleme grave care necesită o atenție imediată.

După cum arată practica utilizării programării extreme (în ciuda numărului de exemple pozitive date de susținătorii acestei metode), orele suplimentare cu această abordare sunt regula, nu excepția, iar lupta împotriva problemelor în acest caz este un fenomen constant. Se intensifică în perioada de înlocuire a actualei versiuni brute a produsului cu o altă versiune, din nou brută. Clientul, inițiat în proces, experimentează asupra lui însuși toate deliciile manifestării erorilor de sistem. Cât timp credeți că va avea suficientă răbdare clientul în această stare de lucruri? Are nevoie ca sistemul să funcționeze...

Deschideți spațiul de lucru. Echipa de dezvoltare este situată într-o cameră mare, înconjurată de încăperi mai mici. În centrul spațiului de lucru sunt instalate computere pe care lucrează perechi de programatori.

În plus, toate acestea, judecând după principiile anterioare, ar trebui să fie situate pe teritoriul clientului, deoarece acesta este foarte activ implicat în procesul de dezvoltare. Apare întrebarea: este reală o asemenea coincidență norocoasă?

Nimic mai mult decât reguli. Membrii echipei care lucrează folosind tehnologia de programare extremă se angajează să respecte regulile menționate. Acestea nu sunt însă altceva decât reguli și echipa le poate schimba oricând dacă membrii săi au ajuns la un acord de principiu cu privire la modificările efectuate.

Poate că, în cele din urmă, va fi dezvoltată o regulă utilă: „mai întâi gândește, apoi face”. În acest caz, vom avea un model foarte asemănător cu o „cascada”. Din anumite motive, susținătorii programării extreme sunt convinși că atunci când se utilizează „cascada” și clonele sale, ciclul de dezvoltare trebuie să fie lung. Nu este clar ce cauzează o astfel de încredere. La urma urmei, nu este interzisă împărțirea proiectului în etape. Din anumite motive, se crede că planificarea va fi neapărat o singură dată și neschimbată, deși, de fapt, acest lucru nu este adevărat, inclusiv în cazul unei „cascade”.

În consecință, obținem o metodă care este potențial foarte adaptabilă la cerințele de proiect foarte în schimbare, dar în același timp nu este lipsită de o serie de dezavantaje serioase. Această din urmă împrejurare nu ne permite să recomandăm această metodă pentru utilizare pentru proiecte care necesită o fiabilitate ridicată sau cel puțin suficientă de funcționare.

ComputerPress 2"2002

Este ușor să trimiți munca ta bună la baza de cunoștințe. Utilizați formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Documente similare

Caracteristici de proiectare a sistemelor informatice bazate pe baze de date. Utilizarea instrumentelor CASE și descrierea proceselor de afaceri în BP-Win. Etape de proiectare a sistemelor informatice moderne, tipuri de diagrame și reprezentare vizuală a unui site web.

lucrare curs, adaugat 25.04.2012

Analiza comparativă sisteme informatice hoteliere. Analiza și selecția instrumentelor CASE pentru modelarea proceselor de afaceri. Modele vizuale și matematice ale disciplinei, alegerea arhitecturii și platformei sistemului informațional, construcția bazei de date.

teză, adăugată 20.07.2014

Sisteme automate de proiectare. Analiza comparativă a instrumentelor de proiectare a sistemelor informatice automatizate. Exportați codul SQL în mediul fizic și completați baza de date cu conținut. Etapele dezvoltării și caracteristicile instrumentelor Case.

lucrare curs, adăugată 14.11.2017

Conceptul de instrumente CASE ca software care sprijină procesele de creare și întreținere a sistemelor informaționale (IS). Caracteristicile tehnologiei IDEF pentru dezvoltarea IP. Descrierea notației IDEF0. Dezvoltarea modelelor funcționale de procese de afaceri.

prezentare, adaugat 04.07.2013

Revizuirea principiilor de construcție și aplicare eficientă sisteme de gestionare a bazelor de date, instrumente de automatizare a proiectării CASE. Analiza capacităţilor metodologiei şi instrumentelor. Dezvoltarea unui model de proces de business hotelier în mediul All Fusion.

lucrare curs, adaugat 28.12.2012

Disponibilitatea unui sistem informatic economic. Matricea proiecțiilor organizaționale. Dezvoltarea unui sistem de baze de date. Instrumente moderne CASE. Principalele etape ale dezvoltării sistemelor informaționale. Indicator absolut și indice de reducere a costurilor.

lucrare curs, adaugat 14.03.2011

Fundamentele de bază ale dezvoltării software: ciclul său de viață clasic, prototipare, strategii de proiectare, modele de calitate ale proceselor de dezvoltare. Aplicarea algoritmilor paraleli si a sistemelor CASE, criterii de evaluare a eficacitatii acestora.

lucrare de curs, adăugată 04.07.2015

Rolul instrumentelor de proiectare în crearea unui sistem informațional. Avantajele instrumentelor de dezvoltare CASE Bpwin și Erwin, sisteme de căutare, corectarea erorilor modelului de date Model Validator. Dezvoltarea unui model de procese de flux de documente ale întreprinderii.

test, adaugat 24.06.2012

Implementarea IP corporativă, dezvoltată independent sau achiziționată de la un furnizor, este adesea însoțită de întreruperea (reproiectarea) proceselor de afaceri existente la întreprindere. Trebuie să le reconstruim pentru a îndeplini cerințele standardelor și logica sistemului implementat. Să observăm imediat că introducerea sistemelor informaționale rezolvă o serie de probleme manageriale și tehnice, dar dă naștere unor probleme asociate cu factorul uman.

Implementarea unui sistem informatic, de regulă, facilitează foarte mult managementul activităților întreprinderii, optimizează fluxurile de informații interne și externe și elimină blocajele în management. Cu toate acestea, după ce sistemul a fost instalat cu succes, „testat” în funcțiune și s-a dovedit a fi eficient, unii angajați arată reticenți în a utiliza SI în munca lor. Ca rezultat al reinginerării, devine clar că unii angajați dublează în mare măsură munca altora sau nu sunt deloc necesari. În plus, implementarea CIS este însoțită de formare obligatorie, dar, după cum se arată experiență rusă Nu sunt mulți oameni dispuși să se recalifice. Spărgerea vechilor abilități și insuflarea altora noi este un proces lung și dificil!

Trebuie să se înțeleagă clar că IP corporativă este concepută pentru a simplifica managementul unei organizații, a îmbunătăți procesele, a consolida controlul și, prin urmare, a oferi beneficii competitive. Numai din acest punct de vedere pot fi evaluate beneficiile implementării sale.

Urmând această logică, devine clar că, deși IS-ul întreprinderii este destinat ca un întreg să ofere tuturor utilizatorilor informatiile necesare, managementul dezvoltării și implementării CSI este apanajul conducerii de vârf a companiei! Liderii înțeleg asta?

Și aici trebuie să luptăm împotriva stereotipurilor persistente. „De ce ar trebui sistem corporativ, dacă lucrurile merg deja bine la întreprindere?" „De ce să spargeți ceva dacă totul funcționează?" Dar cel mai adesea nu este nevoie să-l rupeți. În prima etapă, trebuie doar să formalizați și să transferați în mod competent și corect datele identificate procesele, în care trăiește întreprinderea, în IP corporativă. O astfel de formalizare nu va face decât să clarifice și să șlefuiască descoperirile de marketing și producție de succes, să optimizeze procesul de management și control și să permită schimbări ulterioare.

Introducerea unui nou IS este un proces complex, care durează de la câteva luni pentru SI mici până la câțiva ani pentru SI ale companiilor mari distribuite cu o gamă largă de produse și un număr mare de furnizori. Succesul unui proiect pentru dezvoltarea (sau achiziția) și implementarea unui sistem informațional depinde în mare măsură de disponibilitatea întreprinderii de a conduce proiectul, de interesul personal și de voința managementului, de un program realist de acțiune, de disponibilitatea resurselor, personal instruit și capacitatea de a depăși rezistența la toate nivelurile organizației stabilite.

Până acum a existat set standard Tehnici de implementare a IS. Regula de bază este de a finaliza secvențial fazele necesare și de a nu sări peste niciuna dintre ele.

Următorii factori sunt critici pentru implementare:

· prezența obiectivelor de proiect și a cerințelor IP clar formulate;

· disponibilitatea unei strategii pentru implementarea și utilizarea IP;

· realizarea unui sondaj pre-proiect al întreprinderii și a modelelor de construcție „Așa cum este” și „Așa cum va fi”;

· planificarea lucrărilor, resurselor și monitorizarea implementării planului de implementare;

· participarea managementului superior la implementarea sistemului;

· desfășurarea lucrărilor de implementare a SI de către specialiști în integrare de sisteme împreună cu specialiști în întreprindere;

· monitorizarea periodică a calității muncii prestate;

· primirea rapidă a rezultatelor pozitive, cel puțin în parte din modulele SI implementate sau în cursul acestuia operațiune de probă.

Înainte de a începe elaborarea unui proiect de implementare, trebuie să:

· formalizarea obiectivelor proiectului de implementare SI pe cât posibil;

· evalua minim costurile necesareși elemente de cheltuieli;

· stabiliți o prioritate ridicată pentru proiectul de implementare față de alte proiecte în derulare;

· acorda managerului de proiect maximele puteri posibile;

· desfășoară activități educaționale de masă cu personalul întreprinderii pentru a transmite tuturor importanța și necesitatea transformărilor viitoare;

· elaborarea de măsuri organizatorice pentru aplicarea noilor tehnologia de informație;

· distribuiți responsabilitatea personală în toate etapele implementării și operațiunii de probă.

De asemenea, este necesar să se determine zonele funcționale de implementare a modulelor sistemului informațional:

· management organizatoric;

· suport organizatoric si administrativ;

· managementul proceselor de afaceri;

· management, planificare, financiar si contabil;

· managementul personalului;

· managementul documentelor;

· managementul logisticii;

· managementul relatiilor cu clientii si mediul extern.

În plus față de cele enumerate mai sus, este necesar să se stabilească cerințe tehnologice pentru implementarea SI:

· platformă de sistem - implementarea și adaptarea unei soluții gata făcute de la producător sau dezvoltare personalizată în conformitate cu specificațiile tehnice ale clientului;

· integrabilitate - datele sunt stocate și prelucrate într-un singur spațiu informațional; aceasta le asigură completitatea, consistența, fiabilitatea și reutilizarea; sistemul poate include tehnologii și aplicații nou dezvoltate și deja utilizate;

· adaptabilitate - sistemul este configurat în conformitate cu cerințele clientului și cu caracteristicile câmpului de informații al clientului;

· distribuit - sistemul poate funcționa eficient în divizii și sucursale ale întreprinderii îndepărtate geografic;

· scalabilitate - sistemul poate fi implementat sub forma unui cadru care conține module de bază și extins în conformitate cu cerințele unui mediu extern și intern în schimbare.

Principalele faze ale implementării sistemului informațional

Faza „Lucrări preliminare la pregătirea proiectului de implementare a SI”. În timpul studiului pre-proiect al întreprinderii, se colectează informații detaliate despre structura structurală a organizației, relațiile funcționale, sistemul de management, principalele procese de afaceri, fluxurile din cadrul întreprinderii (Flux de control, Flux de documente, Flux de date, Flux de lucru, Cash). Flow), necesare pentru construcția modelelor adecvate și selectarea obiectelor pentru automatizare. Se evaluează calendarul, resursele, tipurile și volumele de muncă, gama și costul software-ului, hardware-ului și telecomunicațiilor, costul pregătirii personalului etc.

Faza „Pregătirea proiectului”. După finalizarea primei faze, se realizează planificarea preliminară și formarea procedurilor de lansare a proiectului:

· formarea de proiecte și grupuri de experți;

· repartizarea puterilor și responsabilităților;

· determinarea cerințelor organizatorice și tehnice pentru procesul de implementare;

· clarificarea specificațiilor și așteptărilor clienților;

· instruirea grupului de implementare format din specialiști din întreprinderea client.

Ultima, foarte punct important din anumite motive, este adesea omisă atunci când se elaborează un plan de implementare. Dar succesul întregului proiect depinde foarte mult de el! După începerea finanțării, proiectul se consideră a fi lansat.

Faza „Dezvoltarea conceptuală a proiectului”. În această fază:

· se formează și se aprobă un proiect conceptual;

· se realizează o înțelegere neechivocă obligatorie a intențiilor tuturor participanților la proiect cu privire la SI implementat;

· se clarifică și se precizează scopurile și obiectivele proiectului;

· se determină dimensiunile prototipului de sistem;

· se agreează planul de lucru extins, succesiunea etapelor și condițiile de funcționare a testului, planificarea, indicatorii financiari și de raportare;

Mai mult, toate aceste acțiuni trebuie să fie documentate, agreate și aprobate de toate părțile interesate și responsabile.

Faza „Implementarea Proiectului”. În timpul lucrărilor principale de implementare, mediul de sistem este creat, instalat și configurat, sunt determinate procedurile de administrare a sistemului și sunt instalate sisteme și aplicații hardware și software de bază. Sistemul configurează structurile organizatorice, de personal și organizatoric-funcționale ale întreprinderii folosind astfel de unități organizatorice ca ramură, departament, secție, grup de lucru etc.

Se realizează instalarea, configurarea și configurarea instrumentelor de rețea și telecomunicații, datele sunt transferate de la sistemele locale anterioare și sunt create interfețe cu sistemele vechi și externe. În același timp, toți au creat modele, planuri, lucru produse software, documentația este plasată în depozitul end-to-end al proiectului de implementare (Fig. 3). O parte importantă Acest depozit este un sistem de documentare format în cadrul proiectului (Fig. 4).

Problemele sistematice de securitate ale funcționării sistemului în modul multi-utilizator sunt în curs de rezolvare. Sunt create aplicații, șabloane, rapoarte, formulare de acces client și sunt distribuite drepturile de utilizator. Toate sistemele sunt testate în „modul de luptă” cu participarea tuturor părților interesate.

După încheierea fazei de implementare, proiectul de implementare este considerat finalizat. Sistemul informatic este pus în funcțiune.

7. Factori de succes și motive pentru implementările nereușite ale IS

modelarea afacerii de reinginerire a informațiilor

Potrivit statisticilor mondiale, doar o treime din proiectele de dezvoltare și implementare a sistemelor informaționale au succes. Nu se știe nimic despre studii similare în Rusia, dar se pare că aici lucrurile stau și mai rău.

Un proiect de succes este finalizat la timp, în limita bugetului și își atinge rezultatele dorite. Ce se întâmplă cu restul proiectelor? Fie țin mult mai mult decât se aștepta, necesitând din ce în ce mai multă finanțare, fie se creează un sistem automat de care nimeni nu are nevoie și nimeni nu vrea sau nu poate lucra cu el.

Proiectele eșuate sunt foarte asemănătoare între ele. Ei par să se copieze unul pe altul, jucând același scenariu. Mulți ani de observare a practicilor proaste m-au determinat să scriu câteva reguli pentru managerii companiei care îi vor ajuta să evite cele mai multe greșeli tipice la implementarea automatizării managementului întreprinderii. Sunt la fel de potrivite pentru bugetarea proiectelor de automatizare, contabilitate de gestiune, managementul producției și alte domenii guvernanța corporativă.

Trebuie subliniat faptul că aceste sfaturi se adresează, în primul rând, conducerii de vârf a organizației, adică proprietarului sau directorului general al companiei, care acționează ca clienți? schimbări în domeniul guvernanței corporative, inclusiv crearea de sisteme automatizate. Neînțelegere de către persoane? eșalon superior? rolul său în astfel de proiecte este principalul motiv al eșecului unor astfel de eforturi.

Primul. Definiți scopul proiectului

Conform acelorași statistici, șaptezeci la sută din proiectele nereușite au devenit astfel din cauza incertitudinii obiectivelor lor. Cu alte cuvinte, rezultatul final nu a fost clar definit de la început.

Exemplu din practică. Șeful serviciului de tehnologie a informației al unei mari exploatații primește de la directorul general sarcina de a implementa un sistem automatizat care să asigure nivel superior managementul corporativ al operaționale și informaţii de încredere. Șeful serviciului IT, în căutarea unui software adecvat pentru rezolvarea sarcinilor atribuite, apelează la consultanți. La întrebarea noastră despre ce probleme au determinat conducerea companiei să implementeze sistem automatizat, se dă următorul răspuns:

· lipsa unui format unificat de prezentare a datelor contabile de gestiune.

· lipsa reglementărilor pentru generarea rapoartelor de gestiune.

· lipsa unui mediu informațional unificat

Este absolut clar că primele două?probleme? nu sunt legate de automatizare, iar aceasta din urmă nu este o problemă, deoarece prezența unui mediu informațional unificat? în sine nu are niciun beneficiu practic.

Familiarizarea cu starea reală a lucrurilor din companie a condus la înțelegerea faptului că există o problemă de delegare a competențelor șefului corporației către managerii unităților de afaceri. Acesta trebuie rezolvat cu ajutorul controlului, bazat pe planificare regulată și contabilitate de gestiune, precum și motivarea adecvată a managerilor. Cu alte cuvinte, ar trebui să vorbim în primul rând despre stabilirea proceselor de management la nivel corporativ și numai după aceea? despre automatizarea acestor procese. După ce și-au dat seama de acest lucru, managerii companiei au economisit mulți bani renunțând la automatizarea fără rost.

O înțelegere profundă a obiectivelor proiectului poate duce la abandonarea implementării acestuia sau la amânarea termenelor sale din cauza unei revizuiri a priorităților.

Obiectivele automatizării trebuie formulate nu în termeni de avantaje tehnice, ci în termeni de interese de afaceri. Ele pot fi definite, de exemplu, astfel:

· reducerea stocurilor în depozit datorită planificării mai precise a producției și achizițiilor;

· reducerea creanţe de încasat, din cauza suport informativ lucrul cu debitorii;

· a face mai mult proiecte de investitii prin eliminarea operaţiunilor de rutină efectuate de manageri calificaţi.

Această definire a obiectivelor îți va permite să înțelegi de ce faci asta, cât ești dispus să plătești pentru a rezolva aceste probleme și, foarte important, să obții criterii de succes a proiectului prin care poți evalua rezultatele finale.

Doilea. Deschide proiectul

Implementarea unui sistem automatizat- Asta proiect strategic companiilor. Acesta trebuie deschis prin ordin al directorului general. Ordinul definește obiectivele și termenele limită ale proiectului și numește un manager de proiect.

Exemplu din practică. Capul unuia banca mare dă instrucțiuni managerului management financiar implementarea unui sistem de bugetare. În ciuda faptului că a trecut mai bine de un an de la numire, managerul desemnat nu înțelege ce puteri are în legătură cu această misiune, ce rezultate și în ce interval de timp se așteaptă de la el. Proiectul pare să existe, dar lucrurile nu merg înainte.

Cu alte cuvinte, trebuie să înțelegeți clar care este proiectul? acesta este unul cu drepturi depline structura organizatorica, creat temporar în cadrul unei organizații pentru a atinge obiective foarte specifice.

Managerul desemnat de directorul general formează echipa de proiect. Ar trebui să includă șefi de departamente și specialiști interesați de rezultatul final și competenți în domeniul proiectului. Deci, dacă se implementează un sistem de bugetare, atunci echipa de proiect este formată din manageri și specialiști din serviciile financiare și IT, precum și din reprezentanți ai departamentelor de producție și vânzări. Liderul de proiect ar trebui să fie un manager care ocupă o poziție mai înaltă în structura organizatorică a întreprinderii decât orice membru al echipei de proiect.

Treilea. Asigurați proiectul cu resurse

Resurse cheie- sunt bani și oameni. Prin urmare, este necesar să se aprobe bugetul proiectului.

Nota resursele necesare- nu este o sarcină ușoară, și totuși în etapa de justificare a proiectului este important să înțelegem ce buget este considerat acceptabil pentru dezvoltarea tehnologiilor de management și implementarea unui sistem automatizat. Cert este că soluția oricărei probleme este un triunghi: bani - timp - rezultat. Dacă rezultatul dorit este definit cu precizie, atunci se poate calcula timpul necesar pentru a-l atinge și bugetul. Dacă nu există o idee clară despre ce este " rezultat bun„(adică obiectivele proiectului nu sunt precis definite), atunci puteți merge de la buget și puteți rezolva problema în această formă: ce efect de management maxim se poate obține dacă investiți o anumită sumă în configurarea proceselor de management și introducerea tehnologiilor informaționale?

În plus, este important să se aloce o parte din timpul de lucru al persoanelor implicate în proiect pentru a efectua lucrări legate de implementarea sistemului. Altfel?cifra de afaceri? va strica problema. O practică răspândită este aceea că angajații sunt desemnați să implementeze sistem nou management?optional?. Întrucât volumul lor principal de muncă nu este redus, ei tratează munca suplimentară fie ca pe un hobby, fie ca pe o povară enervantă, în funcție de gradul de interes. Această atitudine este destul de firească, deoarece conducerea companiei, încredințându-le o muncă suplimentară neremunerată, și-a demonstrat propria atitudine față de aceasta ca fiind ceva secundar.

Controla resurse umane proiectul presupune bugetarea timpului interpreților. Contabilitatea timpului efectiv petrecut este necesară nu numai pentru plata adecvată a interpreților, ci și pentru evaluarea corectă a costurilor proiectului.

Patrulea. Ai grijă de motivație

Motivația- un element cheie al managementului, așa că ar trebui să luați în considerare cu atenție schema de motivare a executanților proiectului. Acestea nu trebuie neapărat să fie bonusuri mari pentru implementarea cu succes a sistemului.

Cel mai adesea, introducerea unui nou sistem de management ajută la îmbunătățirea statutului participanților la această muncă, le crește nivel profesional. Acestea sunt stimulente foarte importante. Cert este că oamenii creativi văd munca ca pe un mijloc de creștere a capitalului lor intelectual. Astfel de specialiști reprezintă cea mai mare valoare pentru orice afacere legată de inovare.

Este important ca managerul care formează echipa de proiect să înțeleagă corect așteptările interpreților asociate cu succesul acestei afaceri. Ar putea fi creșterea carierei, creșteri salariale, dobândirea de noi cunoștințe, atingerea unor noi culmi în creșterea profesională.

Cincilea. Suport managerial

Succesul este posibil doar dacă proiectul este susținut puternic de conducerea de vârf a companiei. Dacă director general consideră că introducerea unui sistem automatizat- aceasta este doar o chestiune pentru serviciul IT, atunci nu va ieși nimic bun din asta.

Implementarea tehnologiei informației nu înseamnă doar instalarea de programe la locurile de muncă. Astfel de proiecte sunt asociate cu schimbări ale lucrătorilor și procesele de management, redistribuirea responsabilităţilor şi a puterilor. Aceste schimbări intră adesea în conflict cu interesele anumitor șefi de departament și angajați. Ca urmare, începe sabotajul sau rezistența deschisă la schimbare. Prin urmare, șeful organizației trebuie să arate clar de partea cui se află și, dacă este necesar, să suprime rezistența cu o mână fermă, oferind sprijin echipei de proiect.

Şaselea. Împărțiți proiectul în etape

Proiectul pe termen lung este cel mai bun„tăiați în bucăți” și nu treceți la următoarea etapă fără a vă asigura că sarcinile din etapa anterioară sunt complet finalizate. Este foarte important să se determine care ar trebui să fie rezultatul fiecărei etape a proiectului.

Deci, de exemplu, dacă vorbim despre crearea unui sistem automat de management al bugetului, se recomandă succesiunea de pași prezentată în figură.

Puteți trece la următoarea etapă numai după ce sunt îndeplinite trei condiții:

· echipa de proiect a dezvoltat o înțelegere comună a rezultatelor etapei;

· această înțelegere se formalizează sub forma unui document;

· rezultatele etapei sunt acceptate de client, adică de şeful întreprinderii.

Această abordare vă permite să controlați riscurile proiectului, îndreptându-vă progresiv către scopul urmărit.

Şaptelea. Gestionați obiectivele și așteptările

Obiectivele proiectului pot fi ajustate sau chiar modificate semnificativ în timpul lucrului. Aceasta este o practică comună. Situația se schimbă, înțelegerea noastră asupra situației se schimbă și ajungem la concluzia că opiniile noastre anterioare sunt depășite sau eronate. Prin urmare, trebuie să vă întoarceți în mod regulat (la fiecare etapă a proiectului) la rădăcini? și să examineze critic toate premisele subiacente.

Și un ultim lucru. Trebuie să ai curajul să închizi un proiect dacă devine clar că a ajuns într-o fundătură. Managerul de proiect care a luat inițiativa de a pune capăt unui proiect fără speranță merită încurajat ca manager responsabil care a prevenit risipa fondurilor întreprinderii.

De obicei izolat pașii următori Crearea IP:

1. formarea cerințelor de sistem,

2. design,

3. implementare,

4. testare,

5. punerea în funcțiune,

6. operare și întreținere.

Etapa inițială a procesului de creare a unui SI, după determinarea scopului creării sistemului, este modelarea proceselor de afaceri - un set de lucrări interconectate pentru a rezolva o problemă specifică care apare în organizație și a realiza scopurile și obiectivele acesteia. Modelul de organizare, descris în termeni de procese de afaceri și funcții de afaceri, ne permite să formulăm cerințele de bază pentru SI.

Scop etapele inițiale crearea de sisteme informaționale realizată în etapa de analiză a activităților organizației este formarea cerințelor pentru IP, reflectând corect și cu acuratețe scopurile și obiectivele organizației clienților. Pentru a preciza procesul de creare a unui sistem informațional care să răspundă nevoilor organizației, este necesar să se afle și să se articuleze clar care sunt aceste nevoi. Pentru a face acest lucru, este necesar să se determine cerințele clienților pentru SI și să le mapam într-un limbaj model în cerințele pentru dezvoltarea unui proiect IS, astfel încât să se asigure conformitatea cu scopurile și obiectivele organizației.

La scenă proiectaÎn primul rând, se formează modele de date. Designerii primesc rezultatele analizei ca informații inițiale. Construirea modelelor de date logice și fizice este o parte fundamentală a proiectării bazei de date. Modelul informațional obținut în timpul procesului de analiză este mai întâi convertit într-un model de date logic și apoi într-un model de date fizic.

În paralel cu proiectarea schemei bazei de date, se realizează proiectarea procesului pentru a obține specificațiile (descrierile) tuturor modulelor IS. Ambele procese de proiectare sunt strâns legate deoarece o parte din logica de afaceri este de obicei implementată în baza de date (constrângeri, declanșatoare, proceduri stocate). Scopul principal proiectarea procesului constă în maparea funcţiilor obţinute în etapa de analiză în module ale sistemului informaţional. Produsele finale ale etapei de proiectare sunt o schemă de bază de date (pe baza modelului ER dezvoltat în etapa de analiză) și un set de specificații pentru modulele de sistem (acestea sunt construite pe baza modelelor funcționale).

În plus, în faza de proiectare, se realizează și dezvoltarea arhitecturii IS, inclusiv selecția platformei (platformelor) și a sistemului de operare (sisteme de operare). Într-un IS eterogen, mai multe computere pot rula pe platforme hardware diferite și pot rula sisteme de operare diferite. Pe lângă alegerea unei platforme, în faza de proiectare se determină unele caracteristici ale arhitecturii (fișier-server sau client-server, bază de date centralizată sau distribuită, bază de date omogenă sau nu, dacă se vor folosi servere de baze de date paralele pentru îmbunătățirea performanței). Faza de proiectare se încheie cu dezvoltarea proiect tehnic ESTE.

La scenă implementare software-ul de sistem este creat, instalat mijloace tehnice, elaborarea documentaţiei operaţionale.

Etapă testarea apare de obicei distribuit în timp.

După finalizarea dezvoltării unui modul individual, sistemul efectuează un test offline, care are două obiective principale: detectarea defecțiunilor modulului și conformitatea modulului cu specificațiile (prezența tuturor funcțiilor necesare, absența funcțiilor inutile). După ce testul autonom trece cu succes, modulul este inclus în partea dezvoltată a sistemului, iar grupul de module generate trece testele de conectare care ar trebui să urmărească influența lor reciprocă. În continuare, un grup de module este testat pentru fiabilitatea operațională, adică ele sunt supuse, în primul rând, unor teste care simulează defecțiuni ale sistemului și, în al doilea rând, teste ale timpului mediu dintre defecțiuni. Apoi, întregul set de module este supus unui test de sistem - un test intern de acceptare a produsului, care arată nivelul calității acestuia. Acestea includ teste de funcționalitate și teste de fiabilitate a sistemului. Ultimul test al sistemului informatic este testarea de acceptare. Un astfel de test presupune arătarea sistemului informațional către client și trebuie să conțină un grup de teste care simulează procese reale de afaceri pentru a arăta conformitatea implementării cu cerințele clientului.

2. Conceptul de „arhitectură a sistemului informațional”

Să luăm în considerare definiția „arhitecturii sistemului informațional” dată de diverse surse:

Arhitectură este structura organizatorică a sistemului.

ArhitecturaIS– un concept care definește modelul, structura, funcțiile îndeplinite și interconectarea componentelor unui sistem informațional.

Arhitectură- aceasta este organizarea de bază a sistemului, întruchipată în componentele sale, relațiile acestora între ele și cu mediul, precum și principiile care determină proiectarea și dezvoltarea sistemului.

Arhitectură– este un set de decizii semnificative despre organizarea unui sistem software, a unui set elemente structuraleși interfețele acestora, cu ajutorul cărora este compus sistemul, împreună cu comportamentul lor, determinat în interacțiunea dintre aceste elemente, dispunerea elementelor în subsisteme treptat lărgite, precum și stilul. arhitectură, care dirijează această organizare - elemente și interfețele acestora, interacțiuni și aspect.

Arhitectură este structura organizației și comportamentul sistemului asociat acesteia. Arhitectură poate fi dezasamblat recursiv în părți care interacționează prin interfețe, conexiunile care conectează piesele și condițiile de asamblare a pieselor. Părțile care interacționează prin interfețe includ clase, componente și subsisteme.

Dacă combinăm toate aceste definiții, obținem următoarele:

Arhitectura IP numită organizarea fundamentală a componentelor SI, conexiunile dintre acestea și mediul extern, precum și principii și mijloace de dezvoltare și susținere a sistemelor.

Sub arhitectura sisteme software vom înțelege setul de decizii privind:

· organizarea sistemului software;

· selectarea elementelor structurale care alcătuiesc sistemul și interfețele acestora;

· comportamentul acestor elemente în interacţiunea cu alte elemente;

· combinarea acestor elemente în subsisteme;

· stilul arhitectural, care determină organizarea logică și fizică a sistemului: elemente statice și dinamice, interfețele acestora și metodele de combinare a acestora.

Arhitectură al unui sistem software acoperă nu numai aspectele sale structurale și comportamentale, ci și regulile sale de utilizare și integrare cu alte sisteme, funcționalitate, performanță, flexibilitate, fiabilitate, reutilizare, completitudine, limitări economice și tehnologice și probleme de interfață cu utilizatorul.

Pe măsură ce sistemele software se dezvoltă, integrarea lor între ele devine din ce în ce mai importantă pentru a construi un spațiu informațional unificat pentru întreprindere.

Până acum, a apărut un set standard de tehnici pentru introducerea sistemelor informaționale. Regula de baza: efectuați secvențial fazele necesare și nu săriți peste niciuna dintre ele.

Esențiale pentru implementare sunt următoarele: factori :

· prezența obiectivelor de proiect și a cerințelor IP clar formulate;

· disponibilitatea unei strategii pentru implementarea și utilizarea IP;

· realizarea unui sondaj pre-proiect al întreprinderii și a modelelor de construcție „Așa cum este” și „Așa cum va fi”;

· planificarea lucrărilor, resurselor și monitorizarea implementării planului de implementare;

· participarea managementului superior la implementarea sistemului;

· desfășurarea lucrărilor de implementare a SI de către specialiști în integrare de sisteme împreună cu specialiști în întreprindere;

· monitorizarea periodică a calității muncii prestate;

· obținerea rapidă a rezultatelor pozitive cel puțin în parte din modulele IS implementate sau în timpul funcționării sale de probă.

Înainte de a începe dezvoltarea proiect de implementare necesar:

· formalizarea obiectivelor proiectului de implementare SI pe cât posibil;

· estimarea costurilor și elementelor de cheltuieli minime necesare;

· stabiliți o prioritate ridicată pentru proiectul de implementare față de alte proiecte în derulare;

· acorda managerului de proiect maximele puteri posibile;

· desfășoară activități educaționale de masă cu personalul întreprinderii pentru a transmite tuturor importanța și necesitatea transformărilor viitoare;

· elaborarea de măsuri organizatorice pentru utilizarea noilor tehnologii informaţionale;

· distribuiți responsabilitatea personală în toate etapele implementării și operațiunii de probă.

De asemenea, este necesar să se determine zonele funcționale de implementare a modulelor sistemului informațional:

· management organizatoric;

· suport organizatoric si administrativ;

· managementul proceselor de afaceri;

· management, planificare, financiar si contabil;

· managementul personalului;

· managementul documentelor;

· managementul logisticii;

· managementul relatiilor cu clientii si mediul extern.

Pe lângă cele enumerate mai sus, trebuie să setați cerinte tehnologice la implementarea SI:

· platforma de sistem- implementarea și adaptarea unei soluții gata făcute de la producător sau dezvoltare personalizată în conformitate cu specificațiile tehnice ale clientului;

· integrabilitatea- datele sunt stocate si prelucrate intr-un singur spatiu informativ; aceasta le asigură completitatea, consistența, fiabilitatea și reutilizarea; sistemul poate include tehnologii și aplicații nou dezvoltate și deja utilizate;

· adaptabilitate- sistemul este configurat în conformitate cu cerințele clientului și cu caracteristicile câmpului de informații al clientului;

· distributie- sistemul poate funcționa eficient în divizii și sucursale ale întreprinderii îndepărtate geografic;

· scalabilitate- sistemul poate fi realizat sub forma unui cadru care contine module de baza si completat in conformitate cu cerintele mediului extern si intern in schimbare.

6.6.1 Principalele faze ale implementării sistemului informațional

Etapa „Lucrări preliminare la pregătirea proiectului de implementare a SI”. În timpul studiului pre-proiect al întreprinderii (Fig. 4), sunt colectate informații detaliate despre structura structurală a organizației, relațiile funcționale, sistemul de management, principalele procese de afaceri, fluxurile din cadrul întreprinderii (Flux de control, Flux de documente, Flux de date). , Work Flow, Cash Flow ), necesare pentru construirea modelelor adecvate și selectarea obiectelor pentru automatizare. Se evaluează calendarul, resursele, tipurile și volumele de muncă, gama și costul software-ului, hardware-ului și telecomunicațiilor, costul pregătirii personalului etc.

Faza „Pregătirea proiectului”. După finalizarea primei faze, se realizează planificarea preliminară și formarea procedurilor de lansare a proiectului:

· formarea de proiecte și grupuri de experți;

· repartizarea puterilor și responsabilităților;

· determinarea cerințelor organizatorice și tehnice pentru procesul de implementare;

· clarificarea specificațiilor și așteptărilor clienților;

· instruirea grupului de implementare format din specialiști din întreprinderea client.

Din anumite motive, ultimul punct foarte important este adesea omis atunci când se elaborează un plan de implementare. Dar succesul întregului proiect depinde foarte mult de el! După începerea finanțării, proiectul se consideră a fi lansat.

Faza „Dezvoltarea conceptuală a proiectului”. În această fază:

· se formează și se aprobă un proiect conceptual;

· se clarifică și se precizează scopurile și obiectivele proiectului;

· se determină dimensiunile prototipului de sistem;

· se agreează planul de lucru extins, succesiunea etapelor și condițiile de funcționare a testului, planificarea, indicatorii financiari și de raportare;

Mai mult, toate aceste acțiuni trebuie să fie documentate, agreate și aprobate de toate părțile interesate și responsabile.

Etapa „Implementarea proiectului”. În timpul lucrărilor principale de implementare, mediul de sistem este creat, instalat și configurat, sunt determinate procedurile de administrare a sistemului și sunt instalate sisteme și aplicații hardware și software de bază. Sistemul configurează structurile organizatorice, de personal și organizatoric-funcționale ale întreprinderii folosind astfel de unități organizatorice ca ramură, departament, secție, grup de lucru etc.

Figura 12 - Conținutul aproximativ al depozitului de proiect de implementare

Se realizează instalarea, configurarea și configurarea instrumentelor de rețea și telecomunicații, datele sunt transferate de la sistemele locale anterioare și sunt create interfețe cu sistemele vechi și externe. În același timp, toate modelele create, planurile, produsele software de lucru și documentația sunt plasate în depozitul end-to-end al proiectului de implementare (Fig. 12). O parte importantă a acestui depozit este sistemul de documentare generat în cadrul proiectului (Fig. 13).

Figura 13 - Compoziția aproximativă a documentației pentru procesul de implementare a sistemului informațional

După încheierea fazei de implementare, proiectul de implementare este considerat finalizat. Sistemul informatic este pus în funcțiune.

Întrebări de securitate

1. Ce este un „sistem informațional deschis”? Enumerați principalele proprietăți ale sistemelor deschise.

2. Descrieți esența abordării procesului modern pentru gestionarea activităților unei întreprinderi și utilizarea acestei abordări în dezvoltarea sistemelor informaționale.

3. Ce modele și cum sunt utilizate în proiectarea sistemelor informaționale?

4. Ce instrumente software sunt folosite pentru modelarea proceselor în dezvoltarea sistemelor informaţionale?

5. Pe baza a ce date și informații sunt dezvoltate modelele de stat AȘA ESTE și A FI?

6. Cine în companie se ocupă de dezvoltarea, implementarea și dezvoltarea IP? Cine este implicat în pregătire termenii de referință pentru dezvoltarea IP?

7. Numiți principalele etape ale proiectării tehnologiei informației.

8. Enumerați pașii ciclu de viață sistem informatic.

9. În ce stadiu de dezvoltare și implementare a SI este instruit personalul companiei?

10. Enumerați principalele faze ale implementării SI.