3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Transcrição

1 Matéria: O Prcess de Desenvlviment de Sftware Página: 29 3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE É mais fácil escrever um prgrama incrret d que entender um crret. [Alan Perlis] Um prcess define quem está fazend quê, quand e cm para alcançar um cert bjetiv. [Ivar Jacbsn, Grady Bch e James Rumbaugh] Se prcess fr frac, prdut final sfrerá inevitavelmente, mas uma ênfase exagerada n prcess também é perigsa. [Rger Pressman, 2006] 3.1 PANORAMA SOBRE PROCESSO DE SOFTWARE Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? Quand vcê elabra um prdut u sistema é imprtante percrrer uma série de passs previsíveis um rteir que ajuda a criar a temp um resultad de alta qualidade. O rteir que vcê segue é chamad de Prcess de Sftware; Quem faz? Os engenheirs de sftware e seus gerentes adaptam prcess a suas necessidades e depis seguem. Além diss, pessal que slicitu sftware tem um papel a desempenhar n prcess de definí-l, cnstruí-l e testá-l; Pr que é imprtante? Prque frnece estabilidade, cntrle e rganizaçã para uma atividade que pde, se deixada sem cntrle, trnar-se bastante caótica. N entant, uma abrdagem mderna de engenharia de sftware precisa ser ágil. Precisa exigir apenas aquelas atividades, cntrles e dcumentaçã adequads à equipe de prjet e a prdut que deve ser prduzid; Quais sã s passs? Em nível de detalhe, prcess adtad depende d sftware que vcê está cnstruind. Um prcess pderia ser aprpriad à criaçã de sftwares para sistema de aviônica de uma aernave, enquant um prcess inteiramente diferente seria indicad para a criaçã de um site; Qual é prdut d trabalh? D pnt de vista de um engenheir de sftware, s prduts d trabalh sã s prgramas, dcuments e dads prduzids em cnsequência das atividades e tarefas definidas pel prcess; Cm tenh certeza de que fiz crretamente? Existem diverss mecanisms de avaliaçã d prcess de sftware que permitem às rganizações determinar a maturidade d seu prcess de sftware. Tdavia, a qualidade, pntualidade e viabilidade a lng praz d prdut que vcê cnstrói sã s melhres indicadres da eficácia d prcess usad. 3.2 O QUE É PROCESSO? Sbre Prcess de Sftware, Shari L. Pfleeger (2004) destaca s seguintes itens: Cnjunt de tarefas rdenadas; Uma série de etapas que envlvem atividades, restrições e recurss para alcançar a saída desejada; Quand envlve a elabraçã de um prdut, pdems chamar de Cicl de Vida;

2 Matéria: O Prcess de Desenvlviment de Sftware Página: 30 Descreve a vida d prdut de sftware desde a cncepçã até a implementaçã, entrega, utilizaçã e manutençã. Há autres que defendem, n entant, que cicl de vida é uma parte de um prcess de desenvlviment de sftware, fcad nas atividades e na sequência em que elas devem ser executadas. E que prcess apresenta utrs itens, cm ferramentas e pessal envlvid. Cnsiderand a farta variedade de prblemas que pdem ser reslvids através da elabraçã de um sftware, diferentes prcesss de desenvlviment pdem ser aplicads. Para cntemplar essa situaçã, diferentes Mdels de Prcess de Desenvlviment de Sftware estã dispníveis na literatura, servind cm base para que uma rganizaçã elabre seu própri mdel, mais adequad às suas características individuais. 3.3 ATIVIDADES TÍPICAS DO PROCESSO DE SOFTWARE Diferentes autres cnsideram diferentes atividades cm send básicas para a definiçã de um prcess. Prém, mesm que se cnsiderem diferentes nmeclaturas e divisões, elas cntém essencialmente a mesma idéia, quand cnsideradas em cnjunt. Um exempl bastante cmum, de grup de atividades básicas é seguinte: Desenvlviment Análise, Design e Implementaçã. As funcinalidades e as restrições sã especificadas e sftware é prduzid; Validaçã & Verificaçã O sftware é testad. Observaçã: Verificaçã x Validaçã. Verificaçã Checar se realizu tdas as atividades (Fazend cert a cisa). Validaçã Checar se artefat está crret (Fazend a cisa certa); Manutençã O sftware sfre crreções, adaptações e ampliações.

3 Matéria: O Prcess de Desenvlviment de Sftware Página: 31 Já Pressman (2006) destaca seguinte cnjunt de atividades genéricas de um prcess: Cmunicaçã Essa atividade envlve alta cmunicaçã e clabraçã cm cliente (e utrs stakehlders) e abrange levantament de requisits e utras atividades relacinadas; Planejament Essa atividade estabelece um plan para trabalh de engenharia de sftware. Descreve as tarefas técnicas a serem cnduzidas, s riscs prváveis, s recurss que serã necessáris, s prduts de trabalh a serem prduzids e um crngrama de trabalh; Mdelagem Essa atividade inclui a criaçã de mdels que permitam a desenvlvedr e a cliente, entender melhr s requisits d sftware e prjet que vai satisfazer a esses requisits; Cnstruçã Essa atividade cmbina geraçã de códig (manual u autmática) e s testes necessáris para revelar errs n códig; Implantaçã O sftware é entregue a cliente, que avalia prdut e frnece feedback. Pressman (2006) cmplementa que as atividades genéricas sã cmplementadas pr uma série de atividades guarda-chuva, entre as quais pdem ser citadas: Acmpanhament e cntrle de prjet de sftware; Gestã de risc; Garantia de qualidade de sftware; Revisões técnicas frmais; Mediçã; Gestã de cnfiguraçã de sftware; Gestã de reusabilidade; Preparaçã e prduçã d prdut d trabalh. O mesm autr ainda cmenta seguinte: Tda rganizaçã de Engenharia de sftware deveria descrever um cnjunt específic de atividades de arcabuç para (s) prcess(s) de sftware que adta. Deveria preencher cada atividade de arcabuç cm um cnjunt de ações de engenharia de sftware e definir cada açã em terms de um cnjunt de tarefas que identifique trabalh (e prduts de trabalh) a ser realizad para satisfazer às metas de desenvlviment. Deveria, entã, adaptar mdel de prcess resultante para acmdar a natureza específica de cada prjet, pessal que vai fazer trabalh e ambiente n qual trabalh vai ser cnduzid. Independentemente d mdel de prcess que seja selecinad, s engenheirs de sftware tem tradicinalmente esclhid um arcabuç de prcess genéric que inclui as seguintes atividades de arcabuç: cmunicaçã, planejament, mdelagem, cnstruçã e implantaçã. 3.4 CICLO DE VIDA DE SOFTWARE Cm td prdut industrial sftware tem um cicl de vida: Ele é cncebid a partir da percepçã de uma necessidade; É desenvlvid, transfrmand-se em um cnjunt de itens entregue a um cliente; Entra em peraçã, send usad dentr de algum prcess de negóci e sujeit a atividades de manutençã, quand necessári; É retirad de peraçã a final de sua vida útil.

4 Matéria: O Prcess de Desenvlviment de Sftware Página: 32 Assim pde-se fazer a seguinte definiçã para Cicl de Vida: O cicl de vida d sftware é uma sequência de diferentes atividades executadas a lng da existência d sftware. Cada fase d cicl de vida tem divisões e subdivisões. É interessante destacar que a fase de cdificaçã, que representa a escrita final de um prgrama em frma inteligível para um cmputadr, é apenas uma pequena parte d cicl de vida. Para a mairia das pessas, inclusive muits prfissinais, essa ainda parece ser a única tarefa de um prdutr de sftware. Segue abaix um esquema simplificad de Cicl de Vida de Sftware. Percepçã da Necessidade Cncepçã Elabraçã Desenh Arquitetônic Cicl de Vida Desenvlviment Cnstruçã Liberaçã Desenh detalhad Cdificaçã Teste De Unidade Operaçã Retirada Transiçã Testes de Aceitaçã Assim, pde-se dizer que cicl de vida básic d sftware: Cmeça na cncepçã d prblema; Termina quand sistema sai de us. A seguir está dispnibilizada uma lista das atividades mais cmumente realizadas durante cicl de vida de um sftware. Estud de Viabilidade: Determina se desenvlviment prpst é viável; Análise de Mercad: Determina se existe mercad ptencial para prdut; Levantament de Requisits: Determina quais funcinalidades sftware deve ter; Elicidaçã ds Requisits: Obtém s requisits d usuári; Análise de Dmíni: Identifica e caracteriza ambiente (dmíni) n qual está prblema que sftware pretende slucinar;

5 Matéria: O Prcess de Desenvlviment de Sftware Página: 33 Planejament de Prjet: Determina cm desenvlver sftware; Análise de Custs: Determina a estimativa ds custs; Elabraçã de Crngrama: Identifica crngrama para desenvlviment; Garantia da Qualidade de Sftware: Determina atividades irã ajudar a garantir a qualidade d prdut; Definiçã da Estrutura de Decmpsiçã d Trabalh: Determina as sub-tarefas necessárias para desenvlviment d prdut; Elabraçã d Design: Determina cm sftware deverá prver as funcinalidades (características técnicas/tecnlógicas); Elabraçã d Design Arquitetural: Prjeta a estrutura d sistema; Elabraçã d Design de Interface: Especifica as interfaces entre as partes d sistema; Elabraçã d Design Detalhad: Prjeta s algritms e estrutura de dads para cada cmpnente; Elabraçã d Design de Banc de Dads: Especifica (s) mdel(s) de banc de dads; Implementaçã: Cnstruçã d sftware; Teste: Execuçã d sftware cm dads para ajudar a garantir que sftware funcina crretamente; Teste de Unidade: Teste d desenvlvedr riginal; Teste de Integraçã: Teste durante a integraçã d sftware; Teste d Sistema: Teste d sftware em um ambiente semelhante a ambiente peracinal; Teste Alpha: Teste pel cliente n ambiente d desenvlvedr; Teste Beta: Teste pel cliente n seu ambiente; Teste de Aceitaçã: Teste para satisfazer cliente; Teste de Regressã: Teste de armazenament da versã anterir para garantir que a nva versã pssui tdas as capacidades anterires; Entrega: Prvê cliente cm uma sluçã de sftware eficiente; Implantaçã: Trna sftware dispnível n ambiente peracinal d cliente; Treinament: Ensina usuári cm perar sftware; Help desk: Respnde a questões d usuári; Manutençã: Atualizaçã e evluçã d sftware para garantir usabilidade cnstante.

6 Matéria: O Prcess de Desenvlviment de Sftware Página: MODELOS DE PROCESSO DE SOFTWARE Cnfrme destaca Pressman (2006):... A aplicaçã inteligente de qualquer mdel de prcess de sftware deve recnhecer que a adaptaçã (a prblema, a prjet, à equipe e à cultura rganizacinal) é essencial para sucess. Mas s mdels de prcess diferem fundamentalmente: N flux geral de atividades e tarefas e interdependências entre atividades e tarefas; N grau em que as tarefas de trabalh sã definidas dentr de cada atividade de arcabuç; N grau em que s prduts d trabalh sã identificads e slicitads; Na maneira cm as atividades de garantia de qualidade sã aplicadas; N md cm mnitrament de prjet e as atividades de cntrle sã aplicadas; N grau geral de detalhes e rigr em que prcess é descrit; N grau em que clientes e utrs interessads estã envlvids n prjet; N nível de autnmia da equipe de prjet de sftware; N grau em que a rganizaçã da equipe e s papéis sã prescrits. Mdels de prcess que enfatizam a definiçã, identificaçã e aplicaçã detalhada de atividades e tarefas de prcess têm sid aplicads na cmunidade de engenharia de sftware durante s últims trinta ans. Quand esses Mdels Prescritivs de Prcess sã aplicads, bjetiv é melhrar a qualidade d sistema para trnar s prjets mais gerenciáveis, as datas de entrega e s custs mais previsíveis e para guiar equipes de engenheirs de sftware à medida que eles realizam trabalh necessári para cnstruir um sistema. Infelizmente, tem havid épcas em que esses bjetivs nã têm sid alcançads. Se s mdels prescritivs frem aplicads dgmaticamente e sem adaptaçã, eles pdem aumentar nível de burcracia assciad à cnstruçã de sistemas baseads em cmputadr e, inadvertidamente, criar dificuldades para desenvlvedres e clientes. Mdels de prcess que enfatizam a agilidade d prjet e seguem uma série de princípis que levam a uma abrdagem mais infrmal (mas, segund seus prpnentes, nã mens efetiva) d prcess de sftware fram prpsts ns últims ans. Esses Mdels de Prcess Ágil enfatizam a manbrabilidade e a adaptabilidade. Eles sã adequads a muits tips de prjet e sã particularmente úteis quand aplicações Web passam pr engenharia. Que filsfia de prcess de sftware é melhr? Essa questã tem prvcad um debate emcinal entre engenheirs de sftware [...]. Pr hra, é imprtante ntar que essas duas filsfias de prcess têm bjetiv cmum criar sftwares de alta qualidade que satisfaçam às necessidades d cliente -, mas abrdagens diferentes SELECIONANDO UM MODELO DE PROCESSO Origem: Engenharia de Sftware, Rger Pressman, 2006 [...] Cada açã de engenharia de sftware é representada pr um númer diferente de cnjunts de tarefas cada um cm uma cleçã de tarefas de trabalh de engenharia de sftware, prduts de trabalh relacinads, pnts de garantia de qualidade e marcs de prjet. O cnjunt de tarefas esclhid é que melhr acmda as necessidades d prjet e as características da equipe. Iss implica que uma açã de engenharia de sftware (pr exempl, prjet) pde ser adaptada às necessidades específicas d prjet de sftware e às características da equipe d prjet. N que se refere diretamente as mdels de prcess, Pressman ainda cmplementa: [...] Um cnjunt de elements de prcess atividades de arcabuç, ações de engenharia de sftware, tarefas, prduts de trabalh, mecanisms de garantia de qualidade e de cntrle de mdificações

