Arquivo por categoria Processo Unificado

O Processo Unificado (PU)

O Processo Unificado (PU) surgiu posteriormente às metodologias citadas acima e propõe um processo de desenvolvimento iterativo e incremental como meio para sanar fragilidades das metodologias anteriores. Baseia-se em refinamentos e incrementos de um sistema por meio de múltiplas iterações contando com o feedback do cliente e com uma adaptação cíclica como principais propulsores para um sistema que se adeque bem aos interesses do cliente. Não há, no Processo Unificado, uma corrida para implementar o software e nem um longo e demorado projeto que tenta resolver todos os problemas antes da programação. Ao fim de cada iteração tem se um sistema executável, mas que ainda não está pronto para ser colocado em produção (LARMAN, 2004).

No processo unificado valoriza-se muito o feedback vindo do cliente. Segundo Larman (2004) a frase “acolha a mudança” (BECK, 2000 apud LARMAN, 2004) mostra a atitude chave do desenvolvimento iterativo. Ao invés de combater a mudança tentando especificá-la completa e corretamente e fazer com que o cliente assine embaixo de um conjunto de requisitos congelados antes da implementação. No processo unificado aceita-se a mudança e passa a considera-la não um problema, mas sim uma realidade.

Essa realimentação contínua vale ouro, ao invés de se especular sobre requisitos ou projetos corretos, aproxima-se com maior precisão do que o cliente realmente precisa. Todavia isso não é uma justificativa para o desenvolvimento caótico e reativo em que continuamente muda-se a direção, é necessário, sempre, manter um meio termo. No Processo Unificado o desenvolvimento progride através de uma série de ciclos estruturados que envolvem construção-realimentação-adaptação. Frequentemente as primeiras iterações de um projeto tendem a ser maiores visto que os requisitos ainda não estão corretamente refinados (LARMAN, 2004).

Larman (2004) enumera uma série de benefícios tragos pelo processo iterativo:

  • Mitigação precoce de erros, ao invés de tardiamente e de forma arriscada;
  • Progresso visível desde o início do projeto;
  • Realimentação, envolvimento do cliente e adaptação imediatos refinando o sistema.
  • Administra-se melhor a complexidade evitando uma sobrecarga da equipe de desenvolvimento.
  • O aprendizado de uma iteração pode ser aplicado para melhorar o processo de desenvolvimento como um todo.

O processo unificado recomenda pequenas iterações que podem variar de duas a seis semanas. As ideias centrais do processo unificado são, dar pequenos passos, obter feedback rápido e fazer adaptações. Iterações com grandes intervalos de tempo podem prejudicar a motivação da equipe além de aumentarem o risco do projeto.

De acordo com Pressman (2006) é razoável caracterizar as metodologias adotadas nas duas primeiras décadas da Engenharia de Software como a era do “pensamento linear”. A Engenharia de Software, até então, era abordada como uma atividade linear onde a execução de diferentes etapas sequenciais poderia ser utilizada para resolver problemas complexos. Embora essa abordagem seja coerente ela não pode ser empregada sem acarretar nos problemas apontados acima. Para Pressman (2006), apesar das falhas apresentadas por essas metodologias, muitos conceitos criados nesse período são válidos e continuarão sendo utilizados e/ou incorporados em metodologias futuras.

Referências:

LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo Unificado. 2 ed. Porto Alegre: Bookman, 2004.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

Tags: , ,

As Metodologias Tradicionais de Desenvolvimento de Software

As metodologias tradicionais são também chamadas de pesadas ou orientadas a documentação. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros Naquela época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso o software era todo planejado e documentado antes de ser implementado. Uma das metodologias tradicionais mais utilizadas até hoje é o modelo Clássico ou Cascata (SOARES, 2004).

Cascata

Uma das primeiras metodologias criadas para minimizar os problemas destacados acima foi a metodologia Cascata. Ela representava um grande avanço no desenvolvimento de software. Principalmente se levar em conta que antes do surgimento das primeiras metodologias existia o que ficou vulgarmente conhecido como “codifica arrebenta”. Onde o mal ou nenhum levantamento de requisitos levava a sucessivas correções, debugs e muitas vezes ao fracasso do projeto.

O Ciclo de Vida da Metodologia Cascata

Fonte: PRESSMAN, 2006

A Figura acima representa a metodologia cascata, também conhecida como sequencial, ou linear, por se basear em uma sucessão de etapas onde uma só é iniciada após o fim da imediatamente anterior a ela. Como se pode ver o desenvolvimento flui da parte de cima – Engenharia de sistemas – em direção à manutenção. Nessa metodologia, inicialmente procura-se compreender completamente o problema, a ser resolvido, seus requisitos e suas restrições; depois projeta-se soluções que atendam a todos os requisitos e restrições. Feito isto inicia-se a implementação do projeto e quando toda a etapa de implementação é concluída verifica-se junto ao cliente se a solução atende aos requisitos estabelecidos e por fim é efetuada a entrega do produto (KROLL e KRUCHTEN, 2003 apud LOURENÇO, 2011).

