Artigo do tipo Terico Recursos especiais neste artigo:

Comparando mtodos de desenvolvimento A documentao de sistemas tem como foco os profissionais envolvidos na rea de desenvolvimento e usurios de software. Vrias metodologias j foram criadas para gerenciar documentaes de projeto, entretanto, ainda restam dvidas sobre o quanto se deve detalhar e qual a maneira prtica e menos onerosa em relao ao tempo desprendido e at sobre a forma de disponibilizao deste tipo de material para que fique de fcil acesso e interpretao. Neste artigo sero discutidas trs abordagens distintas de apoio ao desenvolvimento de produtos de software. O modelo em cascata, que se caracteriza por suas fases, so totalmente dependentes uma da outra, ou seja, uma fase s comea depois que a anterior finalizada. Este modelo se torna burocrtico, pois no permitida mudana dos requisitos no meio do processo de desenvolvimento. Com isso, uma funcionalidade no poder sofrer alteraes at que ela seja concluda. O RUP (Rational Unified Process) uma metodologia de desenvolvimento iterativa evolutiva, que utiliza os conceitos de orientao a objeto e da UML para criar as notaes grficas atravs de diagramas. Por fim, ser apresentado o Scrum, que se trata de uma metodologia com foco na gesto gil de projetos. Ele segue os conceitos presentes no manifesto gil, que foram elaborados para desburocratizar o processo de desenvolvimento e focar no resultado final esperado pelo usurio. Este artigo tambm indica como se pode evoluir a documentao de requisitos com user stories e casos de uso no Scrum. O foco aprimorar a especificao sem perder a praticidade e a objetividade deste artefato. Em que situao o tema til A importncia do entendimento sobre uma funcionalidade a ser desenvolvida a principal justificativa para que se documente os requisitos do sistema. O entendimento do modelo de desenvolvimento adotado, assim como suas implicaes nos artefatos, que sero elaborados torna-se essencial para a escolha adequada de qual processo seguir na elaborao de um produto de software.

Documentar um sistema uma necessidade conhecida por todos os envolvidos em um processo de desenvolvimento de software. Muitas metodologias j foram criadas para gerenciar documentao de projetos, mas ainda restam dvidas sobre o quanto se deve detalhar e sobre qual a maneira mais prtica e menos onerosa para que a documentao seja facilmente acessvel e interpretado. A documentao de projetos tem como foco profissionais envolvidos na rea de desenvolvimento e usurios do sistema. Para o primeiro, os artefatos produzidos so compostos de informaes tcnicas que representam a estrutura do sistema e o detalhamento do negcio. Para o segundo, o objetivo ser um guia de referncia para a utilizao/configurao do software. Dentro do enfoque tcnico, existem desde modelos que definem os requisitos funcionais e no funcionais, at diagramas de entrega do sistema. Os documentos variam entre a rea de levantamento de requisitos, modelagem do projeto, documentos com cenrios de teste e manuais de instalao. Em relao ao usurio, existem manuais de utilizao do sistema que indicam como realizar algum procedimento no software. Toda a preocupao em documentar tambm est relacionada manuteno, pois o objetivo que cada sistema desenvolvido tenha uma continuao e que se adapte s necessidades do usurio/cliente. Estas adaptaes implicam na realizao de atividades de manuteno e para conseguir faz-las, de uma maneira menos traumtica, preciso conhecer o software. justamente a que a documentao chega como uma aliada. mais fcil conhecer o software atravs de sua documentao do que analisando cdigo fonte. Neste contexto, este artigo abordar a aplicao da documentao no Scrum.

Metodologia de desenvolvimento
No contexto da engenharia de software, uma metodologia define o processo de desenvolvimento, criando um roteiro a ser seguido para tornar este caminho mais produtivo e mais propenso a obter um produto com qualidade. Uma das atribuies de uma metodologia descrever o que cada papel realiza dentro do processo de desenvolvimento, podendo at detalhar qual artefato um determinado papel deve produzir. Ao escolher uma metodologia que ser aplicada ao processo de desenvolvimento, devem-se estudar os conceitos e a estrutura utilizada, para ento descobrir se atende a sua necessidade. Para conhecermos um pouco mais sobre metodologias desenvolvimento, analisaremos em mais detalhes trs delas: modelo cascata, IRUP IBM Rational Unified Process (RUP) e o Scrum.