7 Matéria: O Prcess de Desenvlviment de Sftware Página: 35 para cada prjet. Cada mdel de prcess também prescreve um flux de trabalh ist é, a maneira cm s elements d prcess se inter-relacinam uns cm s utrs. Origem: Wikipedia Os mdels existentes pssuem diferentes graus de sfisticaçã e cmplexidade. Para prjets que envlvem uma equipe de desenvlviment puc numersa e experiente, mais adequad será prvavelmente um prcess simples. N entant, para sistemas maires que envlvem equipes de dezenas u centenas de elements e milhares de utilizadres, um prcess simples nã é suficiente para ferecer a estrutura de gestã e disciplina necessárias à engenharia de um bm prdut de sftware. Desta frma, é necessári alg mais frmal e disciplinad. É imprtante fazer ntar que ist nã significa que se perca em invaçã u que se põe entraves à criatividade. Significa apenas que é utilizad um prcess bem estruturad para permitir a criaçã de uma base estável para a criatividade. Pr mais simples u cmplex que pssa parecer, um mdel de cicl de vida de um prjet é, de fat, uma versã simplificada da realidade. É supst ser uma abstraçã e, tal cm tdas as bas abstrações, apenas a quantidade de detalhe necessária a trabalh em mãs deve ser incluída. Qualquer rganizaçã que deseje pôr um mdel de cicl de vida em prática irá necessitar de adicinar detalhes específics para dadas circunstâncias e diferentes culturas. Pr exempl, a Micrsft quis manter uma cultura de pequena equipe e a mesm temp trnar pssível desenvlviment de grandes e cmplexs prduts de sftware. Dependend d tip de sistema em desenvlviment pde nã ser cmpletamente pssível u até aprpriad seguir s mdels rigrsamente RESUMINDO Sbre Mdels de Prcess: Especificam as atividades que, de acrd cm mdel, devem ser executadas, assim cm a rdem em que devem ser executadas; Prduts de sftware pdem ser cnstruíds utilizand-se diferentes mdels de prcess; Alguns mdels sã mais adequads que utrs para determinads tips de aplicaçã; A pçã pr um determinad mdel deve ser feita levand-se em cnsideraçã prdut a ser desenvlvid, as pessas envlvidas, s recurss dispníveis, e váris utrs parâmetrs; Objetivs: Auxiliar n prcess de prduçã Prduts de alta qualidade, prduzids mais rapidamente e a um cust cada vez menr; Atributs: cmplexidade, visibilidade, aceitabilidade, cnfiabilidade, manutenibilidade, segurança, etc; Pssibilitam: A gerente: cntrlar prcess de desenvlviment de sftware; A desenvlvedr: bter a base para prduzir, de maneira eficiente, sftware que satisfaça s requisits pré-estabelecids.

8 Matéria: O Prcess de Desenvlviment de Sftware Página: PANORAMA SOBRE MODELOS PRESCRITIVOS DE PROCESSO Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? Mdels prescritivs de prcess definem um cnjunt distint de atividades, ações, tarefas, marcs e prduts de trabalh que sã necessáris para fazer engenharia de sftware cm alta qualidade. Esses mdels de prcess nã sã perfeits, mas efetivamente frnecem um rteir útil para trabalh da engenharia de sftware; Quem faz? Engenheirs de sftware e seus gerentes adaptam um mdel de prcess prescritiv a suas necessidades e depis seguem. Além diss, pessal que slicitu sftware tem um papel a desenvlver à medida que mdel de prcess é seguid; Pr que é imprtante? Prque frnece estabilidade, cntrle e rganizaçã a uma atividade que pde, se deixada sem cntrle, trnar-se bastante caótica. Alguns têm-se referid a mdels prescritivs de prcess cm mdels de prcess rigrss, prque eles frequentemente incluem as capacitações sugeridas pel CMMI. N entant, cada mdel de prcess deve ser adaptad para que seja usad efetivamente em um prjet de sftware específic; Quais sã s passs? O prcess dirige uma equipe de sftware pr mei de um arcabuç de atividades guarda-chuva que sã rganizadas em um flux de prcess que pde ser linear, incremental u evlutiv. A terminlgia e s detalhes de cada mdel de prcess diferem, mas as atividades genéricas de arcabuç permanecem razavelmente cnsistentes; Qual é prdut d trabalh? D pnt de vista de um engenheir de sftware, s prduts de trabalh sã s prgramas, dcuments e dads que sã prduzids em cnsequência das atividades e tarefas definidas pel prcess; Cm tenh certeza de que fiz crretamente? Existem diverss mecanisms de avaliaçã de prcess de sftware que permitem às rganizações determinar a maturidade d seu prcess de sftware. Tdavia, a qualidade, pntualidade e viabilidade n lng praz d prdut que vcê cnstrói sã s melhres indicadres da eficácia d prcess usad. Ainda sbre Mdels de prcesss prescritivs autr destaca seguinte: Se s mdels prescritivs de prcess buscam estrutura e rdem, serã aprpriads a mund d sftware que busca mdificações? N entant, se rejeitarms mdels de prcesss cnvencinais (e a rdem que eles implicam) e s substituirms pr alg mens estruturad, trnams impssível bter crdenaçã e cerência n mund de sftware? Nã há respstas fáceis para essas questões, mas existem alternativas dispníveis para s engenheirs de sftware. A seguir serã apresentads alguns ds mdels prescritivs de prcess mais cnhecids CODE AND FIX (CONSTRÓI E CONSERTA) O cde-and-fix nã é um mdel prescritiv de prcess, mas uma primeira ideia de um prcess de sftware. O prdut é cnstruíd sem qualquer especificaçã u design. Nã existe um rteir definid de atividades, simplesmente vai-se se implementand à medida que cntat cm cliente vai identificand nvas necessidades. O prdut é refeit quantas vezes frem necessárias para satisfazer cliente. Este mdel pde funcinar razavelmente para micr prjets. N entant para prjets maires ele é inadequad. A Figura a seguir caracteriza mdel.

9 Matéria: O Prcess de Desenvlviment de Sftware Página: CLÁSSICO / EM CASCATA Este mdel é classificad cm send um Mdel Prescritiv de Prcess. Apesar de tds s seus prblemas, mdel em cascata é utilizad há muits ans, além de ser mais antig ds mdels. Atualmente, devid à cmplexidade cada vez mair ds sistemas, ele é puc utilizad. Suas principais características: Métd sistemátic e sequencial; O resultad de uma fase se cnstitui na entrada de utra - Cada atividade é uma fase distinta. Só após seu ttal términ é que a próxima atividade cmeça; O nível de abstraçã vai diminuind à medida que se avança n prcess enquant frmalism aumenta; Cada fase é estruturada cm um cnjunt de atividades que pdem ser executadas pr pessas diferentes; Os requisits d prblema devem estar bem cmpreendids. Diferentes autres pdem cnsiderar diferentes atividades a serem trabalhadas (mesm que elas tenham características em cmum). N entant que está acima descrit se aplica a qualquer cnjunt de atividades cnsideradas. Pressman (2006), pr exempl, a invés das atividades que estã abaix identificadas trabalha cm as atividades que chama de arcabuç, e que já fram previamente citadas.

10 Matéria: O Prcess de Desenvlviment de Sftware Página: 38 Atividades d Cicl de Vida Clássic Alguns prblemas d Cicl de Vida Clássic: Os prjets reais raramente seguem flux sequencial que mdel prpõe. Alguma iteraçã sempre crre e traz prblemas na aplicaçã d paradigma; Muitas vezes é difícil para cliente declarar tdas as exigências explicitamente. O cicl clássic tem dificuldade de acmdar a incerteza natural que existe n cmeç de muits prjets; Uma versã de trabalh d(s) prgrama(s) só estará dispnível em um pnt muit tardi d crngrama d prjet. O cliente deve ter paciência; N mdel em cascata s subprcesss sã executads em estrita sequência, que permite demarcá-ls cm pnts de cntrle bem definids. Essa característica facilita a gestã ds prjets. Pr utr lad, se interpretad literalmente, é um prcess rígid e burcrátic, em que as atividades devem ser muit bem dminadas, pis nã sã permitids errs (retrnar após uma etapa ter sid cncluída); [...] A natureza linear d mdel em cascata leva a estads de blquei ns quais alguns membrs da equipe de prjet precisam esperar que utrs membrs cmpletem as tarefas dependentes. Realimentaçã entre fases Na prática, é sempre necessári permitir que, em fases psterires, haja revisã e alteraçã de resultads das fases anterires. Pr exempl, s mdels e dcuments de prjet pdem ser alterads durante a implementaçã, à medida que s prblemas vã send descberts. Uma variante que permite superpsiçã entre fases e a realizaçã de crreções é um mdel mais realista, cm realimentaçã entre as fases. Esta realimentaçã dificulta gerenciar prjets baseads neste mdel de prcess.

11 Matéria: O Prcess de Desenvlviment de Sftware Página: INCREMENTAL Este mdel é classificad cm send um Mdel Prescritiv de Prcess. O mdel incremental e iterativ fi prpst cm uma respsta as prblemas encntrads n mdel em cascata. Um prcess de desenvlviment segund essa abrdagem divide desenvlviment de um prdut de sftware em cicls, cm sftware send desenvlvid em partes (increments). Em cada cicl de desenvlviment, pdem ser identificadas tdas as fases d prjet. Essa característica cntrasta cm a abrdagem clássica, na qual as fases d prjet sã realizadas uma única vez. Cada um ds cicls cnsidera um subcnjunt de requisits. Os requisits sã desenvlvids uma vez que sejam alcads a um cicl de desenvlviment. N próxim cicl, um utr subcnjunt ds requisits é cnsiderad para ser desenvlvid, que prduz um nv increment d sistema que cntém extensões e refinaments sbre increment anterir. Assim, desenvlviment evlui em versões, através da cnstruçã incremental e iterativa de nvas funcinalidades até que sistema cmplet esteja cnstruíd. Vale destacar que apenas uma parte ds requisits é cnsiderada em cada cicl de desenvlviment. Na verdade, um mdel iterativ e incremental pde ser vist cm uma generalizaçã da abrdagem em cascata: sftware é desenvlvid em increments e cada increment é desenvlvid em cascata (figura abaix). A abrdagem incremental e iterativa smente é pssível se existir um mecanism para dividir s requisits d sistema em partes, para que cada parte seja alcada a um cicl de desenvlviment. Essa alcaçã é realizada em funçã d grau de imprtância atribuíd a cada requisit.

