of 23 /23
Managementul contractelor

managementul contractelor

  • Author
    apuhccc

  • View
    509

  • Download
    1

Embed Size (px)

DESCRIPTION

Managementul proiectelor software (cursuri si lab)

Text of managementul contractelor

Managementul contractelor

1. Tipuri de contractResursele externe cerute pot fi sub form de servicii. Un exemplu simplu ar fi folosirea unei echipe temporare la contracte de durat mic, n vederea ndeplinirii anumitor sarcini. Pe de alt parte, contractul poate fi ncheiat pentru livrarea unei aplicaii software complete. Acesta poate fi: bespoke system (sistem comandat), i.e. un sistem care e creat de la zero, special pentru un client; off-the-shelf (gata pentru cumprare), pe care l cumperi ca atare (as is) uneori se mai numete shrink-wrapped software; customized off-the-shelf (COTS) software acesta este basic core system, care e modificat pentru a ndeplini cerinele unui anumit client. Obs. Livrarea unui echipament, conform legii din Anglia, poate fi privit ca un contract pentru livrarea de bunuri. Livrarea de software poate fi privit ca oferirea unui serviciu (pentru scrierea software-ului) sau ca acordarea unei licene pentru folosirea software-ului. Aceste disticii au implicaii legale.

O alt clasificare a contractelor este d.p.d.v. al modalitii de plat ctre furnizori: contracte cu pre fixat; contracte de timp i materiale; contracte cu pre fixat per unitatea livrat.

Contracte cu pre fixat

Preul e fixat atunci cnd se semneaz contractul. Clientul tie c dac nu exist schimbri n termenii contractului, preul pe care-l va plti este cel consemnat n contract.

n acest caz trebuie ca analiza cerinelor s fi avut deja loc. Odat nceput dezvoltarea, clientul nu-i poate schimba cerinele fr s negocieze preul contractului.

Avantajele acestei metode sunt: Cheltuielile clientului cunoscute; Motivarea furnizorului; Dezavantajele acestei metode sunt: Preuri mai mari pentru a permite eventualele lucruri neprevzute. Furnizorul adaug o marj la calcularea preului tocmai pentru a reduce riscul apariiei unor situaii neprevzute; Dificulti n modificarea cerinelor; O presiune upward asupra costului schimrilor. n competii cu ali furnizori, furnizorul va ncerca s ofere un pre ct mai sczut. Dac, odat contractul semnat, e nevoie de schimbri ale cerinelor, furnizorul e n poziia forte de a cere un pre mai mare pentru aceste schimbri; Ameninare la calitatea sistemului. Nevoia de a menine un pre fixat poate duce la deteriorarea calitii sistemului.

Contracte de timp i materiale Clientul e taxat la o valoare fix pentru unitatea de efort (de exemplu, or echip). La nceputul contractului, furnizorul ofer o estimare a costului, bazat pe nelegerea cerinelor utilizatorului, dar aceasta nu e baza pentru plata final. Avantajele acestei metode sunt: Uurina n a schimba cerinele; Lipsa presiunii preului; Dezavantajele acestei metode sunt: Handicapul clientului. Clientul e cel care se va nfrunta cu toate riscurile asociate cu cerine vag definite sau care se schimb; Lipsa motivaiei pentru furnizor. Furnizorul nu are motivaie s lucreze ntr-o manier care s ncurajeze economia costurilor.

Contracte cu pre fixat per unitatea livrat (pre unitar fixat) Acesta e asociat cu function point (FP) counting. Mrimea sistemului care urmeaz s fie livrat e calculat sau estimat la nceputul proiectului. Mrimea sistemului trebuie s fie estimat n linii de cod, dar FPs pot fi derivate cu uurin de la documentaia cerinelor. E stabilit preul per unitate. Preul final va fi preul unitar nmulit cu numrul de uniti. Exemplu. Tabelul de mai jos arat o astfel de estimare a preurilor (tabel preluat din Garmus, Herron, Measuring The Software Process, 1996)