Modelo Cascata (Waterfall)

Modelo criado em 1970 e mesmo tendo mais de 40 anos, ainda o mais utilizado para desenvolvimento de sistemas. Ele tem este nome pelo fato de suas fases serem dependentes uma da outra. A Figura 1 mostra as fases e o caminho que o desenvolvimento percorre quando se utiliza esta metodologia.

abrir imagem em nova janela Figura 1. Diagrama de fases do Modelo Cascata. Neste modelo, o objetivo que um sistema de informao ter um clico de vida com fases semelhantes a um produto. Estas fases variam entre definio de projeto e ps-implementao: Definio de Projeto: objetiva entender qual a necessidade do projeto; Estudo dos Sistemas: consiste no detalhamento do levantamento inicial onde, baseado nos requisitos levantados, ser analisado o que ser ou no desenvolvido; Projeto: consiste na construo do alicerce da programao; Programao: converte toda a parte conceitual, que foi detalhada atravs das especificaes tcnicas, em cdigo de programa; Instalao: responsvel por aplicar o que foi desenvolvido no ambiente do usurio;

 Ps-Implementao: nesta fase sero disponibilizadas as atualizaes de correes ou melhorias. Existem algumas variaes deste modelo que diminuem a quantidade de fases. Mesmo com menos ou com mais etapas, o modelo define que no se pode iniciar uma nova fase sem que a anterior tenha sido concluda, para garantir a consistncia do que foi produzido. Pela sua filosofia, este modelo se torna burocrtico, pois no permitida mudana dos requisitos no meio do processo de desenvolvimento. Com isso, uma funcionalidade no poder sofrer alteraes at que ela seja concluda. Outra limitao do modelo est no fato do usurio s conseguir ter um retorno sobre como o sistema foi desenvolvido na etapa final do projeto.

IRUP IBM Rational Unified Process

O IRUP (ou RUP, como mais conhecido) uma metodologia iterativa evolutiva de propriedade da IBM (quando adquiriu a empresa Rational). O RUP utiliza os conceitos de orientao a objetos e de UML para criar as notaes grficas atravs de diagramas. O RUP guiado por casos de uso, que um documento que detalha uma funcionalidade do sistema. O objetivo do documento de casos de uso detalhar a funcionalidade tentando prever todos os possveis cenrios que ela poder ter. Ao comparar o RUP com o modelo em cascata, percebe-se que suas disciplinas tm o mesmo propsito que as fases da cascata, porm so realizadas em cada fase. Assim, a disciplina requisitos ser realizada na fase de iniciao, elaborao, construo e transio. A execuo da disciplina est relacionada quantidade de iteraes que ela ter por fase. Esta estrutura interessante uma vez que o projeto passa a ser dividido em vrios incrementos, cada um com uma srie de entregas programadas para o cliente. Isto permite um acompanhamento mais prximo do cliente e uma avaliao contnua da viabilidade do projeto, podendo-se optar at mesmo por descontinuar o desenvolvimento. Esta vantagem ainda mais significativa ao se considerar que no modelo cascata os clientes s conseguiriam ter este retorno no momento da entrega final do produto. Para entender melhor este benefcio, considere o exemplo de um projeto que tem o tempo de desenvolvimento estimado em um ano. No

modelo cascata o cliente s viria o resultado do projeto aps um ano. Por outro lado, no RUP este projeto pode ser dividido em quatro entregas e o cliente conseguiria ter o primeiro retorno em trs meses. Apesar das vantagens, esta metodologia vista muitas vezes como pesada e de uso preferencial para projetos de grande porte, o que justifica a quantidade de artefatos que devem ser gerados. Proporcionalmente, o tempo de elaborao de artefatos para projetos grandes no se torna to alto quanto para projetos menores. Este fato pode tornar invivel a aplicao desta metodologia para projetos de pequeno porte. Em contrapartida, o RUP uma metodologia que foi criada pensando na sua customizao. Para cada tamanho e tipo de projeto, pode se ter um grupo diferente de artefatos. Assim, projetos menores podem considerar um nmero menor de artefatos em seu desenvolvimento. Outro aspecto importante no RUP que ela prega algumas boas prticas como, por exemplo, desenvolver os casos de usos mais complexos antes dos mais simples. Isto sugerido, pois se entende que iniciar o desenvolvimento dos casos de uso mais complexos pode trazer resultados mais favorveis, pois nos antecipamos a futuros problemas. O RUP dirigido por fases que tm as mesmas disciplinas, conforme detalhado a seguir: Concepo (Iniciao): o objetivo desta fase definir o escopo do projeto. Para isto, so definidos planos, avaliando os possveis riscos, prazos, recursos, definio de prioridades e estimativa de custos. Nesta fase o foco requisito, pois atravs deles que ser definido o escopo; Elaborao: nesta etapa se busca estabilizar a arquitetura do sistema a ser desenvolvido. Sero mitigados os casos de uso mais complexos e que representam mais riscos para o projeto. A partir disto, se estabelece uma baseline que ser usada na fase de construo; Construo: com base na arquitetura definida na fase de Elaborao, se d sequncia ao desenvolvimento dos casos de uso restantes. Aqui o que deve ser gerenciado o processo mais operacional, ou seja, alocao e otimizao de recursos visando a diminuio de custos e aumento de produtividade; Transio: o objetivo desta etapa garantir que o software estar disponvel para o usurio. Assim, os esforos devem estar voltados para os detalhes finais do projeto e as atividades esto mais relacionadas com a preparao do ambiente para a publicao da verso e, caso necessrio, sobre manuais de instalao e de utilizao do sistema.

Cada fase do RUP possui nove disciplinas: Modelagem de negcios: cujo objetivo entender o domnio do negcio de forma que seja possvel iniciar o desenvolvimento desta iterao; Requisitos: tem como objetivo definir o escopo que ser desenvolvido na iterao, as funcionalidades e as limitaes que o sistema dever considerar; Anlise e Design: converte os requisitos funcionais identificados para o desenvolvimento da iterao em especificaes tcnicas que serviro de apoio para os desenvolvedores na disciplina de implementao; Implementao: constri o software baseado na fase anterior; Teste: possui o objetivo de avaliar a qualidade do software produzido na iterao corrente; Implantao: feita a distribuio do software desenvolvido na iterao. O objetivo garantir que esse esteja disponvel para o usurio; Gerenciamento de mudanas: possui o objetivo de controlar as mudanas dos artefatos gerados pela iterao, garantindo a integridade delas; Gerenciamento de projetos: objetiva analisar as concorrncias das atividades a serem realizadas na iterao, analisar os riscos e gerenciar os recursos disponveis; Ambiente: foca no ambiente no qual ser desenvolvido o sistema de iterao. Assim, aqui so definidos processos e ferramentas que daro suporte equipe de desenvolvimento.

A Figura 2 apresenta um grfico que ilustra a estrutura do RUP.

Figura 2. Diagrama do RUP. Ao analisar a Figura 2, no topo da imagem esto as fases que compem o RUP (Iniciao, Elaborao, Construo e Transio), no lado esquerdo, encontram-se as disciplinas realizadas em cada fase. interessante observar neste grfico que praticamente todas as disciplinas so executadas em cada fase, mudando apenas a quantidade de esforo que investido em cada uma delas.