12 Matéria: O Prcess de Desenvlviment de Sftware Página: RAD (RAPID APPLICATION DEVELOPMENT) Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e incremental. O desenvlviment rápid de aplicaçã é um mdel de prcess de desenvlviment de sftware incremental que enfatiza um cicl de desenvlviment extremamente curt (pr exempl, de 60 a 90 dias). É uma adaptaçã d mdel cascata, n qual desenvlviment rápid é cnseguid cm us de uma abrdagem de cnstruçã baseada em cmpnentes, requerend que s requisits sejam bem cmpreendids, s bjetivs prpsts e haja diferentes equipes de desenvlviment envlvidas. (PRESSMAN, 2006). Pressman (2006) ainda destaca s pssíveis prblemas de tal abrdagem: Aument da necessidade de recurss humans (tamanh das equipes), a medida que escp d prblema aumenta;; Necessidade de mair envlviment e cmprmetiment, para cumprir s prazs curts; O prblema precisa ser adequadamente mdularizad, para que haja atuaçã das diferentes equipes; Em prjets de alt desempenh, cm interfaces de móduls muit interligadas, há mair prbabilidade de errs; Pde nã ser a abrdagem mais adequada quand s riscs técnics sã alts, cm pr exempl, na utilizaçã de uma nva tecnlgia.

13 Matéria: O Prcess de Desenvlviment de Sftware Página: MODELOS EVOLUCIONÁRIOS Sbre mdels de prcess evlucináris Pressman (2006) destaca seguinte: O sftware, cm td sistema cmplex, evlui cm passar d temp. Os requisits d negóci e d prdut mudam frequentemente à medida que desenvlviment prssegue, dificultand um caminh diret para um prdut final; prazs reduzids de mercad trnam impssível cmpletar um prdut de sftware abrangente, mas uma versã reduzida pde ser elabrada para fazer frente à cmpetitividade u às pressões d negóci; um cnjunt de requisits básics de um prdut u sistema é bem entendid, mas s detalhes das extensões d prdut u sistema ainda precisam ser definids. Nesse cas, e em situações semelhantes, s engenheirs de sftware precisam de um mdel de prcess que tenha sid explicitamente prjetad para acmdar um prdut que evlui cm temp. O mesm autr ainda prssegue, destacand a necessidade ds mdels evlucináris: [...] sftware de cmputadr mdern é caracterizad pr mdificações cntínuas, prazs muit curts e pr uma enfática necessidade de satisfaçã d cliente/usuári. Em muits cass, períd até a clcaçã n mercad é requisit gerencial mais imprtante. Se um nich de mercad é perdid, prjet de sftware em si pde ser insignificante. Pressman (2006) destaca também alguns prblemas que esse tip de mdel acarreta: Dificulta planejament de prjet, pis há um númer incert de cicls para cnstruir prdut; A velcidade da evluçã pde acarretar prblemas n própri prdut; Sã prcesss fcads na flexibilidade e extensibilidade, em detriment de utrs critéris de qualidade.

14 Matéria: O Prcess de Desenvlviment de Sftware Página: Prttipagem A prttipagem pde ser cnsiderada cm um mdel de prcess de desenvlviment de sftware, mas que pde funcinar cncmitantemente cm qualquer utr tip de mdel. N desenvlviment de um sftware, a prttipagem é um esbç de uma parte d sistema. Prtótips sã cnstruíds para telas de entrada, de saída, para subsistemas u mesm para td um sistema. A cnstruçã de prtótips cstuma utilizar as denminadas linguagens de prgramaçã visuais. Exempls sã Delphi, PwerBuilder e Visual Basic que cstumam ter ambientes cm facilidades para a cnstruçã da interface gráfica (telas, frmuláris etc.). Além diss, alguns sistemas gerenciadres de bancs de dads também frnecem ferramentas para a cnstruçã de telas de entrada e saída de dads. Fim Iníci Cleta e Refinament ds Requisits Engenharia d Prdut Prjet Rápid Refinament d Prtótip Cnstruçã d Prtótip Avaliaçã d Prtótip pel Cliente Esse mdel cnstrói uma versã descartável (u prtótip). Esse prtótip visa a testar cnceits e requisits e será usad para demnstrar cmprtament as clientes. Após a cncrdância ds clientes, sftware é desenvlvid seguind as mesmas fases d mdel clássic, u de algum utr mdel que seja adtad. O esfrç despendid n prtótip geralmente é cmpensad pel nã desenvlviment de características desnecessárias. Pde assumir 3 frmas: (1) Um prtótip em papel u autmatizad; (2) Um prtótip de trabalh que implementa algum subcnjunt da funçã exigida d sftware desejad; (3) Um prgrama existente que executa parte u tda a funçã desejada. O funcinament básic é seguinte: A prttipaçã inicia-se cm a cleta ds requisits. O desenvlvedr e cliente reúnem-se e definem s bjetivs glbais para sftware. Ocrre entã a elabraçã de um design rápid. O design rápid leva a cnstruçã de um prtótip que é avaliad pel cliente/usuári e é usad para refinar s requisits para sftware a ser desenvlvid. Idealmente, prtótip serve cm um mecanism para identificar s requisits de sftware, quand há muitas dúvidas entre estes. A prttipaçã é fundamental à medida que cresce a imprtância da interface cm usuári. O prtótip pde servir cm primeir sistema sistema esse que recmenda-se seja jgad fra. O prblema é que alguns usuáris tendem a encarar prtótip cm alg já cnfiável, u seja, cm se já fsse parte d sftware real.

15 Matéria: O Prcess de Desenvlviment de Sftware Página: 43 Na mairia ds prjets, primeir sistema cnstruíd, se fr via prtótip, dificilmente é usável. Ele pde ser muit lent, muit grande, desajeitad em us, u tds s três. Nã resta utra alternativa senã cmeçar tud de nv, mas cm mais habilidade técnica. O desenvlvedr pde nã utilizar as técnicas de prgramaçã adequadas, pensand apenas na rapidez. Um prtótip nrmalmente precupa-se apenas cm a interface, nã tratand ds algritms e regras de negóci. Esse é, prtant mais um mtiv para que ele seja descartad, a invés de servir de base para sftware final. Ainda que pssam crrer prblemas, a prttipaçã é um paradigma eficiente da engenharia de sftware. A chave é definir-se as regras d jg lg n cmeç, u seja, cliente e desenvlvedr devem ambs cncrdar que prtótip seja cnstruíd para servir cm um mecanism afim de definir s requisits. Ele será depis descartad (pel mens em parte) e sftware real será prjetad Espiral u Evlutiv Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e evlucinári. Cleta inicial ds Requisits e Planejament d Prjet Planejament Análise ds Riscs Análise ds riscs baseada ns requisits iniciais Análise ds riscs baseada na reaçã d cliente Planejament basead ns cmentáris d cliente Decisã de Prsseguir u nã Na direçã de um sistema cncluid Avaliaçã d cliente Avaliaçã d Cliente Engenharia Prtótip de Sftware inicial Prtótip de nível seguinte Sistema cnstruid pela engenharia Este é um mdel que atende s seguintes cass: O prblema a ser reslvid nã está ttalmente entendid; A realidade pde mudar enquant sistema está send desenvlvid; A própria sluçã adtada pde ter algum efeit clateral descnhecid; A precupaçã está centrada mais na qualidade e funcinalidade d que se prduz. O mdel espiral para a engenharia de sftware fi desenvlvid para abranger as melhres características tant d cicl de vida clássic (n que se refere a sistematizaçã e cntrle) cm da prttipaçã (n que se refere a iteratividade), acrescentand, a mesm temp, um nv element a análise ds riscs que falta a esses paradigmas. O mdel, representad pela espiral, define quatr imprtantes atividades representadas pels quatr quadrantes da figura, send elas:

16 Matéria: O Prcess de Desenvlviment de Sftware Página: Planejament: determinaçã ds bjetivs, alternativas e restrições. 2. Análise ds riscs: análise de alternativas e identificaçã/resluçã ds riscs. 3. Engenharia: desenvlviment d prdut n nível seguinte. 4. Avaliaçã pel cliente: avaliaçã ds resultads da engenharia. N mdel em Espiral prdut é desenvlvid em uma série de iterações. Cada nva iteraçã crrespnde a uma vlta na espiral. Iss permite cnstruir prduts em prazs curts, cm nvas características e recurss que sã agregads à medida que a experiência descbre sua necessidade. As atividades de avaliaçã sã usadas para identificar prblemas. Seus registrs frnecem dads para definir s requisits das próximas liberações. As versões prgressivamente mais cmpletas d sftware sã cnstruídas a lng de cada iteraçã da espiral. Durante iníci d gir, s bjetivs, alternativas e restrições sã definids, e s riscs sã identificads e analisads. A cnclusã da análise ds riscs resulta numa decisã de prsseguir u nã. Se s riscs frem muit grandes, prjet pde ser encerrad. Há desenvlviment de parte d prgrama, que é dispnibilizad para testes. Entã cliente avalia trabalh de engenharia e apresenta sugestões para mdificações. Cada passagem pela regiã de planejament resulta em ajustes n plan de prjet. O cust e crngrama sã ajustads cm base n feedback derivad d cliente após a entrega. Além diss, gerente d prjet ajusta númer planejad de iterações necessárias para cmpletar sftware (Pressman, 2006). Deve-se ntar que númer de atividades de desenvlviment que crre n quadrante inferir direit eleva-se à medida que as atividades se afastam d centr da espiral. O paradigma d mdel espiral usa a prttipaçã cm um mecanism de reduçã ds riscs, pssibilitand que desenvlvedr aplique a abrdagem de prttipaçã em qualquer etapa da evluçã d prdut. O mdel espiral exige uma cnsideraçã direta ds riscs técnics em tdas as etapas d prjet e, se adequadamente aplicad, deve reduzir s riscs antes que eles se trnem prblemátics. Ele exige cnsiderável experiência na avaliaçã ds riscs e fia-se nessa experiência para sucess. Se um grande risc nã fr descbert, indubitavelmente crrerã prblemas. O principal prblema d cicl de vida em espiral é que ele requer gestã muit sfisticada para ser previsível e cnfiável. E pde ser difícil cnvencer s clientes sbre a realizaçã de cntrle em tal frma de trabalh, vist s cnstantes ajustes que sã realizads. Vale destacar que mdel em espiral pde ser cntinuamente utilizad, após a cnclusã inicial d sftware, para a realizaçã das manutenções que mesm deverá sfrer a lng d temp. Uma utra figura interessante é apresentada pr Smmerville (2007), e está a seguir destacada.

17 Matéria: O Prcess de Desenvlviment de Sftware Página: Cncrrente Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e evlucinári. O mdel cncrrente é representad através de uma série de atividades e seus estads crrespndentes. Sbre ele pde ser dit seguinte: As atividades pdem crrer em paralel, mas estã em diferentes estads; O mdel define uma série de events que vã disparar transições de estad para estad, para cada uma das atividades; Em vez de usar uma sequência cm mdel cascata, ele define uma rede de atividades; Pde ser aplicad a td tip de desenvlviment de sftware e frnece uma visã exata de cm está estad d prjet. Um exempl de uma rede de atividades pde ser cm da figura a seguir.

18 Matéria: O Prcess de Desenvlviment de Sftware Página: 46 nne Mdeling act ivit y Under develpment represents the state f a sftware engineering activity r task Await ing changes Under review Under revisin Baselined Dne DESENVOLVIMENTO BASEADO EM COMPONENTES Origem: Engenharia de Sftware, Rger Pressman, 2006 É um mdel desenvlvid para apiar a reusabilidade, necessária a atual desenvlviment de sftware, pr suas principais cnsequências: reduçã de praz e cust. Tal mdel se utiliza de cmpnentes de sftware cmercial de prateleira, ist é, cmpnentes que apresentam funcinalidade e interface bem definidas e que pdem ser utilizads integrads n sftware em desenvlviment. Incrpra muitas das características d mdel espiral. É um mdel evlucinári pr natureza, demanda uma abrdagem iterativa. Nrmalmente, apresenta s seguintes passs: Pesquisa e avaliaçã de cmpnentes dispníveis n mercad; Análise das necessidades de integraçã/implementaçã; Prjet da arquitetura de sftware, cnsiderand s cmpnentes; Integraçã e Implementaçã que fr necessária; Validaçã rigrsa.