Dac sistemul conine 2600 FPs, costul total va fi: 2000x967+500x1019+100x1058

Avantajele acestei metode sunt: nelegerea din partea clientului. Clientul poate vedea cum e calculat preul; Uurina de a face comparaii. Preurile stabilite pot fi comparate; Emerging functionality. Furnizorul nu-i asum riscul funcionalitii n cretere. Eficiena furnizorului. Furnizorul are nc motivaia s livreze sistemul la funcionalitatea cerut. Lyfe cycle range. Cerinele nu trebuie specificate n forma final la nceput. Contractul poate acoperi att etapa de analiza, ct i etapa de design. Dezavantajele acestei metode sunt: Dificulti cu msurarea dimensiunii software-ului. Numrul de linii de cod poate fi mrit folosind un stil de codare bombastic. Folosirea regulilor de numrare a FPs poate favoriza furnizorul sau clientul. Soluia ar fi s fie angajat un independent FP counter (numrtor independent al FPs); Schimbarea cerinelor. Anumite cerine pot afecta drastic tranzaciile, dar nu se adaug la numrrea global a FPs. O schimbare a cerinelor fcut trziu n ciclul de dezvoltare va necesita aproape sigur mai mult efort pentru implementare dect dac s-ar produce mai devreme.

O alt clasificare a contractelor (conform regulilor din Uniunea European) se face n legtur cu abordarea care e folosit pentru selectarea contractorului: deschis (open); restricionat (restricted); negociat (negociated).

Open tendering process n acest caz, orice furnizor poate face o ofert pentru furnizarea de bunuri i servicii. Mai mult, toate ofertele care sunt n conformitate cu condiiile originale din invitation to tender trebuie s fie considerate i evaluate n acelai mod ca celelalte. La un proiect major, unde exist o mulime de oferte i procesul de evaluare e consumator de timp, acest mod poate fi scump.

Restricted tendering process n acest caz, sunt oferte doar de la furnizorii care au fost invitai de client. Spre deosebire de open tendering process, clientul poate n orice moment s reduc numrul furnizorilor poteniali. Este n mod uzual cea mai bun abordare. Exist totui riscuri: acolo unde contractul rezultant e la un pre fixat, clientul i asum responsabilitatea pentru corectitudinea i completarea cerinelor specificate furnizorilor.

Negociated procedure Sunt situaii cnd procesul de ofertare restricionat nu e cel mai potrivit. n aceste cazuri, se poate justifica abordarea unui singur furnizor, caz n care clientul poate fi acuzat de favoritisme.

2. Etape n definitivarea contractelorAnaliza cerinelor naninte de abordarea furnizorului, trebuie s fie specificate clar cerinele. Documentarea cerinelor trebuie sp aib, n mod tipic, seciuni de forma celor artate n tabelul de mai jos (un asemenea document se numete uneori operational requirement sau OR):

Cerinele definesc cu grij funciile care necesit s fie duse la bun sfrit de noua aplicaie i toate intrrile(inputs) i ieirile(outputs) necesare pentru aceste funcii. Cerinele trebuie de asemenea s declare orice standard cu care trebuie s fie conforme i sistemele cu care noul sistem s fie compatibil. Sunt necesare de asemenea cerine operaionale i de calitate (vezi capitolul despre Calitatea produselor software). Cerinele obligatorii (mandatory) trebuie s fie ndeplinite. Dac o propunere nu ndeplinete obligatorie, atunci propunerea va fi respins. Dac cerina e dezirabil (desirable), dar nu obligatorie, atunci propunerea poate fi acceptat din acest punct de vedere, dar trebuie ca alte aspecte ale propunerii s compenseze acest neajuns.

Planul de evaluare (evaluation plan) Odat specificat lista de cerine, trebuie schiat planul despre cum va fi evaluat propunerea. Pentru o aplicaie off-the-shelf, sistemul nsui va fi evaluat.