Scrum
O Scrum uma metodologia com foco na gesto gil de projetos. Segue os conceitos presentes no manifesto gil, elaborado para desburocratizar o processo de desenvolvimento e focar no resultado final esperado pelo usurio. O primeiro item do manifesto define que a comunicao e interao entre os envolvidos do processo mais valiosa do que a burocracia da utilizao de um processo e, principalmente, do fato de colocar o peso do sucesso do desenvolvimento em cima dos artefatos documentais. O segundo item foca em resultado; entendendo que o sistema funcionando um artefato mais valioso que um artefato que s documenta, pois o usurio de posse do sistema consegue ter um retorno sobre o projeto mais rpido do que analisando artefatos. O terceiro item define que o cliente integrante do time de desenvolvimento, ele auxilia nas possveis dvidas sobre negcio e sobre prioridade dos itens

que sero desenvolvidos. Com a colaborao do cliente mais presente e no burocrtica, se economiza tempo e o sistema a ser desenvolvido tende a se tornar mais prximo do desejado. Por fim, o manifesto indica a flexibilidade sobre a questo das mudanas, pois as metodologias que seguem este manifesto no burocratizam o processo de solicitao de mudana. Alm disso, no existe uma solicitao de mudana, simplesmente define-se um item a ser desenvolvido, ficando a cargo do cliente definir o que ser mais valioso, se a mudana de algo que j foi feito ou o desenvolvimento de um novo item. O Scrum uma metodologia iterativa evolutiva. Ela visa melhorar o processo de desenvolvimento e, para isto, divide o sistema a ser produzido em vrios incrementos, que sero construdos em intervalos de tempos denominados Sprint. Sprint o nome dado para cada iterao dentro do Scrum. Elas tm durao entre uma semana a um ms, tempo este que ser definido no incio do projeto. As Sprints no podem alterar o tempo entre cada entrega, o objetivo que sempre tenha o mesmo tempo, pois assim ser uma unidade de medida para saber o que cadaSprint conter. Antes do incio da Sprint existe uma reunio onde so decididos os itens que sero desenvolvidos dentro desta entrega e, aps isto, ocorre outra reunio de reviso que tem por objetivo analisar o progresso sobre os itens desenvolvidos. O Scrum define trs papis: Scrum Master, Product Owner e Time. O Scrum Master o responsvel por garantir que o processo ser utilizado e que ocorrer sem nenhum impedimento. Sua responsabilidade fazer com que a equipe no seja impactada por eventos externos e, para isto, diariamente realizada uma reunio chamada de Daily Meeting, com durao de 15 minutos e realizada em p, de forma que o foco no seja perdido em nenhum momento. atravs desta reunio que o Scrum Master descobre se houve algum impedimento na execuo da atividade. Caso este tenha ocorrido, ele resolve depois da reunio com a pessoa que o reportou. Product Owner o papel representado pelo cliente. O profissional que estiver realizando esta funo dentro do processo deve ter poder para representar o cliente e ser responsvel por eliminar dvidas de negcio, priorizar atividades e, principalmente, definir o escopo do projeto. O Time composto pelos implementadores, responsveis por converter as especificaes do que deve ser desenvolvido em cdigo fonte.

O Scrum indica que os profissionais sejam autogerenciveis. Dessa forma, estes papis servem apenas para que as pessoas consigam realizar suas tarefas sem impedimento e, principalmente, saibam o que cada um tem que fazer.

Planning Poker
Dentro da estrutura do Scrum existem as user stories (estrias dos usurios), que nada mais so do que a descrio das funcionalidades que devero ser desenvolvidas. Estas funcionalidades so coletadas e priorizadas atravs do Product Owner e oradas pelo Time. Entretanto, para orar eles no utilizam como unidade de medida o tempo em horas, mas sim o nvel da complexidade de cada atividade. No incio do desenvolvimento definido o quanto em pontos que um Sprint poder conter. Tendo como base este nmero, o time de desenvolvimento se rene para pontuar cada user story. De posse da lista priorizada pelo cliente, sero elencados os itens que sero entregues no prximo Sprint, tendo como referncia o total que pode ser entregue. Por exemplo, considerando que a user story com a funcionalidade Controle de acesso atravs de tela de login pontuada com 20 pontos e a funcionalidade de cadastro de usurio pontuada com 40. Considerando tambm que o total de pontos que pode ser entregue na Sprint 70. Neste caso, ainda resta espao para atividades que juntas cheguem a 10 pontos.