19 Matéria: O Prcess de Desenvlviment de Sftware Página: O MODELO DE MÉTODOS FORMAIS Origem: Engenharia de Sftware, Rger Pressman, 2006 Os mdels de métds frmais abrangem um cnjunt de atividades que levam à especificaçã matemática frmal d sftware de cmputadr. Sã mdels que se apóiam na aplicaçã de uma rigrsa ntaçã matemática. Tem ganhad adepts quand há necessidade d desenvlviment de sftwares crítics em terms de segurança, devid à sua prmessa de um prdut livre de errs. Vantagens: Ambiguidades, incnclusões e incnsistências pdem ser descbertas e crrigidas mais facilmente, pr mei de análise matemática; Prblemas: O desenvlviment de mdels frmais é atualmente muit lent e dispendis; Cm pucs desenvlvedres de sftware têm prepar necessári para aplicar métds frmais, trna-se necessári um treinament extensiv; É difícil usar s mdels cm um mecanism de cmunicaçã, cm clientes despreparads tecnicamente DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS Origem: Engenharia de Sftware, Rger Pressman, 2006 Certas precupações transversais cbrem tda a arquitetura de um sistema, nã send exclusivas de uma funcinalidade, característica u infrmaçã. Pr exempl: segurança, tlerância a falhas, transações, geraçã de lgs. Assim, pde-se definir: Aspects: mecanisms que transcendem subrtinas e herança para lcalizar a expressã de uma precupaçã transversal, afetand tda a arquitetura de sftware. Nã existe ainda prcess rientad a aspects que seja cnsiderad suficientemente madur, mas é prvável que adte características tant d mdel de prcess espiral quant d cncrrente. Alguns terms que cmeçam a se trnar cnhecids: POA Prgramaçã Orientada a Aspects; DSOA Desenvlviment de Sftware Orientad a Aspects.

20 Matéria: O Prcess de Desenvlviment de Sftware Página: PROCESSO UNIFICADO (PU) Origem: Engenharia de Sftware, Rger Pressman, 2006 Engenharia de Sftware, Ntas de Aula, prf. Ricard de Almeida Falb, UFES De acrd cm Pressman (2006), PU é uma tentativa de apiar-se ns melhres recurss e características ds mdels cnvencinais de prcess de sftware, mas caracterizá-ls de um md que implemente s melhres princípis de desenvlviment ágil de sftwares. O Prcess Unificad é um prcess de engenharia de sftware desenvlvid pr três ds principais gurus da indústria de sftware: Ivar Jacbsn, James Rumbaugh e Grady Bch, send resultad de mais de 30 ans de experiência acumulada. É primeir prcess de desenvlviment a explrar integralmente as capacidades d padrã UML e baseia-se nas práticas cmuns as prjets de sftware cm mais alt ROI d mercad. Prcess de Sftware Unificad (Ratinal Unified Prcess) = Prcess + Métds + Linguagem (UML) Históric: O desenvlviment de sistemas seguind RUP é um prcess: Dirigid pr cass de us (use cases); Centrad na arquitetura; Iterativ e incremental.

21 Matéria: O Prcess de Desenvlviment de Sftware Página: 49 O RUP trata um cnjunt de atividades: Bem definidas; Cm respnsáveis; Cm artefats de entrada e saída; Cm dependências e rdem de execuçã; Cm mdel de cicl de vida; Cm uma descriçã sistemática de cm executá-las; Usand linguagem UML.

22 Matéria: O Prcess de Desenvlviment de Sftware Página: 50 Cnceits-chave d RUP: fnte: O Prcess Unificad prpst pela Ratinal (Ratinal Unified Prcess RUP) fi criad para apiar desenvlviment rientad a bjets, frnecend uma frma sistemática para se bter reais vantagens n us da Linguagem de Mdelagem Unificada (Unified Mdeling Language UML). De fat, ele nã é exatamente um prcess: é uma infraestrutura genérica de prcess que pde ser especializada para uma ampla classe de sistemas de sftware, para diferentes áreas de aplicaçã, tips de rganizaçã, níveis de cmpetência e tamanhs de prjets. O RUP está fundamentad em três princípis básics: rientaçã a cass de us, arquitetura e iteraçã. Ele é dit dirigid a cass de us, pis sã s cass de us que rientam td prcess de desenvlviment. Cm base n mdel de cass de us, sã criads uma série de mdels de análise, design e implementaçã, que realizam estes cass de us. É centrad em arquitetura, pis defende a definiçã de um esquelet para a aplicaçã (a arquitetura), a ganhar crp gradualmente a lng d desenvlviment. Finalmente, RUP é iterativ e incremental, ferecend uma abrdagem para particinar trabalh em prções menres u mini-prjets. Esses três cnceits sã igualmente imprtantes. A arquitetura prvê a estrutura para guiar desenvlviment d sistema em iterações, enquant s cass de us definem as metas e cnduzem trabalh de cada iteraçã. O cicl de vida adtad n RUP é tipicamente evlutiv. Cntud, uma frma de rganizaçã em fases é adtada para cmprtar s cicls de desenvlviment, permitind uma gerência mais efetiva de prjets cmplexs. A cntrári d tradicinalmente definid cm fases na mairia ds mdels de cicl de vida planejament, levantament de requisits, análise, prjet, implementaçã e testes, sã definidas fases rtgnais a estas, a saber: Cncepçã: nesta fase, é estabelecid escp d prjet e suas frnteiras, determinand s principais cass de us d sistema. Esses cass de us devem ser elabrads cm a precisã necessária para se prceder estimativas de prazs e custs. As estimativas devem

23 Matéria: O Prcess de Desenvlviment de Sftware Página: 51 ser glbais para prjet cm um td e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sbre planejament e, pr cnseguinte, é necessári levantar requisits d sistema e preliminarmente analisá-ls. A términ dessa fase, sã examinads s bjetivs d prjet para se decidir sbre a cntinuidade d desenvlviment; Elabraçã: prpósit desta fase é analisar mais refinadamente dmíni d prblema, estabelecer uma arquitetura de fundaçã sólida, desenvlver um plan de prjet para sistema a ser cnstruíd e eliminar s elements de prjet que ferecem mair risc. Embra prcess deva sempre acmdar alterações, as atividades da fase de elabraçã asseguram que s requisits, a arquitetura e s plans estã suficientemente estáveis e que s riscs estã suficientemente mitigads, de md a se pder prever cm precisã s custs e prazs para a cnclusã d desenvlviment. Cnstruçã: durante esta fase, um prdut cmplet é desenvlvid de maneira iterativa e incremental, para que esteja prnt para a transiçã à cmunidade usuária. Transiçã: nesta fase, sftware é dispnibilizad à cmunidade usuária. Após prdut ter sid clcad em us, naturalmente surgem nvas cnsiderações que vã demandar a cnstruçã de nvas versões para permitir ajustes d sistema, crrigir prblemas u cncluir algumas características que fram pstergadas. É imprtante realçar que dentr de cada fase, um cnjunt de iterações, envlvend planejament, levantament de requisits, análise, prjet e implementaçã e testes, é realizad. Cntud, de uma iteraçã para utra e de uma fase para a próxima, a ênfase sbre as várias atividades muda, cm mstra a figura 1 abaix, em que a cr preta indica grande ênfase, enquant a cr branca indica muit puca ênfase. Na fase de cncepçã, fc principal recai sbre entendiment ds requisits e a determinaçã d escp d prjet (planejament e levantament de requisits). Na fase de elabraçã, enfque está na captura e mdelagem ds requisits (levantament de requisits e análise), ainda que algum trabalh de prjet e implementaçã seja realizad para prttipar a arquitetura, evitand certs riscs técnics. Na fase de cnstruçã, enfque cncentra-se n prjet e na implementaçã, visand evluir e rechear prtótip inicial, até bter primeir prdut peracinal. Finalmente, a fase de transiçã cncentra-se ns testes, visand garantir que sistema pssui nível adequad de qualidade. Além diss, usuáris devem ser treinads, características ajustadas e elements esquecids adicinads. Além ds cnjunts de iterações em cada fase, as fases em si pdem crrer de frma iterativa. Cm mstra a figura 2, elas nã necessariamente têm a mesma duraçã. O esfrç realizad em cada uma varia frtemente em funçã das circunstâncias específicas d prjet.

