Modulo IV Introduo Engenharia de Software Pedro de Alcntara dos Santos Neto

FICHA BIBLIOGRFICA

PRESIDENTE DA REPBLICA Luiz Incio Lula da Silva MINISTRO DA EDUCAO Fernando Haddad GOVERNADOR DO ESTADO DO PIAU Wellington Dias UNIVERSIDADE FEDERAL DO PIAU Luiz de Sousa Santos Jnior SECRETRIO DE EDUCAO A DISTNCIA DO MEC Carlos Eduardo Bielschowsky COORDENADORIA GERAL DA UNIVERSIDADE ABERTA DO BRASIL Celso Costa SECRETRIO DE EDUCAO DO ESTADO DO PIAU Antnio Jos Medeiro COORDENADOR GERAL DO CENTRO DE EDUCAO ABERTA A DISTNCIA DA UFPI Gildsio Guedes Fernandes SUPERITENDENTE DE EDUCAO SUPERIOR NO ESTADO Eliane Mendona CENTRO DE CIENCIAS DA NATUREZA Helder Nunes da Cunha COORDENADOR DO CURSO DE SISTEMA DE INFORMAO NA MODALIADE DE EAD Carlos Andr Bastista de Carvalho COORDENADORA DE MATERIAL DE DIDTICO DO CEAD/UFPI Cleidinalva Maria Barbosa Oliveira DIAGRAMAO Joaquim Carvalho de Aguiar Neto

APRESENTAO

Os Sistemas de Informao (SI) so produtos de software cada vez mais importante no dia-a-dia das pessoas. Tais sistemas so usualmente compostos por muitos elementos que operam juntos para recuperar, processar, armazenar e distribuir informao, que normalmente utilizada para auxiliar a anlise e tomada de deciso em uma organizao. Por conta disso necessrio o uso de mtodos, tcnicas e ferramentas para sua construo, para que possamos obter altos nveis de qualidade a baixos custos. Nesta apostila apresentamos uma introduo Engenharia de Software que rea da Computao que aborda a construo de software, incluindo os Sistemas de Informao, como um produto de Engenharia. Na Unidade I apresentamos as origens da Engenharia de Software, bem como os conceitos bsicos existentes, explorando o conceito de Processo e dos modelos de ciclo de vida, que so elementos bsicos para entender a rea. Na Unidade II faremos uma breve apresentao dos principais fluxos da Engenharia de Software, que so chaves para o desenvolvimento de um projeto e que sero abordados com mais profundidade em outras disciplinas do curso. Por fim, na Unidade III apresentamos um Processo de Software, baseado nos princpios geis, exemplificando seu uso para controle de um projeto envolvendo tarefas simples.

SUMRIO GERAL

INTRODUO ENGENHARIA DE SOFTWARE UNIDADE I ................................................................................................... 9 CONCEITOS BSICOS ............................................................................. 9 1. O nicio................................................................................................... 9 1.1. Ser que a crise acabou? .............................................................. 12 1.2. O que Engenharia de Software? ................................................ 14 1.3. Problemas no desenvolvimento de software ................................ 17 1.4. Software: Mitos e Realidade ........................................................ 21 1.4.1. Mitos de Gerenciamento ...................................................... 22 1.4.2. Mitos do Cliente................................................................... 23 1.5. Mitos do Profissional ................................................................... 24 1.6. Exerccios ..................................................................................... 25 2. Processos de Software.......................................................................... 26 2.1. Modelos de Ciclo de Vida............................................................ 28 2.1.1. Codifica-Remenda................................................................ 29 2.1.2. Cascata ................................................................................. 30 2.1.3. Espiral .................................................................................. 32 2.1.4. Incremental........................................................................... 33 2.1.5. Entrega Evolutiva................................................................. 37 2.1.6. Outros Modelos de Ciclo de Vida ........................................ 38 2.2. Exerccios ..................................................................................... 39 UNIDADE II ................................................................................................ 43 AS PRINCIPAIS DISCIPLINAS DA ENG. DE SOFTWARE ............. 43 3. Requisitos............................................................................................. 46 3.1. O Processo Praxis......................................................................... 46 3.2. O Fluxo de Requisitos.................................................................. 49 3.3. Exerccios ..................................................................................... 55 4. Anlise.................................................................................................. 56 4.1. Exerccios ..................................................................................... 59 5. Desenho................................................................................................ 60 5.1. Exerccios ..................................................................................... 65 6. Implementao ..................................................................................... 66 6.1. Exerccios ..................................................................................... 71 7. Testes.................................................................................................... 72 7.1. Exerccios ..................................................................................... 75 8. Gesto de Projetos................................................................................ 76 8.1. Exerccios ..................................................................................... 77 UNIDADE III ............................................................................................... 80 9. Um Exemplo de um Processo de Software .......................................... 82

9.1. Os Papis ...................................................................................... 84 9.2. As Cerimnias .............................................................................. 85 9.2.1. A Reunio Inicial ................................................................. 85 9.2.2. A Reunio de Planejamento ................................................. 89 9.2.3. A Reunio Diria.................................................................. 97 9.2.4. Acompanhamento do Projeto ............................................... 97 9.2.5. Apresentao do Sprint ........................................................ 98 9.2.6. Retrospectiva........................................................................ 99 9.3. Finalizao ................................................................................... 99 9.4. Exerccios ................................................................................... 100 10. Aplicando o SCRUM ..................................................................... 102 10.1. O Exemplo ............................................................................. 102 10.2. Discusso sobre o uso do Scrum ............................................ 106 10.3. Exerccios ............................................................................... 107

UNIDADE I CONCEITOS BSICOS

RESUMO Nesta unidade apresentamos os conceitos bsicos da Engenharia de Software, definindo os pontos bsicos para o seu entendimento. No Capitulo 1 apresentamos o evento que deu origem a rea, conhecido como a Crise do Software, discutindo se ela realmente foi superada. Fazemos ainda uma definio precisa sobre o conceito de Processo, que fundamental para a Engenharia de Software. Por fim, apresentamos os mitos do software, que diferentemente dos mitos tradicionais, trazem desinformao e geram problemas, ao invs de serem histrias interessantes e cativantes. No Captulo 2 apresentamos o conceito de ciclo de vida do software, juntamente com a apresentao dos principais modelos de ciclo de vida existentes, ressaltando aqueles que so mais utilizados atualmente.

SUMRIO DA UNIDADE

INTRODUO ENGENHARIA DE SOFTWARE UNIDADE I ................................................................................................... 9 CONCEITOS BSICOS ............................................................................. 9 1. O nicio................................................................................................... 9 1.1. Ser que a crise acabou? .............................................................. 12 1.2. O que Engenharia de Software? ................................................ 14 1.3. Problemas no desenvolvimento de software ................................ 17 1.4. Software: Mitos e Realidade ........................................................ 21 1.4.1. Mitos de Gerenciamento ...................................................... 22 1.4.2. Mitos do Cliente................................................................... 23 1.5. Mitos do Profissional ................................................................... 24 1.6. Exerccios ..................................................................................... 25 2. Processos de Software.......................................................................... 26 2.1. Modelos de Ciclo de Vida............................................................ 28 2.1.1. Codifica-Remenda................................................................ 29 2.1.2. Cascata ................................................................................. 30 2.1.3. Espiral .................................................................................. 32 2.1.4. Incremental........................................................................... 33 2.1.5. Entrega Evolutiva................................................................. 37 2.1.6. Outros Modelos de Ciclo de Vida ........................................ 38 2.2. Exerccios ..................................................................................... 39

UNIDADE I CONCEITOS BSICOS

1.

O Incio
A partir de 1961 o mundo presenciou o surgimento de novos

computadores, mais modernos e com mais poder computacional. A partir dessa data o software ganhou notoriedade e, por conta disso,
A Crise do Software surgiu devido ao amadorismo existente na conduo do processo de desenvolver software.

uma srie de problemas relacionados ao amadorismo utilizado para sua construo ficou evidente. Esses fatores originaram a Crise do Software, em meados de 1968. O termo expressava as dificuldades do desenvolvimento de software frente ao rpido crescimento da demanda existente, da complexidade dos problemas a serem resolvidos e da inexistncia de tcnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados.

Figura 1: Fotos da NATO Software Engineering Conference.

Em 1968 surgiu a Engenharia de Software.

Em

1968

aconteceu

NATO

Software

Engineering

Conference, um evento criado com o objetivo de discutir alternativas para contornar a Crise do Software. Essa conferncia marcou assim o incio dessa nova rea na computao. A Figura 1 mostra registros dessa conferncia, que teve como um dos participantes o ilustre professor de Matemtica, da Universidade Eindhoven de Tecnologia,

Edsger Dijkstra. Em 1972 Dijkstra recebeu o Prmio Turing (Turing Award), que dado anualmente pela Association for Computing Machinery (ACM), para uma pessoa selecionada por contribuies de natureza tcnica feitas para a comunidade de computao. Seu
Dijkstra um personagem ilustre da computao, com diversas contribuies em diversas reas.

discurso

para

recebimento

do

prmio,

intitulado

Pobre

Programador (The Humble Programmer) tornou-se um clssico da Engenharia de Software. Um trecho desse discurso, traduzido para o portugus e que resume a crise, exibido a seguir: A maior causa da crise do software que as mquinas tornaram-se vrias ordens de magnitude mais poderosas! Para esclarecer melhor: quando no havia mquinas, a programao no era um problema; quando tnhamos poucos computadores, a programao tornou-se um problema razovel, e agora, que ns temos computadores gigantes, a programao grande.. Mas o que realmente seria a Crise do Software? Podemos resumir a crise imaturidade no desenvolvimento de software, causando diversos problemas, como por exemplo: Projetos estourando o oramento. Projetos estourando o prazo. Software de baixa qualidade. Software muitas vezes no atendendo os requisitos. Projetos no gerenciveis e cdigo difcil de manter. tornou-se um problema igualmente

10

4% - Usado como foi entregue 29% - Pago e nunca entregue

45% - Impossvel de ser usado 22% - Modificado e refeito para ser utilizado
Figura 2: Exemplo de um quadro da situao na poca da crise do software.

A Figura 2 exibe um quadro da situao relacionada ao desenvolvimento de software poca da crise. Nesse perodo, apenas 4% dos projetos eram finalizados e o produto gerado era utilizado tal qual foi entregue; 29% dos produtos no eram entregues, embora tenham sido pagos; 45% eram entregues, porm, o produto resultante era impossvel de ser utilizado, normalmente, por conter uma quantidade de incorrees que impediam sua utilizao e 22% eram modificados, em muitos casos extremamente modificados, para que pudessem ser utilizados. Mesmo com a evoluo dos computadores, das tcnicas e ferramentas nos ltimos anos, a produo de software confivel, correto e entregue dentro dos prazos e custos estipulados ainda 11

muito difcil. Dados do STANDISH GROUP, de 2004, usando como base mais de 8000 projetos mostrou que apenas 29% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas. Aproximadamente 18% dos projetos
Ainda hoje diversos projetos de desenvolvimento de software fracassam.

foram cancelados antes de estarem completos e 53% foram entregues, porm com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no incio do projeto. Dentre os projetos que no foram finalizados de acordo com os prazos e custos especificados, a mdia de atrasos foi de 222%, e a mdia de custo foi de 189% a mais do que o previsto. Considerando todos os projetos que foram entregues, alm do prazo e com custo maior, na mdia, apenas 61% das funcionalidades originais foram includas. Mesmo os projetos cuja entrega feita respeitando os limites de prazo e custo, possuem qualidade suspeita, uma vez que provavelmente foram feitos com muita presso sobre os desenvolvedores, o que pode quadruplicar o nmero de erros de software, segundo a mesma pesquisa.

1.1.

Ser que a crise acabou?

Uma pergunta que devemos nos fazer atualmente : ser que

a crise acabou? Para respond-la necessrio fazer uma srie de anlises.

12

Figura 3: Dificuldades durante o desenvolvimento de software.

A Figura 3 apresenta uma ilustrao muito conhecida na rea de Engenharia de Software. Ela apresenta um grande problema, relacionado falta de entendimento entre os grupos que fazem parte de um projeto. O quadro inicial da figura apresenta uma ilustrao
Um grande problema a ser superado a falha na comunicao entre as equipes.

tentando expressar como o cliente explicou o que necessitava para a equipe de desenvolvimento. O quadro seguinte exibe como o lder do projeto entendeu. Podemos notar que existe uma diferena significativa entre as figuras. Isso no deveria acontecer, ou deveria haver o mnimo possvel de diferenas. Desse ponto adiante existe uma srie de entendimentos diferentes, algumas vezes causados por falhas na comunicao, outros por comodidade, uma vez que certos entendimentos favorecem alguns grupos. O resultado de tudo isso que o produto resultante tende a ser algo totalmente discrepante do que foi solicitado e ainda mais diferente do que realmente era necessitado. Observe que, o ltimo quadro na figura apresenta o que o cliente realmente desejava, que bastante diferente do que ele relatou que necessitava. Mais adiante, quando 13

falarmos de requisitos e na prxima disciplina relacionada Engenharia de Software, que trata exclusivamente de requisitos, vamos entender isso com muito mais clareza. Embora problemas durante o desenvolvimento de software
Assim como na construo civil, muitas empresas estouram custos e prazos, mesmo tendo mtodos e tcnicas bem estabelecidas. No desenvolvimento de software a situao a mesma: aqueles que utilizam os princpios corretamente tm grandes chances de sucesso.

aconteam, e com certa freqncia, os processos, mtodos e ferramentas existentes auxiliam muito o desenvolvimento. Uma vez aplicados por pessoas com os conhecimentos adequados, podemos ter certeza do sucesso em um projeto. Por conta disso que existem diversos projetos grandes com sucesso absoluto. Para isso, necessrio aplicar, corretamente, a Engenharia de Software! Ou seja, respondendo questo inicialmente formulada nesta seo: a crise acabou, mas apenas para aqueles que utilizam a Engenharia de Software como base para a construo de produtos de software.

1.2.

O que Engenharia de Software?

J comentamos sobre as origens da Engenharia de Software

mas at agora no fizemos uma definio precisa do que seja exatamente isso. Nesta seo faremos isso. Mas antes da definio, vamos fazer uma analogia muito interessante: voc sabe como funciona o processo de fabricao de um carro?

Unidades

Integrao

Requisitos

Projeto e Simulaes

Integrao

Produto Concludo

Figura 4: Passos para desenvolvimento de um carro.

14

A Figura 4 apresenta os passos para desenvolvimento de um carro. Sua construo inicia a partir do momento que tem-se a idia de iniciar essa tarefa. A partir disso, iniciado o levantamento das caractersticas, necessidades e desejos relacionados ao produto. Tudo isso ir compor a especificao de requisitos do carro. So exemplos desses requisitos porta-malas com capacidade de 500l, motor 1.6, cmbio automtico, etc. Com a identificao dos requisitos possvel iniciar a montagem de um prottipo, para se avaliar diversos pontos que necessitam de esclarecimento antes da construo efetiva do carro. Essa prototipao pode ser feita via ferramentas de simulao, como as famosas ferramentas CAD existentes ou a partir da criao de verses em miniatura do produto (Figura 4, Projeto e Simulaes). O modelo criado, seja qual for, normalmente utilizado para responder diversas questes, para em seguida dar-se incio ao desenvolvimento das partes que iro compor o automvel. Essas partes so chamadas de unidades, como por exemplo, a barra de direo, a porta, o motor, as rodas, etc (Figura 4, Unidades). Cada componente do carro possui especificaes e precisa ser verificado com relao a isso. Por exemplo, a barra de direo deve ser retilnea, com 1,80m de extenso e deve suportar at 500 kg em seu ponto central. A verificao consiste em analisar se isso realmente foi atendimento pelo processo de fabricao do componente. Se o item no passar nessa verificao, no podemos continuar com a construo do produto, pois certamente haver mais problemas quando utilizarmos o componente com problemas. Caso os componentes sejam aprovados na verificao, podemos iniciar a combinao desses componentes, integrando-os, para em seguida verificar se eles continuam atendendo s especificaes (Figura 4, Integrao). Como exemplo, imagine que a barra de direo do carro foi integrada s rodas. Ela deveria sustentar os 500 kg em seu ponto central. Embora isso j tenha sido verificado aps a fabricao do 15

item, uma nova verificao necessria aps sua integrao com demais elementos, uma vez que agora o ponto de falha pode no ser a barra de direo em si, mas os pontos de conexo entre a barra e as rodas. Caso os componentes agrupados continuem
A construo de um carro e a construo de um software so projetos similares, mas que exigem diferentes habilidades na sua conduo e execuo.

funcionando

conforme

esperado,

poderemos

continuar