Invitaia la ofert (invitation to tender) Dup analiza cerinelor i producerea planului de evaluare, e posibil etapa de a invita posibilii furnizoti s fac o ofert. n esen, aceast invitaie trebuie nsoit de o scrisoare, n care s se ofere diverse informaii: cum va fi tratat legal oferta, care este termenul limit pentru prezentarea ofertei etc. Abordrile privind aceast etap nu sunt unitare n diverse ri, de aceea recomandm consultarea normelor legale pentru fiecare ar.

Evaluarea propunerilor Procesul de evaluare trebuie fcut metodic i planificat i ar putea include: examinarea atent a documentelor propunerii; intervievarea reprezentanilor furnizorilor; demonstraii; examinri ale site-urilor; teste practice. Documentele propunerii oferite de furnizori pot fi examinate pentru a vedea dac conin toate elementele ce satisfac cerinele originale. Se pot cere anumite clarificri asupra unor puncte ale propunerii. Orice declarare factual fcut de furnizor presupune o angajare legal din partea lui dac influeneaz cumprtorul s ofere contractul acelui furnizor. Cumprtorul poate lua iniiativa de a pstra note ale ntlnirilor i de scrie apoi furnizorului pentru a obine confirmarea asupra acurateii lor. Furnizorul poate, n finalul documentului contractului, s ncerce s exclud orice angajare la orice reprezentaii fcute n negocierile precontract.

Cnd produsul livrat se bazeaz pe un produs existent, e posibil s vad o demonstraie. Un pericol cu demonstraiile este acela c sunt controlate de furnizor. De aceea, clientul ar trebui s fac o planificare a lucrurilor pe care dorete s le vad n demonstraie, asigurndu-se astfel c toate elementele importante sunt vzute. Cu un software off-the-shelf, e posibil s avem acces concret la aplicaie. De exemplu, o versiune demonstrativ poate fi valabil (de genul celor care dup 39 zile nu mai sunt valabile). E nevoie de un plan de test, care s ne asigure ca sunt evaluate caracteristicile importante.

O problem frecvent este aceea c n timp ce o aplicaie existent lucreaz bine pe o anumit platform, nu lucreaz mulumitor pe platforma clientului. n acest caz sunt mai utile examinrile unor site-uri operaionale care folosesc sistemul.

3. Termenii tipici ai unui contractE nevoie s schim anumite arii majore asupra crora trebuie s ne concentrm: Definiii S-ar putea ca terminologia folosit n documentul contractului s fie definit, de exemplu ce se nelege prin client i furnizor. Forma nelegerii De exemplu, e contract de vnzare, de leasing sau licen? De asemenea, poate subiectul unui contract, cum ar fi licena pentru utilizare unei aplicaii software, poate fi transferat unei tere pri? Bunuri i servicii furnizate Echipament i software. Include o list concret a pieselor individuale de echipament care vor fi livrate.

Servicii. Acestea acoper lucruri ca: instruire; documentare; instalare; conversia fiierelor existente; mentenan; msuri de asigurare temporare. Proprietarul software-ului Dou chestiuni apar: mai nti, poate clientul s vnd software-ul la alii i a doua dac furnizorul poate vinde software-ul la alii. Cnd un software e scris special pentru un client, clientul va dori probabil s-i asigure exclusivitatea, de exemplu prin cumprarea copyright-ului sau prin specificarea n constract c folosete exclusiv software-ul.

Mediul (environment) Cnd trebuie instalat echipamentul fizic, trebuie specificat linia de demarcaie dintre responsabilitile furnizorului i clientului cu privire la lucruri cum ar fi furnizarea de energie. Cnd software-ul e furnizat, trebuie confirmat compatibilitatea cu hardware-ul existent i sistemul de operare existent. Angajamentele clientului Clientul trebuie s asigure accomodation pentru furnizori i probabil alte faciliti (internet, linie telefonic etc). Proceduri de acceptare Un sistem va fi acceptat numai dup a trecut de testele de acceptare. O parte a contractului va specifica detalii ca timpul pe care-l are clientul s fac testele, deliverables de care depind testele de acceptare i procedura pentru semnare atunci cnd testarea e completat. Standarde Clientul poate cere furnizorului dovada c diverse standarde sunt respectate.

