Curs_dezvoltarea Rapida a Aplicatiilor Software

  • View
    5

  • Download
    0

Embed Size (px)

Text of Curs_dezvoltarea Rapida a Aplicatiilor Software

  • 1

    Managementul proiectelor

    Dezvoltarea rapid a aplicaiilor software

    1. INTRODUCERE

    2. STRATEGIA DEZVOLTRII RAPIDE

    2.1. Strategia general

    2.2. Cele patru dimensiuni ale dezvoltrii rapide

    2.2.1.1. Oamenii

    2.2.1.2. Procesul

    2.2.1.3. Produsul

    2.2.1.4. Tehnologia

    3. GREELI CLASICE

    3.1. Efectul greelilor asupra programrii dezvoltrii

    3.2. Enumerarea greelolor clasice

    1

    4

    4

    5

    5

    6

    8

    8

    9

    9

    10

    1. INTRODUCERE

    Problema timpului de dezvoltare este insidioas i omniprezent. Diferite studii au artat c

    aproape dou treimi dintre proiecte depesc substanial estimrile (Lederer & Prasad 1992,

    Gibbs 1994, Standish Group 1994). Data planificat a livrrii este depit cu 25 - 50 % i

    mrimea alunecrii programului planificat crete cu mrimea proiectului (Jones 1994). An

    dup an, sursele vitezei de dezvoltare au aprut n fruntea listei celor mai critice probleme

    puse n faa comunitii dezvoltatorilor de software (Symons 1991).

    Dei problema dezvoltrii lente a proiectelor este presant, unele organizaii se dezvolt rapid.

    Cercettorii au descoperit diferene de 10 la 1 n productivitate ntre companii din cadrul

    acelorai industrii, iar unii cercettori au gsit variaii chiar mai mari (Jones 1994).

    Unul dintre scopurile cursului este de a furniza grupurilor care sunt n mod curent mai

    aproape de "1" (n cadrul acestui raport de 1 la 10) informaiile necesare pentru a se apropia

    de "10". Cursul i propune s v ajute n aducerea sub control a proiectelor voastre, care s

    furnizeze o funcionalitate sporit ntr-un timp de dezvoltatre mai sczut.

    Care sunt segmente int ale cursului ?

    Responsabilii n partea tehnic

    Unele exemple practice care v vor fi prezentate sunt tehnice. Ca responsabili n acest sector,

    nu vei avea probleme n implementarea lor. Alte exemple sunt orientate mai mult spre

    management, care este de fapt i titlul cursului. Presupunem c suntei (sau vei deveni n

    scurt timp) manageri pe partea tehnic, deci oameni capabili s mnuiasc att problemele

  • 2

    tehnice, ct i pe cele manageriale. Naiva dihotomia tehnic-managerial nu este tocmai

    potrivit, responsabilii din sectorul tehnic fiind adesea chemai s fac recomandri upper-

    management-ului n legtur cu problemele de management orientate tehnic.

    Programatorii individuali

    Multe proiecte software sunt derulate de ctre programatori individuali sau de ctre "self-

    managed teams", punnd participanii din zona tehnic individual n roluri de responsabili

    tehnici.

    Manageri

    Managerii consider adeseori c dezvoltarea rapid a unui software este n primul rnd o

    problem tehnic. Cu toate acestea, un manager poate face n mod normal la fel de mult ca i

    dezvoltatorii pentru a mbunti viteza dezvoltrii proiectului. Acest curs va descrie i

    exemple de dezvoltare rapid la nivelul managementului.

    Cursul pune accentul pe problemele legate de dezvoltarea de software, innd cont de faptul

    c acest domeniu este ntr-o explozie fantastic pe scar global, dar i naional i local,

    reprezentnd unul dintre puinele sectoare viabile i de mare perspectiv ale rii noastre.

    Muli dintre voi sunt antrenai n mod direct sau indirect n activiti de dezvoltare de

    software, iar ceilali suntei cu siguran n zone adiacente, n care problemele legate de

    aplicarea i mentenaa software-ului sunt stringente.

    n acest context, putem considera c proiectele software pot fi optimizate pentru oricare dintre

    urmtoarele scopuri: rata de defectare cea mai sczut, viteza de execuie cea mai mare,

    gradul de acceptan de ctre utilizator cel mai ridicat, mentenabilitatea cea mai bun, costul

    cel mai sczut sau timpul de dezvoltare cel mai scurt. O abordare inginereasc ne conduce

    ctre buna cntrire a problemelor: poi optimiza timpul de dezvoltare tind de la calitate?

    Tind de la capacitatea de folosin? Cernd dezvoltatorilor s lucreze peste program? Cnd

    "momentul adevrului" se apropie, cte reduceri n planificare poi opera? Sunt cteva dintre

    ntrebri la care vom rspunde mpreun de-a lungul acestui curs.

    Putem s vorbim despre o criz a softitilor relativ la problema dezvoltrii lente a softurilor?

    n occident da. Iar la noi ncepe s apar. Clienii i managerii rspund acestei probleme n

    primul rnd prin creterea presiunii planificrii i prin suprancrcarea dezvoltatorilor.

    Presiunea excesiv a planificrii se produce n aproximativ 75 % dintre proiectele mari i n

    aproximativ 100 % dintre proiectele foarte mari (Jones 1994). Aproape 60 % dintre

    dezvoltatori spun c nivelul de stres resimit este n cretere (Glass 1994). Media

    dezvoltatorilor n SUA lucreaz ntre 48 i 50 de ore pe sptmn (Krantz 1995). Muli

    muncesc considerabil mai mult. Nu este deci surprinztor c satisfacia general a muncii din

    acest domeniu a sczut semnificativ n ultimii ani (Zawacki 1993). O reconsiderare a

    managementului proiectelor software poate aduce mbuntiri substaniale i din acest punct

    de vedere.

  • 3

    Dezvoltarea rapid - ce este i ce vrea ea?

    Managerul de producie mi-a spus c dorete s construiasc un produs potrivit pentru o

    schimbare. El dorete s fim ateni la calitate, s prevenim neconformitatea, s inem sub

    control planificarea i s putem furniza o dat predictibil a lansrii.

    Cnd a sosit timpul de a face efectiv proiectul, a devenit clar c lansarea cu rapiditate a

    produsului a fost singura prioritate real. Utilizabilitatea? Nu avem timp. Performana? Nu

    putem atepta. Mentenabilitatea? La urmtorul proiect. Testarea? Utilizatorii notri doresc

    produsul acum. S li-l oferim acum.

    Acest manager de producie nu conduce numai proiectul unui produs. i el se poate identifica

    cu aproape orice manager de producie. Timpul de dezvoltare a devenit o prioritate att de

    important, nct i-a "furat" pe oameni de la alte consideraii semnificative, chiar de la acelea

    care influeneaz n ultim instan i timpul de dezvoltare.

    Ce este dezvoltarea rapid ?

    Depinde de cine se gndete la asta. Pentru unii oameni, aplicarea unei singure unelte sau a

    unei singure metode. Pentru un hacker - 36 de ore pentru un scop. Pentru inginerul din IT -

    RAD (Rapid Development), o combinaie ntre uneltele CASE, implicarea intensiv a

    utilizatorului i "timeboxes" foarte strnse. Pentru programatorul tip "vertical-market" -

    elaborarea cu rapiditate a unui prototip utiliznd ultima versiune de Visual Basic sau Delphi.

    Pentru managerul disperat care dorete s scurteze termenele - orice chestiune practic

    desprins din cele mai recente numere ale revistelor de afaceri.

    Oricare dintre aceste unelte i metode este bun atta timp ct "merge" i fiecare poate

    contribui la creterea vitezei de dezvoltare. Dar pentru a furniza un beneficiu maxim, trebuie

    ca fiecare s fie orchestrat ca parte a unei strategii cuprinztoare. Niciuna dintre ele nu se

    poate aplica n toate cazurile. i niciuna dintre ele nu se poate msura cu anumite alte

    practici care nu sunt gndite n mod obinuit ca practici pentru dezvoltare rapid, dar care au

    oricum profunde implicaii asupra dezvoltrii rapide.

    n cadrul acestui curs, termenul de "dezvoltare rapid" este mai degrab o sintagm

    descriptiv, care contrasteaz cu "dezvoltare lent i tipic". Un termen generic care nseamn

    acelai lucru ca i "scurtarea termenelor".

    Atunci, un "proiect dezvoltat rapid" este orice proiect care trebuie s sublinieze viteza de

    dezvoltare. In climatul zilelor noastre, aceast descriere se potrivete unei sumedenii de

    proiecte.

  • 4

    2. STRATEGIA DEZVOLTRII RAPIDE

    2.1 Strategia general

    Putei realiza o dezvoltare rapid urmrind o strategie cu patru linii directoare:

    Evitai greelile clasice.

    Aplicai bazele dezvoltrii.

    Conducei riscurile pentru a evita ntoarcerile catastrofale.

    Aplicaii practicile orientate spre planificare (vitez, risc planificat, vizibilitate):

    o Care mbuntesc viteza dezvoltrii, permindu-v s livrai produsul mai

    repede.

    o Care reduc riscul planificat, permindu-v s evitai depiri uriae ale

    planificrii.

    o Care fac vizibil progresul, permindu-v s nlturai aparent unei dezvoltri

    ncete.

    Figura 2.1 Cei patru piloni ai dezvoltrii rapide

    Pilonii din figur ilustreaz cteva aspecte importante:

    Sprijinul optim pentru cea mai bun planificare posibil este cnd avem toi pilonii i cnd i

    facem pe toi ct mai puternici posibil. Fr sprijinul primilor trei, abilitatea voastr n

    planificare va fi n primejdie putei s folosii cele mai solide practici orientate pe planificare,

    dar dac facei greeala clasic de a scurta timpul destinat calitii produsului n faza timpurie

    a proiectului, vei pierde timp corectnd defecte atunci cnd este cel mai scump. Proiectul va

    ntrzia.

    Dac srii peste principiul de dezvoltare de a crea un proiect bun nainte de a lucra efectiv,

    produsul va avea de suferit cnd concepia lui se va schimba n unele pri prin dezvoltare i

    proiectul va ntrzia. i dac nu conducei riscurile, putei afla chiar nainte de data lansrii c

    un subcontractor-cheie este n urm cu trei luni fa de planificare. i vei ntrzia iari.

    Figura sugereaz de asemenea c primii trei piloni furnizeaz cel mai mare sprijin necesar

    pentru cea mai bun planificare. Poate c nu un sprijin ideal, dar cea mai mare parte din

    Cea mai buna planificare

    posibil

  • 5

    necesar. Este pos