agrupamento at que tenhamos o produto completo. Uma vez tendo terminado o produto, teremos que submet-lo a uma srie de avaliaes para verificar o seu nvel de qualidade. No caso de um carro so necessrios testes de desempenho, consumo, segurana, etc. Aps essa verificao poderemos afirmar que o produto foi concludo com sucesso. Mas por que conversar sobre carros se o objetivo desta seo apresentar o conceito de Engenharia de Software? Justamente por que o processo de fabricao de um carro tem tudo haver com a Engenharia de Software. De modo geral, podemos dizer que Engenharia de Software poderia ser resumida utilizao de princpios de engenharia para o desenvolvimento de software, ou seja, levantar os requisitos associados, construir modelos para representar a soluo a ser desenvolvida, implementar as diversas unidades que iro compor o produto, verificando se tais unidades atendem aos requisitos identificados, realizar a integrao entre as unidades, tambm verificando seu funcionamento, at que tenhamos o produto por completo, que deve passar por uma srie de verificaes (teste funcionais, desempenho e estresse, usabilidade, etc.) para que possamos concluir o desenvolvimento. Em resumo e utilizando termos mais formais, podemos dizer que a Engenharia de Software a aplicao de uma abordagem sistemtica, disciplinada software. Na literatura, podem-se encontrar mais definies para Engenharia de Software, dentre eles destacamos: "O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e 16 e quantificvel para o desenvolvimento de

que funcione eficientemente em mquinas reais.", NAUR PETER, 1969. A aplicao prtica do conhecimento cientfico para o projeto e a construo de programas computacionais e a documentao necessria sua operao e manuteno., BARRY BOEHM, 1976. Conjunto de mtodos, tcnicas e ferramentas necessrias produo de software de qualidade para todas as etapas do ciclo de vida do produto., SACHA KRAKOWIAK, 1985.

Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendo a aplicao da cincia e da matemtica atravs das quais os equipamentos computacionais so colocados disposio do homem por meio de programas, procedimentos e documentao associada. De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessria para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadores so essencialmente a qualidade e o custo. A qualidade de um produto de software um parmetro cuja quantificao no trivial, apesar dos esforos desenvolvidos nesta direo. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados. Um grande problema facilmente percebido hoje justamente o fato de boa parte das organizaes no encararem o desenvolvimento de software como um projeto de verdade, aplicando as tcnicas, mtodos e ferramentas necessrias. Por conta disso, boa parte desses projetos fracassa. Na prxima seo vamos discutir alguns dos aspectos que fazem isso acontecer.

1.3.

Problemas no desenvolvimento de software

Embora a Engenharia de Software seja uma rea consolidada

e existam vrias empresas que a utilizam com muito sucesso em projetos de desenvolvimento de software, isso no verdade na 17

maioria dos casos. A crise continua em muitos locais, no mais por ausncia de mtodos, tcnicas e ferramentas, mas pela falta do seu uso!

preciso um equilbrio entre Pessoas, Processos e Tecnologias para o sucesso em um projeto de desenvolvimento de software.

Figura 5: Trip da Engenharia de Software. A Figura 5 apresenta o trip no qual a Engenharia de Software baseada: processos, pessoas e tecnologia. No adianta termos os melhores profissionais do mundo se no possumos boas tecnologias para uso ou se no possumos um processo que guie o desenvolvimento de software. Da mesma forma, no adianta possuir as tecnologias mais avanadas se as pessoas no conseguem utiliz-las. Alm disso, mesmo que parea inconcebvel para alguns, de nada adianta termos a melhor tecnologia e as melhores pessoas se no existe um processo que guie as atividades dessas pessoas utilizando tais tecnologias. Existem grande chances de termos problemas relacionados falta de controle ou desorganizao, caso no tenhamos um processo que discipline as tarefas das pessoas.

Figura 6: Componentes de um sistema.

18

Um conceito que muitas vezes causa confuso o de sistema, que muito se confunde ao conceito de software. Pode-se definir o software, numa forma clssica, como sendo: "um conjunto de instrues que, quando executadas, produzem a funo e o desempenho desejados, estruturas de dados que permitam que as informaes relativas ao problema a resolver sejam manipuladas adequadamente e a documentao necessria para um melhor entendimento da sua operao e uso". Entretanto, no contexto da Engenharia de Software, o software deve ser visto como um produto a ser "vendido".
O termo bug est associado ao conceito de falha. Bug signifca inseto em Ingls. Diz-se que o termo foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fongrafo em 1878, mas pode ser que o termo seja mais antigo. A inveno do termo atribuda erroneamente a Grace Hopper, que publicou em 1945 a causa do mau funcionamento no Mark II (um dos primeiros computadores) seria um inseto preso nos contatos de um Rel.

importante dar esta nfase, diferenciando os "programas" que so concebidos num contexto mais restrito, onde o usurio ou "cliente" o prprio autor. No caso destes programas, a documentao associada pequena ou (na maior parte das vezes) inexistente e a preocupao com a existncia de erros de execuo no um fator maior, considerando que o principal usurio o prprio autor do programa, este no ter dificuldades, em princpio, na deteco e correo de um eventual "bug". Alm do aspecto da correo, outras boas caractersticas no so tambm objeto de preocupao como a portabilidade, a flexibilidade e a possibilidade de reutilizao. Um produto de software (ou software, como vamos chamar ao longo da disciplina), por outro lado, sistematicamente destinado ao uso por pessoas diferentes dos seus programadores. Os eventuais usurios podem ter formaes e experincias diferentes, o que significa que uma grande preocupao no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforada com uma documentao rica em informaes para que todos os recursos oferecidos possam ser explorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usurios no estaro interessados (e nem tero capacidade) de detectar e corrigir os eventuais erros de execuo.

19

Resumindo, um programa desenvolvido para resolver um dado problema e um produto de software destinado resoluo do mesmo problema so duas coisas totalmente diferentes. bvio que o esforo e o conseqente custo associado ao desenvolvimento de um produto sero muito superiores. Um sistema bem mais que o software. Na verdade, o sistema o conjunto de elementos, coordenados entre si e que funcionam como uma estrutura organizada. Embora o software seja uma parte importante de um sistema, ele no a nica. Se no existir o hardware para execuo do software, de nada servir. Da mesma forma, necessrio existir bases de dados, uma vez que praticamente todos os sistemas com algum tipo de utilidade devem armazenar dados. Atualmente, com o advento da Internet, dificilmente um sistema seja til se no tiver certos mecanismos de comunicao associados. Tudo isso junto, forma o sistema. Por diversas vezes tendemos a utilizar software e sistema como algo similar, mas importante ressaltarmos suas diferenas, de forma a deixar claro o que representa cada um desses termos. Os produtos de software desenvolvidos utilizando a

Engenharia de Software sempre esto envolvidos em algum processo de negcio, seja ele simples ou complexo. Assim, fundamental entender esse processo de negcio para que seja possvel informatiz-lo. Embora isso seja bvio, em muitas ocasies isso simplesmente ignorado. O desenvolvimento de software muitas vezes acontece sem sabermos o que deve ser feito. Logicamente isso tem grande chance de resultar em fracasso. importante ressaltar que isso inconcebvel em qualquer rea, mas parece que muitos acreditam que quando tratamos de software algo diferente. Imagine adentrar em uma construtora de respeito e perguntar: quanto custa construir uma casa? Se a empresa for sria, certamente no vai dar nenhuma estimativa de custo nem de prazo, uma vez que nada foi dito sobre o projeto. Uma casa pode ser feita gastando-se R$1.000,00 ou R$1.000.000,00. 20

Tudo depende dos requisitos relacionados casa. Com o software exatamente o mesmo. Se no soubermos quais so os requisitos simplesmente impossvel fazer qualquer estimativa de tempo e custo. Qualquer ao nesse sentido irresponsabilidade ou extrema ignorncia! Em resumo, os sistemas informatizados normalmente no fazem o que deveriam fazer por que os problemas tm que ser minuciosamente definidos para que possam ser resolvidos. Se no entendermos bem sobre o domnio do problema, certamente no desenvolveremos uma boa soluo. fundamental levantarmos os requisitos de um software antes de procedermos com sua construo. O custo para levantamento desses requisitos um fator a ser considerado, mas no fazer tal levantamento provavelmente seja bem mais caro! Alm disso, importante que os usurios do produto participem desse levantamento, caso contrrio, os dados obtidos no levantamento no devero expressar aquilo que realmente importante para o processo de negcio.

1.4.

Software: Mitos e Realidade

Muitas causas de problemas relacionados ao

desenvolvimento de software so provenientes de mitos que surgiram durante a histria inicial dessa atividade, conforme descrito por ROGER PRESSMAN. Diferente dos antigos mitos, que so interessantes histrias e freqentemente fornecem lies humanas merecedoras de ateno, os mitos de software propagam desinformao e confuso. Esses mitos tinham certos atributos que os tornavam parecidos com afirmaes razoveis, tendo aspecto intuitivo e, muitas das vezes, eram divulgados por profissionais experientes e que deveriam entender do assunto. Atualmente, boa parte dos profissionais reconhece os mitos por aquilo que so: afirmaes enganosas e que j causaram problemas. No entanto,

21

cabe a todos ns conhec-los, para tentar evit-los em locais que isso ainda esteja acontecendo.

1.4.1.

Mitos de Gerenciamento

Mito 1. "Se a equipe dispe de um manual repleto de padres e procedimentos de desenvolvimento de software, ento a equipe ser capaz de conduzir bem o desenvolvimento." Realidade 1. Isso no o suficiente! preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual. necessrio que o manual reflita a moderna prtica de desenvolvimento de software e que este seja exaustivo com relao a todos os problemas de desenvolvimento que podero aparecer no percurso. Mito 2. "A equipe tem ferramentas de desenvolvimento de software de ltima gerao, uma vez que eles dispem de computadores modernos." Realidade 2. Ter sua disposio o ltimo modelo de computador pode ser bastante confortvel para o desenvolvedor do software, mas no oferece nenhuma garantia quanto qualidade do produto desenvolvido. Mais importante do que ter um hardware de ltima gerao ter ferramentas para a automao do desenvolvimento de software e sab-las utilizar adequadamente. Mito 3. "Se o desenvolvimento do software estiver atrasado, aumentando a equipe poderemos reduzir o tempo de desenvolvimento." Realidade 3. Acrescentar pessoas em um projeto atrasado provavelmente vai atras-lo ainda mais. De fato, a introduo de novos profissionais numa equipe em fase de conduo de um projeto vai requerer uma etapa de treinamento dos novos elementos da equipe; para isto, sero utilizados elementos que esto envolvidos diretamente no desenvolvimento, o que vai, conseqentemente, implicar em maiores atrasos no cronograma. 22

1.4.2.

Mitos do Cliente

Mito 4. "Uma descrio breve e geral dos requisitos do software o suficiente para iniciar o seu projeto. Maiores detalhes podem ser definidos posteriormente." Realidade 4. Este um dos problemas que podem conduzir um projeto ao fracasso, o cliente deve procurar definir o mais precisamente possvel todos os requisitos importantes para o software: funes, desempenho, interfaces, restries de projeto e critrios de validao so alguns dos pontos determinantes do sucesso de um projeto. O deixar pra depois pode simplesmente no acontecer, a no ser em casos previstos pelos processos geis em que os clientes esto sempre presente e dentro da organizao desenvolvedora. No entanto, sabido que essa prtica uma das mais difceis de serem seguidas... Mito 5. "Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isto no representa um problema, uma vez que o software flexvel e poder suportar facilmente as alteraes." Realidade 5. verdade que o software flexvel (pelo menos mais flexvel do que a maioria dos produtos manufaturados). Entretanto, no existe software, por mais flexvel que suporte alteraes de requisitos significativas sem um adicional em relao ao custo de desenvolvimento. O fator de multiplicao nos custos de desenvolvimento do software devido a alteraes nos requisitos cresce em funo do estgio de evoluo do projeto, como mostra a Figura 7.

23

60 ~ 100 x

CUSTO

1.5 ~ 6 x

1x

DEFINIO

DESENVOLVIMENTO

MANUTENO

Figura 7: Influncia das alteraes de requisitos no custo de um sistema.

1.5.

Mitos do Profissional
Mito 6. "Aps a finalizao do programa e a sua implantao,

o trabalho est terminado." Realidade 6. O que ocorre na realidade completamente diferente disto. Segundo dados obtidos a partir de experincias anteriores, ilustrados no livro de Roger Pressman, 50 a 70% do esforo de desenvolvimento de um software empregado aps a sua entrega ao cliente (manuteno). Mito 7. "Enquanto o programa no entrar em funcionamento, impossvel avaliar a sua qualidade." Realidade 7. Na realidade, a preocupao com a garantia do da qualidade do software deve fazer parte de todas as etapas do desenvolvimento. O teste, por exemplo, pode iniciar antes do produto atingir um estado funcional, a partir do planejamento dos casos de teste. Mito 8. "O produto a ser entregue no final do projeto o programa funcionando."

24

Realidade 8. O programa em funcionamento um das componentes do software. Alm do software em si, um bom projeto deve ser caracterizado pela produo de um conjunto importante de documentos. Um produto de software sem um manual de operao pode ser to ruim quanto um software que no funciona!

1.6.

Exerccios
1. Qual foi a principal causa do surgimento da Engenharia de software? 2. Quais eram os problemas associados Crise do Software? 3. A crise do software realmente acabou? Comente sobre isso. 4. Faca uma comparao entre a Engenharia de Software e o desenvolvimento de um carro. 5. Defina Engenharia de Software. 6. Qual o trip em que a Engenharia de Software est baseada? 7. O que um sistema? Quais seus principais componentes? 8. possvel fazer a estimativa de custo e prazo para desenvolvimento de um software com apenas alguns poucos minutos de conversa? Comente sobre isso relacionando sua resposta a outras reas. 9. O que so os mitos do Software? 10. Cite alguns mitos relacionados ao gerenciamento, comentando a realidade relacionada aos mitos. 11. Cite alguns mitos relacionados aos clientes, comentando a realidade relacionada aos mitos. 12. Cite alguns mitos relacionados aos profissionais do desenvolvimento de software, comentando a realidade relacionada aos mitos.

25

UNIDADE I CONCEITOS BSICOS

2.

Processos de Software
Conforme comentado no captulo anterior, a Engenharia de

Software nada mais que o tratamento do software como um produto, empregando dentro do processo de desenvolvimento todos os princpios da engenharia. Como todo produto, o software tambm possui um ciclo de vida, que pode ser definido como o conjunto de todas as etapas relacionadas sua existncia, desde a sua concepo, at o seu desaparecimento. Isso inclui uma srie de etapas, dentre elas as destacadas a seguir: a concepo, onde o produto idealizado, a partir da percepo de uma necessidade; o desenvolvimento, a partir da identificao dos requisitos e sua transformao em itens a serem entregues ao cliente; a operao, quando o produto instalado para ser utilizado em algum processo de negcio, sujeito a manuteno, sempre que necessrio; a retirada, quando o produto tem sua vida til finalizada. No ciclo de vida de um software, a codificao, que representa a escrita do programa utilizando alguma linguagem de programao, apenas uma parte do ciclo de vida, embora muitos profissionais de informtica acreditem, erroneamente, que essa seja a nica tarefa relacionada ao desenvolvimento de software. E j que estamos em um captulo denominado Processo de Software, qual a relao com Ciclo de Vida? O Processo de Software um guia de como um produto de software deve ser construdo, do incio ao fim. A ligao est no fato que esse guia depende do modelo de ciclo de vida utilizado. Existem vrios

26

modelos e dependendo dele, as atividades a serem executadas podem variar. Essa a ligao. Necessitamos ainda definir o conceito de Processos de Software com maior exatido. Um processo um conjunto de passos parcialmente ordenados, constitudos por atividades, mtodos, prticas e transformaes, utilizados para se atingir uma meta. Uma meta est associada a resultados, que so os produtos resultantes da execuo do processo. importante percebermos outra diferena que muitas vezes imperceptvel para muitos profissionais de informtica: enquanto o processo um guia para se construir um produto, um projeto o uso de um processo para desenvolvimento de um produto especfico. Isso se assemelha muito ao conceito de classe e objeto. Enquanto que classe uma estrutura que abstrai um conjunto de objetos com caractersticas similares, um objeto uma instncia da classe, com valores especficos para cada uma dessas caractersticas. Dessa forma, o processo est para classe assim como o projeto est para um objeto. Em resumo, um projeto a instanciao de um processo para a construo de um produto. De acordo com Wilson de Pdua, um processo deve ter uma documentao que o descreve, apresentando detalhes sobre o que feito (produto), quando (passos), por quem (agentes), o que usa como entrada (insumo) e o que produzido (resultado). Essa documentao pode ser simples e informal, como o caso dos Processos geis, que veremos mais adiante, ou completamente detalhada, como o caso dos processos baseados no Processo Unificado. Existem processos que abrangem todo o ciclo de vida do software, assim como processos especficos para partes do desenvolvimento, como, por exemplo, processos para testes, processos para manuteno, etc., que so considerados subprocessos.

27

O ponto inicial para seleo de um processo, e posterior iniciao de um projeto, entender qual modelo de ciclo de vida ele utiliza. Um modelo de ciclo de vida pode ser apropriado para um projeto mas no ser apropriado para outro. necessrio entender bem os conceitos relacionados para que as escolhas feitas sejam baseadas em conhecimento e no no acaso. Na prxima seo iremos detalhar os modelos de ciclo de vida existentes, que muitas
O termo modelo de ciclo de vida utilizado para descrever um grupo de atividades relacionado ao desenvolvimento de software e a forma como elas se relacionam. Para cada modelo de ciclo de vida existe um relacionamento diferente entre as atividades, determinando formas diferente de se conduzir o processo de construo do produto.

vezes so tratados como paradigmas de engenharia de software. Neste trabalho vamos utilizar o termo modelo de ciclo de vida ao invs de paradigma, por acharmos que ele mais apropriado.

2.1.

Modelos de Ciclo de Vida

Conforme j comentado, ciclo de vida pode ser resumido

como sendo todas as atividades relacionadas a um software, desde a concepo de suas idias at a descontinuidade do produto. Existem diversos modelos de ciclo de vida, com caractersticas diferentes. Nesta seo iremos apresentar os principais modelos de ciclo de vida. Para importantes detalhamento ligados s dos tarefas modelos de de ciclo de vida, Esses necessitaremos entender melhor cada um dos subprocessos mais desenvolvimento. subprocessos so organizados de acordo com um tema e so chamados tambm de fluxos ou disciplinas. A seguir apresentamos uma breve descrio desses subprocessos, que sero um pouco mais detalhados nos captulos posteriores: Requisitos: obteno do enunciado, completo, claro e preciso dos desejos, necessidades, expectativas e restries dos clientes em relao ao produto a ser desenvolvido. Anlise: modelagem dos conceitos relevantes do domnio do problema, com o intuito de verificar a qualidade dos requisitos obtidos e detalhar tais requisitos em um nvel adequado aos desenvolvedores.

28

Desenho

(ou

projeto):

definio

de

uma

estrutura

implementvel para um produto, que atenda aos requisitos especificados. Implementao: codificao das partes que compe o software, definidas no desenho, utilizando as tecnologias selecionadas. Teste: verificao dinmica das partes que constituem o software, utilizando um conjunto finito de casos de teste, selecionados dentro de um domnio potencialmente infinito, contra seu comportamento esperado. A literatura cita vrios tipos de modelos de ciclo de vida de software. No consideramos que alguns desses modelos devam receber este status. No entanto, iremos comentar sobre eles ao final da Seo. So exemplos o modelo de prototipao e modelo de desenvolvimento rpido. Esses modelos so, em nossa viso, apenas o desenvolvimento de software baseado em certas tcnicas e ferramentas. Embora alguns autores renomados os apresentem como modelos de ciclo de vida, o autor os considera como abordagens para aplicao do ciclo de vida.

2.1.1.

Codifica-Remenda

O modelo de ciclo de vida mais utilizado o modelo codificaremenda. Conforme exibido na Figura 8, partindo de uma especificao incompleta, ou mesmo ausente, inicia-se a codificao do software, que por sua vez tende a gerar algo. Esse algo gerado, na grande maioria das vezes no o que o cliente deseja, mas vai sendo alterado e consertado at que o produto atinja um estgio que permita seu uso. Nenhum processo seguido nessa iterao.

29

Figura 8: O modelo de ciclo de vida codifica-remenda. A grande utilizao desse modelo se d em virtude de boa parte dos profissionais responsveis pelo desenvolvimento de
Esse modelo ainda o mais comum, pela falta de profissionais habilitados para o desenvolvimento de software. De forma similar, existem muito mais obras sendo tocadas por profissionais sem qualquer formao tcnica, do que obras tocadas por engenheiros. O resultado disso que dificilmente uma obra sem um engenheiro possuir custo e prazo conhecido!

software no terem qualquer conhecimento sobre a Engenharia de Software. possvel que o uso desse modelo de ciclo de vida gere resultados aceitveis para produtos pequenos e com equipes formadas por poucas pessoas, normalmente por um nico desenvolvedor, mas certamente ele s gerar problemas em qualquer projeto envolvendo produtos que requeiram equipes maiores. O aspecto positivo desse modelo que no exige nenhum conhecimento tcnico ou gerencial. Basta iniciar, sem muito preparo sobre o tema a ser abordado, e trabalhar para gerar algo como resultado. Por outro lado, um modelo de alto risco, praticamente impossvel de se gerenciar, tornando-se impossvel estabelecer qualquer estimativa de custo e prazo.

2.1.2.

Cascata

O modelo em cascata, tambm conhecido como modelo seqencial linear, sugere que os principais subprocessos relacionados ao desenvolvimento de software sejam executadas em seqncia, conforme apresentado na Figura 9.

30

Requisitos

Anlise

Desenho

Impl ementao

Testes

O modelo em cascata , em teoria, uma maravilha. Na prtica rgido e burocrtico, tendo sido considervel invivel pelas organizaes que o utilizam!

Figura 9: O modelo de ciclo de vida em Cascata. Esse modelo de ciclo de vida (ou paradigma) foi muito utilizado no passado. No entanto, devido a falhas durante sua execuo, ele vem sendo preterido por outros modelos. Dentre essas falhas, destacam-se as relatadas por Pressman: Projetos reais raramente seguem o fluxo seqencial, conforme sugerido pelo modelo. Isso pode causar grandes problemas quando temos mudanas em um projeto em andamento. Em geral, difcil para os clientes identificarem todos os requisitos explicitamente. Esse modelo exige isso e tem dificuldade em acomodar a incerteza natural que existem em grande parte dos projetos. O cliente precisa ter pacincia, uma vez que a primeira verso executvel do produto somente estar disponvel no fim do projeto. Erros grosseiros podem ser desastrosos e causar perda de praticamente todo o trabalho. Esse talvez o maior problema: a baixa visibilidade por parte do cliente.

31

2.1.3.

Espiral

Um modelo bem diferente do apresentado anteriormente (cascata) o modelo em Espiral. Esse modelo foi proposto originalmente por Barry Boehm. A idia bsica desenvolver um produto a partir de pequenas verses incrementais, que podem iniciar com um modelo em papel e evoluir at verses do sistema completamente funcionais.

Ativao
A idia bsica por trs do modelo em espiral : dividir para conquistar! Ao invs de querer resolver todos os problemas de uma vez, interessante resolver parte dele e ento partir para o restante.

Anlise

Operao

Desenvolvimento

Figura 10: O modelo de ciclo de vida em espiral.

Podemos fazer uma comparao com o modelo em cascata: uma volta na espiral equivale execuo do modelo em cascata para uma pequena parte do software. Durante essa volta na espiral, deve ser realizado o levantamento de requisitos para a pequena parte do software que desejamos abordar, a modelagem desses requisitos (anlise), o projeto das partes que sero desenvolvidas (desenho), a codificao dessas partes (implementao) e sua verificao (teste). Quando isso acontece temos o incio de um novo ciclo e tudo se repete, at que tenhamos todo o produto desenvolvido.

32

 importante ressaltar que as diversas voltas na espiral so utilizadas para se construir as partes do produto, mas essas partes intermedirias e ainda incompletas do produto no so entregues ao cliente. Essa abordagem utilizada apenas para a reduo dos riscos e para o enfoque maior naquilo que mais importante/complexo/crtico no sistema. O prximo modelo de ciclo de vida que apresentamos baseado nesse modelo, porm apresenta uma leve e sutil diferena: a entrega das partes para o cliente. O fato de dividir um sistema para trat-lo por partes favorece o entendimento e facilita a prpria vida dos clientes, que podem emitir opinies e identificar requisitos com mais propriedade. Isso facilita o uso desse tipo de modelo de ciclo de vida. No entanto, como apenas uma parte do produto considerada, possvel que uma deciso tomada seja incompatvel com uma nova parte sendo desenvolvida. Isso acontece por que a tomada de decises feita apenas com o conhecimento do produto que existe at o momento. O ideal seria que todo o produto j fosse conhecido, o que nos remete ao modelo em cascata novamente. Esse ponto justamente o problema do modelo em espiral: sua dificuldade de gerir, para que tenhamos estimativas em um projeto que sejam previsveis e confiveis.

2.1.4.

Incremental

O modelo incremental, tambm denominado de prototipagem evolutiva, baseado no modelo em espiral. No entanto, a grande diferena para o modelo anterior que as verses parciais do produto so efetivamente entregues aos clientes, para que sejam verificadas, validadas e utilizadas no ambiente operacional. importante ressaltar essa diferena: o modelo incremental no utilizado apenas para construir o produto por completo, mas uma srie de verses provisrias, denominadas prottipos, que cobrem

33

cada vez mais requisitos e que so efetivamente entregues aos clientes.

Pl anejamento da iterao

Requi si tos

Anl ise

Nova iterao Desenho

Embora os processos geis prescrevam pouca burocracia, eles prescrevem alguma burocracia. No seguilas pode significar anarquia total no desenvolvimento. Existem muitas organizaes que dizem seguir os preceitos geis, apenas por que no seguem nada, o que um completo absurdo e podem manchar as metodologias geis

Avali ao da iterao Proj eto terminado

Testes

Impl ementao

Figura 11: O modelo de ciclo de vida incremental (prototipagem evolutiva). No modelo incremental um projeto dividido em vrias iteraes, que so as divises do produto que sero consideradas durante a construo. Escolhe-se uma dessas iteraes para iniciar o desenvolvimento, comeando pelo planejamento da iterao, levantamento de requisitos, anlise, desenho, implementao, testes e avaliao da iterao, geralmente realizada com a participao do cliente, conforme apresentado na Figura 11. Essa verso do software normalmente liberada para uso e, caso o produto no tenha sido concludo, uma nova iterao planejada para prosseguir com o desenvolvimento. O modelo incremental sofre dos mesmos problemas do modelo em espiral, no entanto, apresenta como grande vantagem o fato dos requisitos serem definidos progressivamente, sua alta flexibilidade e visibilidade para os clientes. No entanto, requer gerncia sofisticada e uma arquitetura forte, para que o produto inicialmente concebido no esbarre em problemas que impeam sua

34

continuidade a partir dos direcionamentos (decises arquiteturais) inicialmente concebidos. Processos de software famosos, como o XP e Scrum utilizam esse modelo de ciclo de vida. Esses processos so conhecidos como Processos (ou Mtodos ou Metodologias) geis, em virtude de darem mais importncia ao software funcionando do que qualquer outro artefato gerado durante o desenvolvimento. Os Mtodos geis surgiram como uma resposta aos mtodos mais estruturados, especialmente aos mtodos baseados no modelo em cascata. Processos orientados a documentao para o desenvolvimento de software, como o utilizado no modelo em Cascata, so de certa forma fatores limitadores aos desenvolvedores. Muitas organizaes no possuem recursos ou inclinao para processos burocrticos para a produo de software, baseados em intensa documentao. Por esta razo, muitas organizaes acabam por no usar nenhum processo, o que pode levar a efeitos desastrosos em termos de qualidade de software, conforme descrito por Alistais Cockbun. Como alternativa a esse cenrio, surgiram os mtodos geis, que, apesar de possurem documentao e alguma burocracia, so mais flexveis, orientadas a entregas e possuem uma maior iteratividade no processo de desenvolvimento e codificao do produto. A maioria dos mtodos geis no possui nada de novo em relao aos processos tradicionais. O que os diferencia dos outros mtodos so o enfoque e os valores. A idia dos mtodos geis o enfoque nas pessoas e no em processos ou algoritmos. Alm disso, existe a preocupao de gastar menos tempo com documentao e mais com a implementao. Uma caracterstica dos mtodos geis que eles so adaptativos ao invs de serem preditivos. Com isso, eles se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invs de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. 35

O termo metodologias geis tornou-se popular em 2001 quando diversos especialistas em processos de desenvolvimento de software representando as metodologias Extreme Programming (XP), SCRUM, DSDM (Dynamic Systems Development Methodology), Crystal e outros, estabeleceram princpios comuns compartilhados por todos esses mtodos. O resultado foi a criao da Aliana gil, e o estabelecimento do Manifesto gil (Agile Manifesto). Os conceitos chaves do Manifesto gil so: Indivduos e interaes ao invs de processos e ferramentas; Software executvel ao invs de documentao; Colaborao do cliente ao invs de negociao de contratos; Respostas rpidas a mudanas ao invs de seguir planos. O Manifesto gil no rejeita os processos e ferramentas, a documentao, a negociao de contratos ou o planejamento, mas simplesmente mostra que eles tm importncia secundria quando comparado com os indivduos e interaes, com o software estar executvel, com a colaborao do cliente e as respostas rpidas a mudanas e alteraes. Esses conceitos aproximam-se melhor com a forma que pequenas companhias de Tecnologia da Informao trabalham e respondem a mudanas. Para ser realmente considerada gil a metodologia deve aceitar a mudana ao invs de tentar prever o futuro. O problema no a mudana em si, mesmo porque ela ocorrer de qualquer forma. O problema como receber, avaliar e responder s mudanas. Enquanto as metodologias geis variam em termos de prticas e nfases, elas compartilham algumas caractersticas, como desenvolvimento iterativo e incremental, comunicao e reduo de produtos intermedirios, como documentao extensiva. Desta forma existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes so mutveis.

36

2.1.5.

Entrega Evolutiva

Uma combinao muito interessante entre o modelo em cascata e o modelo incremental o modelo de entrega evolutiva, apresentado na Figura 11. Ele uma combinao dos modelos de Cascata e Prototipagem evolutiva. Nesse modelo, o levantamento de requisitos feito como um todo, para que seja possvel entender todo as questes que envolvem o produto a ser construdo, porm, em pontos bem definidos os usurios podem avaliar as partes do produto j desenvolvidas, fornecendo realimentao quanto s decises tomadas, de forma bem similar ao que acontece na Prototipagem Evolutiva. Isso facilita o acompanhamento dos projetos, tanto por parte dos gerentes, quanto por parte dos clientes, que podem acompanhar o que est sendo realizado.

Requi sitos

Anlise

Desenho arquitetni co

Desenho detalhado Nova iterao

Implementao

Avaliao da iterao Proj eto terminado

Testes

Figura 12: O modelo de ciclo de vida entrega evolutiva. A principal dificuldade associada ao modelo de entrega evolutiva o levantamento de requisitos, que deve ser bem feito, para que a partir disso seja possvel a definio da arquitetura do produto, que deve ser robusta, mantendo-se ntegra ao longo dos 37

ciclos de liberaes parciais. De uma forma geral a arquitetura chave nesse modelo. Um dos grandes representantes desse modelo de ciclo de vida o Processo Unificado (PU). Vrios processos, tais como o RUP (Rational Unified Processo) e o PRAXIS utilizam o PU como processo base. Esses processos so muito utilizados no
O modelo de entrega evolutivo atual e possui inmeros casos de sucesso. Muitos dos defensores dos processos geis confundem a entrega evolutiva com o modelo em cascata, o que representa um erro absurdo!

mundo, com vrios casos de sucesso. Um erro muito comumente cometido pelos defensores dos mtodos geis afirmar que processos como o RUP e PRAXIS so baseados no modelo em cascata. Esse um erro grosseiro e freqente. Embora os Processos geis sejam muito interessantes, comum a existncia de xiitas que defendem tais mtodos sem avaliar os prs e contras de cada um dos modelos de ciclo de vida associados. Normalmente onde os requisitos so conhecidos e relativamente estveis os processos baseados no modelo de entrega evolutiva so mais apropriados; para projetos envolvendo equipes pequenas e cujos requisitos no sejam bem conhecidos ou sejam muito instveis os processos baseados no modelo incremental so mais apropriados. De forma geral o bom senso o melhor termmetro para definio do que mais apropriado em uma situao, mas um conselho a todos que possam se deparar com essa situao : nunca acredite em pessoas que defendem cegamente esse ou aquele processo; como tudo na vida, o contexto da situao pode determinar o que o mais apropriado.

2.1.6.

Outros Modelos de Ciclo de Vida

Alguns autores, erroneamente em nossa opinio, consideram como sendo outros modelos de ciclo de vida, o uso de certas ferramentas e tecnologias especficas. Esse o caso, por exemplo, de considerar que o Desenvolvimento Baseado em Componentes ou que o uso de ferramentas RAD sejam modelos de ciclo de vida. No nosso ponto de vista isso apenas a definio de uso de certas

38

tecnologias e que no geram ciclos de vida diferenciados do que j foi exposto neste captulo.

2.2.

Exerccios

1. Quais so as principais fases do ciclo de vida de um produto de software? 2. Qual a ligao entre Ciclo de Vida e Processo de Software? 3. Qual a definio para Processo de Software? 4. Quais so os principais subprocessos (tambm conhecidos como fluxos ou disciplinas) ligados ao desenvolvimento de software? 5. Descreve o modelo de ciclo de vida denominado CodificaRemenda. 6. Quais so os problemas relacionados ao modelo de ciclo de vida em cascata? 7. Como podemos relacionar o modelo em cascata e o modelo em espiral? 8. Qual a grande diferena entre o model em espiral e o modelo incremental? 9. Os mtodos geis so baseados no manifesto gil. Quais so os conceitos chaves desse manifesto? 10. Como funciona o modelo de entrega evolutiva? 11. Os dois modelos de ciclo de vida recomendados para uso e mais utilizados atualmente so o modelo incremental e o modelo de entrega evolutiva. Quando um mais apropriado que outro?

39

UNIDADE I CONCEITOS BSICOS

WEBLIOGRAFIA

Pgina da Universidade Aberta do Piau - UAPI http://www.ufpi.br/uapi Pgina da Universidade Aberta do Brasil- UAB http://www.uab.gov.br Instituto de Engenharia de Software do MIT http://www.sei.cmu.edu/ Stio de apoio ao livro de Roger Pressman http://www.rspa.com/ Stio de apoio ao livro de Ian Sommerville http://www.comp.lancs.ac.uk/computing/resources/IanS/ Stio de apoio ao livro de Wilson de Pdua http://homepages.dcc.ufmg.br/~wilson/ Relatrios do Standish Group, incluindo dados sobre desenvolvimento de software http://www.standishgroup.com

40

UNIDADE I CONCEITOS BSICOS

REFERNCIAS BIBLIOGRFICAS
ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes, Editora Bookman, 2003. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS, ISO/IEC 12207 Tecnologia da Informao Processos de ciclo de vida de software, Rio de Janeiro: ABNT, 1996. BERTRAND MEYER, Object-oriented Software Construction,

Prentice-Hall, 2a edio, 1997. EDSGER W. DIJKSTRA, The humble programmer,

Communications of ACM, volume 15, nmero 10, outubro de 1972, pginas 859-866. FREDERICK P. BROOKS, No silver bullet: essence and accidents of software engineering, Computer Magazine, abril de 1987. IAN SOMMERVILLE, Engenharia de Software, 6a. Edio, Addison-Wesley, 2005. KENDALL SCOTT, Processo Unificado Explicado, Editora

Bookman, 2003. KENT BECK, Extreme Programming Explained: embrace

change. Boston: AddisonWesley/Longman, 1999.

41

RICHARD FAIRLEY, Software Engineering Concepts, McGrawHill, New York, 1985. ROGER S. PRESSMAN, Engenharia de Software, 5a. Edio, McGraw-Hill, So Paulo, 2002. STEVE MACCONNELL, Rapid Development, Microsoft Press, 1996. W. WAYT GIBBS, Software's chronic crisis, Scientific American, Setembro de 1994. WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

42

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

RESUMO Nesta unidade apresentamos os principais fluxos (ou subprocessos) Desenvolvimento que de guiam a execuo baseados de em Projetos princpios de de Software

Engenharia. Este captulo totalmente baseado no livro do Prof. Wilson de Pdua, e no seu Processo, o Praxis, uma vez que o mesmo possui exemplos ilustrativos de todas as partes que compem o desenvolvimento de software, aliados a uma definio precisa das atividades, mtodos e tcnicas relacionados a cada fluxo. No Captulo 3 apresentamos o fluxo de Requisitos, onde devem ser obtidas e registradas informaes relativas ao desejo dos usurios em relao a um produto de software. Apresentamos tambm uma breve descrio do processo Praxis, utilizado como base para as descries dos fluxos desta unidade. No Captulo 4 apresentamos o fluxo de Anlise, onde devem ser modelados os conceitos relacionados ao problema identificado a partir do levantamento de requisitos, realizando assim uma validao do que foi levantado, alm de iniciarmos a sua modelagem em um formato mais prximo dos desenvolvedores. No Captulo 5 apresentamos o fluxo de Desenho, onde deve ser modelada uma soluo para o problema identificado durante o Requisito e Anlise. A grande diferena nesse ponto o foco: enquanto que a Anlise foca no problema, o Desenho foca na soluo para o problema. Um ponto muito importante nesse fluxo a definio da arquitetura do produto.

43

No Captulo 6 apresentamos o fluxo de Implementao, onde devem ser codificadas as partes que iro compor o produto, utilizando as tecnologias definidas no Desenho. No Captulo 7 apresentamos o fluxo de Teste, responsvel pela verificao e validao da implementao desenvolvida. No Captulo 8 apresentamos o fluxo Gesto de Projetos, onde deve ser criado o plano de desenvolvimento de software, juntamente com clculos para gerar estimativas de custo e prazo, alm do acompanhamento da execuo do mesmo.

44

SUMRIO DA UNIDADE

INTRODUO ENGENHARIA DE SOFTWARE UNIDADE II ................................................................................................ 43 AS PRINCIPAIS DISCIPLINAS DA ENG. DE SOFTWARE ............. 43 3. Requisitos............................................................................................. 46 3.1. O Processo Praxis......................................................................... 46 3.2. O Fluxo de Requisitos.................................................................. 49 3.3. Exerccios ..................................................................................... 55 4. Anlise.................................................................................................. 56 4.1. Exerccios ..................................................................................... 59 5. Desenho................................................................................................ 60 5.1. Exerccios ..................................................................................... 65 6. Implementao ..................................................................................... 66 6.1. Exerccios ..................................................................................... 71 7. Testes.................................................................................................... 72 7.1. Exerccios ..................................................................................... 75 8. Gesto de Projetos................................................................................ 76 8.1. Exerccios ..................................................................................... 77

45

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

3.

Requisitos
Nesta unidade iremos apresentar os principais fluxos da

Engenharia de Software. Conforme comentamos, utilizaremos o livro do Prof. Wilson de Pdua como base nessa explicao. Esse livro descreve o Processo Praxis, que ser brevemente apresentado a seguir, para ento darmos incio ao detalhamento dos fluxos ligado Engenharia de Software.

3.1.

O Processo Praxis
O Praxis um processo de software baseado no modelo de

entrega evolutiva. O termo significa PRocesso para Aplicativos eXtensveis e InterativoS e constitui um processo de desenvolvimento de software desenhado para projetos com durao de seis meses a um ano, realizados individualmente ou por pequenas equipes. Ele voltado para o desenvolvimento de aplicativos grficos interativos, baseados na tecnologia orientada a objetos. Seguindo a arquitetura definida no Processo Unificado, o Praxis prope um ciclo de vida composto por fases, divididas em uma ou mais iteraes, e fluxos, que correspondem a disciplinas da Engenharia de Software. Durante a execuo das fases, diversos fluxos podem ser necessrios, de acordo com o que descrito nos scripts das iteraes. A

46

Tabela 1 apresenta a diviso em fases e iteraes, enquanto a organizao em fluxos descrita na Tabela 2.

47

Tabela 1: Fases e Iteraes do Processo Praxis.

Fase Iterao Descrio Levantamento e anlise das necessidades dos usurios e conceitos da aplicao, em nvel de detalhe suficiente para justificar a especificao de um produto de software. Levantamento das funes, interfaces e requisitos nofuncionais desejados para o produto.

Concepo

Ativao Levantamento dos requisitos

Elaborao

Modelagem conceitual dos elementos relevantes do domnio do problema e uso desse modelo para validao dos requisitos e Anlise dos requisitos planejamento detalhado da fase de Construo. Definies interna e externa dos componentes de um produto de software, em nvel suficiente para decidir as principais questes de arquitetura e tecnologia e para permitir o planejamento detalhado das liberaes. Implementao de um subconjunto de funes do produto que ser avaliado pelos usurios. Realizao dos testes de aceitao, no ambiente dos desenvolvedores, juntamente com elaborao da documentao de usurio e possveis planos de Transio. Realizao dos testes de aceitao no ambiente dos usurios. Operao experimental do produto em instalao piloto do cliente, com a resoluo de eventuais problemas atravs de processo de manuteno.

Desenho Implementvel Construo Liberao 1..n

Testes Alfa Testes Beta

Transio

Operao Piloto

Tabela 2: Principais fluxos tcnicos e gerenciais do Praxis.

Natureza Fluxo Requisitos Descrio Fluxo que visa a obter um conjunto de requisitos de um produto, acordado entre cliente e fornecedor. Fluxo que visa a detalhar, estruturar e validar os requisitos de um produto, em termos de um modelo conceitual do problema, de forma que eles possam ser usados como base para o planejamento e controle detalhados do respectivo projeto de desenvolvimento. Fluxo que visa a formular um modelo estrutural do produto que sirva de base para a implementao, definindo os componentes a desenvolver e a reutilizar, assim como as interfaces entre si e com o contexto do produto. Fluxo que visa a detalhar e implantar o desenho atravs de componentes de cdigo e de documentao associada. Fluxo que visa a verificar os resultados da implementao, atravs do planejamento, desenho e realizao de baterias de testes. Fluxo que visa a planejar e controlar os projetos de software. Fluxo que visa a verificar e assegurar a qualidade dos produtos e processos de software.

Anlise

Desenho Implementao

Tcnicos Gerenciais

Testes Gesto de Projeto Gesto da Qualidade

Apesar de ter sido originalmente destinado utilizao em projetos didticos em disciplinas de Engenharia de Software, o Praxis vem sendo usado com sucesso tambm em projetos maiores, 48

alguns envolvendo equipes de at dezenas de pessoas. Conforme comentado anteriormente, nesta unidade vamos descrever os principais fluxos tcnicos e gerenciais do processo, uma vez que eles so similares em quase todos os processos existentes.

3.2.

O Fluxo de Requisitos
O fluxo de Requisitos possui atividades que visam a obter o

enunciado completo, claro e preciso dos requisitos de um produto de software. Os requisitos correspondem a qualquer desejo, necessidade, restrio ou expectativa dos clientes em relao a um produto de software. Estes requisitos devem ser levantados pela equipe do projeto, em conjunto com representantes do cliente, usurios chaves e outros especialistas da rea de aplicao. O conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto forma a Engenharia de Requisitos. O resultado principal do fluxo de requisitos um documento de Especificao de Requisitos de Software (que abreviaremos ERSw). Esse documento possui uma caracterizao do problema do cliente e que deve ser utilizado para criao de um produto. Projetos de produtos mais complexos geralmente precisam de maior investimento em Engenharia de Requisitos do que projetos de produtos mais simples, por questes bvias. A Engenharia de Requisitos tambm mais complexa no caso de produtos novos. O desenvolvimento de uma nova verso de um produto existente [e muito ajudado pela experincia dos usurios com as verses anteriores, uma vez que permite identificar de forma rpida e clara aquilo que mais importante, o que no pode ser mudado e tudo aquilo que no funciona e precisa de uma nova soluo urgente. No caso de um novo produto, difcil para os usurios identificar o que mais importante, tornando igualmente difcil para os desenvolvedores entender claramente o que os usurios desejam.

49

Uma boa Engenharia de Requisitos um passo essencial para o desenvolvimento de um bom produto, em qualquer caso. Neste captulo descrevemos brevemente as atividades do fluxo de Requisitos do Praxis. Para garantir ainda mais a qualidade, os requisitos devem ser submetidos aos procedimentos de controle previstos no processo, e devem ser verificados atravs das atividades de Anlise. Requisitos de alta qualidade so claros, completos, sem ambigidade, implementveis, consistentes e testveis. Os requisitos que no apresentem estas qualidades so problemticos: eles devem ser revistos e renegociados com os clientes e usurios. A Especificao dos Requisitos do Software o documento oficial de descrio dos requisitos de um projeto de software. Ela pode se referir a um produto indivisvel de software, ou a um conjunto de componentes de software, que formam um produto quando usados em conjunto (por exemplo, um mdulo cliente e um mdulo servidor). As caractersticas que devem estar contidas na Especificao dos Requisitos do Software incluem: Funcionalidade: O que o software dever fazer? Interfaces externas: Como o software interage com as pessoas, com o hardware do sistema, com outros sistemas e com outros produtos? Desempenho: qual o tempo de resposta mximo permitido dado um contexto de funcionamento, como por exemplo, 100 usurios realizando emprstimo de um livro. Outros atributos: Quais as consideraes sobre portabilidade, manutenibilidade e confiabilidade que devem ser observadas? Restries impostas pela aplicao: existem padres e outros limites a serem obedecidos, como linguagem de

50

implementao, ambientes de operao, limites de recursos etc.? A Figura 13 apresenta as atividades do fluxo de Requisitos do Praxis. O fluxo iniciado atravs da Determinao do contexto, que levanta os aspectos dos processos de negcio ou de um sistema maior que sejam relevantes para a determinao dos requisitos do produto. A Definio do escopo delimita os problemas que o produto se prope a resolver.

Figura 13: O Fluxo de Requisitos. A Definio dos requisitos produz uma lista de todos os requisitos funcionais e no-funcionais. Estes requisitos so descritos 51

Um Caso de Uso uma fatia de funcionalidade do sistema, sem superposio nem lacunas, que representam algo de valor para os usurios finais.

de forma sucinta, ainda sem entrar-se em detalhes. A Tabela 3 exibe um exemplo de requisitos definidos para um produto responsvel pelo controle de leitos de hospitais. Normalmente utilizamos o conceito de Caso de Uso associado s funcionalidades de um produto. So tambm identificados os grupos de usurios do produto, tambm denominados Atores, e as demais restries aplicveis. Um diagrama de casos de uso exibe os relacionamentos entre atores e casos de uso, e apresentado na Figura 14. recomendvel, at este ponto, que os tomadores de deciso do cliente participem do levantamento dos requisitos. As atividades seguintes cobrem aspectos mais detalhados, sendo provavelmente mais adequado que participem os usurios chaves e no necessariamente pessoal gerencial do cliente. Ela ser revista nesta fase, normalmente com a participao de um nmero maior de partes interessadas. Tabela 3: Exemplo de requisitos para um produto de software.
Nr 1 2 3 Caso de uso Gesto de Hospitais Descrio Cadastros dos Hospitais com leitos controlados pelo SRLEP.

Um Ator representao dos usurios e outros sistemas que interagem com o produto

Um Diagrama de Casos de Uso exibe os relacionamentos entre atores e casos de uso, deixando claro que grupos utilizam quais funes.

Gesto de Leitos Cadastro dos Leitos hospitalares controlados pelo SRLEP. Autorizao de envio para lista de espera Controle de Internaes Registro da autorizao da solicitao para constar na lista de espera por leitos. Controle das internaes em leitos, com possibilidade registro de alta, e conseqente liberao do leito, alm de transferncias para outros leitos. Visualizao de quadro de escala hospitalar.

Consulta Escala

As trs atividades posteriores correspondem ao detalhamento dos requisitos de interface, funcionais e no-funcionais. Os dois primeiros so mostrados como atividades paralelas, pois existem interaes fortes entre os requisitos de interface e os requisitos funcionais.

52

Figura 14: Exemplo de diagrama de caso de uso. Durante o Detalhamento dos requisitos de interface so detalhados os aspectos das interfaces do produto que os usurios
aconselhvel a utilizao de um formato independente de tecnologia para descrio das telas de um sistema. Isso evita uma reduo no espao das solues. Utilizar um componente do tipo Select ou Radio Button pode bloquear a viso de desenvolvedor para solues mais interessantes!

consideram requisitos. Normalmente, feito um esboo das interfaces de usurio, levantado atravs de um prottipo executvel ou de estudos em papel. Esses esboos, entretanto, no devem descer a detalhes de desenho, mas apenas facilitar a visualizao dos verdadeiros requisitos (por exemplo, que informao a interface deve captar e exibir). A Figura 15 exibe um esboo de uma interface de usurio sem amarrao a qualquer tecnologia de implementao. So tambm detalhadas as interfaces com outros sistemas e componentes de sistema. No Praxis, o Detalhamento dos requisitos funcionais utiliza a notao de casos de uso. O fluxo de execuo das funes descrito de forma padronizada, dentro da Especificao dos Requisitos do Software.

53

Gesto de Condies de Internao Pesquisa por Condies de Internao Condio Insuficincia heptica grave (at 50 caracteres) <Pesquisar> Condies de internao recuperadas
Condio Insuficincia respiratria grave Coma mixedematoso Tipo Primria Secundria

<Novo> <Alterar> Condies de Internao Condio* Tipo Insuficincia heptica grave (at 50 caracteres) [Primria; Secundria] <Salvar>

Figura 15: Exemplo de um prottipo de tela independente de tecnologia. O Detalhamento dos requisitos no-funcionais completa os requisitos, descrevendo os requisitos de desempenho e outros aspectos considerados necessrios para que o produto atinja a qualidade desejada. Inclui-se aqui tambm o detalhamento de requisitos derivados de outros tipos de restries (por exemplo, restries de desenho). A Classificao dos requisitos determina as prioridades
Na disciplina Requisitos de Software ser detalhado o fluxo de requisitos e anlise. Iremos realizar diversas prticas relacionadas ao tema.

relativas dos requisitos e avalia a estabilidade e a complexidade de realizao. Os requisitos aprovados so lanados no Cadastro dos Requisitos do Software, para que sejam posteriormente registrados e rastreados seus relacionamentos com tens derivados, em outros artefatos do projeto. Finalmente, a Reviso dos requisitos determina se todos eles satisfazem os critrios de qualidade de requisitos e se a Especificao dos Requisitos do Software est clara e bem entendida por todas as partes interessadas. Na disciplina Requisitos de Software iremos detalhar com bastante profundidade este fluxo, juntamente com os mtodos e tcnicas associados.

54

3.3.

Exerccios

1. Qual o objetivo do fluxo de requisitos? 2. Por que o levantamento de requisitos para produtos novos geralmente mais difcil que para produtos j existentes? 3. O que deve conter uma Especificao de Requisitos? 4. Quais as atividades de requisitos? 5. Em qual atividade feita uma descrio dos requisitos de forma sucinta? 6. Como so representados os grupos de usurios do produto? 7. Que notao utilizada para descrio dos requisitos funcionais? 8. Por que aconselhado fazer um esboo das telas de forma independente de tecnologia?

55

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

4.

Anlise
O fluxo da Anlise tem como objetivos: modelar de forma precisa os conceitos relevantes do domnio do problema, identificados a partir do levantamento de requisitos; verificar a qualidade dos requisitos identificados; detalhar esses requisitos o suficiente para que atinjam o nvel de detalhe adequado aos desenvolvedores. No Praxis, os mtodos de Anlise so baseados na

Tecnologia Orientada a Objetos, resultando em um Modelo de Anlise do Software, expresso na notao UML. O Modelo de Anlise deve conter os detalhes necessrios para servir de base para o desenho do produto, mas deve-se evitar a incluso de detalhes que pertenam ao domnio da implementao e no do problema. Quando se usa um Modelo de Anlise orientado a objetos, os requisitos funcionais so tipicamente descritos e verificados atravs dos seguintes recursos de notao: Os casos de uso descrevem o comportamento esperado do produto. Os diagramas de casos de uso descrevem os relacionamentos dos casos de uso entre si e com os atores. As classes representam os conceitos do mundo da aplicao que sejam relevantes para a descrio mais precisa dos requisitos, exibindo os relacionamentos entre essas. As realizaes dos casos de uso mostram como objetos das classes descritas colaboram entre si para 56

realizar

os

principais

roteiros

que

podem

ser

percorridos dentro de cada caso de uso.

Figura 16: O Fluxo de Anlise. A Figura 16 exibe as atividades da Anlise. Ela inicia pela Identificao das classes, na qual so analisados os fluxos dos casos de uso e outros documentos relevantes em relao ao produto desejado. Os conceitos candidatos a classes so localizados, e filtrados de acordo com vrios critrios. Prossegue com a Organizao das classes, que organiza as classes em pacotes lgicos (agrupamentos de classes correlatas) e lhes atribui os esteretipos de entidade, fronteira e controle, dependendo do papel que desempenham no modelo. A Identificao dos 57

relacionamentos determina os relacionamentos de vrios tipos que podem existir entre os objetos das classes identificadas.. Em seguida, a Identificao dos atributos levanta os atributos de anlise, isto , propriedades que fazem parte do conceito expresso pela classe. Todas as atividades descritas anteriormente do origem ao diagrama de classes contendo todos os detalhamentos de atributos, diviso em pacotes e com especificao dos relacionamentos. Um exemplo de diagrama contendo essas informaes exibido na Figura 17.

O diagrama de classe fornece uma viso geral do sistema e representa um artefato imprescindvel no desenvolvimento.

Figura 17: Exemplo de diagrama de classes exibindo classes, atributos e relacionamentos. Em paralelo, a Realizao dos casos de uso verifica os fluxos dos casos de uso, representando-os atravs de diagramas de interao. Estes mostram como os fluxos so realizados atravs de 58

trocas de mensagens entre os objetos das classes encontradas. Isso ajuda a localizar imprecises e outros tipos de problemas nos fluxos e permite definir as operaes das classes de anlise. Por fim, a Reviso da anlise valida o esforo de Anlise e o correspondente esforo de Requisitos. Podem acontecer vrias revises informais, individuais ou em grupo (por exemplo, dentro de uma oficina de detalhamento dos requisitos).

4.1.

Exerccios

1. Qual o objetivo do fluxo de anlise? 2. Quais recursos da UML so utilizados para descrever os requisitos em um modelo de anlise? 3. O que descrito no diagrama de classes? 4. O que a realizao dos casos de uso? 5. Que locais so consultados para se tentar identificar classes?

59

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

5.

Desenho
O fluxo de Desenho (design ou projeto) tem por objetivo

definir uma estrutura implementvel para um produto de software que atenda aos requisitos associados. Sua principal diferena para a anlise est justamente no foco: a Anlise visa modelar os conceitos relacionados ao domnio do problema, enquanto o Desenho visa modelar os conceitos relacionados uma soluo para o problema. Alguns processos de software prescrevem que a Anlise e o Desenho devam ser um nico fluxo, com o intuito de modelar a soluo para o problema. Conforme detalhado aqui, o Praxis separa bem esses dois conceitos. Nesse caso ento, o desenho de um produto de software deve considerar os seguintes aspectos: o atendimento dos requisitos no-funcionais, como os requisitos de desempenho e usabilidade; a definio de classes e outros elementos de modelo em nvel de detalhe suficiente para a respectiva implementao; a decomposio do produto em componentes cuja construo seja relativamente ser independente, por de forma que eventualmente possa realizada pessoas diferentes,

possivelmente trabalhando em paralelo; a definio adequada e rigorosa das interfaces entre os componentes do produto, minimizando os efeitos que problemas em cada um dos componentes possam trazer aos demais elementos; a documentao das decises de desenho, de forma que estas possam ser comunicadas e entendidas por quem vier a implementar e manter o produto;

60

 a reutilizao de componentes, mecanismos e outros artefatos para aumentar a produtividade e a confiabilidade; o suporte a mtodos e ferramentas de gerao semiautomtica de cdigo. O foco do fluxo de Desenho a concepo de estruturas robustas, que tornem a implementao mais confivel e produtiva. Tipicamente, as atividades de Desenho so realizadas por grupos bastante pequenos de profissionais experientes nas tcnicas deste fluxo; a implementao correspondente pode ser delegada a profissionais no necessariamente proficientes em Desenho, mas conhecedores do ambiente de implementao, e treinadas nas respectivas tcnicas.

61

Figura 18: O Fluxo de Desenho. A Figura 18 exibe as atividades do fluxo de Desenho. Ele inicia pela atividade de Desenho arquitetnico, que trata de aspectos estratgicos de desenho. Ela define a diviso do produto em subsistemas, escolhendo-se as tecnologias mais adequadas. As decises sobre tecnologia devem viabilizar o atendimento dos requisitos no-funcionais e a execuo do projeto dentro do prazo e custos estimados. Uma deciso fundamental a escolha do ambiente definitivo de implementao, se isso j no fizer parte das restries de desenho constantes da Especificao dos Requisitos

62

A arquitetura de um produto corresponde a todas as tecnologias empregadas para sua construo, aliadas a forma de interconexo entre tais tecnologias. Uma empresa com diversos produtos normalmente segue a arquitetura j existente para produtos novos. Quando h a necessidade de mudarmos de tecnologia, necessrio muito estudo e testes para se obter o nvel de entendimento e maturidade necessrio para implementar um novo projeto.

do Software. Faz parte dessa atividade tambm a definio estratgica e estrutural da documentao para usurios. Um exemplo da escolha do ambiente definitivo de implementao seria: vamos utilizar Java, na verso 1.6, com o Hibernate 2.1, utilizando o Framework Struts 2.0, que ser executado no container Tomcat 5.5. Todas essas decises devem ser registradas e comunicadas equipe.

Figura 19: Exemplo de uma tela no ambiente final de implementao. O Desenho das interfaces trata do desenho das interfaces reais do produto em seu ambiente definitivo de implementao. Essa atividade baseada nos requisitos de interfaces constantes da Especificao dos Requisitos do Software. Esses requisitos so detalhados, levando-se em conta as caractersticas do ambiente de implementao e os resultados dos estudos de usabilidade. Parte do cdigo fonte das classes correspondentes figura como artefato resultante desta atividade, pois em muitos ambientes mais fcil desenhar os elementos grficos das interfaces de usurio dentro do ambiente de implementao, extraindo desse cdigo o respectivo modelo por meio de ferramentas. Um exemplo do detalhamento da interface de usurio independente de tecnologia, exibido na Figura 15, apresentado na Figura 19 utilizando a tecnologia escolhida para a implementao do software.

63

O Detalhamento dos casos de uso resolve os detalhes dos fluxos dos casos de uso de desenho, considerando os componentes reais das interfaces. Todos os fluxos alternativos devem ser
Um framework ou arcabouo uma abstrao que une cdigos comuns entre vrios projetos de software, provendo uma funcionalidade genrica e facilitando o seu uso.

detalhados, inclusive os que consistem de emisso de mensagens de exceo ou erro. Se esta atividade for feita de forma completa, pode-se deixar a cargo de profissionais de redao tcnica a confeco da documentao para usurios, e at das mensagens aos usurios. Os fluxos dos casos de uso desenho so tambm a base para o desenho dos testes de aceitao, e a referncia para os implementadores quanto ao comportamento desejado para o produto. A atividade de Desenho das entidades transforma as classes de entidade do do Modelo de de Anlise nas classes aqui a correspondentes Modelo Desenho. Inclui-se

considerao de possvel reutilizao dessas classes, ou de transformao delas em componentes fisicamente distintos. Muitos detalhes irrelevantes para a Anlise devem ser ento decididos, como a visibilidade das operaes e a navegabilidade dos relacionamentos. Inclui-se aqui tambm a tomada de decises sobre como sero representados os relacionamentos; no caso de multiplicidades maiores que um, geralmente essa representao envolve o desenho de colees de objetos.
Scott Ambler discute sobre camadas de persistncia em um artigo referenciado no mundo inteiro. Confira na Webliografia!

A atividade de Desenho da persistncia trata da definio de estruturas externas de armazenamento persistente, como arquivos e bancos de dados. Dois problemas devem ser resolvidos: a definio fsica das estruturas persistentes externas, como o esquema de um banco de dados, e a realizao de uma ponte entre o modelo de desenho orientado a objetos e os paradigmas das estruturas de armazenamento, que geralmente so de natureza bastante diferente. Esta ponte feita pela camada de persistncia. As classes desta camada so desenhadas nesta atividade; entretanto, como uma camada de persistncia bem desenhada altamente reutilizvel, muitas vezes a atividades se reduz a adaptaes de componentes j existentes. 64

A Realizao dos casos de uso determina como os objetos das classes de desenho colaboraro para realizar os casos de uso.
No fluxo de desenho devemos identificar os padres a serem seguidos no projeto. Padres so solues bem conhecidas para problemas recorrentes. So exemplos de problemas recorrentes: como criar uma classe e garantir que haver somente uma instncia dela ativa no sistema? O padro Singleton nos ensina como resolver esse problema de forma simples, sem termos que perder tempo pensando nessa soluo. Nas referncias citamos o livro mais famoso relacionado a padres, escrito por quatro profissionais altamente reconhecidos no mundo e citados como sendo a Gangue dos Quatro (Gang Of Four GoF).

As classes da camada de controle contero o cdigo que amarra essas colaboraes, de maneira a obter-se o comportamento requerido pelos casos de uso de desenho. Diagramas de interao so usados para descrever as colaboraes. Esta atividade permite validar muitas das decises tomadas nas atividades anteriores. Classes utilitrias, agrupadas em uma camada de sistema, ajudam a abstrair aspectos que sejam comuns s realizaes de diferentes casos de uso. Casos de uso e classes de desenho so repartidos entre as liberaes, procurando-se mitigar primeiro os maiores riscos, obter realimentao crtica dos usurios a intervalos razoveis, e possivelmente dividir as unidades de implementao de forma conveniente, entre a fora de trabalho. Finalmente, a Reviso do desenho valida o esforo de Desenho, confrontando-o com os resultados dos Requisitos e da Anlise. Dependendo da iterao, o Praxis padro prev revises tcnicas da Descrio do Desenho, ou inspees, que focalizam principalmente o Modelo de Desenho.

5.1.

Exerccios

1. Qual a principal diferena entre a Anlise e o Desenho? 2. Quais so os principais aspectos a considerar no Desenho? 3. Quais as caractersticas dos grupos que realizam Desenho em uma organizao desenvolvedora de software? 4. O que vem a ser a arquitetura de um produto? 5. O que uma camada de persistncia? 6. O que feito de adicional no desenho das entidades, em relao ao que existe na Anlise?

65

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

6.

Implementao
O fluxo de Implementao detalha os componentes previstos

no desenho, descrevendo todos os componentes de cdigo fonte e cdigo binrio, em nvel de linguagem de programao ou de acordo com as tecnologias escolhidas, que podem at no incluir programao diretamente. A implementao inclui as seguintes tarefas: planejamento detalhado da implementao das unidades de cada iterao; implementao das classes e outros elementos do modelo de desenho, em unidades de implementao, geralmente constitudas de arquivos de cdigo fonte; verificao das unidades, por meio de revises, inspees e testes de unidade; compilao e ligao das unidades; integrao das unidades entre si; integrao das unidades com componentes reutilizados, adquiridos de terceiros ou reaproveitados de projetos anteriores; integrao das unidades com os componentes resultantes das liberaes anteriores. A integrao comentada acima nada mais que a ligao de um componente desenvolvido com outro que necessite dos seus servios. Consideramos que durante a implementao gerada a documentao de uso do produto. Esta documentao inclui

66

manuais de usurios, ajuda on-line, stios Web integrados ao produto, material de treinamento, demonstraes e outros recursos. O fluxo de Implementao contm um grupo de atividades de implementao normal, e duas atividades de categoria parte, que so as atividades de Documentao de usurio e Prototipagem.

Figura 20: O Fluxo de Implementao. A Figura 20 exibe as atividades do Fluxo de Implementao. Ele inicia com o Desenho detalhado, que preenche os detalhes restantes do Modelo de Desenho, no nvel necessrio para guiar a

67

codificao. Nessa reviso so conferidos os detalhes de interfaces, lgica e mquinas de estado das operaes.

Figura 21: Exemplo de uma entidade codificada na linguagem Java. A traduo do desenho detalhado no cdigo de uma ou mais
O uso de linguagens orientadas a objetos virou um padro mundial de programao atualmente. Linguagens como C e Java so, disparadas, as linguagens mais utilizadas para o desenvolvimento de novos sistemas.

linguagens de programao feita na atividade de Codificao. A Figura 21 exibe o exemplo de uma entidade codificada na linguagem Java. Essa codificao normalmente feita utilizando uma IDE (Integrated Development Enviroment), que so ferramentas para desenvolvimento que incluem uma srie de bibliotecas, atalhos, wizards e outras funcionalidades integradas, de forma a tornar mais fcil a vida do desenvolvedor. As unidades de cdigo fonte produzidas so submetidas a uma reviso de cdigo, para eliminar os defeitos que so introduzidos por erros de digitao ou de uso da linguagem. Essa reviso tambm deve ser feita pelos autores, possivelmente com a ajuda de outros programadores. As unidades de cdigo fonte so transformadas em cdigo objeto na por meio da compilao. 68

As prximas atividades so: a Inspeo de implementao e os Testes de unidade. A Inspeo de implementao verifica, de forma rigorosa, o desenho detalhado e o cdigo, por meio de um grupo de revisores pares dos autores. Os Testes de unidade so feitos usando-se componentes de teste que devem tambm ter sido desenhados, revistos, codificados e compilados nas atividades anteriores. Um arcabouo para teste muito utilizado atualmente a famlia xUnit. Existem arcabouos especficos para Java (JUnit), para C (CUnit), para Delphi (DUnit), dentre outros. Esses arcabouos provm facilidades para se criar classes de teste, disponibilizando mecanismos para execuo dos testes a partir de interfaces grficas, facilidades para comparao de valores, agrupamento de testes e etc. Um teste de unidade nada mais que uma classe que invoca mtodos de outra classe e verifica se essa ativao, com certos parmetros, gera a resposta correta, previamente conhecida. Um exemplo de um teste de unidade exibido na Figura 22. Essa classe um teste para a classe tringulo, que possui um mtodo, denominado classifica, que retorna o tipo do tringulo. Podemos facilmente notar que em cada teste existe a criao de um objeto tringulo, com certos valores para seus vrtices, seguido da chamada ao mtodo que retorna o tipo do tringulo e a posterior comparao desse resultado com o valor esperado. Embora bem menos formais que os testes de integrao e aceitao, os resultados desses testes devem pelo menos ser registrados em relatrios simplificados. A ordem de execuo destas atividades definida pela convenincia de cada projeto. A Integrao, finalmente, liga as unidades implementadas com os componentes construdos em liberaes anteriores, reutilizados de projetos anteriores ou adquiridos comercialmente. O cdigo executvel resultante passa ao fluxo de Testes, para realizao dos testes de integrao. A atividade de Documentao de usurio tem como principal objetivo produzir uma documentao que auxilie o uso do sistema 69

por parte dos usurios. Em certos tipos de aplicativos, como os sistemas baseados em Web, esta atividade no gera documentos separados, e sim gabaritos para a gerao de pginas que so misturadas aos relatrios produzidos, de acordo com a tecnologia empregada.

/** * Testa a classe triangulo. */ public class TestTriangulo extends TestCase { /** * Construtor padrao. */ public TestTriangulo() { } public void testeEquilatero() { Triangulo t = new Triangulo(3,3,3); String result = t.classifica(); assertEquals(result, "EQUILATERO"); } public void testeIsosceles() { Triangulo t = new Triangulo(3, 3, 4); String result = t.classifica(); assertEquals(result, "ISOSCELES"); } public void testeEscaleno() { Triangulo t = new Triangulo(3,4,5); String result = t.classifica(); assertEquals(result, "ESCALENO"); } }

Figura 22: Um exemplo de teste de unidade. A atividade de Prototipagem tambm representa uma categoria parte. Ela executa as mesmas atividades da implementao normal, mas de maneira informal e sem maiores preocupaes com padronizao e documentao, pois o cdigo resultante sempre descartvel.

70

6.1.

Exerccios

1. Qual o objetivo do fluxo de Implementao? 2. O que significa integrar no fluxo de Implementao? 3. Em qual atividade feito a programao utilizando alguma linguagem ou tecnologia? 4. O que so as IDEs? 5. O que um teste de unidade? 6. O que a documentao de usurio? Em qual atividade ela desenvolvida?

71

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

7.

Testes
O Teste de Software a verificao dinmica do

funcionamento de um programa utilizando um conjunto finito de casos de teste, adequadamente escolhido dentro de um domnio de execuo infinito, contra seu comportamento esperado. Nesse conceito existem alguns elementos chaves que merecem um maior
Na disciplina Qualidade de Software ser detalhado o fluxo de teste e realizado diversas prticas relacionadas ao tema.

detalhamento: dinmica: o teste exige a execuo do produto, embora algumas de suas atividades possam ser realizadas antes do produto estar operacional; conjunto finito: o teste exaustivo geralmente impossvel, mesmo para produtos simples; escolhido: necessrio selecionar testes com alta probabilidade de encontrar defeitos, preferencialmente com o mnimo de esforo; comportamento esperado: para que um teste possa ser executado necessrio saber o comportamento esperado, para que ele possa ser comparado com o obtido. No Praxis existem diversos conjuntos de teste, tambm conhecidos como baterias de teste. Cada um desses conjuntos est relacionado com uma determinada iterao do processo. As principais baterias de teste existente so: testes de aceitao, testes de integrao e testes de unidade. Um caso de teste especifica como deve ser testado uma parte do software. Essa especificao inclui as entradas, sadas esperadas, e condies sob as quais os testes devem ocorrer. Um exemplo para um caso de teste para um login invlido apresentado 72

na Tabela 5. Um procedimento de teste detalha as aes a serem executadas em um determinado caso de teste. A Tabela 4 exibe o Procedimento de Teste de Login. Observe que um caso de teste s faz sentido se for especificado o(s) procedimento(s) de teste associado(s). Sem essa associao no possvel determinar o que deve ser feito com as entradas especificadas no caso de teste. Observe tambm que o procedimento de teste independente dos dados utilizados nos casos de teste. Tabela 4: Exemplo de Procedimento de Teste. Identificao Procedimento de Teste Login Objetivo Requisitos especiais Fluxo Efetuar o login de um usurio no Merci. A TelaPrincipal deve estar no estado SEM USUARIO.
1. Preencher o campo login e senha 2. Pressionar o boto login.

Identificao Itens a testar

Tabela 5: Exemplo de Caso de Teste. Login invlido com caracteres no permitidos Verificar se a tentativa de login utilizando um identificador invlido, contendo caracteres no permitidos, exibe a mensagem apropriada. Campo Valor pasn! aaaa Valor pasn! aaaa (exibida com *s) O campo login deve ter no mnimo 2 e no mximo 8 caracteres alfabticos.

Entradas

Login Senha Campo Login Senha Mensagem

Sadas esperadas

Estado alcanado Ambiente Dependncias

SEM USUARIO Banco de dados de teste. No aplicvel.

Procedimentos Procedimento de Teste Login

73

O fluxo de teste tem dois grandes grupos de atividades para cada bateria a ser desenvolvida: preparao e realizao. O plano da bateria elaborado durante a preparao, juntamente com o desenho das especificaes de cada teste. Durante a realizao, os testes so executados, os defeitos encontrados so, se possvel, corrigidos e os relatrios de teste so redigidos. A preparao e realizao de cada bateria correspondem a uma execuo completa do fluxo de Testes. As atividades do Fluxo de Teste so exibidas na Figura 23.

Figura 23: O Fluxo de Teste. O grupo de preparao compreende as atividades de Planejamento, que produz o plano de testes da bateria, e Desenho, 74

Na Webliografia apresentamos o stio do Brazilian Software Testing Qualification Board, que responsvel pela Certificao Brasileira de Teste de Software. Essa certificao atribuda ao profissional que aprovado na prova e garante assim que ele possui conhecimento na rea. De acordo com diversas pesquisas de mercado feitas recentemente, os profissionais de teste esto entre os mais procurados e mais bem remunerados profissionais de informtica do mundo.

que produz as respectivas especificaes. O grupo de realizao formado pelas demais atividades: Implementao, que monta o ambiente de testes; Execuo, que os executa efetivamente, produzindo os principais relatrios de testes; Verificao do trmino, que determina se a bateria pode ser considerada como completa; e Balano final, que analisa os resultados da bateria, produzindo um relatrio de resumo. Tipicamente, uma organizao comea a implementar o fluxo de teste pelas baterias de testes de aceitao. Esse tipo de teste tem por objetivo validar o produto, ou seja, verificar se ele atende aos requisitos identificados. Na medida em que a cultura da organizao absorva esses testes, passa a preparar e realizar tambm os testes de integrao.

7.1.

Exerccios

1. O que o teste de software? 2. O que um procedimento de teste? O que um caso de teste? Qual a ligao que existe entre esses dois conceitos? 3. As atividades de teste so divididas em dois grandes grupos. Quais so eles? 4. Quais so os objetivos do teste de aceitao?

75

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

8.

Gesto de Projetos
Este captulo trata dos principais mtodos de gesto de

projetos de desenvolvimento de software. Os seguintes tpicos so brevemente apresentados aqui: os procedimentos de gesto dos requisitos, que regulam o cadastramento, a manuteno e a alterao dos requisitos de um projeto de software;
Na disciplina Qualidade de Software ser detalhado o fluxo de teste e realizadas diversas prticas relacionadas ao tema.

os procedimentos de planejamento de projetos, que tratam da previso de tamanho, esforos, recursos, prazos e riscos de um projeto de software; os procedimentos de controle de projetos, que tratam do acompanhamento do progresso e dos riscos de um projeto, assim como do replanejamento e do balano final.

A Figura 24 mostra um diagrama de alto nvel de abstrao do fluxo de Gesto de Projetos, onde cada subfluxo aparece como uma atividade. Cada subfluxo expandido em atividades mais detalhadas, mas que no sero apresentadas neste trabalho. Iremos detalhar parte desses subfluxos nas disciplinas subseqentes do curso. A Gesto de Requisitos refere-se ao processo de acompanhamento dos requisitos durante todo decorrer do projeto, verificando a necessidade de alteraes, analisando o impacto causado em casos como esse e calculando tempo e esforo necessrio para tal realizao. O Planejamento de Projetos refere-se ao processo de estimar os recursos, esforo e prazo necessrio para se desenvolver um software ou parte dele, com base nos dados histricos mantidos pela organizao. O Controle de Projeto referese s tarefas de verificao comumente executadas durante o 76

desenvolvimento e ao monitoramento dos riscos e da evoluo esperada, sempre prescrevendo aes quando o estimado diferir muito do planejado. Na prxima unidade apresentamos um exemplo de um processo de software, ressaltando suas atividades relacionadas
Na Webliografia apresentamos o stio do Project Management Institute - PMI. O PMI uma entidade mundial sem fins lucrativos voltado definio de boas prticas do gerenciamento de projetos.

gesto do projeto. Embora sejam atividades simples, poderemos visualizar como essas atividades podem auxiliar o acompanhamento do projeto, fornecendo uma viso geral do que foi realizado e ainda existe a ser feito.

Figura 24: O Fluxo de Gesto de Projetos.

8.1.

Exerccios

1. O que vem a ser a Gesto de Requisitos? 2. O que o Planejamento de Projeto? 3. Quais so as aes associados ao Controle de Projeto? 77

UNIDADE II AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

WEBLIOGRAFIA
Stio de apoio ao processo Praxis, com exemplos da aplicao dos fluxos em um exemplo real de desenvolvimento http://homepages.dcc.ufmg.br/~wilson/ Pgina de Scott Ambler com boas prticas para o desenvolvimento de software http://www.ambysoft.com/ STORM (Software Testing Online Resources). Stio com diversos materiais sobre testes, desde ferramentas, artigos, livros, etc. http://www.mtsu.edu/~storm/ Project Management Institute (PMI) http://www.pmi.org/ Certificao Brasileira de Teste de Software http://www.bstqb.org.br/

78

UNIDADE II PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE

REFERNCIAS BIBLIOGRFICAS
ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes, Editora Bookman, 2003. BERTRAND MEYER, Object-oriented Software Construction,

Prentice-Hall, 2a edio, 1997. GLENFONRD MYERS, The art of the software testing, John Wiley & Sons, 1979. GRADY BOOCH, JAMES RUMBAUGH, IVAR JACOBSON, UML: Guia do Usurio, Traduo da 2 edio, Editora Campus, 2000. IEEE, Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004, editores: Alain Abran e James W. Moore. KENDALL SCOTT, Processo Unificado Explicado, Editora

Bookman, 2003. WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

79

UNIDADE III UM EXEMPLO DE UM PROCESSO DE SOFTWARE

RESUMO Nesta unidade apresentamos um processo de software baseado nos princpios da agilidade, alm de apresentarmos seu uso para uma tarefa simples. No Captulo 11 apresentamos as prescries do processo SCRUM, que vem se destacando no cenrio industrial de desenvolvimento de software, sendo cada dia mais utilizado por diversas organizaes. Apresentamos os principais papis associados ao seu uso, alm das cerimnias previstas durante sua utilizao, detalhando os artefatos que devem ser gerados. No Captulo 12 apresentamos um exemplo da aplicao do SCRUM para guiar a execuo de um projeto simples, ilustrando assim como utilizar o processo para qualquer atividade em que se deseje ter mais controle sobre sua execuo.

80

SUMRIO DA UNIDADE

INTRODUO ENGENHARIA DE SOFTWARE

UNIDADE III ............................................................................................... 80 9. Um Exemplo de um Processo de Software .......................................... 82 9.1. Os Papis ...................................................................................... 84 9.2. As Cerimnias .............................................................................. 85 9.2.1. A Reunio Inicial ................................................................. 85 9.2.2. A Reunio de Planejamento ................................................. 89 9.2.3. A Reunio Diria.................................................................. 97 9.2.4. Acompanhamento do Projeto ............................................... 97 9.2.5. Apresentao do Sprint ........................................................ 98 9.2.6. Retrospectiva........................................................................ 99 9.3. Finalizao ................................................................................... 99 9.4. Exerccios ................................................................................... 100 10. Aplicando o SCRUM ..................................................................... 102 10.1. O Exemplo ............................................................................. 102 10.2. Discusso sobre o uso do Scrum ............................................ 106 10.3. Exerccios ............................................................................... 107

81

UNIDADE III UM EXEMPLO DE UM PROCESSO DE SOFTWARE

9.

Um Exemplo de um Processo de Software

Scrum um processo gil para gerenciamento e

Scrum uma disposio de jogadores de um time de Rugby, utilizada para reincio do jogo em certos casos.

desenvolvimento de projetos. Esse mtodo foi primeiro descrito por Takeuchi e Nokata em um trabalho entitulado The New Product Development Game em 1986 pela Harvard Business Review que definia um mtodo de desenvolvimento de alto desempenho apropriado para pequenas equipes. Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo no desenvolvimento de software em todo o mundo. O Scrum utilizado com sucesso em diversas empresas de desenvolvimento de software. Porm este mtodo pode ser utilizado em qualquer contexto em que uma equipe, composto por diversas pessoas, necessitem trabalhar juntas para atingir um objetivo comum. Empresas como a Microsoft, Yahoo, Google, Philips, Siemens, Nokia e vrias outras usam o Scrum como mtodo de desenvolvimento desenvolvimento na confeco projetos de de softwares preo fixo, comerciais, aplicaes interno,

financeiras, vdeo games, websites e muitas outras aplicaes. Ken Schwaber define o Scrum como um guia geral de como fazer desenvolvimento de produtos, com a finalidade de fazer a equipe pensar diferente. Segundo ele o desenvolvimento de 82

produtos uma tarefa complexa e no deve depender de um conjunto de regras, pois elas no so suficientes para todas as circunstncias. A equipe deve descentralizar as decises, porque provavelmente no haver uma nica resposta para cada tipo de questionamento. Scrum um mtodo interativo e incremental, baseado no
O Scrum utiliza o modelo de ciclo de vida incremental, conforme discutido anteriormente.

modelo de ciclo de vida interativo, onde o foco principal est na entrega do produto, no menor tempo possvel. Isso permite uma rpida e contnua inspeo do software em produo. As necessidades do negcio que determinam as prioridades do desenvolvimento do sistema. As equipes se auto-organizam para definir a melhor maneira de entregas as funcionalidades de maior prioridade. Em tempos ajustveis possvel analisar o software em produo, decidindo se ele avana no processo ou se deve ser melhorado. Para uma boa adoo do mtodo Scrum em uma empresa necessrio que ela tenha uma cultura de fazer as coisas de modo diferente, mas que necessita tambm de muita disciplinada, uma vez que no haver muitas regras e nem interferncia externa na execuo das tarefas. A evoluo do desenvolvimento de um sistema feito com base em uma srie de perodos definidos de tempo, chamados Sprints, que variam, preferencialmente de 2 a 4 semanas. Durante o esse tempo os requisitos so detalhados, o produto projetado, codificado e testado. Ao final de cada Sprint feita uma avaliao do que estava programado, assim o acompanhamento feito em curtos espaos de tempo. O desenvolvimento feito de forma paralela em detrimento do desenvolvimento seqencial (modelo de ciclo de vida em cascata), ou seja, as equipes fazem um pouco de cada coisa, todo o tempo. Para a descrio do Scrum vamos apresentar os papis relacionados ao seu uso, em seguida as principais cerimnias que so prescritas pelo processo. Uma cerimnia um ritual com formalidades a serem seguidas, lembrando sempre que o objetivo 83

Embora os Processos geis prescrevam menos burocracia no seu uso, eles exigem alguma burocracia e no segui-la significa anarquia!

dos processos geis reduzir ao mximo o trabalho burocrtico. Apresentaremos juntamente com as cerimnias os principais artefatos produzidos, exibindo alguns exemplos prticos do mesmo.

9.1.

Os Papis
O Scrum possui trs papis associados sua execuo: o

Scrum

Master,

Product

Owner

Equipe

de

Desenvolvimento. O Product Owner o membro com maior conhecimento das funcionalidades do produto, decidindo as datas de lanamento e contedo. Ele prioriza as funcionalidades de acordo com o valor de mercado, mas para isso deve entender o produto a ponto de priorizar sem gerar problemas. Da mesma forma, ele tem a tarefa contnua de ajustar as funcionalidades e prioridades, revendo descries e conversando com os membros da equipe sempre que uma dvida surgir. fundamental para o sucesso de um projeto a presena de um Product Owner com domnio do problema. Idealmente a pessoa com tal responsabilidade deveria ser um representante dos clientes do produto, embora em casos excepcionais um desenvolvedor possa assumir esse papel, devendo assim manter contato permanente com os clientes reais.
O Scrum Mster o papel chave no Scrum. Ele deve garantir o uso do processo e eliminar interferncias externas!

O Scrum Master representa a gerncia para o projeto, ao mesmo tempo em que responsvel pela aplicao dos valores e prticas do Scrum. Ele deve manter uma vigilncia contnua sobre o uso correto das prescries do Scrum, garantindo assim a disciplina de todos os membros da equipe. Embora os processos geis tenham um mnimo de burocracia, ainda existe burocracia a ser seguida. No segui-la pode levar ao caos e a mais completa anarquia no desenvolvimento. Embora o Scrum Master seja uma espcie de gerente do projeto, removendo todo e qualquer obstculo que atrapalhe o trabalho da equipe e devendo ter bom relacionamento com os nveis mais altos da organizao, ele tambm deve ter conhecimento 84

tcnico suficiente para entender todo o desenvolvimento e ajudar sempre que necessrio.
Embora o Scrum tenha sido criado para equipes pequenas, existem relatos de projetos com grandes equipes utilizando essa metodologia. Existe o conceito de Scrum de Scrum aplicado justamente nesse caso!

A Equipe no Scrum normalmente composta de 5 a 9 membros, embora o Scrum possa ser aplicado tanto com mais colaboradores, quanto com um colaborador apenas. A diferena que aplicar o Scrum com um membro apenas torna sem sentido algumas das prticas previstas no processo. No entanto, ainda assim o seu uso garante um controle nas atividades sendo executadas e um conhecimento na produtividade, fatos esse que s tem a acrescentar a qualquer tipo de trabalho. Os membros da equipe devem ser multifuncionais, ou seja, eles devem ser capazes de executar diversos tipos de tarefas, desde a modelagem at o teste das funcionalidades. Em alguns casos possvel associar colaboradores a tarefas especficas, mas isso no deve ser utilizado de modo contnuo, pois pode gerar o que chamamos de ilhas de conhecimento, onde apenas uma pessoa entende sobre determinado aspecto. Essa caracterstica pssima para um projeto e deve ser evitada sempre que possvel, sendo uma das premissas bsicas da agilidade: o cdigo coletivo! A equipe deve ser autoorganizada, ou seja, cada um escolhe o que quer fazer. Uma caracterstica importante da equipe que ela deve sentar junto e se ajudar sempre que necessrio, pois isso a premissa bsica para o trabalho em conjunto.

9.2.

As Cerimnias
As cerimnias referem-se aos rituais que devem ser seguidos

no uso do processo. As principais cerimnias previstas no Scrum so as seguintes reunies: Inicial, Planejamento, Apresentao, Retrospectiva e Reunio Diria.

9.2.1.

A Reunio Inicial

No inicio do projeto necessrio fazer o levantamento de requisitos do produto a ser desenvolvido. No caso dos processos 85

geis, isso feito em uma srie de reunies, denominada aqui de Reunio Inicial. Nela que ocorre a definio das estrias do produto. Uma estria pode ser vista como sendo a descrio do cliente sobre uma funcionalidade do produto, descrito em sua prpria linguagem. Cabe a equipe de desenvolvimento entender esse linguajar e depois detalhar as atividades necessrias para implementao da estria. O conjunto de todas as estrias identificadas nessa reunio inicial ser usado para compor o Product Backlog, que equivale aos
O levantamento de requisitos durante o uso do Scrum acontece durante todo o projeto, mas a identificao desses requisitos, descrevendo-os de forma sucinta, acontece na reunio inicial.

requisitos do produto, descrito na forma de estrias do usurio. A definio dessas estrias geralmente feita com a participao de toda a equipe, juntamente com o Product Owner e, opcionalmente, outros membros representante dos clientes. Essa reunio geralmente dura um ou mais dias, com bastante conversa sobre as estrias do produto. fundamental ressaltar que o mais importante nesse momento no obter um entendimento detalhado sobre o produto, mas sim identificar as funes existentes e que devem ser tratadas a posteriori. O registro dos dados coletados na reunio um ponto crucial para o restante do processo. necessrio registrar tudo o que foi discutido pois cada uma dessas estrias sero utilizadas no decorrer do projeto. Tambm importante que a equipe tente entender melhor sobre o produto a ser desenvolvido, para que a reunio possa ser a mais produtiva possvel. Nesse caso, a equipe deve estudar e ler materiais relacionados, analisar solues similares prexistentes e, acima de tudo, perguntando bastante para os representantes dos clientes. Um formato seguido pelo autor deste material para guiar as perguntas sempre questionar como tudo inicia. Por exemplo, no levantamento de requisitos para uma soluo para uma cooperativa foi questionado: o que necessitamos para iniciar os trabalhos da cooperativa? A resposta foi: inicialmente precisamos cadastrar os cooperados. Nesse caso foi novamente feita outra pergunta: o que necessrio para cadastrar um cooperado? A resposta foi uma srie 86

de

dados

relacionada

ao

cooperado,

incluindo

informaes

bancrias. Nesse momento, uma nova questo foi formulada? O que necessrio para cadastrar informaes bancrias? Tudo ento se repete at que tenhamos chegado a um ponto em que tudo que existe de dependncia tenha sido esclarecido. Logicamente, isso dar origem a uma srie de estrias, que devero ser registradas. Resolvendo todas as questes, podemos partir para o prximo passo: uma vez tendo cooperados cadastrados, o que mais necessrio? Mais uma vez, as questes seguem novamente... Um ponto interessante em cada questo tentar identificar quem o responsvel pelas aes. Isso normalmente est relacionado a papis dentro do produto. Papis representam responsabilidades e no pessoas. Cada estria normalmente possui um papel associado a sua execuo. As estrias e os papeis podem ser representados utilizando diagramas de caso de uso. Essa notao ser abordada com mais detalhes na disciplina Requisitos de Software. Nesse diagrama, os papis so representados por bonecos e as funcionalidades (estrias) so representadas por elipses, chamadas de casos de uso.

Diagramas de caso de uso fornecem uma boa viso dos grupos de usurios do sistema e suas funcionalidades associadas.

Figura 25: Exemplo de Diagrama de Caso de Uso. A Figura 25 apresenta um exemplo de um diagrama de caso de uso. Ele exibe dois papis (regulador e intensivista) e algumas funes do produto (autorizao de envio para lista de espera, 87

controle da lista de espera, controle de internao e cadastro de solicitao de leito). Essas funcionalidades foram descobertas a partir de conversas com os usurios do produto. Analisando o diagrama fcil perceber quais so os papis relacionados a certas estrias, facilitando assim o entendimento. necessrio ainda detalhar cada caso de uso e cada um dos atores, para facilitar o entendimento do contexto por qualquer pessoa que ingresse no projeto. Um exemplo do detalhamento dos casos de uso apresentado na Tabela 6. Um exemplo do detalhamento dos papis (ou atores) apresentado na Tabela 7. Embora o diagrama de caso de uso seja importante para obtermos um bom entendimento de alto nvel do produto, necessrio detalhar um pouco melhor cada estria e registr-la em um formato adequado para manipulao. Uma planilha eletrnica um formato que utilizamos com relativo sucesso, mas dependendo do caso, pode no ser o mais adequado. Assim, aconselhamos a utilizao de uma planilha contendo todos os dados das estrias, seguindo o modelo de cartes para registro das estrias, detalhado a seguir. O principal resultado da reunio inicial o Product Backlog, que o conjunto dos requisitos do produto e que retrata todo o trabalho desejado no projeto. Cada estria deve ter sua prioridade definida pelo Product Owner e repriorizado em vrios momentos do processo.

88

Tabela 6: Detalhamento dos Casos de Uso.

Nmero de ordem 1 Caso de uso Autorizao de envio para lista de espera Controle da Lista de Espera Controle de Internaes Cadastro de Solicitao de Leito Descrio Registro da autorizao da solicitao para constar na lista de espera por leitos. Controle da lista de espera por leitos, com registro de evoluo dos pacientes, alm de registro de entrada ou encaminhamento em leitos hospitalares e eventual remoo da lista. Controle das internaes em leitos, com possibilidade registro de alta, e conseqente liberao do leito, alm de transferncias para outros leitos. Cadastro das solicitaes de leitos para pacientes com necessidades de internao.

Tabela 7: Detalhamento dos atores.

Nmero de ordem 1 2 Ator Definio

Intensivista Regulador

Mdico plantonista que coordena a UTI no hospital e faz a solicitao das vagas. Mdico regulador da Central de Leitos, que recebe, avalia e gerencia as solicitaes e eventuais interna.

9.2.2.

A Reunio de Planejamento

Na Reunio de Planejamento a equipe seleciona os itens do Product Backlog com os quais se compromete a concluir dentro do
A reunio de planejamento a cerimnia mais importante do Scrum e deve ser realizada com muito cuidado.

prazo do Sprint. O Sprint o tempo que a equipe planeja para produzir uma verso funcional do produto com parte dos itens do Product Backlog. Um tamanho comum para um Sprint gira entre 2 e 4 semanas, mas isso pode ser diferente, dependendo da situao. Esse nmero pode ser menor, quando precisamos ter respostas mais rpidas e para obter dados sobre produtividade, ou maiores, quando as coisas j esto mais estveis e podemos nos dar o luxo de adiar a entrega para o cliente para termos mais itens desenvolvidos. Definido o tamanho do Sprint, hora de calcular a fora de trabalho que a equipe poder cumprir. Uma forma simples de calcular multiplicar a soma das quantidades de horas dirias dedicadas ao projeto por parte da equipe, pela quantidade de dias 89

teis do Sprint. Esse a fora de trabalho bruta. Normalmente utiliza-se um fator de ajuste para encontrarmos a fora de trabalho lquida. O fator de ajuste corresponde ao percentual de tempo produtivo efetivamente utilizado para computar carga de trabalho da equipe. Colaboradores que trabalham 8h/dia, dificilmente passam 8h realizando tarefas diretamente relacionadas ao desenvolvimento. Existe tempo para ler e-mails, conversar com colegas, tomar caf, ir ao banheiro, etc... Um fator de ajuste muito comum usar 75%, mas esse nmero depende de vrias condies que devem ser analisadas. Um ponto importante na definio da dedicao da equipe
necessria muita prudncia para definio da dedicao dos colaboradores ao projeto, pois isso pode gerar grandes problemas no Sprint. Um fator comum superestimar a participao dos membros, esquecendo-se de outras tarefas existentes!

nunca considerar o Scrum Master nem o Product Owner (caso esse seja um membro da equipe agindo como um cliente) dedicados integralmente s tarefas de desenvolvimento. Assim, um Scrum Master que trabalhe 8h/dia certamente poder se dedicar apenas 4h/dia para agir como desenvolvedor. O restante das horas deve ser gasto com as tarefas de acompanhamento do processo e de auxlio equipe.

Figura 26: Clculo da fora de trabalho de uma equipe. A Figura 26 exibe o detalhamento do clculo da fora de trabalho de uma equipe. Existem cinco colaboradores no projeto, com sua dedicao diria expressas na figura. Na coluna Total feito o clculo das horas disponveis durante o Sprint, levando em 90

considerao a quantidade de dias e o fator de ajuste. O valor Total do Sprint representa a fora de trabalho para essa equipe no Sprint. Com o clculo da fora de trabalho possvel elaborar o grfico de acompanhamento, tambm conhecido como Burndown. Esse grfico nos ajuda a acompanhar visualmente o andamento do projeto, facilitando a identificao visual de atrasos ou de adiantamentos. Para sua criao, basta criar uma reta que inicia na quantidade de horas alocadas para o Sprint e que toca em zero no ltimo dia do Sprint. A Figura 27 exibe o grfico para os clculos que fizemos anteriormente. Em breve, na cerimnia denominada acompanhamento dirio, descrevemos como o grfico dever ser utilizado.
Grfico de Acompanhamento
180 170 160 150 140 130 120 110 100 90 80 70 60 50 40 30 20 10 0

5 Dias do Sprint

10

Figura 27: Grfico de acompanhmento. O prximo passo selecionar as estrias que faro parte do Sprint. Elas comporo o que denominamos Sprint Backlog, ou os requisitos do Sprint. Para que possamos inserir uma estria no Sprint teremos que conversar sobre ela e tentar descobrir todas as atividades associadas ao seu desenvolvimento. Observe que uma estria pode desencadear vrias atividades ou uma apenas. Tudo depende da situao.

91

Cada estria a ser inserida no Sprint deve ser representada por um carto, com o formato exibido na Figura 28. Ele possui diversos compartimentos, cada um com um significado especfico: ID: identificador da tarefa; Nome: descrio identificao; Descrio: texto simples e objetivo descrevendo a tarefa com mais detalhes; Como verificar: indicao de como deve ser feita a verificao dessa tarefa, quando a mesma estiver concluda; Tempo estimado: tempo especificado pela equipe para realizao da tarefa; Tempo real: tempo efetivamente utilizado para realizao da tarefa; Responsvel: colaborador encarregado de realizar a tarefa. resumida da tarefa para fcil

Figura 28: Exemplo de carto descrevendo uma atividade. 92

Para o clculo do tempo estimado a maioria das equipes que usa Scrum utiliza o Jogo do Planejamento. Nesse jogo, cada
importante que todos faam suas estimativas sem conhecer as estimativas dos outros membros do grupo, para evitar interferncias nas opinies. Mas fundamental conversar quando grandes diferenas so registradas!

membro da equipe deve opinar com uma estimativa de tempo para uma atividade. Essa estimativa deve ser feita a partir do lanamento de cartas com o valor estimado. Isso ocorre dessa maneira para tentar no influenciar os outros membros da equipe em suas estimativas. De preferncia, as cartas devem ser atiradas viradas, de forma que apenas depois que todos as joguem que possamos viralas para ento analisar os valores estimados. A Figura 29 exibe algumas cartas utilizadas durante o Jogo do Planejamento. Pode-se considerar a mdia dos valores obtidos, o que bastante comum, ou descartar alguns valores para esse clculo (maior e menor, por exemplo). O mais importante estabelecer parmetros de aceitao, impedindo, por exemplo que estimativas muito diferentes possam acontecer. Por conta disso existem algumas definies para as cartas que merecem ateno: Um ? indica que mais explicaes so necessrias; Um 0 indica algo to pequeno que no merece estimar; Uma xcara indica necessidade de tempo pra pensar e hora para o caf... Tarefas acima de 16h merecem ser divididas, pois em caso contrrio podem gerar problemas no acompanhamento, por serem grandes demais e necessitarem de vrios dias para se descobrir que ela est atrasada! Estimativas muito diferentes merecem explicaes

93

Figura 29: Exemplos de cartas para o jogo do planejamento. Assim, para que possamos descobrir que itens devem entrar em um Sprint devemos analisar as prioridades dos itens no Product Backlog e selecionar aquele com maior prioridade. Em seguida devemos conversar bastante sobre a estria, a ponto de descobrirmos as tarefas associadas, para ento iniciar a estimativa das tarefas. Cada vez que uma tarefa ingressar no Sprint devemos calcular quanto ainda temos que horas disponveis, para saber se mais tarefas podem ser introduzidas no Sprint. O Tempo real, presente nos cartes, deve ser preenchido com o tempo realmente gasto para concluso da tarefa, independente do tempo estimado. A partir do confrontamento entre o tempo estimado e o tempo real que poderemos apurar nossas estimativas e assim chegarmos em um ponto onde o erro possa ser considerado desprezvel. A principio, os responsveis pelas tarefas no devem ser definidos: cada um escolhe, dentre as tarefas do Sprint, aquilo que for mais interessante em seu ponto de vista, sempre respeitando as prioridades envolvidas. Embora o campo Como verificar parea dispensvel, quando existem muitas tarefas a verificar, podemos perder o foco no que importante. Esse campo ajuda a sempre mantermos o foco em como a tarefa deve ser verificada, garantindo assim que ela foi realmente concretizada. Outro item importante a ser definido durante o planejamento a Definio de Feito (DoD). Todo projeto deve ter uma definio 94

clara sobre o que considerado feito! Para uma tarefa de modelagem, por exemplo, poderamos considerar uma tarefa efetivamente concluda apenas se existe: Diagrama representando a modelagem feita na ferramenta de modelagem definida no projeto;
Sem a definio de feito clara e precisa comum que as tarefas entrem e saiam da coluna concluda, retornando para em execuo, por diversas vezes, sem que esteja efetivamente terminada.

Diagrama contido em um repositrio do projeto; Reviso em conjunto com o Scrum Mster.

Um outro ponto prescrito pelo Scrum so as reunies dirias, que abordaremos a seguir. Durante o planejamento importante a definio do local e horrio dessas reunies. Por fim, um quadro com as informaes do Sprint precisa ser criado. Um exemplo desse quadro exibido na Figura 30. O quadro deve ter as seguintes divises para tarefas: No iniciadas, Em execuo, Concludas e Verificadas. Tarefas concludas so aquelas em que seus executores acreditam ter finalizado todo o trabalho associado. No entanto, elas podem no estar totalmente finalizadas, por conta do esquecimento de algum item a ser feito, e por conta disso no recebem o status de verificadas, devendo retornar para em execuo. As possveis mudanas de estados permitidas so exibidas no diagrama de estados contido na Figura 31. Nessa figura podemos notar que uma tarefa em execuo pode ser considerada concluda pelo seu responsvel, mas ela pode retornar para em execuo, caso o Scrum Mster no a considere concluda durante a verificao que sempre exigida nesses casos.

95

Figura 30: Exemplo da organizao do quadro do Sprint.

Figura 31: Mudanas permitidas no quadro do Sprint. De um modo geral, o quadro do Sprint algo fundamental para o processo, devendo conter todos os itens que facilitem a comunicao com a equipe e o restante da organizao, sendo elas: rea para Objetivo do Sprint; rea para o Grfico de Acompanhamento; rea para especificar a equipe; rea para detalhar a data de incio e fim do sprint; rea para especificar dia da apresentao dos resultados; rea para especificar local e horrio das reunies dirias; rea para especificar o dia da retrospectiva do Sprint. 96

importante manter o quadro do projeto com todas as definies registradas aqui!

9.2.3.

A Reunio Diria

A Reunio Diria uma prtica feita com toda a Equipe, o ScrumMaster e o Product Owner, com durao de no mximo 15 minutos, apenas para uma avaliao das aes do dia anterior e o
A reunio diria TEM que ser rpida, caso contrrio, perder sua efetividade!

planejamento do dia. O objetivo principal da reunio consiste em cada membro responder as seguintes perguntas: O que voc fez de ontem pra hoje? O que far de hoje at amanh? Existe algum impedimento? Na reunio no se resolve problemas: eles devem apenas ser identificados e os envolvidos em sua resoluo devem se reunir posteriormente para tentar chegar a uma possvel resoluo. Os impedimentos identificados na reunio devem ser registrados, assim como os itens no planejados. Todos esses elementos precisam ser registrados para acompanhamento. importante garantir que todos falem, sob a superviso do Scrum Master.

9.2.4.

Acompanhamento do Projeto

O Scrum Mster possui diversas tarefas no controle dirio do projeto, alm da reunio diria: Verificar tarefas concludas Atualizar grfico de acompanhamento Resolver impedimentos Atuar quando houver desvio no planejamento

Para a verificao das tarefas concludas, normalmente aconselhado a presena do Scrum Master e do Product Owner. O que deve ser feito a utilizao da definio de como verificar existente no carto, para analisar se realmente o item est concludo. Se algo discordar do que foi acertado para o projeto, isso deve ser indicado ao responsvel para correo e efetiva concluso do item. Conforme ser visto na disciplina de Qualidade de Software, 97

 importante ter muito cuidado com os testes, para as tarefas que envolvem implementao. Tambm necessrio incluir a anlise do cdigo fonte, para evitar surpresas futuras. A atualizao do grfico de acompanhamento deve seguir a seguinte diretriz: para cada tarefa concluda e verificada, baixar o nmero correspondente estimativa da tarefa no grfico. Muito importante: baixar a estimativa e no o tempo efetivamente gasto! Essa ao no prov uma informao visual de fcil interpretao e de grande valia para qualquer gerente de projeto. Talvez seja aquilo que mais chamativo no Scrum. Para exemplificar, se existe uma tarefa estimada em 8h dentro do backlog do Sprint, mesmo que ela tenha sido feita em 12h, devemos baixar no grfico de acompanhamento apenas 8h quando ela tiver sido efetivamente concluda e verificada. Sempre que houver uma diferena muito grande no previsto e no realizado o Scrum Mster deve tentar identificar as causas e, se possvel, atuar para tentar resolver o problema associado. Da mesma forma, toda vez que um impedimento for registrado necessrio procurar mecanismo para resolv-los, caso contrrio, todo o projeto poder ser comprometido.

9.2.5.

Apresentao do Sprint

Ao final de um Sprint, o Scrum recomenda que seja feita a apresentao dos resultados. Essa apresentao tipicamente se resume a demonstrao de novas funcionalidades do produto ou da sua arquitetura, nos casos de implementao. Ela informal, sem a necessidade de muita preparao e sem slides. Toda a equipe deve participar, assim como outros participantes. Essa reunio uma forma de forar o comprometimento de todos com o trabalho realizado e uma forma de estimular a obteno de resultados efetivos, uma vez que tudo o que foi feito dever ser apresentado.

98

9.2.6.

Retrospectiva

Durante um Sprint, necessrio observar o que funciona e o que no funciona. Na retrospectiva, tudo o que aconteceu e merece algum registro deve ser discutido por todos para que possamos ter melhores resultados em Sprints futuros, levando em considerao as experincias passadas. Essa reunio tipicamente rpida, durando cerca de uma hora, ao final de cada Sprint, com todos os envolvidos no projeto. A equipe tenta responder a trs questes nessa reunio: O que voc achou muito bom no Sprint e que deveria continuar sendo feito; O que voc achou muito ruim e no deveria mais ser feito (ou mudado); O que no est sendo feito, mas deveria iniciar. Um formato indicado para conduzir tal reunio solicitar a cada participante que responda s questes, respondendo com at trs alternativas cada questo, com cada uma das respostas em um carto diferente. Nesse caso, se houver trs respostas para cada pergunta, dever haver nove cartes para um participante. Em seguida, para cada questo devem ser agrupadas as respostas similares, de forma a identificarmos as respostas mais comuns. Em cima dessa identificao que registraremos o que foi mais consensual para cada uma das trs questes. O Scrum Mster deve ficar atento a esses itens e garantir que eles sero levados em considerao no prximo Sprint.

9.3.

Finalizao
Neste captulo apresentamos as recomendaes de um

processo de software muito utilizado mundialmente, o Scrum. Explicamos as diversas cerimnias associadas ao seu uso, de forma a tentar deixar claro os passos a serem executados para seu uso em um projeto. No prximo captulo, para tentar clarificar mais ainda o uso desse processo, apresentamos como utilizar o Scrum para guiar uma atividade simples. 99

De forma geral, as atividades para se utilizar o Scrum em um projeto, so as seguintes: 1. Obter a lista do que fazer (product backlog). 2. Priorizar os elementos da lista. 3. Definir o tamanho do Sprint. 4. Calcular a fora de trabalho para o Sprint. 5. Criar o grfico de acompanhamento. 6. Estimar o tamanho das tarefas a comporem o Sprint. 7. Registrar as tarefas utilizando os cartes. 8. Organizar o quadro do projeto, contendo todos os dados identificados neste captulo. 9. Acompanhar o decorrer do projeto, realizando reunies dirias, atualizando o grfico de acompanhamento e verificando as tarefas terminadas, confrontando com a definio de feito e a forma descrita sobre como verificar a tarefa. 10. Realizar uma apresentao dos resultados do Sprint. 11. Realizar uma retrospectiva do Sprint.

9.4.

Exerccios

1. Qual a origem do Scrum? 2. Quais so os papis relacionados ao uso do Scrum? Detalhe as responsabilidade de cada um desses papis dentro do processo. 3. Qual o objetivo da Reunio Inicial no Scrum? Qual o principal artefato gerado? 4. O que um Sprint? 5. Como podemos definir a fora de trabalho para um Sprint no Scrum? Que variveis podem influenciar nesse clculo? 6. Como sabemos quantas estrias (ou tarefas) podem ser includas em um Sprint? 7. Quais informaes precisam estar associadas a uma estria (ou tarefa) registrada em um Sprint?

100

8. O Scrum prescreve a organizao de um Sprint utilizando um quadro. O que deve ter nesse quadro? 9. Como criado o grfico de acompanhamento e como devemos atualiz-lo diariamente? 10. Quais so as divises do quadro de tarefas e quais as possveis transies entre essas divises? 11. Quais so as perguntas bsicas durante as reunies dirias? 12. Quais so as tarefas rotineiras do Scrum Mster durante o dia a dia dos projetos? 13. O que deve ser feito na reunio de retrospectiva do Sprint? Como isso pode ser guiado?

101

UNIDADE III UM EXEMPLO DE UM PROCESSO DE SOFTWARE

10. Aplicando o SCRUM

Neste captulo apresentamos um exemplo do uso do Scrum para o desenvolvimento de um livro sobre Introduo Engenharia de Software. Como o exemplo no est relacionado ao desenvolvimento de um software e no envolve uma equipe, e sim um nico executor das tarefas, certamente no poderemos utilizar todas as prescries do Scrum, uma vez que boa parte delas no faz sentido quando o desenvolvedor o nico membro atuante no projeto. No entanto, esse exemplo servir para mostrar a dinmica maior do processo e o controle que ele pode nos d durante o desenvolvimento de qualquer tarefa.

10.1. O Exemplo
Qualquer trabalho pode ser controlado com auxlio do Scrum! Vrias equipes de empresas, que no trabalham com desenvolvimento de software, utilizam Scrum para controlar suas atividades.

Conforme mencionado anteriormente, utilizaremos como exemplo o desenvolvimento de um livro introdutrio sobre Engenharia de Software. Depois de alguns momentos de reflexo fizemos a construo do Backlog desse projeto, que seria composto basicamente pelas seguintes tarefas exibidas na Tabela 8. Nela as prioridades definidas para as atividades j encontram-se especificadas. Tabela 8: Product Backlog para o exemplo considerado.
ID Nome Estudar conceitos bsicos, processos e ciclo 1 de vida Prioridade

80

102

2 Escrever captulo introdutrio 3 Escrever captulo sobre processos Estudar as disciplinas da Engenharia de 4 Software Escrever captulos sobre as principais 5 disciplinas 6 Estudar a metodologia Scrum 7 Escrever captulo sobre o Scrum

60 60 50 40 30 20

Iremos utilizar Sprints de duas semanas (dez dias teis) para acompanhamento das tarefas. Com essa definio j podemos criar nosso grfico de acompanhamento, conforme exibido na Figura 32. Podemos notar na Figura a definio da carga de trabalho diria, definida como 1,2h, alm do tamanho do Sprint (10 dias) e o fator de ajuste considerado (75%). Com isso chegou-se a uma carga de trabalho do Sprint de 9h.

Figura 32: Dados do Sprint e Grfico de Acompanhamento. Antes de comear as tarefas importante definir como verific-las, para que possamos saber exatamente quando poderemos considerar algo concludo, uma vez que no teremos a 103

ajuda de outras pessoas nessa empreitada, por se tratar de um trabalho individual. Isso tem haver no somente com a definio dos cartes, que precisam ter essa informao, como est relacionado tambm definio de feito associado ao projeto. Um exemplo para a definio de feito associada s tarefas existentes no Backlog poderia ser: Para tarefas relativas a estudos: breve resumo do item estudado, com detalhamento das referncias utilizadas. Para tarefas relativas escrita de texto: texto escrito, formatado conforme exigido, existncia de bibliografia e exerccios relacionados. O prximo passo a definio da estimativa de tempo para a realizao das tarefas. Normalmente encontramos um erro grande nas tarefas iniciais de um projeto, mas medida que o tempo prossegue conseguimos cada vez mais nos aproximarmos do tempo efetivamente gasto. Fizemos a estimativa de todas as tarefas, no intuito de agilizarmos o processo. Observe que essas estimativas podem ser alteradas, desde que a tarefa com a estimativa a ser alterada no se encontra no Sprint em execuo. As tarefas e suas estimativas so apresentadas na Tabela 9. Tabela 9: Tarefas com estimativa de execuo.
ID Nome Prioridade Estudar conceitos bsicos, procesos e ciclo de vida 80 Escrever captulo introdutrio 60 Escrever captulo sobre processos 60 Estudar as disciplinas da Engenharia de Software 50 Escrever captulos sobre as principais disciplinas 40 Estudar a metodologia Scrum 30 Escrever captulo sobre o Scrum 20 Tempo Estimado

1 2 3 4 5 6 7

4 4 6 8 4 4 4

Com base em nossa carga de trabalho, de apenas 9h, e analisando o Backlog, sempre atento s prioridades existentes e estimativas definidas, podemos notar que apenas as tarefas 1 e 2 104

podem ser includas no Sprint inicial, ainda assim deixando uma lacuna de 1h em aberto. Resolvemos ento iniciar o Sprint com apenas essas duas tarefas.
Grfico de Acompanhamento
10 9 8 7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7 8 9 10 Dias do Sprint

Figura 33: Grfico de acompanhamento aps a primeira semana de tabalho. Na primeira semana de trabalho no conseguimos finalizar nenhuma das tarefas, o que nos gerou um grfico de acompanhamento conforme exibido na Figura 33. Observe que analisando o grfico podemos facilmente perceber que estamos atrasados em relao ao que foi previsto nas estimativas de execuo das tarefas. A linha de acompanhamento acima da ideal indica atraso, assim como a linha abaixo indica um adiantamento em relao ao previsto. Ao final de duas semanas e finalizado o Sprint, obtivemos o grfico exibido na Figura 34. Observe que apenas uma tarefa foi finalizada, por conta disso, ao final do Sprint o grfico de acompanhamento indica que produzimos bem menos que o estimado.

105

Grfico de Acompanhamento

10 9 8 7 6 5 4 3 2 1 0

10

Dias do Sprint

Figura 34: Grfico de acompanhamento ao final do Sprint. A tarefa foi finalizada com apenas 3h de esforo, de acordo com os registros associados sua execuo, exibidos na Tabela 10. Fizemos uma breve retrospectiva sobre o que aconteceu e facilmente identificamos que nossa estimativa no foi o problema principal: na verdade, o desenvolvedor no conseguiu se dedicar conforme havia sido planejado. Tabela 10: Registro dos tempos gastos nas tarefas.
ID Nome Estudar conceitos bsicos, procesos 1 e ciclo de vida 2 Escrever captulo introdutrio Tempo Tempo Prioridade Estimado Gasto

80 60

4 4

Com base nos dados obtidos na retrospectiva teremos que realizar um novo planejamento para um novo Sprint e continuar com a execuo das atividades at que tenhamos finalizado todo o trabalho.

10.2. Discusso sobre o uso do Scrum

Embora o exemplo apresentado anteriormente seja

relativamente simples e no ligado diretamente ao desenvolvimento de software, ele ilustra parte do uso do Scrum no controle de uma atividade. importante ressaltar que o Scrum utilizado hoje nas mais variadas reas de aplicao, tendo rompido a barreira dos

106

ncleos de tecnologia e se espalhado nos outros setores das empresas j h algum tempo. O grfico de acompanhamento uma ferramenta fundamental para qualquer gerente de projeto, pois informa, de maneira simples e direta, como est o andamento das tarefas planejadas para um perodo de tempo. Por tudo isso que o Scrum ganha muito destaque no cenrio nacional e representa como a Engenharia de Software pode ajudar no desenvolvimento de software de qualidade, alm de auxiliar a organizao de qualquer trabalho baseado em tarefas a serem executadas.

10.3. Exerccios
1. Utilize o Scrum para guiar um projeto bem simples: a leitura de um livro. Esse livro poder ser livremente escolhido por voc. Leia alguns captulos inicialmente, apenas para ter noo da sua velocidade de leitura de pginas. Em cima disso, planeje as tarefas (ler os captulos 1, 2, 3, 4, ...), calcule sua fora de trabalho para o Sprint, defina o tamanho do Sprint, acompanhe sua execuo, sempre de olho no grfico, conforme exemplo exibido nesse captulo. Faa um breve relato sobre o uso do processo para controlar essa atividade.

107

UNIDADE III UM EXEMPLO DE UM PROCESSO DE SOFTWARE

WEBLIOGRAFIA

Organizao divulgadora do Scrum mundialmente http://www.scrumalliance.org/ Empresa com diversos artigos e casos de sucesso no uso de prticas geis http://www.mountaingoatsoftware.com/ Vdeos e tutoriais sobre o Scrum http://www.controlchaos.com/ Stio com um livro disponvel para download http://www.infoq.com/br/ Srcumming - Ferramenta Educacional para Apoio ao Ensino de Prticas de SCRUM http://www.inf.pucrs.br/~rafael/Scrumming/ Manifesto gil http://agilemanifesto.org/

108

UNIDADE III UM EXEMPLO DE UM PROCESSO DE SOFTWARE

REFERNCIAS BIBLIOGRFICAS

HENRIK KNIBERG H., Scrum e XP das Trincheiras: Como fazermos Scrum, InfoQ, 2007. HIROTAKA TAKEUCHI, IKUJIRO NONAKA,, The New Product Development Game, Harvard Business Review, 1986. KEN SCHWABER, SCRUM Development Process, Burlington, MA, USA, 1996. KEN SCHWABER, Agile Project Management with Scrum. Microsoft Press, 2004. STANDISH, The Standish Group International, CHAOS

Demographics and Project Resolution, Dennis, MA, USA, 2004. VINICIUS MANHES TELES, Extremme Programming, Editora Novatec, 2004.

109

Autor

Pedro de Alcntara dos Santos Neto

CV. http://lattes.cnpq.br/3452982259415951

Possui graduao em Bacharelado em Cincia da Computao pela Universidade Federal do Piau (1995), mestrado em Cincia da Computao pela Universidade Federal de Pernambuco (1999) e doutorado em Cincia da Computao pela Universidade Federal de Minas Gerais (2006). Atualmente professor da Universidade Federal do Piau. Tem experincia na rea de Engenharia de Software, atuando principalmente na automao de testes, desenvolvimento de software utilizando metodologias geis e engenharia de software experimental.

110