24 Matéria: O Prcess de Desenvlviment de Sftware Página: 52 Autr: RICARDO DE ALMEIDA FALBO (fnte: Pressman (2006) destaca que as fases prpstas n PU pdem ser encaradas da mesma frma que as atividades de arcabuç pr ele prpstas, cnfrme destacad na figura abaix: Prcess de Engenharia de Sftware na visã d RUP

25 Matéria: O Prcess de Desenvlviment de Sftware Página: 53 Um prcess é um cnjunt de passs rdenads cm a intençã de atingir uma meta. Em engenharia de sftware, a meta é criar um sftware u aperfeiçar um existente; em engenharia de prcesss, a meta é desenvlver u aperfeiçar um prcess. N RUP, eles sã rganizads em um cnjunt de disciplinas para psterirmente definirem s fluxs de trabalh e utrs elements d prcess. Em terms de mdelagem de negócis, prcess de desenvlviment de sftware é um prcess de negócis, e Ratinal Unified Prcess (RUP) é um prcess de negócis genéric para engenharia de sftware rientada a bjets. Ele descreve uma família de prcesss de engenharia de sftware relacinads, que cmpartilham uma estrutura cmum, uma arquitetura de prcesss cmum. Ele prprcina uma abrdagem disciplinada para a atribuiçã de tarefas e de respnsabilidades dentr de uma rganizaçã de desenvlviment. Sua meta é garantir a prduçã de sftware de alta qualidade que atenda às necessidades ds usuáris, dentr de uma prgramaçã e um rçament previsíveis. O RUP captura muitas das melhres práticas d desenvlviment de sftware mdern, de frma que pssam ser adaptadas para uma grande variedade de prjets e de rganizações. Quand um sistema de sftware é desenvlvid cmeçand d zer, desenvlviment é prcess de criaçã de um sistema a partir ds requisits. Prém, depis que s sistemas tiverem tmad frma (u seja, tiverem passad pel cicl de desenvlviment inicial), s desenvlviments subsequentes serã prcess de adaptaçã d sistema as requisits nvs u mdificads. Iss se aplica durante td cicl de vida d sistema. Pressman (2006) destaca que nem tda tarefa identificada para um flux de trabalh d PU é cnduzida para qualquer prjet de sftware. A equipe adapta prcess (ações, tarefas, subtarefas e prduts de trabalh) para satisfazer às suas necessidades. 3.6 DESENVOLVIMENTO ÁGIL PANORAMA SOBRE DESENVOLVIMENTO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? A engenharia de sftware ágil cmbina uma filsfia e um cnjunt de diretrizes de desenvlviment. A filsfia encraja a satisfaçã d cliente e a entrega incremental de sftware lg de iníci; equipes de prjet pequenas, altamente mtivadas; métds infrmais; prduts de trabalh de engenharia de sftware mínims e simplicidade glbal de desenvlviment. As diretrizes de desenvlviment enfatizam a entrega em cntrapsiçã à análise e a prjet (apesar dessas atividades nã serem desencrajadas) e a cmunicaçã ativa e cntínua entre desenvlvedres e clientes; Quem faz? Engenheirs de sftware e utrs interessads n prjet (gerentes, clientes e usuáris finais) trabalham junts em uma equipe ágil uma equipe que é aut-rganizada e cntrla seu própri destin. Uma equipe ágil enfatiza a cmunicaçã e a clabraçã entre tds que a cmpõe; Pr que é imprtante? O ambiente mdern de negócis que cria sistemas baseads em cmputadr e prduts de sftware é apressad e sempre mutável. A engenharia ágil de sftware representa uma alternativa razável para a engenharia de sftware cnvencinal para certas categrias de sftware e certs tips de prjet de sftware. Tem sid demnstrad que ela entrega rapidamente sistemas bem-sucedids; Quais sã s passs? O desenvlviment ágil pderia ser melhr denminad pequena engenharia de sftware. As atividades básicas de arcabuç cmunicaçã cm cliente, planejament, a mdelagem, cnstruçã, entrega e avaliaçã permanecem. Mas elas sã

26 Matéria: O Prcess de Desenvlviment de Sftware Página: 54 reduzidas a um cnjunt mínim de tarefas que leva a equipe de prjet à cnstruçã e entrega (alguns alegariam que iss é feit à custa da análise d prblema e prjet da sluçã); Qual é prdut d trabalh? Clientes e engenheirs de sftware que têm adtad a filsfia ágil têm a mesma impressã únic prdut de trabalh realmente imprtante é um increment de sftware peracinal que é entregue a cliente na data de entrega cmbinada; Cm tenh certeza de que fiz crretamente? Se a equipe ágil cncrdar que prcess funcina e prduz increments de sftware em cndições de serem entregues e que satisfaçam a cliente, vcê fez crretamente. Cmentáris: Os mdels de prcess ágeis fram desenvlvids em um esfrç para vencer as fraquezas percebidas e reais da engenharia de sftware cnvencinal; Pde frnecer imprtantes benefícis, mas ele nã é aplicável a tds s prjets, prduts, pessas e situações; Nã é cntrári à sólida prática de engenharia de sftware, prevalecend cm uma filsfia sbre trabalh de sftware; Os engenheirs de sftware devem ser ágeis suficiente para respnder a um ambiente de negócis mutante. E a engenharia de sftware está evluind para se adaptar a essa nva necessidade de agilidade. Pressman (2006) apresenta ainda Manifest d Desenvlviment Ágil de Sftware, nde é declarad: Estams descbrind melhres mds de desenvlviment de sftware, fazend- e ajudand utrs a fazê-l. Pr mei desse trabalh passams a valrizar: Indivídus e interações em vez de prcesss e ferramentas. Sftwares funcinand em vez de dcumentaçã abrangente. Clabraçã d cliente em vez de negciaçã de cntrats. Respsta a mdificações em vez de seguir um plan. Ist é, ainda que haja valr ns itens à direita, valrizams mais s itens à esquerda O QUE É AGILIDADE Pressman (2006) destacu que nã se deve cmeter err de cnsiderar que agilidade dá a engenheir de sftware a licença de imprvisar sluções. A agilidade está relacinada a: Capacidade de respnder rapidamente a mudanças; Estruturas e atitudes de equipe que trnam a cmunicaçã mais fácil; Entrega rápida de sftware peracinal; Mens imprtância para prduts de trabalh intermediáris; Adçã ds clientes cm parte da equipe de desenvlviment; Planejament em um mund incert tem limites e um plan de prjet deve ser flexível. O mesm autr ainda destaca 12 princípis (prpsts pel Manifest Ágil) que devem ser seguids para se alcançar agilidade, send eles:

27 Matéria: O Prcess de Desenvlviment de Sftware Página: 55 A mais alta priridade é a satisfaçã d cliente, pr mei da liberaçã mais rápida e cntínua de sftware de valr; Receba bem as mudanças de requisits, mesm em estágis tardis d desenvlviment. Prcesss Ágeis devem admitir mudanças que trazem vantagens cmpetitivas para cliente; Libere sftware frequentemente (em intervals de 2 semanas até 2 meses), dand preferência para uma escala de temp mais curta; Mantenha pessas ligadas a negóci (cliente) e desenvlvedres trabalhand junts a mair parte d temp d prjet; Cnstrua prjets cm indivídus mtivads, dê a eles ambiente e suprte que precisam e cnfie neles para ter trabalh realizad; O métd mais eficiente e efetiv para repassar infrmações entre uma equipe de desenvlviment é pela cmunicaçã face-a-face; Sftware funcinand é a principal medida d prgress de um prjet de sftware; Prcesss ágeis prmvem desenvlviment sustentad. Assim, patrcinadres, desenvlvedres e usuáris devem ser capazes de manter cnversaçã pacífica indefinidamente; A atençã cntínua para a excelência técnica e um bm prjet (design) aprimram a agilidade; Simplicidade a arte de maximizar a quantidade de trabalh nã feit é essencial, devend ser assumida em tds s aspects d prjet; As melhres arquiteturas, requisits e prjets emergem de equipes aut-rganizadas; Em intervals regulares, as equipes devem refletir sbre cm se trnaram mais efetivas, e entã refinarem e ajustarem seu cmprtament de acrd O QUE É UM PROCESSO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 Qualquer prcess ágil é caracterizad de md que atenda a três supsições-chave: É difícil prever antecipadamente quais requisits de sftware vã persistir e quais serã mdificads. É igualmente difícil prever cm as priridades d cliente serã mdificadas à medida que prjet prssegue; O prjet e a cnstruçã sã intercalads, ist é, as duas atividades devem ser realizadas juntas de md que s mdels de prjet sejam cmprvads à medida que sã criads. É difícil prever quant de prjet é necessári antes que a cnstruçã seja usada para cmprvar prjet; Análise, prjet, cnstruçã e testes nã sã tã previsíveis (d pnt de vista d planejament) cm gstaríams. Pergunta: Cm criar um prcess que pssa gerenciar a imprevisibilidade? Respsta: Um prcess ágil deve ser adaptável e ser adaptad incrementalmente, cm base n feedback d cliente.

28 Matéria: O Prcess de Desenvlviment de Sftware Página: POLÍTICA DE DESENVOLVIMENTO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 Ninguém é cntra a agilidade (defensres de cada categria de mdels de prcess), que se tem sã respstas diferentes para as seguintes perguntas: Qual melhr md de alcançar a agilidade? Cm cnstruir sftwares que satisfaçam às necessidades d cliente atual e exiba características de qualidade que lhe permitam ser estendid e ampliad para satisfazer às necessidades d cliente n lng praz? Nã há respstas abslutas para as perguntas acima lançadas. Há muit a ser ganh cnsiderand que huver de melhr em cada abrdagem FATORES HUMANOS Origem: Engenharia de Sftware, Rger Pressman, 2006 O desenvlviment ágil enfca s talents e habilidades ds indivídus, mldand prcess a pessas e equipes específicas. Características-chave que devem existir entre as pessas de uma equipe ágil e na equipe entre si: Cmpetência; Fc cmum; Clabraçã; Capacidade de tmada de decisã - autnmia; Habilidade de reslver prblemas vags; Respeit e cnfiança mútua; Aut-rganizaçã. A equipe serve cm sua própria gerência. A equipe ágil rganiza-se para trabalh a ser feit; A equipe rganiza prcess para melhr acmdar seu ambiente lcal; A equipe rganiza crngrama de trabalh para cnseguir melhr entrega d increment de sftware. Alguns mdels ágeis de prcess que pdem ser destacads sã s seguintes: EXTREME PROGRAMMING (XP) Origem: Wikipédia, a enciclpédia livre. Prgramaçã extrema (d inglês extreme Prgramming), u simplesmente XP, é uma metdlgia ágil para equipes pequenas e médias e que irã desenvlver sftware cm requisits vags e em cnstante mudança. Para iss, adta a estratégia de cnstante acmpanhament e realizaçã de váris pequens ajustes durante desenvlviment de sftware. Os quatr valres fundamentais da metdlgia XP sã: cmunicaçã, simplicidade, feedback e cragem. A partir desses valres, pssui cm princípis básics: feedback rápid, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalh de qualidade.

29 Matéria: O Prcess de Desenvlviment de Sftware Página: 57 Dentre as variáveis de cntrle em prjets (cust, temp, qualidade e escp), há um fc explícit em escp. Para iss, recmenda-se a pririzaçã de funcinalidades que representem mair valr pssível para negóci. Desta frma, cas seja necessári a diminuiçã de escp, as funcinalidades mens valisas serã adiadas u canceladas. A XP incentiva cntrle da qualidade cm variável d prjet, pis pequen ganh de curt praz na prdutividade, a diminuir qualidade, nã é cmpensad pr perdas (u até impediments) a médi e lng praz. Práticas Para aplicar s valres e princípis durante desenvlviment de sftware, XP prpõe uma série de práticas. Há uma cnfiança muit grande na sinergia entre elas, s pnts fracs de cada uma sã superads pels pnts frtes de utras. Jg de Planejament (Planning Game): O desenvlviment é feit em iterações semanais. N iníci da semana, desenvlvedres e cliente reúnem-se para pririzar as funcinalidades. Essa reuniã recebe nme de Jg d Planejament. Nela, cliente identifica priridades e s desenvlvedres as estimam. O cliente é essencial neste prcess e assim ele fica sabend que está acntecend e que vai acntecer n prjet. Cm escp é reavaliad semanalmente, prjet é regid pr um cntrat de escp negciável, que difere significativamente das frmas tradicinais de cntrataçã de prjets de sftware. A final de cada semana, cliente recebe nvas funcinalidades, cmpletamente testadas e prntas para serem pstas em prduçã. Pequenas Versões (Small Releases): A liberaçã de pequenas versões funcinais d prjet auxilia muit n prcess de aceitaçã pr parte d cliente, que já pde testar uma parte d sistema que está cmprand. As versões chegam a ser ainda menres que as prduzidas pr utras metdlgias incrementais, cm RUP. Metáfra (Metaphr): Prcura facilitar a cmunicaçã cm cliente, entendend a realidade dele. O cnceit de rápid para um cliente de um sistema jurídic é diferente para um prgramadr experiente em cntrlar cmunicaçã em sistemas em temp real, cm cntrle de tráfeg aére. É precis traduzir as palavras d cliente para significad que ele espera dentr d prjet. Prjet Simples (Simple Design): Simplicidade é um princípi da XP. Prjet simples significa dizer que cas cliente tenha pedid que na primeira versã apenas usuári "teste" pssa entrar n sistema cm a senha "123" e assim ter acess a td sistema, vcê vai fazer códig exat para que esta funcinalidade seja implementada, sem se precupar cm sistemas de autenticaçã e restrições de acess. Um err cmum a adtar essa prática é a cnfusã pr parte ds prgramadres de códig simples e códig fácil. Nem sempre códig mais fácil de ser desenvlvid levará a sluçã mais simples pr parte de prjet. Esse entendiment é fundamental para bm andament d XP. Códig fácil deve ser identificad e substituíd pr códig simples. Time Ces (Whle Team): A equipe de desenvlviment é frmada pel cliente e pela equipe de desenvlviment. Testes de Aceitaçã (Custmer Tests): Sã testes cnstruíds pel cliente e cnjunt de analistas e testadres, para aceitar um determinad requisit d sistema. Ritm Sustentável (Sustainable Pace): Trabalhar cm qualidade, buscand ter ritm de trabalh saudável (40 hras/semana, 8 hras/dia), sem hras extras. Hras extras sã permitidas quand truxerem prdutividade para a execuçã d prjet. Outra prática que se verifica neste prcess é a prática de trabalh energizad, nde se busca trabalh mtivad sempre. Para ist ambiente de trabalh e a mtivaçã da equipe devem estar sempre em harmnia. Reuniões em pé (Stand-up Meeting): Reuniões em pé para nã se perder fc ns assunts, prduzind reuniões rápidas, apenas abrdand tarefas realizadas e tarefas a realizar pela equipe.

30 Matéria: O Prcess de Desenvlviment de Sftware Página: 58 Psse Cletiva (Cllective Ownership): O códig-fnte nã tem dn e ninguém precisa slicitar permissã para pder mdificar mesm. O bjetiv cm ist é fazer a equipe cnhecer tdas as partes d sistema. Prgramaçã em Pares (Pair Prgramming): é a prgramaçã em par/dupla num únic cmputadr. Geralmente a dupla é frmada pr um iniciante na linguagem e utra pessa funcinand cm um instrutr. Cm é apenas um cmputadr, nvat é que fica à frente fazend a cdificaçã, e instrutr acmpanha ajudand a desenvlver suas habilidades. Desta frma prgrama sempre é revist pr duas pessas, evitand e diminuind assim a pssibilidade de errs (bugs). Cm ist busca-se sempre a evluçã da equipe, melhrand a qualidade d códig fnte gerad. Padrões de Cdificaçã (Cding Standards): A equipe de desenvlviment precisa estabelecer regras para prgramar e tds devem seguir estas regras. Desta frma parecerá que td códig-fnte fi editad pela mesma pessa, mesm quand a equipe pssui 10 u 100 membrs. Desenvlviment Orientad a Testes (Test Driven Develpment): Primeir crie s testes unitáris (unit tests) e depis crie códig para que s testes funcinem. Esta abrdagem é cmplexa n iníci, pis vai cntra prcess de desenvlviment de muits ans. Só que s testes unitáris sã essenciais para que a qualidade d prjet seja mantida. Refatraçã (Refactring): É um prcess que permite a melhria cntínua da prgramaçã, cm mínim de intrduçã de errs e mantend a cmpatibilidade cm códig já existente. Refabricar melhra a clareza (leitura) d códig, divide- em móduls mais cess e de mair reaprveitament, evitand a duplicaçã de códig-fnte. Integraçã Cntínua (Cntinuus Integratin): Sempre que prduzir uma nva funcinalidade, nunca esperar uma semana para integrar à versã atual d sistema. Ist só aumenta a pssibilidade de cnflits e a pssibilidade de errs n códig-fnte. Integrar de frma cntínua permite saber status real da prgramaçã. Origem: Engenharia de Sftware, Rger Pressman, 2006 O XP usa uma abrdagem rientada a bjets cm seu paradigma de desenvlviment preferencial. A metdlgia d Extreme Prgramming pssui 4 atividades de arcabuç:

31 Matéria: O Prcess de Desenvlviment de Sftware Página: 59 Planejament: Prjet: Cdificaçã: Teste: Criaçã de um cnjunt de histórias que descrevem as características e funcinalidades requeridas. O cliente atribui uma priridade para cada história, cm base n valr de negóci glbal da história. Membrs da equipe atribuem um cust às histórias medid em semanas de desenvlviment. Se uma história precisar de mais de 3 semanas, pede-se a cliente para dividir a história em histórias menres. Nvas histórias pdem ser escritas a qualquer mment. A equipe e cliente reúnem-se para agrupar as histórias na versã seguinte e identificar md cm elas serã desenvlvidas. Calcula-se a velcidade de prjet quantidade de histórias implementadas na primeira versã para ajudar a estimar datas futuras e verificar cmprmetiment cm as histórias. Segue rigrsamente princípi KIS (keep it simple mantenha simples), frnecend apenas diretrizes de implementaçã. Encraja us de cartões CRC (Classe-Respnsabilidade-Clabraçã) para identificar e rganizar as classes rientadas a bjets que sã relevantes para increment. Se um prblema de prjet difícil é encntrad, recmenda-se a criaçã imediata de um prtótip peracinal, denminad Sluçã de Pnta. Encraja-se a refabricaçã prcess de mdificar um sistema de tal md que ele nã altere cmprtament extern d códig, mas aperfeiçe a estrutura interna. O prjet é vist cm um artefat prvisóri, cntinuamente mdificad. Desenvlviment de testes unitáris das histórias antes da cdificaçã, exercitand a interface, as estruturas de dads e a funcinalidade d cmpnente e pssibilitand um feedback mais rápid quand códig é cncluíd. Prgramaçã em pares. Os fcs sã um puc diferentes, pderia-se ter um prgramadr pensand ns detalhes d códig e utr n atendiment das nrmas de prgramaçã. Integraçã diária ds códigs desenvlvids pels pares de prgramadres. Testes de regressã cm s testes unitáris gerads anterirmente. Teste de integraçã. Teste de validaçã. Teste de aceitaçã XP (testes d cliente).

32 Matéria: O Prcess de Desenvlviment de Sftware Página: SCRUM Origem: Wikipédia, a enciclpédia livre. Scrum é um métd ágil para Gerenciament de prjets. Inicialmente, Scrum fi cncebid cm um estil de gerenciament de prjets em empresas de fabricaçã de autmóveis e prduts de cnsum, pr Takeuchi e Nnaka n artig "The New New Prduct Develpment Game". Eles ntaram que prjets usand equipes pequenas e multidisciplinares (crss-functinal) prduziram s melhres resultads, e assciaram estas equipes altamente eficazes à frmaçã Scrum d Rugby (utilizada para reiníci d jg em certs cass). Jeff Sutherland, Jhn Scumnitales, e Jeff McKenna dcumentaram, cnceberam e implementaram Scrum, cm descrit abaix, na empresa Easel Crpratin em 1993, incrprand estils de gerenciament bservads pr Takeuchi e Nnaka. Em 1995, Ken Schwaber frmalizu a definiçã de Scrum e ajudu a implantá-l em desenvlviment de sftware em td mund. Scrum junta cnceits de Lean, desenvlviment iterativ e d estud de Takeuchi e Nnaka. A funçã primária d Scrum é ser utilizad para gerenciament de prjets de desenvlviment de sftware. Ele tem sid usad cm sucess para iss, assim cm Extreme Prgramming e utras metdlgias de desenvlviment. Prém, tericamente pde ser aplicad em qualquer cntext n qual um grup de pessas necessitem trabalhar juntas para atingir um bjetiv cmum, cm iniciar uma escla pequena, prjets de pesquisa científica, u até mesm planejament de um casament. Mesm que Scrum tenha sid idealizad para ser usad em gestã de prjets de desenvlviment de sftware, ele também pde ser usad para gerenciar equipes de manutençã, u cm uma abrdagem para gestã de prgramas: Scrum de Scrums. Características de Scrum Cada sprint é uma iteraçã que segue cicl PDCA e entrega increment de sftware prnt; Um backlg é um cnjunt de requisits, pririzad pel Prduct Owner (cliente); Há entrega de cnjunt fix de itens d backlg em uma série de iterações curtas u sprints; Breve reuniã diária, u scrum, em que cada participante fala sbre prgress cnseguid, trabalh a ser realizad e/u que impede de seguir avançand (também chamad de Standup Meeting u Daily Meeting, já que s membrs d time geralmente ficam em pé); Breve sessã de planejament, na qual s itens d backlg para uma sprint (iteraçã) sã definids; Retrspectiva, na qual tds s membrs da equipe refletem sbre a sprint passada. O Scrum é facilitad pr um Scrum Master, que tem cm funçã primária remver qualquer impediment à habilidade de uma equipe de entregar bjetiv d sprint. O Scrum Master nã é líder da equipe (já que as equipes sã aut-rganizadas), mas atua cm um firewall entre a equipe e qualquer influência desestabilizadra. Outra funçã extremamente imprtante de um Scrum Master é de assegurar que a equipe esteja utilizand crretamente as práticas de Scrum, mtivand-s e mantend fc na meta da Sprint. Scrum permite a criaçã de equipes aut-rganizadas, encrajand a cmunicaçã verbal entre tds s membrs da equipe e entre tdas as disciplinas que estã envlvidas n prjet. Um princípi chave d Scrum é recnheciment de que desafis fundamentalmente empírics nã pdem ser reslvids cm sucess utilizand uma abrdagem tradicinal de "cntrle". Assim, Scrum adta uma abrdagem empírica, aceitand que prblema nã pde ser ttalmente entendid u definid, fcand na maximizaçã da habilidade da equipe de respnder de frma ágil as desafis emergentes. Um ds grandes defeits d Scrum, prém, é a abrdagem de "receita de bl" d gerenciament de prjets exemplificad n Prject Management Bdy f Knwledge u PRINCE2, que tem cm bjetiv atingir qualidade através da aplicaçã de uma série de prcesss prescrits.

33 Matéria: O Prcess de Desenvlviment de Sftware Página: 61 Backlg de prdut e backlg de sprint Um backlg é uma lista de itens pririzads a serem desenvlvids para um sftware. O backlg de prdut é mantid pel Prprietári d Prdut e é uma lista de requisits que tipicamente vêm d cliente. O backlg de sprint é uma interpretaçã d backlg d prdut e cntém tarefas cncretas que serã realizadas durante próxim sprint para implementar alguns ds itens principais n backlg d prdut. O backlg de prdut e de sprint sã, entã, duas cisas ttalmente diferentes, primeir cntend requisits de alt-nível e segund cntend infrmações sbre cm a equipe irá implementar s requisits. Planejament de sprint Antes de td sprint, Prprietári d Prdut, Scrum Master e a Equipe decidem n que a equipe irá trabalhar durante próxim sprint. O Prprietári d Prdut mantém uma lista pririzada de itens de backlg, backlg d prdut, que pde ser repririzad durante planejament d sprint. A Equipe selecina itens d tp d backlg d prdut. Eles selecinam smente quant de trabalh eles pdem executar para terminar. A Equipe entã planeja a arquitetura e design de cm backlg d prdut pde ser implementad. Os itens d backlg d prdut sã entã destrinchads em tarefas que se trnam backlg d sprint. Scrum simplificad Muitas rganizações têm sid resistentes às metdlgias intrduzidas em baixs níveis da rganizaçã. Prém, a adaptabilidade d Scrum permite que ele seja intrduzid de frma invisível ("stealth"), usand s três passs: Agende uma demnstraçã d sftware cm seu cliente em um mês a partir de agra; Cm equipe, tme um mês para deixar sftware prnt para uma dem, cm funcinalidades prntas, nã simplesmente telas; Na demnstraçã, btenha feedback e use- para guiar seu próxim mês de trabalh de desenvlviment. Algumas características de Scrum Clientes se trnam parte da equipe de desenvlviment (s clientes devem estar genuinamente interessads na saída); Entregas frequentes e intermediárias de funcinalidades 100% desenvlvidas; Plans frequentes de mitigaçã de riscs desenvlvids pela equipe; Discussões diárias de status cm a equipe; A discussã diária na qual cada membr da equipe respnde às seguintes perguntas: O que fiz desde ntem? O que estu planejand fazer até amanhã? Existe alg me impedind de atingir minha meta? Transparência n planejament e desenvlviment; Reuniões frequentes cm s stakehlders (tds s envlvids n prcess) para mnitrar prgress; Prblemas nã sã ignrads e ninguém é penalizad pr recnhecer u descrever qualquer prblema nã vist; Lcais e hras de trabalh devem ser energizadas, n sentid de que "trabalhar hras extras" nã necessariamente significa "prduzir mais".

34 Matéria: O Prcess de Desenvlviment de Sftware Página: 62 Agendand discussões diárias Um mment bm para as discussões diárias é depis d almç. Durante a manhã pde ser cmplicad. Estas discussões de status nã demram e uma frma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadr negr. Cm as pessas tendem a ficar cansadas depis d almç, ter uma viva reuniã em pé nessa hra permite que a equipe mantenha a sua energia alta. Cm tds estiveram trabalhand durante a manhã, suas mentes estã fcadas n trabalh e nã em questões pessais. Scrum Sl Scrum é basead em pequenas equipes. Ele permite a cmunicaçã entre s membrs da equipe. Entretant, há uma grande quantidade de sftwares desenvlvids pr prgramadres sls. Um sftware send desenvlvid pr um só prgramadr pde ainda se beneficiar de alguns princípis d Scrum, cm: um backlg de prdut, um backlg de sprint, um sprint e uma retrspectiva de sprint. Scrum Sl é uma versã adaptada para us de prgramadres sl. Origem: Engenharia de Sftware, Rger Pressman, 2006 Algumas características seguidas pel SCRUM: Pendência lista pririzada de requisits u características d prjet que frnecem valr de negóci para cliente. Itens pdem ser adicinads a qualquer hra; Sprints unidades de trabalh que sã necessárias para satisfazer a um requisit definid na pendência que precisa ser cumprid em um interval de temp definid (tipicamente 30 dias). Durante sprint, s itens em pendência a que as unidades de trabalh d sprint se destinam sã cngelads; Reuniões Scrum sã reuniões curtas (nrmalmente 15 minuts) feitas diariamente pela equipe. Três questões-chave sã feitas e respndidas pr tds: O que vcê fez desde a última reuniã de equipe? Que bstáculs vcê está encntrand? O que vcê planeja realizar até a próxima reuniã? Dems entrega increment de sftware a cliente de md que a funcinalidade implementada pssa ser demnstrada e avaliada pela cliente.

35 Matéria: O Prcess de Desenvlviment de Sftware Página: FDD (FEATURE DRIVEN DEVELOPMENT) Origem: Wikipédia, a enciclpédia livre A FDD - Feature Driven Develpment (Desenvlviment Guiad pr Funcinalidades) é uma das seis metdlgias ágeis riginais, cujs representantes redigiram Manifest Ágil para Desenvlviment de Sftware, em Nessa casiã, representante da FDD fi Jn Kern, que trabalhava na TgetherSft, substituind Peter Cad. Origens A FDD nasceu num prjet em Cingapura, entre 1997 e 1999, a partir d Métd Cad (uma metdlgia cmpleta para Análise, Desenh e Prgramaçã Orientads a Objets, desenvlvida pr Peter Cad nas décadas de 1980 e 1990) e das técnicas de gerenciament iterativ, incremental e enxut de prjets utilizadas pr Jeff De Luca, um gerente de prjets australian. Seu lema é "Resultads frequentes, tangíveis e funcinais". A primeira descriçã ficial ds prcesss fi publicada n livr "Java Mdeling in Clr with UML", pr Peter Cad, Eric Lefebvre e Jeff De Luca, em O livr de referência é "A Practical Guide t Feature-Driven Develpment", pr Stephen Palmer e Jhn Mac Felsing, publicad em 2002 pela Prentice-Hall, cmpnd uma série editada pel própri Peter Cad. FDD e a Família Ágil Cm relaçã às utras metdlgias de desenvlviment de sftware, situa-se numa psiçã intermediária entre as abrdagens mais prescritivas (Prcess Unificad, Cascata tradicinal - Waterfall) e as abrdagens Ágeis (XP - Prgramaçã Extrema, Scrum, Crystal, etc.). Oferece um cnjunt ces de princípis e práticas tant para a Gestã de Prjets quant para a Engenharia de Sftware, mas cnvive bem cm abrdagens mais especialistas, cm Scrum.

36 Matéria: O Prcess de Desenvlviment de Sftware Página: 64 Apesar de algumas divergências pntuais cm a XP, várias práticas prpstas pr esta última também sã utilizadas pr equipes usand FDD, cm s testes unitáris, refatraçã, prgramaçã em pares, integraçã cntínua, entre utras. Apenas a ênfase na FDD é que nã é tã grande quant na XP. A FDD também prpõe práticas cm inspeçã frmal (de desenh e de códig) e psse individual/situacinal de códig/classe, que pdem cntrastar cm algumas das práticas fundamentais da XP. A experiência da equipe e ds gerentes é que deve julgar quais práticas sã mais aprpriadas. Os Prcesss A FDD é, classicamente, descrita pr cinc prcesss: Desenvlver um Mdel Abrangente: pde envlver desenvlviment de requisits, análise rientada a bjets, mdelagem lógica de dads e utras técnicas para entendiment d dmíni de negóci em questã. O resultad é um mdel de bjets (e/u de dads) de alt nível, que guiará a equipe durante s cicls de cnstruçã. Cnstruir uma Lista de Funcinalidades: decmpsiçã funcinal d mdel d dmíni, em três camadas típicas: áreas de negóci, atividades de negóci e passs autmatizads da atividade (funcinalidades). O resultad é uma hierarquia de funcinalidades que representa prdut a ser cnstruíd (também chamad de prduct backlg, u lista de espera d prdut). Planejar pr Funcinalidade: abrange a estimativa de cmplexidade e dependência das funcinalidades, também levand em cnsideraçã a priridade e valr para negóci/cliente. O resultad é um plan de desenvlviment, cm s pactes de trabalh na sequência aprpriada para a cnstruçã. Detalhar pr Funcinalidade: já dentr de uma iteraçã de cnstruçã, a equipe detalha s requisits e utrs artefats para a cdificaçã de cada funcinalidade, incluind s testes. O prjet para as funcinalidades é inspecinad. O resultad é mdel de dmíni mais detalhad e s esquelets de códig prnts para serem preenchids. Cnstruir pr Funcinalidade: cada esquelet de códig é preenchid, testad e inspecinad. O resultad é um increment d prdut integrad a repsitóri principal de códig, cm qualidade e ptencial para ser usad pel cliente/usuári.

37 Matéria: O Prcess de Desenvlviment de Sftware Página: 65 Origem: Engenharia de Sftware, Rger Pressman, 2006 Característica é uma funçã valrizada pel cliente que pde ser implementada em duas semanas u mens; Define cinc atividades de arcabuç clabrativas (prcesss); O FDD clca mais ênfase em diretrizes e técnicas de gestã de prjet d que muits utrs métds ágeis. Benefícis: Cm as características sã pequens blcs de funcinalidade passíveis de entrega, s usuáris pdem descrevê-las mais facilmente, entender cm elas se relacinam umas cm as utras e revisá-las melhr quant a ambiguidades, errs u missões; As características pdem ser rganizadas em um agrupament hierárquic relacinad a negóci; Cm uma característica é um increment de sftware passível de entrega d FDD, a equipe desenvlve características peracinais a cada duas semanas; Cm as características sã pequenas, suas representações de prjet e de códig sã mais fáceis de inspecinar; Planejament de prjet, crngramaçã e mnitraçã sã guiads pela hierarquia de características em vez de pr um cnjunt de tarefas de engenharia de sftware arbitrariamente adtad.

38 Matéria: O Prcess de Desenvlviment de Sftware Página: AUTOMATIZAÇÃO DO PROCESSO DE SOFTWARE AUTOMATIZAÇÃO DE PROCESSOS DE SOFTWARE Origem: Dissertaçã de Mestrad - DEFINIÇÃO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autr: Gleidsn Bertl. UFES Devid à influência d prcess de sftware n desenvlviment de prduts de sftware de qualidade, muit trabalh tem sid feit n sentid de apiar rganizações em seus esfrçs pela busca da qualidade de prcess. Cnfrme apntad pr ARBAOUI et al. (2002), as pesquisas na área de prcesss de sftware ns últims ans têm explrad duas principais vertentes: (i) abrdagens para mdelagem, análise e melhria d prcess de sftware; (ii) tecnlgia de api a prcess de sftware. A primeira vertente fcaliza abrdagens para estruturaçã, rganizaçã, dcumentaçã e descriçã de prcesss de sftware e inclui nrmas e mdels de qualidade de prcess de sftware, tais cm as apresentadas na seçã anterir. A segunda vertente está vltada para desenvlviment de Ambientes de Desenvlviment de Sftware (ADSs), que buscam cmbinar técnicas, métds e ferramentas para apiar engenheir de sftware na cnstruçã de prduts de sftware, abrangend tdas as atividades inerentes a prcess, tais cm planejament, gerência, desenvlviment e cntrle da qualidade. Os benefícis da utilizaçã de ADSs incluem (PRESSMAN, 2005): Facilitar a transferência de infrmaçã entre ferramentas e, cnsequentemente, entre passs d prcess de sftware; Reduzir s esfrçs para realizar atividades de gerência de cnfiguraçã, garantia de qualidade e prduçã de dcumentaçã; Aumentar cntrle d prjet, através de melhr planejament, mnitrament e cmunicaçã; Prver crdenaçã entre s recurss humans que estã trabalhand em um grande prjet de sftware. A integraçã de ferramentas ainda é um ds maires desafis ds ADSs, pis demanda representaçã cnsistente da infrmaçã, interfaces padrnizadas, significads hmgênes para a cmunicaçã entre engenheirs de sftware e ferramentas, e uma efetiva abrdagem que pssibilite prtar s ADSs para várias platafrmas (PRESSMAN, 2005). THOMAS e NEJMEH (1992), TRAVASSOS (1994), FALBO (1998) e PFLEEGER (2001), dentre utrs, prpõem que a integraçã de ferramentas em ADSs seja tratada através de uma infraestrutura que cntemple várias dimensões, dentre elas: Integraçã de Dads: trata de serviçs de repsitóri de dads, prvend armazenament e gerência de bjets, e integraçã de dads, permitind cmpartilhament de infrmações entre as ferramentas; Integraçã de Apresentaçã: diz respeit a serviçs de interface cm usuári. As interfaces de um ADS devem ser hmgêneas e cnsistentes, permitind que s desenvlvedres alternem entre as ferramentas que utilizam, sem mudanças substanciais de estil; Integraçã de Cntrle: está relacinada as serviçs de gerência de funcinalidades e mensagens, permitind uma ferramenta ntificar u iniciar uma açã em utra ferramenta, cntrland s events crrids e cmpartilhand funcinalidades; Integraçã de Prcess: é btida pela ligaçã explícita entre ferramentas e prcess de sftware. Para integrar ferramentas, é precis ter um fc frte n gerenciament d prcess de sftware. O prcess deve definir que ferramentas um engenheir de sftware pde utilizar e quand deverá ter acess às mesmas, em funçã da atividade que está realizand; Integraçã de Platafrma: trata da independência da platafrma sbre a qual funcinará a ferramenta;

39 Matéria: O Prcess de Desenvlviment de Sftware Página: 67 Integraçã de Cnheciment: diz respeit as serviçs de gerência de cnheciment, permitind capturar cnheciment durante s prjets de sftware e ferecer api basead em gerência de cnheciment as engenheirs de sftware durante a realizaçã de atividades d prcess. Devid às dificuldades inerentes a cntrle de prcesss de sftware, a integraçã de prcess tem se mstrad tã imprtante que deu rigem a uma nva classe de ambientes, s Ambientes de Desenvlviment de Sftware Centrads em Prcess (ADSCPs). ADSCPs integram ferramentas para apiar desenvlviment d sftware e para apiar a mdelagem e a execuçã d prcess de sftware utilizad para desenvlver este prdut (HARRISON et al., 2000; FUGGETTA, 2000). Um ADSCP explra uma definiçã explícita d prcess de sftware e pde ser vist cm a autmatizaçã parcial desse prcess, incluind mecanisms para (CHRISTIE, 1995): (i) guiar a sequência de atividades definida; (ii) gerenciar s prduts que estã send desenvlvids; (iii) executar ferramentas necessárias para a realizaçã das atividades; (iv) permitir cmunicaçã entre as pessas; (v) clher dads de métricas autmaticamente; (vi) reduzir errs humans e (vii) prver cntrle d prjet à medida que este vai send executad. Prcesss mdelads em um ADSCP tipicamente descrevem as atividades a serem realizadas, s respnsáveis pr cada uma delas e as ferramentas de sftware a serem utilizadas. Sã criads para váris prpósits, dentre eles: dcumentaçã d prcess de sftware, melhria d prcess de sftware, gerenciament d flux de trabalh e autmatizaçã (GRUHN, 2002). Desta frma, a prver meis de descrever e implementar prcesss de engenharia de sftware, ADSCPs prvêem um mecanism de integraçã de prcess e ferramentas e, parcialmente, de autmatizaçã de tarefas (HARRISON et al., 2000). Alguns exempls de ADSCPs citads em (HARRISON et al.,2000) incluem: Adele, Arg, PCTE e SPADE. Em (ARBAOUI et al., 2002) sã citads TEMPO e APEL (cnstruíds a partir d Adele), LEU, PEACE, PIE e OZ. HOLZ et al. (2001) e RICHTER e MAURER (2003) enfcam ADSCP MILOS (Mdeling Language and Operatinal Supprt fr Sftware Prcesses), que prvê meis para definir um mdel de prcess genéric e cnfigurar plans de prjet cncrets baseads neste mdel. N cntext deste trabalh, dis ADSCPs merecem destaque: ambiente ODE (FALBO et al., 2003), n qual este trabalh fi desenvlvid, e a Estaçã TABA (BERGER, 2003) que adta uma filsfia de definiçã de prcesss crrelata à apresentada neste trabalh. A seguir, esses dis ambientes sã apresentads cm maires detalhes A Estaçã TABA Origem: Dissertaçã de Mestrad - DEFINIÇÃO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autr: Gleidsn Bertl. UFES A Estaçã TABA, desenvlvida desde 1990 (ROCHA et al., 1990), é um meta-ambiente capaz de gerar ambientes de desenvlviment de sftware adequads às particularidades de rganizações, prcesss de sftware e prjets específics. Para tal, utiliza atualmente a abrdagem de geraçã de ambientes mstrada na Figura 2.3.

40 Matéria: O Prcess de Desenvlviment de Sftware Página: 68 Figura Geraçã de ambientes a partir da Estaçã TABA (BERGER, 2003) Inicialmente, é necessári criar um Ambiente Cnfigurad a partir das características da rganizaçã e de sua maturidade em desenvlver sftware. O ambiente cnfigurad cntém prcess padrã da rganizaçã e s prcesss especializads para s paradigmas de desenvlviment utilizads na rganizaçã. Esse ambiente armazena e prvê cnheciment capturad pela rganizaçã, imprtante para desenvlviment e a manutençã de sftware. Um ambiente cnfigurad cntém uma ferramenta para apiar a instanciaçã de prcesss, que tem a capacidade de gerar, a partir ds prcesss instanciads, ambientes de desenvlviment de sftware para prjets específics, s dits Ambientes de Desenvlviment de Sftware Orientads a Organizaçã (ADSOrg). Os ambientes instanciads sã s ambientes que apóiam desenvlviment ds prduts de sftware e cntêm utras ferramentas de api a desenvlviment (BERGER, 2003). A Estaçã TABA é também um ADS Centrad em Prcess, pis pssibilita mdelar explicitamente um prcess de sftware e cntrlá-l n ambiente instanciad. O ambiente pssibilita, ainda, a gestã d cnheciment da rganizaçã, definind um repsitóri de cnheciment que pde ser acessad pels ADSOrg instanciads. O prcess de instanciaçã descreve as atividades necessárias para se realizar a adaptaçã (instanciaçã) de um prcess especializad para um prjet específic, dentr d cntext de um Ambiente Cnfigurad, a saber (BERGER, 2003): Pré-Cndiçã: Identificaçã de Atividades Obrigatórias 1. Caracterizar Prjet 1.1 Definir Prjet 1.2 Identificar Características d Prjet 2. Planejar Prcess 2.1 Incluir Atividades d Tip de Sftware 2.2 Definir Mdel de Cicl de Vida 2.3 Mapear Atividades d Mdel de Cicl de Vida Verificar a Existência de Mapeament Anterir Realizar Mapeament

41 Matéria: O Prcess de Desenvlviment de Sftware Página: Excluir Atividades Nã Pertinentes 2.5 Incluir Nvas Atividades 2.6 Selecinar Técnicas de Avaliaçã 2.7 Selecinar Ferramentas 3. Instanciaçã de ADSOrg para prjet As atividades descritas sã de respnsabilidade d gerente d prjet. O resultad da instanciaçã é um prcess instanciad que cnstitui Plan d Prcess de Desenvlviment para um prjet específic. A cada nv prjet deve ser instanciad um nv ambiente (BERGER, 2003). 3.8 TEXTO COMPLEMENTAR O Ambiente ODE Origem: ODE, Labratóri de Sftware, UFES ( Alta qualidade e prdutividade sã fatres crítics n desenvlviment de sftware. Neste cntext, trna-se essencial prver ferramentas para ajudar engenheir de sftware em suas tarefas. O suprte de ferramentas influencia diretamente temp de desenvlviment d sftware, seu cust e a qualidade d prdut desenvlvid [1]. Assim, diversas ferramentas, cnhecidas cm ferramentas CASE (Cmputer-Aided Sftware Engineering), têm sid amplamente utilizadas n desenvlviment de sftware. Entretant, essas geralmente sã ferramentas isladas, que nã sã capazes de cmpartilhar serviçs, u sequer infrmações. Muit embra us de ferramentas individuais pssa trazer benefícis em atividades separadas, real pder dessas ferramentas de api smente pde ser alcançad através da integraçã [2]. Dessa frma, Ambientes de Desenvlviment de Sftware (ADSs) têm ganhad cada vez mais imprtância. Tais ambientes buscam cmbinar técnicas, métds e ferramentas para apiar engenheir de sftware na cnstruçã de prduts de sftware, abrangend tdas as atividades inerentes a prcess, tais cm de gerência, desenvlviment e cntrle da qualidade [3]. Um ADS tem bjetiv de ser um ambiente cmplet, capaz de suprtar td prcess de sftware, cm diversas ferramentas integradas trabalhand em cnjunt. ODE (Ontlgy-based sftware Develpment Envirnment) é um ADS centrad em prcess, fundamentad em ntlgias. O ambiente ODE vem send desenvlvid n Labratóri de Engenharia de Sftware da UFES (LabES) e é implementad em platafrma livre, utilizand Java cm linguagem de prgramaçã e banc de dads PstgreSQL. Algumas características de ODE que merecem destaque sã: a unifrmidade de cnceits prvida pelas ntlgias, que facilita a integraçã, deixa ambiente mais hmgêne e trna mais efetiva a cmunicaçã entre pessas e entre ferramentas; a frte base em cnheciment, que permite que ambiente fereça um suprte especializad a usuári na realizaçã de suas tarefas e pssibilita que as infrmações geradas mantenham-se interligadas e cnsistentes a lng de td prcess; e fc em ferramentas gerenciais, uma vez que a gerência é uma área de grande imprtância e ainda é bastante carente em terms de ferramentas. A seguir, sã brevemente apresentads s principais móduls e ferramentas integradas atualmente a ambiente ODE.

42 Matéria: O Prcess de Desenvlviment de Sftware Página: 70 - Cntrle de Prjets (Manutençã e Caracterizaçã) ODE é direcinad a prjets. Assim, a mair parte das funcinalidades d ambiente é acessada n cntext de um prjet. O Ambiente permite que váris prjets sejam criads e cntrlads. Dessa frma, s usuáris têm acess apenas as prjets em que estejam alcads. Outr pnt relevante é a Caracterizaçã de Prjets que pssibilita a cmparaçã entre prjets e, entã, a recuperaçã de prjets similares, muit imprtante nas tarefas que fazem us de dads histórics. - Cadastr de Cnheciment (sbre Prcesss, Riscs e Qualidade) Permite que s dads rganizacinais sejam registrads n ambiente. Cm base nas ntlgias existentes atualmente em ODE, é pssível armazenar infrmações a respeit de prcesss (mdels de cicl de vida, atividades, recurss, artefats, prcediments etc.), riscs e métricas de qualidade. Cm as ferramentas integradas ferecem suprte frtemente basead nesse cnheciment, é pssível frnecer a usuári api direcinad a cnheciment rganizacinal. <<Cncept>> Prcedure 0..* sub-activity pssible adptin 0..* 0..* 0..* <<Cncept>> 0..* Activity prduct 0..* <<Cncept>> Artifact 0..* 0..* 0..* 0..* input <<Cncept>> Prcess 1 use 0..* <<Cncept>> Sftware Tl <<Cncept>> Resurce implementatin * <<Cncept>> Human Resurce <<Cncept>> Prject 0..* 0..* team allcatin 0..* <<Cncept>> Team - Cadastr de Recurss Organizacinais Gerencia s recurss humans, ferramentas de sftware e recurss de hardware da rganizaçã, assim cm s usuáris d ambiente. Pssibilita que s clabradres sejam assciads às funções que estã apts a realizar, apiand a alcaçã de recurss às atividades. Além diss, registra as ferramentas de sftware utilizadas pela rganizaçã através d ambiente, sejam elas parte integrante d ambiente, u ferramentas externas desenvlvidas independentemente dele.

43 Matéria: O Prcess de Desenvlviment de Sftware Página: 71 - Definiçã de Prcesss Pr ser centrad em prcess, ODE tem esta cm uma de suas ferramentas mais centrais. É nela que sã definids s prcesss que guiarã s prjets da rganizaçã. A ferramenta utiliza um efetiv suprte d cnheciment para apiar gerente na definiçã de um mdel de cicl de vida para prcess, de suas atividades, ds artefats a serem prduzids e cnsumids, ds recurss humans, de sftware e de hardware necessáris à execuçã, e ds métds, técnicas, rteirs e nrmas utilizads. Devid à definiçã d prcess, ambiente é capaz de se cnfigurar de frma a melhr atender a prcess definid, exibind as ferramentas que devem apiar cada usuári nas atividades em que sã necessárias. - Acmpanhament de Prjets Assim que um prjet é iniciad, é pssível acmpanhá-l pr esta ferramenta. O prcess d prjet é apresentad na frma de um graf que exibe as atividades, destacand sua hierarquia, rdem de execuçã e estads atuais. Para cada uma das atividades, sã mstradas infrmações relevantes cm seus artefats, prcediments, recurss alcads e datas. Dessa frma, gerente pde mnitrar e cntrlar andament ds prjets. - Alcaçã de Recurss Humans Esta ferramenta apóia a definiçã de equipes para prjets e a alcaçã de seus membrs às atividades definidas. Cm base na necessidade de recurss humans de cada atividade (estipulada na definiçã de prcesss), s clabradres da rganizaçã pdem ser alcads às atividades, send definids seus papéis, datas de alcaçã e dedicaçã. A partir da alcaçã, ambiente se cnfigura para permitir as clabradres acess apenas às funcinalidades necessárias à realizaçã das atividades em que estã alcads.

44 Matéria: O Prcess de Desenvlviment de Sftware Página: 72 - Alcaçã de Ferramentas de Sftware De frma semelhante à alcaçã de recurss humans, esta ferramenta permite alcar as ferramentas da rganizaçã às atividades que delas necessitam. A alcaçã é válida tant para ferramentas internas quant externas e também é necessária à cnfiguraçã d ambiente, dispnibilizand as ferramentas ns mments em que devem ser utilizadas. - GeRis - Gerência de Riscs Gerenciar riscs é um fatr de grande imprtância em qualquer prjet. GeRis apóia a gerência de riscs ds prjets de sftware e a elabraçã de um plan de riscs. Cm base n cnheciment rganizacinal sbre riscs, gerente pde identificar s riscs relevantes a cada prjet; avaliá-ls segund suas prbabilidades, impacts, e cnsequências; selecinar ações adequadas de mitigaçã e cntingência e, pr fim, gerar um plan de riscs para prjet. - Agenda e Registr de Esfrç Através da ferramenta de agenda, s usuáris d ambiente pdem visualizar a quais atividades de que prjets estã alcads, as datas previstas e efetivas e esfrç registrad até mment. A gerente de prjets, é frnecida uma visã mais ampla d andament das atividades. A ferramenta permite ainda que s usuáris registrem s esfrçs despendids diariamente nas atividades em que estã alcads. - EstimaODE - Estimativas de Tamanh e Esfrç Esta ferramenta pssui uma estrutura cmum que cntempla três abrdagens de estimativas: - Análise de Pnts de Funçã: apóia a realizaçã de estimativas de tamanh, utilizand a técnica de

45 Matéria: O Prcess de Desenvlviment de Sftware Página: 73 pnts de funçã. Pssibilita que usuári inicie as estimativas, infrme s dads das funções d sistema, registre s níveis de influência relacinads e gere um relatóri cm s pnts de funçã determinads. Permite ainda que sejam feitas recntagens ds pnts de funçã n decrrer d prjet, aprveitand a cntagem anterir e mantend um históric para efeit cmparativ. - Análise de Pnts de Cass de Us: utiliza a técnica de pnts de cass de us para também dar suprte à realizaçã de estimativas de tamanh. Uma vez iniciada a estimativa, é pssível determinar s pess de atres e cass de us, s fatres técnics e calcular s pnts de cass de us. Também permite a geraçã de relatóris e a recntagem de pnts. - Estimativa pr Decmpsiçã d Prcess: apóia a realizaçã de estimativas de esfrç utilizand decmpsiçã d prcess e dads histórics de prjets similares. Permite estimar esfrç de prjets e suas atividades baseand-se em dads de esfrçs reais btids de prjets já realizads n ambiente. - Gerência de Cnheciment Gerenciar cnheciment prduzid durante desenvlviment de sftware é um fatr de grande imprtância e que traz vantagens à realizaçã de prjets. ODE pssui uma infra-estrutura de gerência de cnheciment que é cmpsta pr uma memória rganizacinal e pr serviçs que permitem a criaçã, recuperaçã, disseminaçã, us e manutençã de cnheciment. Alguns itens de cnheciment cm s quais ambiente lida sã lições aprendidas e artefats em geral. Cm a utilizaçã da gerência de cnheciment, s usuáris pdem registrar cnheciment que adquirem n decrrer ds prjets n própri ambiente, assim cm buscar cnheciment registrad pr utras pessas da rganizaçã. Cm pôde ser bservad, ambiente ODE pssui um abrangente crp de ferramentas úteis a várias tarefas d desenvlviment de sftware. Cntud, a pesquisa e desenvlviment cntinuam. Dessa frma, algumas ferramentas que já se encntram em fase de cnstruçã e em breve serã incrpradas a ambiente sã: