Baixe Métodos tradicionais e ágeis de desenvolvimento: aplicação empresa de software e outras Manuais, Projetos, Pesquisas em PDF para Cultura, somente na Docsity!
AVALIAÇÃO DOS MÉTODOS DE DESENVOLVIMENTO TRADICIONAIS E
ÁGEIS PARA APLICAÇÃO EM UMA EMPRESA DE SOFTWARE.
Lorival Warmeling Matias 1
Resumo:
Este artigo apresenta métodos que podem ser aplicados no desenvolvimento de software. Inicialmente é feito um detalhamento de alguns dos métodos de desenvolvimento tradicionais e ágeis, e por último, como esse artigo é bibliográfico e comparativo, é apresentado um posicionamento sobre esses métodos e como aplicá-los em uma empresa de software.
Os resultados obtidos foram conclusivos, foi possível verificar a relação entre as metodologias ágeis: FDD, XP e SCRUM, os modelos tradicionais: sequencial linear, prototipagem, clássico, incremental, espiral, RUP e RAD, e a relação entre ágil e tradicional.
Foi possível verificar que indiferente da metodologia escolhida, o que deve ficar definido é o processo, suas relações com os papéis (pessoas) e os valores/práticas/regras relacionadas, desta forma, a empresa deve possuir essa metodologia bem definida e para isso deve escolher qual método melhor se adapta, para garantir a conclusão dos projetos de desenvolvimento de software.
Palavras-chave: Desenvolvimento de Software. Desenvolvimento Clássico. Desenvolvimento Ágil.
Introdução O termo engenharia de software surgiu em 1968 em uma conferência organizada para discutir problemas no desenvolvimento de software, a experiência inicial do desenvolvimento informal mostrou-se ineficaz, com muitos atrasos e alto custo. Novas técnicas e métodos eram necessários para controlar as etapas de desenvolvimento, principalmente em sistemas grandes e complexos (SOMMERVILLE, 2007).
A abordagem inicial para elaboração desses métodos era produzir software de qualidade, dentro do prazo e com custos previsíveis. Métodos como a análise estruturada, desenvolvida na década de 70, tentaram identificar componentes funcionais básicos de um sistema, esse método foi complementado por métodos orientados a
(^1) Dados do autor ao final do artigo
objetos nas décadas de 80 e 90. Todas essas abordagens foram integradas em uma única abordagem chamada Unified Modeling Language (UML) (SOMMERVILLE, 2007).
Esses métodos são utilizados até os dias atuais devido a sua vasta abordagem na condução dos levantamentos de requisitos, controles de projetos, controle sobre o desenvolvimento, controle sobre a manutenção e finalização dos projetos (SBROCCO; MACEDO, 2012).
Em contrapartida, como o desenvolvimento de software não se assemelha ao desenvolvimento de um produto físico, por exemplo, hardware, onde a matéria-prima é palpável e a dificuldade é em reproduzi-lo, com o software, o problema principal é no desenvolvimento, já que sua replicação tem praticamente custo zero. Pensando nisso, na década de 90, iniciaram-se estudos para definição de metodologias que focaram nos fatores humanos e no atendimento das expectativas dos clientes e não meramente em atender a burocracia do processo, essa técnica ficou conhecida como metodologia leve. Como a aplicação dessa técnica teve retorno positivo, em 2001, seus idealizadores promoveram um manifesto reunindo todas essas práticas que são conhecidas atualmente como métodos ágeis (BASSI FILHO, 2008).
Como o objetivo deste artigo é avaliar os métodos de desenvolvimento para aplicação em uma empresa de desenvolvimento de software, serão apresentados os métodos tradicionais e ágeis e por fim será feito uma comparação entre eles e como aplicá-los.
Métodos de desenvolvimento tradicionais É fato que um processo de qualidade gere produtos de qualidade, seguindo essa premissa, os métodos tradicionais buscam uma organização dos processos para garantir a qualidade, prazo e custo aceitáveis.
A idéia de aprimoramento de processos veio originalmente do engenheiro William Edwards Deming, que trabalhou na indústria japonesa depois da segunda guerra mundial com o objetivo de aumentar a qualidade dos produtos, Deming
A modelagem desse método inicia fazendo o levantamento de todos os requisitos para todas as partes do sistema e é necessária uma análise de alto nível e também um conhecimento estratégico sobre regras de negócio. Nesse caso o analista precisa ter tanto domínio sobre as informações do software quanto das funções necessárias, nesse método os requisitos do sistema são documentados e revistos pelo cliente.
O projeto é um processo de múltiplos passos que engloba os seguintes temas: estrutura de dados; arquitetura do software; representação da interface e detalhes procedimentais.
Inevitavelmente ao colocar o software em uso, são detectadas omissões ou erros nos requisitos levantados inicialmente, erros de programação ou ainda a necessidade de adicionar novas funcionalidades, desta forma, deve haver uma evolução do software para que o mesmo se torne útil. Outro aspecto desse método é que o programa executável somente é liberado quando todas as funcionalidades estiverem desenvolvidas, o que pode ocasionar divergências que serão vistas somente quando o sistema for liberado (SOMMERVILLE, 2007).
Modelo de prototipagem É quando o cliente define os objetivos do sistema, mas não faz o detalhamento das entradas, processamento e saídas. Partes do software são desenvolvidas e já liberadas, permitindo ao cliente interagir com as entradas e saídas tornando assim a descoberta e/ou melhoria de requisitos mais fáceis.
Esse modelo estabelece o ciclo de processos: ouvir o cliente, construir/revisar o protótipo e o cliente testar o protótipo, esse ciclo pode ser reiniciado tantas vezes quanto for necessário.
Por mais que o cliente e o desenvolvedor gostem desse tipo de método, ele pode apresentar sérios problemas (SBROCCO; MACEDO, 2012): Quando uma parte do software é liberada, o cliente acredita ser a versão completa, e normalmente reclama se for exposta a
necessidade de ajustes para garantir a qualidade ou a evolução das funcionalidades. A fim de liberar mais rapidamente, o desenvolvedor desconsidera pontos importantes, como por exemplo: linguagem de programação ou sistema operacional, ficando assim, limitado ao que conhece ou está facilmente disponível. E que pode, ao passar do tempo, tornar- se parte integral do sistema por desconhecimento dos pontos frágeis do desenvolvimento.
Modelo clássico Esse modelo surgiu em uma época diferente da atual onde imperava os mainframes e os chamados "terminais burros", onde os desenvolvimentos e alterações tinham alto custo, devido às ferramentas de desenvolvimento não possuírem, por exemplo, depuradores de código. Devido a isso o planejamento e a documentação eram amplamente utilizados.
Composto de etapas de fácil entendimento foi o primeiro processo de desenvolvimento de software publicado (SBROCCO; MACEDO, 2012), segue abaixo imagem demonstrando as etapas:
Figura 1 - Modelo clássico.
Desenvolvimento em espiral Esse modelo combina técnicas de prototipagem com aspectos controlados e sistemáticos do modelo sequencial linear. Esse modelo oferece suporte ao desenvolvimento de verões incrementais, como por exemplo, em versões iniciais pode ser prototipagem, em versões finais pode ser entregue funcionalidades ainda mais completas.
A estrutura do modelo espiral é distribuída em atividades normalmente conhecidas como regiões de tarefa, segundo Pressman (2001 apud Sbrocco e Macedo, 2012, p.66), existem de três a seis destas regiões de tarefas, conforme descrito a seguir:
- Comunicação com o cliente: tarefas de comunicação entre desenvolvedor e cliente para a obtenção dos objetivos.
- Planejamento: tarefas de definição de recursos, prazos, entre outras.
- Análise de risco: tarefas de avaliação de riscos técnicos e gerenciais, por exemplo, se houver dúvida sobre os requisitos há a necessidade da construção de um protótipo do sistema.
- Desenvolvimento e validação: tarefas para construir, testar, instalar e apoiar o usuário (documentação e treinamento).
- Avaliação pelo cliente: tarefas para obter o posicionamento do cliente sobre as funcionalidades oferecidas e o modelo de implantação, oportunizando uma realimentação advinda do cliente e a liberação para o próximo incremento.
Esse modelo pode ser aplicado tanto para pequenos, quanto grandes projetos, cada tarefa pode definir um conjunto de atividades e essas variam dependendo do tamanho do projeto. Diferentemente do modelo clássico, o modelo espiral pode ser utilizando durante todo o clico de desenvolvimento do software, visto que sempre requer um novo planejamento após a realimentação da avaliação do cliente. Da mesma forma que ocorre com outros modelos clássicos, é fundamental a avaliação apurada dos ricos para garantir aos clientes que o modelo é sustentável, a imagem a seguir ilustra o desenvolvimento em espiral.
Figura 3 - Modelo espiral, segundo Sbrocco e Macedo (2012).
IBM Rational Unified Process® (RUP) Esse modelo foi inicialmente desenvolvido pela Rational Corporation e em seguida adquirido pela IBM. É uma plataforma de processos de desenvolvimento de software onde tarefas são distribuídas para garantir que a qualidade esteja de acordo com as necessidades dos clientes.
Esse modelo possui três perspectivas que demonstram como são relacionadas às atividades, a distribuição do tempo e as práticas durante a sua execução (SOMMERVILLE, 2007): Estática - eixo vertical: representa as atividades do fluxo de trabalho (workflow), são elas:
- Modelagem de negócio: processos de negócio são modelados com a ajuda dos casos de uso do UML.
- Requisitos: os requisitos do sistema são desenvolvidos com base nos casos de uso.
Segue imagem ilustrando as fases do RUP®:
Figura 4 - Fases do RUP®
Fase de iniciação Nessa fase e feito o levantamento do esforço, riscos, as exigências que devem ser analisadas antes de dar sequência no projeto. E importante também nesse momento fazer a formulação do escopo do projeto. Essa fase deve proporcionar um caminho no gerenciamento dos requisitos e no gerenciamento do projeto. Se o projeto não tiver aderência ao negócio, o mesmo pode ser cancelado nessa fase.
Fase de elaboração Nesse momento é desenvolvido o entendimento sobre o projeto, é definido e validado a arquitetura a ser utilizada (execução, desenho e implementação da fase de construção). Ao final dessa fase tem-se uma descrição dos requisitos (casos do uso da UML), da arquitetura e um plano de desenvolvimento.
Fase de construção Nessa fase é feito a elaboração do projeto, programação e os testes, desta forma, não é interessante adicionar processos ou ferramentas nesse momento,
para assim, garantir um processo estável. Nessa fase ainda existe um esforço, principalmente nas primeiras interações, de design e um contato muito próximo com o cliente e os demais stakeholders. Ao final dessa fase tem-se um sistema do software desenvolvido juntamente a documentação para ser liberara para os usuários.
Fase de transição Nessa fase são finalizados todos os materiais que serão disponibilizados aos usuários finais, como também é feito os testes das funcionalidades diretamente na base do cliente. Nesse momento é criado um release do produto. Também são recebidos os feedbacks dos usuários para fazer os ajustes necessários. Idem a fase de construção, não se deve adicionar processos ou ferramentas, isso pode ser feito nos próximos projetos. Ao final dessa fase, tem- se o software documentado e funcionando na base operacional.
A abordagem RAD (Rapid Application Development) Desenvolvimento rápido de aplicação, ou simplesmente RAD, utiliza o método incremental e destaca o ciclo extremamente curto de desenvolvimento, esse método é parecido com o desenvolvimento linear, só que utilizando componentes. Se o entendimento dos requisitos e do objetivo do projeto e claro e simplificado, é possível utilizar esse método para construção de aplicações em curto espaço de tempo.
A abordagem RAD é dividida em cinco fases, conforme a seguir:
- Modelagem de negócio: é definido que tipo de informação abrange o negócio, quem as gera, quem utiliza e quem processa essas informações.
- Modelagem de dados: são definidos os objetos, suas características (atributos) e como se relacionam.
- Modelagem de processos: é desenhado o processo com objetivo de atender a função do negócio e são definidos os procedimentos necessários para a manipulação dos objetos de dados.
- Geração da aplicação: enfatiza a idéia de reutilização ou criação de componentes para futura utilização em linguagens não convencionais.
O conceito de gestão orientada a pessoas requer um time muito eficaz, que interajam entre si de forma eficiente. Já no processo tradicional isso não se faz necessário, visto que o conhecimento sobre o que deve ser feito encontra-se no processo e não nas pessoas, desta forma, pessoas são partes substituíveis do projeto (SBROCCO; MACEDO, 2012).
Com base na crescente necessidade de mais dinamismo das empresas e respostas mais rápidas as mudanças do mercado, a aplicação de metodologias ágeis acaba sendo mais eficientes, pois vem de encontro com essas necessidades.
A seguir serão apresentadas algumas das técnicas de desenvolvimento ágil.
Feature Driven Development (FDD) A metodologia FDD foi criada em Singapura nos anos 90, mais especificamente entre 97 e 98, foi utilizada pela primeira vez para o desenvolvimento de um sistema bancário internacional, que já havia sido considerado inviável dentro do prazo determinado (SBROCCO; MACEDO, 2012).
A modelagem FDD divide os papeis em três grandes grupos (BASSI FILHO, 2008):
- Desenvolvimento da aplicação (papéis chave): gerente de projetos, especialista em negócios, arquiteto chefe, gerente de desenvolvimento, programador chefe e dono da classe (programador).
- Auxiliares ao desenvolvimento (papéis de apoio): gerente de release, guru de linguagem, engenheiro de integração, toolsmith^3.
- Opcionais ao desenvolvimento (papéis opcionais): testadores, implantadores, escritores técnicos.
(^3) Toolsmith é o responsável por criar ferramentas de apoio à equipe de desenvolvimento e testes. Pode atuar também como centralizador de conhecimento gerenciando sites intranet (Wiki). Normalmente é atribuição de programadores júnior ou recém graduados.
Os processos do FDD são compostos por cinco etapas que abrangem as fases de modelagem e implementação (BASSI FILHO, 2008), são elas:
- Desenvolvimento do modelo geral: os especialistas em negócio chegam a um consenso sobre os objetivos, escopo e funcionalidades do projeto, criando assim uma lista de requisitos do sistema.
- Construir a lista de funcionalidades: é criada a lista de funcionalidades com bases nos requisitos, contendo informações detalhadas do que deve ser desenvolvido.
- Planejar por funcionalidade: é feito a ordenação das funcionalidades pelo programador chefe em pacotes para facilitar a liberação ao cliente, e a distribuição para os programadores (donos das classes).
- Modelar por funcionalidade: os programadores chefes selecionam conjuntos de funcionalidades e montam pequenas equipes que trabalham em paralelo sobre seu comando.
- Implementar por funcionalidade: é feito o desenvolvimento, testes e inspeções no código. Assim que as funcionalidades desenvolvidas forem validadas pelo programador chefe são integradas ao projeto principal e é dado inicio a outro conjunto de funcionalidades.
Essa metodologia também possui um conjunto de oito práticas recomendadas, que combinadas, aumentam a integração e o entendimento do projeto (BASSI FILHO, 2008), são elas: modelagem de domínio de objetos, desenvolvimento por funcionalidade, propriedades de classes, equipes por funcionalidade, inspeções, versões com regularidade, gerenciamento de configuração e relatórios de progresso.
Extreme Programming (XP) A metodologia XP foi criada por Kent Beck em 1996. Esse método foi resultado de um projeto crítico na empresa Chrysler, ela possuía um sistema de folha de pagamento com sérios problemas de custo e prazo, que após a aplicação das técnicas de Beck, o projeto que foi iniciado do zero, foi entregue com excelente qualidade e dentro do prazo (BASSI FILHO, 2008).
de um desenvolvimento mais complexo para melhorar o sistema, esse deve ser desenvolvido quando for necessidade do cliente. Por outro lado, a simplicidade não quer dizer desenvolver de qualquer jeito, sem levar em consideração recursos que poderão comprometer o sistema ou o processo do cliente no futuro.
- Coragem: diferentemente do desenvolvimento tradicional, na metodologia XP, muitos requisitos podem aparecer durante o desenvolvimento, que nesse caso, os desenvolvedores devem ter a coragem de enfrentar processos complexos ou de alto risco, mesmo que inicialmente o cliente não deseje tais desenvolvimentos, visto que pode existir quebra de cultura ou paradigmas em que o cliente está inserido.
- Feedback: esse valor enfatiza o feedback do cliente assim que cada parte do sistema é liberada, para que haja uma sinergia entre desenvolvimento e cliente.
- Respeito: o respeito deve estar presente em todas as relações com o grupo e com os clientes, ações como: discriminar alguém que tenha posição inferior ou pela forma como trabalha, pode provocar reações negativas irreversíveis, desfocando os objetivos do projeto e tirando a sinergia do grupo.
Práticas No primeiro livro de Beck foram propostas doze práticas, que transformam os valores em ações e segundo ele, devem ser seguidas (BASSI FILHO, 2008), são elas: versões pequenas, jogo do planejamento, design simples, programação em pares, testes, refatorações, integração continua, propriedade coletiva do código, ritmo sustentável, cliente presente, metáfora e padrões de código.
Uma consideração importante sobre a prática de teste, ou desenvolvimento guiado por teste, essa prática sugere que toda funcionalidade
tenha um teste automatizado (testes unitários), em algumas situações é necessário o teste por aceitação, que são aprovados pelo cliente.
Após algum tempo, grupos que utilizam essa metodologia entenderam que era necessário uma adaptação dessas práticas, pois não era possível sua aplicação integral, desta forma, essas práticas foram reformuladas e derem origem a dois grupos chamados: práticas primárias e práticas corolário.
As praticas primárias são descritas por treze práticas que ajudam na introdução da metodologia, são elas: integração contínua, programação em pares, trabalho energizado, desenvolvimento dirigido por testes, sentar junto, time completo, área de trabalho informativa, histórias, ciclo semanal, ciclo trimestral, folga, build ágil e design incremental.
As práticas corolário, divididas em onze, são de aplicação mais difícil, principalmente sem ter aplicado as práticas primárias, são elas: código compartilhado, envolvimento real com o cliente, implantação incremental, continuidade da equipe, redução da equipe, análise de causa inicial, código e testes, repositório de código unificado, implantação diária, contrato de escopo negociável e pague-pelo-uso.
Papéis Os papéis são importantes dentro da equipe, porém não necessariamente todos precisam coexistir ou serem atribuídos as mesmas pessoas, Beck descreveu em seu livro os seguintes papéis (BASSI FILHO, 2008) e (SBROCCO; MACEDO, 2012):
- Gerente de projeto: é quem administra o projeto, quem remove impedimentos, promove a comunicação necessária entre equipe e cliente.
- Analistas de negócio: é quem faz o levantamento dos requisitos justamente com o cliente e ajuda-o a definir as histórias.
- Arquiteto: analisa a estrutura do sistema e propõe alterações.
- Gerente de produto: é quem escreve as histórias e estabelece os ciclos de desenvolvimento.
Papéis São divididos em três:
- Scrum Master: é o facilitador, promove a comunicação de todos os envolvidos, representa o cliente no projeto, remove impedimentos durante o desenvolvimento, ajuda o Product Owner a tomar as melhores decisões na condução do projeto e mantêm o foco da equipe. Esse papel tem obrigação de verificar se os processos da metodologia Scrum são seguidos.
- Product Owner: ou simplesmente, dono do produto, é quem transforma necessidades em valores de negócio para o cliente, neste caso, representando-o. Tem a função de atualizar o Product Backlog, definir as prioridades com base no ROI (Return of Investment), definir a data de liberação do produto e aprovar ou reprovar os desenvolvimentos.
- Equipe Scrum: é a equipe de desenvolvimento, normalmente possuí de cinco a nove pessoas, essas pessoas devem ter habilidades para analisar, desenvolver, testar, entre outras. Não deve haver uma distinção de níveis ou atribuições, a atenção deve estar voltada para o projeto, não pode ser trocado integrante durante a sprint. Suas tarefas principais são: estimar os tempos, dividir os itens da Sprint Backlog em tarefas, garantir qualidade, apresentar os resultados ao Product Owner.
Cerimônias Ao longo da sprint existem pelo menos quatro cerimônias (reuniões):
- Sprint Planning Meeting: reunião de planejamento da sprint, com duração de no máximo oito horas, é feito a seleção da lista do Product Backlog pelo Product Owner que define a meta, posteriormente a equipe define o Sprint Backlog (detalhamento em tarefas) para cumprir a meta estabelecida. Todos os envolvidos participam dessa reunião.
Como no Scrum não tem a definição de tempo das tarefas, e sim do tamanho delas, existem uma técnica que pode ser utilizada para medir o tamanho das tarefas, é o Planning Poker ou pôquer do planejamento.
Nessa técnica a equipe senta ao redor de uma mesa e o facilitador apresenta a funcionalidade que deve ser desenvolvida, após o entendimento de todos sobre a tarefa em questão, cada membro escolhe uma das cartas e coloca na mesa virada para baixo, assim que todos escolherem as cartas, elas são apresentadas e a equipe e essa deve chegar a um consenso entre os valores, em que cada integrante pode expor os motivos pela seleção e assim convencer o restante da equipe, assim que houver consenso o número selecionado é associado à funcionalidade. Essa mesma sequência é feita com todas as funcionalidades da SprintBacklog.
Figura 5 - Cartas do pôquer do planejamento.
Existem cartas especiais, como por exemplo, a zero que significa que a funcionalidade tem um tamanho insignificante e que levaria minutos para ser realizada, a carta com interrogação indica que o integrante não tem noção de quanto tempo levaria para a tarefa ser realizada e por último a xícara de café, que sugere ao grupo uma pausa, pois existe um cansaço que pode