A abordagem adotada pela metodologia cascata acaba trazendo alguns problemas. Dentre estes problemas merece destaque o fato de que os projetos reais dificilmente seguem o fluxo sequencial, o cliente quase sempre não consegue exprimir todas as suas necessidades além de ser exigida dele muita paciência visto que o software só estará pronto para uso num ponto tardio do cronograma. E o maior dos problemas é que se ocorrer um erro em qualquer uma das etapas o resultado pode ser desastroso e frequentemente caro (PRESSMAN, 2006).

Algumas vezes o cliente define um conjunto de objetivos gerais que não esclarecem consistentemente os requisitos. Outras vezes o desenvolvedor não tem certeza da eficiência de parte do código, da adaptação da aplicação ao sistema operacional ou mesmo da forma que interação homem-máquina deve ter. Visando fornecer melhores soluções à casos assim surgiu a metodologia conhecida como prototipação.

Prototipação

A Prototipação é uma metodologia surgida posteriormente à Cascata. Ela possibilita a equipe de desenvolvimento a criar uma aplicação protótipo que pode assumir três formas distintas. A primeira delas é um protótipo em papel ou mesmo no computador que retrate a interação homem-máquina. A segunda opção é implementar uma funcionalidade que já está no escopo do software a ser desenvolvido. Por fim existe a possibilidade de utilizar-se de um software já pronto que tenha parte ou todas as funcionalidades desejadas. Esta forma é mais comumente adotada em softwares que apesar de prontos ou parcialmente prontos possuem características que precisam ser incrementadas ou melhoradas em um novo esforço de desenvolvimento (PRESSMAN, 2006).

Geralmente o protótipo serve apenas como um mecanismo para identificar requisitos de software. Isto ocorre por que na maior parte dos casos o primeiro sistema construído não é completamente usável. Normalmente ele possui uma série de problemas que só serão corrigidos em uma versão reprojetada na qual as deficiências sejam corrigidas (BROOKS,1975 apud PRESSMAN, 2006).

Assim como a metodologia Cascata a Prototipação também apresenta os seus pontos negativos. Um deles, é que o cliente pode acreditar que o protótipo já é o software pronto ou em fase de término e começar pressionar para que se faça pequenos ajustes e entregue o software rapidamente. Diante de um quadro assim, muitas vezes, a equipe de desenvolvimento cede e a qualidade final, bem como a manutenibilidade podem ficar comprometidas. Outro ponto negativo é que algumas vezes a equipe de desenvolvimento pode  fazer concessões temporárias a fim de colocar o protótipo em funcionamento que acabam permanecendo no software final.

Apesar desses problemas, a prototipação ainda é uma eficiente metodologia de desenvolvimento de software. A fim de se obter sucesso no projeto, tanto cliente quanto desenvolvedor devem chegar a um consenso de que o protótipo servirá apenas para ajudar na definição dos requisitos (PRESSMAN, 2006). Apesar de resolverem muitos dos problemas do desenvolvimento de software alguns parâmetros ainda não eram fornecidos pelas metodologias existentes.

Espiral

A metodologia espiral foi concebida para englobar as melhores práticas tanto do ciclo de vida clássico quanto da prototipação. Essa metodologia inovou ao trazer também um novo elemento, a análise de riscos. Além disso, foi uma das primeiras metodologias a adotar o conceito de iteração. Sucessivas iterações moldam aos poucos soluções mais completas do software (PRESSMAN, 2006).

Na primeira iteração, os objetivos, alternativas e restrições são definidos e os riscos são identificados e analisados. O cliente avalia o resultado da iteração e baseado nos apontamentos do mesmo a próxima iteração é iniciada. Isso possibilita ao cliente e ao desenvolvedor perceber e reagir a riscos em cada uma das etapas evolutivas. Entretanto a metodologia espiral exige considerável experiência para avaliar os riscos e se baseia nela para obter sucesso. Encara-se que se um grande risco não for detectado indubitavelmente ocorrerão problemas.

Referências:

LOURENÇO, Marcelo. Obtendo Qualidade de Software com o RUP. Disponível em: < http://qualidade-de-software.blogspot.com/2010/03/obtendo-qualidade-de-software-com-o-rup.html >  acesso em 05 mar. 2011.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2004. Disponível em: < http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf > acesso em: 04 abr. 2011.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

Tags: , , , ,