Trabalhando com casos de uso no Scrum

O Scrum no define um modelo de documento para as user stories que, por conta disto, podem ser definidas de maneira incompleta trazendo problemas para o processo de desenvolvimento. Quando se desenvolve um caso de uso, mesmo que indiretamente, ele nos fora a pensar bastante sobre a funcionalidade que estamos analisando. Precisamos definir itens como, ator, pr-condio, ps-condio e quais so as aes dos fluxos principais (bsicos) e alternativos. Com isto, se consegue analisar o problema a ser atendido. A aplicao de casos de uso em um processo Scrum completamente vivel. O Scrum no impe qualquer forma particular de elucidar e registrar requisitos, alm das recomendaes de conversao face a face, reunies regulares de posicionamento, sesses de planejamento da Sprint ou talvez at mesmo a anlise das userstories, mas acima de tudo prega atividade colaborativa e transparncia em geral.

Para aplicar os casos de uso no Scrum sem tornar a metodologia mais burocrtica, pode-se proceder de duas maneiras. A primeira delas fazer com que o Product Owner detalhe as user stories, antes de serem apresentadas para o time de desenvolvimento. O objetivo no burocratizar, mas tornar o processo de anlise mais eficiente, inclusive fazendo com que o Product Owner tenha material para analisar, se de fato aquele item deve ou no ser desenvolvido, ou at mesmo para mudar a prioridade de desenvolvimento dele. A segunda maneira seria fazer com que o time desenvolva os casos de uso baseados nas user stories, podendo assim utilizar este material como guia no momento do teste ou at para auxiliar futuros ajustes. Neste caso, este tempo gasto poderia ser orado junto com o tempo de desenvolvimento das user stories.

Concluso
No detalhamento feito sobre as metodologias neste artigo, foi visto que elas partiram de um modelo bem ntegro e consistente, porm engessado que o modelo cascata. Em seguida, analisou-se o RUP que veio com uma proposta de uma metodologia bem estruturada e que tem sido aplicada com sucesso na indstria de software. Contudo, pelo grande nmero de documentos dentro de seu modelo, o RUP muitas vezes visto como uma abordagem pesada e burocrtica. Por fim, analisou-se a metodologia gil Scrum. Ela traz uma nova cultura de desenvolvimento, pois pressupe uma maior aproximao com o cliente e a reduo da necessidade de documentao durante o projeto. O Scrum uma metodologia em ascenso e traz uma mudana cultural, bastante significativa dentro do processo de desenvolvimento de sistemas. Para tornar esta metodologia mais aceitvel e mais prxima das empresas que utilizam RUP, interessante mostrar o quanto ela pode se adaptar. Uma das formas de realizar esta adaptao pode ser atravs da aplicao dos casos de uso no lugar das user stories. Por ter uma estrutura mais definida, casos de uso auxiliam de forma mais clara as demais atividades do processo de desenvolvimento ajudando principalmente na etapa de anlise, fazendo com que equipes que utilizam o Scrum se tornem mais seguras quanto ao nvel de entendimento do que deve ser desenvolvido. Referncias AMBLER, Scott. W. Agile Databases Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. 2003.

BECK, Kent. Extreme Programming Explained. Addison Wesley. Estados Unidos, 2000. BECK,Kent.Programaoextrema(XP)explicada:acolhaas mudanas.PortoAlegreRS:Bookman,2004. PRESSMAN, Roger S. Engenharia de software. Traduo Rosngela Delloso Penteado. Reviso Ferno Stella R. Germano. 6. ed. So Paulo: McGraw-Hill, 2006. SCHWABER, Ken. Agile Software Development with Scrum - Scrum FAQ, 2006. Version 1.0. Conchango.

Leia mais em: Comparando mtodos de desenvolvimento http://www.devmedia.com.br/comparando-metodos-dedesenvolvimento/28510#ixzz2uGgfgF6I