Managementul proiectului i al calitii Contractul trebuie s cear ca standardele din seria ISO-9000 s fie ndeplinite, ca i ISO 12207 (de exemplu). Planificarea Ofer o planificare a timpului n care trebuie completate prile cheie ale proiectului. Aceast planificare va obliga att clientul, ct i furnizorul. De exemplu, furnizorul poate si n stare s instaleze software-ul la o dat convenit numai dac clientul face platforma hardware disponibil. Preul i metoda de plat n contract trebuie stabilit preul i modalitatea de plat. Cerine legale diferite n contract pot fi specificate ce condiii se aplic la subcontractarea muncii, obligaia pentru daune ctre o ter parte i liquidated damages. Liquidated damages sunt estimatori ai pierderilor financiare pe care clientul le sufer dac furnizorul a euat n obligaiile pe care i le-a asumat.

4. Managementul contractuluiLa anumite puncte de decizie, clientul are nevoie s examineze munca deja fcut i s ia decizii despre direcia viitoare a proiectului. Proiectul va necesita ca reprezentani ai clientului i furnizorului s interacioneze n multe puncte ale ciclului de dezvoltare. Aceast interaciune, sau ali factori externi, conduc(e) de obicei la necesitatea unor schimbri. Pentru fiecare punct de decizie, trebuie s fie definite deliverables ce urmeaz s fie prezentate de furnizori i toate output-urile.

Odat contractul ncheiat, trebuie avut n vedere calitatea muncii. Standardul ISO 12207 ofer printre altele posibilitatea existenei unor ageni, angajai independent de client sau furnizor, care se vor duce la bun sfrit verificarea, validarea i asigurarea calitii. Pe msur ce sistemul se dezvolt, apare uneori nevoia unor schimbri n cerine, care pot duce la modificarea termenilor contractului. Va fi nevoie deci de o procedur de control al schimbrilor, care s nregistreze cerinele pentru schimbri, mpreun cu acordul furnizorului i eventualele costuri suplimentare necesare pentru munca n plus. Clientul, pe de alt parte, trebuie s se asigure c n contract se specific i felul cum sunt tratate situaiile n care furnizorul nu respect una sau mai multe obligaii legale.

5. AcceptareaCnd munca e terminat, clientul trebuie s nceap activitatea legal pentru realizarea testrii de acceptare (acceptance testing). Contractul poate stabili o dat limit pentru ct poate dura testarea, astfel nct clientul s poat face testarea nainte de expirarea timpului, n vederea corectrii problemelor ridicate. O parte a plii sau chiar toat plata va depinde de testul de acceptare. Uneori o parte a plii finale va fi reinut pentru perioada rulare operaional i va fi pltit dac nivelul de fiabilitate este conform specificaiilor contractate. Exist de obicei o perioad de garanie, n timpul creia furnizorul poate pune la punct orice eroare aprut. Probabil c furnizorul poate cere o perioad de garanie mai mic (30 zile, de exemplu), n timp ce clientul ar ncerca s duc perioada de garanie pn spre 120 zile, de exemplu (aceste valori sunt orientative, dar pot fi ntlnite adesea n realitate).

Concluzii Cteva dintre punctele cheie din acest capitol pot fi astfel rezumate: contractarea

cu succes necesit timp important;

e mai uor s se obin concesii din partea furnizorului nainte de semnarea contractului dect dup; un contract va stabili obligaii i pentru client, i pentru furnizor; negocierea contractului va include nelegerea asupra managementului relaiei dintre furnizor i client n timpul executrii proiectului.