Metodologia XP (eXtreme Programming) – Modelos tradicionais

Por / Extreme Programming

Esta série de artigos sobre Metodologia XP de desenvolvimento é uma versão compacta do trabalho de conclusão de curso (TCC) onde o título original da monografia em que foi baseada esta série é:

O USO DA METODOLOGIA XP NO DESENVOLVIMENTO DE SOFTWARE E OS IMPACTOS NA GESTÃO DE RISCOS

Toda semana, sempre às segundas-feiras, postaremos uma parte ou capítulo da monografia, o que totalizará 10 semanas de postagens. No capitulo de hoje, abordaremos o tópico “Modelos tradicionais de desenvolvimento” para entendermos como as equipes de desenvolvimento trabalhavam e quais são as características que estão defasadas para o atual cenário que vivemos no mercado de desenvolvimento de software.

Sumário do artigo “Metodologia XP”:

Metodologia XP ( eXtreme Programming )

Modelos tradicionais de desenvolvimento

Conforme apresentado anteriormente, qualidade de software está diretamente relacionada com qualidade de processo, que pode ser definido grosseiramente como os métodos utilizados pela equipe de desenvolvimento de software.

A seguir, serão abordados alguns dos processos tradicionais de desenvolvimento criados pela Engenharia de Software a partir da década de 70.

Modelo em cascata

Segundo Pressman (2006), o modelo em cascata foi o primeiro paradigma de desenvolvimento criado pela Engenharia de Software, que teve sua essência retirada de outras áreas da Engenharia. Mas, conforme é descrito ao longo desse trabalho, a construção de software não pode ser comparada a produção de produtos manufaturados, pois o software é o resultado de um processo de criação e não de fabricação. Para Pressman (2006) o modelo em cascata sugere uma abordagem linear e seqüencial de todas as atividades envolvidas no desenvolvimento de software, e por se tratar de uma seqüência de eventos, esse modelo também ficou conhecido como “ciclo de vida” do software.

Os estágios do modelo em cascata e a seqüência com que esses eventos são executados são ilustrados na Figura 3 abaixo:

Ciclo de vida de um software
Figura 3 – Modelo em cascata

Adaptado de: Pressman (2006); Pfleeger (2004)

Definição dos requisitos – Segundo Pfleeger (2004), os requisitos são características de algo que o sistema será capaz de realizar para atingir determinado objetivo. Para isso, a equipe de desenvolvimento deve questionar o cliente sobre a forma que o sistema deve ser para satisfazer as suas necessidades. Em seguida a equipe deve registrar esses requisitos em um documento de tal maneira que clientes e desenvolvedores cheguem a um acordo sobre como o sistema deve ser.

Projeto de Software – Os requisitos são um conjunto de problemas que o sistema deve resolver para o cliente e com base nesses requisitos, a equipe de desenvolvimento deve, antes de codificar, projetar uma solução que satisfaça as necessidades do cliente (PFLEEGER, 2004).

Desenvolvimento – De acordo com Pressman (2006), a atividade de desenvolvimento consiste em transformar, através de técnicas de programação, o projeto de software em um produto executável e operacional.

Testes de sistema – Ainda citando este autor, os testes são um processo de execução de um programa que têm como objetivo revisar a codificação implementada e encontrar erros na estrutura do software.

Implantação – Implantação compreende a entrega do software para o cliente e a utilização do usuário final. Nesse momento, o cliente tem a oportunidade avaliar se o software atende às suas necessidades e em caso de não conformidades, a equipe deve registrar as modificações necessárias para dar início à manutenção do software (PRESSMAN, 2006).

Segundo Pfleeger (2004), todo o processo começa com as especificações dos objetivos com o cliente, e nenhum outro estágio é iniciado antes do término do seu antecessor, pois cada estágio envolve um ou mais documentos que devem ser aprovados e assinados para que seja autorizado o início do próximo.

Para Pressman (2006), esse método de desenvolvimento apresenta vários problemas. O principal é que em uma equipe de desenvolvimento, alguns membros necessitam esperar o término do estágio anterior pra começar a trabalhar, e por mais que o gerente tente administrar sua equipe para que isso não aconteça, é inevitável que algum dia membros da equipe fiquem ociosos por terem que esperar que outros completem suas tarefas.

Além disso, há outros problemas que segundo Pressman (2006) a modelagem em  cascata pode acarretar:

“… projetos reais raramente seguem o fluxo seqüencial que o modelo propõe…” (PRESSMAN, 2006, p.39).

O modelo em cascata não possui a flexibilidade que uma equipe de desenvolvedores necessita, muitas vezes, no meio do desenvolvimento o cliente percebe algum item que ficou faltando nos requisitos. Essas mudanças não são tratadas no modelo em cascata e na maioria das vezes causa confusão à medida que a equipe prossegue com o projeto.

“… em geral, é difícil para o cliente estabelecer todos os requisitos explicitamente…” (PRESSMAN, 2006, p.39).

Raramente um cliente que contrata uma equipe para desenvolver um software sabe exatamente o que quer de um software. O cliente sabe que precisa, mas não faz ideia de como explicar detalhadamente a forma como deve ser esse software para atender suas necessidades.

Essa incerteza do cliente se torna uma barreira para o modelo em cascata, uma vez que modelo necessita que todas as informações e requisitos sejam definidos logo no início do projeto.

“… cliente precisa ter paciência…” (PRESSMAN, 2006, p.39).

Como nenhum estágio pode ser iniciado antes do seu antecessor, a “produção visível” do software é demorada e o cliente precisa ter muita paciente até que a equipe projete, desenvolva, implante e teste o software completamente.

Modelo incremental

Nos primeiros anos de desenvolvimento de software, alguns projetos demoravam vários anos para serem entregues. Evidentemente que, atualmente, isso não é mais aceito devido ao mercado concorrido e a economia super aquecida do mundo globalizado. Segundo Pfleeger (2004), uma solução para reduzir o tempo de entrega do software foi passar a projetar o mesmo em pequenas partes e entregar para o cliente ao término de cada fase do projeto. Dessa forma, o usuário pode experimentar, mesmo que aos poucos, os recursos e funções que o software terá ao final do desenvolvimento.

Na verdade, o modelo incremental combina os elementos do modelo em cascata de forma iterativa. Cada iteração é uma seqüência linear que produz um subproduto de um sistema. O primeiro incremento é freqüentemente chamado de núcleo de produto, que possui os requisitos básicos do sistema para que o cliente possa avaliar e elaborar os próximos incrementos que melhor satisfaçam as suas necessidades (PRESSMAN, 2006).

A seqüência do modelo incremental pode ser ilustrada como a figura abaixo:

Ciclo de vida de um software
Figura 4 – Modelo incremental

Adaptado de: Pressman (2006); Pfleeger (2004)

Prototipagem

Para Pressman (2006), a Prototipagem é comumente utilizada como uma técnica aplicada em outras metodologias de desenvolvimento e tem seu fundamento na construção rápida de vários protótipos que são descartados à medida que os novos protótipos são melhores que seus antecessores. Os primeiros protótipos concentram-se unicamente na representação dos aspectos que estarão visíveis para o cliente. Dessa forma, é possível implantar rapidamente um protótipo que será avaliado, e então o feedback produzido é usado para refinar os requisitos do software e construir um novo protótipo com mais recursos que atendam a necessidade do cliente.

Segundo Pfleeger (2004) um protótipo é construído com a finalidade de ajudar a entender melhor as necessidades do cliente e explorar a viabilidade das possíveis soluções. Neste protótipo não há nenhuma pretensão de utilizá-lo como parte real do sistema a ser entregue, por isso o protótipo é descartado e inicia-se a construção de um novo. No entanto, Pressman (2006) afirma que o emprego de protótipos pode ser problemático, pois o cliente vê uma versão de seu software em funcionamento, mas ignora o fato de que foi construído na pressa de fazê-lo rodar e que, conseqüentemente, ninguém considerou a qualidade do código fonte. Em alguns casos, o cliente não aceita o fato de descartarem o protótipo, que aparentemente funciona, para construírem um novo com altos níveis de qualidade. Então, o cliente exige “alguns consertos” para transformar o protótipo no produto final e na maioria das vezes a gerência de desenvolvimento do software, mesmo discordando, acaba por fazer a vontade do cliente.

Continue lendo essa série de artigos sobre em Metodologia XP ( eXtreme Programming ) – Desenvolvimento Ágil

Observação: Todos as referências serão creditadas no último artigo da série.