A Evolucao dos Processos de Desenvolvimento de Software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
29,780
On Slideshare
29,651
From Embeds
129
Number of Embeds
1

Actions

Shares
Downloads
854
Comments
0
Likes
4

Embeds 129

http://www.slideshare.net 129

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A Evolução dos Processos de Desenvolvimento de Software Resumo O desenvolvimento de software passou por sensível melhora com o crescimento da Engenharia de Software. O primeiro processo formal estabelecido foi o Cascata, que significou um salto qualitativo para o desenvolvimento de software. Atualmente, há processos de desenvolvimento de software melhores que o processo Cascata, mas este continua sendo o mais utilizado, pois a mudança exige adaptações na forma de trabalho e na cultura das empresas. 1. Engenharia de Software – Processos de Software Mal o homem começou a produzir software, já se deparou com uma série de problemas de qualidade e com uma demanda maior que a capacidade produtiva. A solução foi introduzir conceitos de engenharia a esse trabalho. Assim, consolidou-se a Engenharia de Software que, com a introdução de metodologias e ferramentas, proporcionou condições para a melhoria da qualidade do produto.Pela primeira vez, falou-se em um processo de desenvolvimento de software. No dicionário Michaelis, uma das definições de processo é “maneira de operar, resolver”. Assim, processo de desenvolvimento de software é a maneira como se produz software. 2. Processos Cascata O primeiro processo criado foi o modelo Cascata (ou waterfall). Esse processo estabeleceu um ciclo de vida básico para o desenvolvimento de um software. Esse ciclo é formado por etapas que dividem o trabalho de
  • 2. desenvolvimento de software em etapas claras, conforme demonstrado na figura 1. Isso trouxe alguma organização para as equipes de desenvolvimento e, também, para os usuários, que passaram a ter que definir melhor suas solicitações, antes de ver iniciado o trabalho de codificação de programas. O ciclo de vida Cascata é bastante utilizado atualmente e, apesar de ter ajudado muito a organizar o desenvolvimento de software, traz consigo uma série de problemas. Figura 1: O ciclo de vida Cascata (PRESSMAN, 1995). 3. Problemas com o Ciclo de Vida cascata O processo Cascata tem muitas qualidades, mas nem sempre é possível aplicá-lo na íntegra, por vários motivos. O modelo tem algumas desvantagens que serão discutidas a seguir. A maioria dos problemas está ligada aos requisitos do software que se vai construir. Segundo Pressman (1995), as principais críticas a esse modelo são:
  • 3. a) Os projetos raramente seguem o fluxo seqüencial, gerando, por vezes, iterações; b) É muito difícil para o cliente declarar todas as suas necessidades corretamente e de forma clara logo no início do projeto; c) Decorre muito tempo entre o início do projeto e a disponibilização de uma primeira versão minimamente utilizável do sistema (durante esse período, os requisitos podem sofrer modificações ou mesmo deixar de fazer sentido); d) O risco de insucesso é alto, visto que, se um erro de grande impacto for cometido e não detectado, provavelmente só será descoberto muito tarde - o que pode ser desastroso para o projeto. O ciclo Cascata presume que o projeto terá uma seqüência correta, sem desvios e sem problemas. Nesse ponto, temos outra grande deficiência dele: não considera riscos que podem impactar negativamente e até mesmo inviabilizar o projeto. 3.1. Requisitos Dos motivos destacados por Pressman, o maior foco está no tratamento de requisitos. Sobre isso, Sommerville (2003) destaca que os acordos com os clientes devem ser feitos em um estágio inicial do processo de desenvolvimento em que, geralmente, os requisitos são desconhecidos ou não são claros. Quando esses requisitos são alterados posteriormente, causam impacto negativo no produto de software, que deve ser refeito, ao menos em parte. Assim, Sommerville aconselha a só utilizar esse modelo quando os requisitos forem bem compreendidos. Embora o ciclo de vida Cascata constitua uma abordagem melhor que a abordagem casual (abordagem livre, antes da Engenharia de Software), a
  • 4. forma altamente dinâmica como se desenvolve software exige um processo mais ágil e dinâmico. 4. Ciclo de Vida Espiral O Ciclo de Vida Espiral traz uma alternativa interessante a esse problema, pois divide a tarefa de levantar requisitos em etapas que não ocorrem todas de uma vez, no início do desenvolvimento. O modelo Espiral mantém como princípio as mesmas etapas do modelo Cascata. Porém, elas são executadas várias vezes ao longo do ciclo de desenvolvimento do software (uma vez para cada pacote de desenvolvimento). A figura 2 ilustra essas etapas. O centro da figura assinala o início do desenvolvimento. À medida que o desenvolvimento ocorre, caminha-se, na espiral, para sua parte mais externa, passando pelas disciplinas de desenvolvimento várias vezes. O efeito dessa forma de trabalho são entregas parciais de software para o cliente, em vez de uma entrega única ao final do processo.
  • 5. Figura 2 – Ciclo de Vida Espiral (SOMMERVILLE, 2003). Essa divisão do desenvolvimento em pequenos pacotes, como se fossem subprojetos, é uma boa alternativa ao problema com requisitos, que são tratados (capturados, especificados e validados) em vários estágios e não em um estágio único, permitindo revisões do usuário à medida que o desenvolvimento avança. Certamente, é mais fácil para todos vislumbrar os requisitos à medida que o projeto ganha maturidade. Nesse modelo, não é necessário detalhar todos os requisitos no início do desenvolvimento. São identificados os pontos principais e separados em pacotes de trabalho. Após a priorização dos pacotes, apenas o primeiro será detalhado e desenvolvido. Após a entrega deste, os próximos, um por vez, terão seus requisitos detalhados e serão desenvolvidos. O candidato mais forte a primeiro pacote a ser desenvolvido é aquele que contém a funcionalidade principal do sistema com seus cadastros básicos. Por exemplo, em um sistema de informações comerciais, a essência
  • 6. é registrar o pedido do cliente. Consultas, relatórios, cálculos estatísticos e contabilizações, ficam para um momento posterior. Isso tem uma lógica: se o primeiro pacote tiver sucesso, os demais que dependem dele terão grandes chances de serem bem sucedidos, pois partem de uma base sólida. Se esse primeiro pacote não estiver bom o suficiente, é possível corrigi-lo e aperfeiçoá-lo antes de iniciar o desenvolvimento dos demais (caso contrário, os problemas com ele seriam propagados para os demais pacotes do sistema e, muitas vezes, podendo potencializar os problemas). 5. Ciclo de Vida Iterativo-Incremental O modelo Espiral surgiu na década de 80. Outros processos foram criados baseados nele. O mais famoso é o Processo Unificado, desenvolvido após 1995, com a junção do Processo Objectory com a abordagem da Rational. O Processo Unificado é mais recente e teve mais penetração no mercado que o próprio modelo Espiral. O Processo Unificado é o típico modelo Iterativo-Incremental.Iterativo significa repetição (não confundir com INteração). Como o dicionário Michaelis define, iteração significa “feito ou repetido muitas vezes”. Iterar é o ato de fazer uma ou mais coisas repetidas vezes, como em um loop dentro de um programa, em que um trecho de código é repetido várias vezes. Os princípios do Modelo Iterativo são os mesmos do Modelo Espiral: dividir o trabalho em pacotes de trabalho menores, ordenar por prioridades, desenvolvendo e implantando um pacote por vez. Quanto ao termo Incremental, como o software é entregue aos poucos para o cliente, cada entrega significa aumento, ou incremento, em relação ao cenário anterior.
  • 7. O Processo Unificado é o mais famoso entre os Iterativo-Incrementais. Esse processo de desenvolvimento de software divide seu trabalho em Fases e Disciplinas, como em uma matriz. A figura 3 demonstra as fases (no topo, na horizontal) e as disciplinas (coluna à esquerda, na vertical) do processo Unificado. FASES Concepção Elaboração Construção Transição D I Requisitos S C Análise I P Design L I Implementação N A Testes S Iter. Iter. _ _ _ _ _ Iter. Iter. #1 #2 #n-1 #n Figura 3 – Processo Unificado, fases X disciplinas X trabalho realizado (JACOBSON, 1999). 5.1. Seqüência de trabalho do Processo Unificado A primeira idéia de seqüência temporal é dada pelas fases que ocorrem em seqüência, da esquerda para a direita. Na figura 3, dentro da matriz, vemos áreas de trabalho assinaladas para cada disciplina. Por exemplo, na disciplina de Requerimentos, o trabalho começa na fase de Concepção, tem seu auge entre essa fase e a de Elaboração, reduzindo muito na fase de Construção e ficando ausente na fase de Transição. Isso indica que a disciplina de Requerimentos, mesmo com o desenvolvimento sendo dividido em pacotes, tem mais presença no início que no final de um projeto de software. A figura 3 indica como está distribuído o trabalho das demais disciplinas.
  • 8. 5.2. Fases X Iterações O trabalho de desenvolvimento é executado dentro de cada fase. Assim, quando estamos na fase de Concepção, passamos por todas as disciplinas (descendo na vertical), algumas com mais ênfase e outras com menos. Há uma “segunda rodada” de trabalho (outra iteração), ainda dentro da fase de Concepção - o que caracteriza a segunda Iteração. O foco principal de cada fase vem, justamente, da disciplina que tem mais trabalho concentrado ali. Assim, para as fases abaixo, destacam-se as seguintes disciplinas (como observado na figura 3): - Concepção - requisitos do sistema; - Elaboração - análise e design do sistema; - Construção - implementação em linguagem de programação; - Transição - testes, implantação e documentação do software. O gráfico do Processo Unificado exibido na figura 3 traz uma sugestão de iterações por fase, mas há de se destacar que esse número não é absoluto. Dependendo do porte e complexidade do projeto, a quantidade de iterações dentro de cada fase pode aumentar ou diminuir. Em um projeto muito pequeno, por exemplo, as fases de Concepção e de Elaboração podem constituir uma única iteração. Já em um projeto muito grande ou complexo, a fase de Construção poderia ter cinco iterações.
  • 9. :Ciclo Iniciação Elaboração Construção Transição :Fase :Fase :Fase :Fase Model agem de Negócio:Disciplina Requisito:Disciplina Análise e Projeto :Disciplina Implementação :Disciplina Teste:Disciplina Implantação:Disciplina Figura 4 – distribuição do esforço: fases X disciplinas no modelo Iterativo (ALHIR, 2002). A figura 4 demonstra a seqüência do esforço em um projeto por meio de fases e disciplinas. As setas na vertical indicam a seqüência. Uma fase é executada quando a anterior é concluída. O objetivo é entregar pacotes de software mais constantemente para os usuários, não acumulando toda a entrega para o final.
  • 10. 6. Principais diferenças entre Cascata e Iterativo Uma comparação entre os processos de desenvolvimento de software Cascata e os Iterativo-Incrementais está demonstrada na Tabela 1: Característica Processo Cascata Processo Iterativo Só passamos para a Passamos pela fase várias Indivisibilidade próxima fase após vezes, o que permite das Fases concluirmos 100% da fase refinamento incremental dos atual. artefatos e do sistema. Pode progredir para frente ou para trás por meio das fases, Fluxo de Há progresso serial por para mudar o foco e envolver Trabalho meio das disciplinas. várias disciplinas, a fim de endereçar o risco. Não oferece Oferece oportunidades claras oportunidades claras para para entregas parciais de um entregas parciais de um sistema ao final de uma Reação às sistema ou para a iteração, permitindo a Mudanças introdução de mudanças introdução de mudanças no dentro do ciclo de vida. É, ciclo de vida ao final de uma portanto, reativa a iteração e antes da próxima. É, mudanças. portanto, proativa a mudanças. Tabela 1 – Principais diferenças entre processo Cascata e Iterativo 7. Vantagens dos Processos Iterativos O processo Iterativo, ao entregar pacotes de software com mais constância para os usuários, possibilita que estes dêem feedback mais cedo
  • 11. sobre o produto de software que receberam. No processo Cascata, esse feedback só aconteceria tardiamente, quando os usuários tivessem contato com o software, ou seja, de maneira parcial, na fase de testes, e, total, na entrega final. Essa característica confere uma série de vantagens ao processo Iterativo sobre o Processo Cascata. São elas: • Antecipa mudanças; • Controla riscos; • Foca o desenvolvimento no produto do cliente; • Aumenta a qualidade do produto final. 71. Antecipa Mudanças Se há um erro no projeto, quanto antes ele for descoberto e corrigido, menor será o impacto e menor será o custo para a correção necessária. Corrigir um erro significa, em geral, refazer uma parte ou todo o trabalho até aquele ponto, ou seja, gera retrabalho e, conseqüentemente, mais custo para o projeto. Custo de Alteração em um processo de software Custo Tempo Figura 5 – Custo das Mudanças ao longo do Ciclo de Desenvolvimento. Quanto mais tardia a correção for disparada, maior será o retrabalho e, inevitavelmente, maior o custo da correção. A figura 5 mostra um esboço do
  • 12. aumento do custo para se efetuarem alterações no software ao longo do tempo em que o sistema está sendo desenvolvido. As mudanças devem vir o quanto antes no projeto. Em um processo Iterativo, a captura dos requerimentos é feita parcialmente, a cada iteração. É comum que os clientes solicitem alterações ou inspirem-se com novas idéias, quando se entregam versões de software (ainda que reduzidas). No momento em que o usuário recebe parte da solução, começa a vislumbrar algumas funcionalidades que não havia considerado anteriormente. Assim, conforme Kroll, 2001, devem-se encorajar as mudanças, pois a abordagem iterativa foi otimizada exatamente para isso. Entretanto, essas transformações devem ser gerenciadas para que aconteçam no tempo adequado. 7.2. Controla Riscos Ao desenvolver um projeto de software, a preocupação com os riscos deve ser constante. Risco é tudo aquilo que pode atrapalhar o desenvolvimento de um projeto ou, até mesmo, levar a seu cancelamento. A ocorrência de um risco pode atrasar o projeto, aumentar seu custo, alterar a qualidade do produto final. Assim, é necessário atacar os riscos antes que eles possam, de alguma forma, com intensidade maior ou menor, impactar o projeto. Se seguirmos com o projeto sem avaliar e endereçar seus riscos, podemos estar investindo em esforços que podem não nos trazer o retorno esperado. O modelo Cascata não trata os riscos diretamente. No modelo Iterativo, como temos iterações, ou seja, fases repetitivas, os riscos do projeto são avaliados a cada nova iteração. Ainda, o fato de termos entregas parciais ajuda na redução do risco, pois, uma vez que o módulo ou parte do software é aprovado e instalado, deixa de haver o risco de rejeição.
  • 13. A figura 6 mostra dois gráficos comparando a redução do risco ao longo do processo de desenvolvimento para os modelos Cascata e Iterativo. Desenvolvimento Cascata Cascata X Iterativo Figura 6 – Risco do projeto ao longo do ciclo de desenvolvimento (RUP, 2000). No Ciclo de Vida Cascata, não se pode verificar se um risco está claro até um ponto tardio do Ciclo de Vida. Assim, no primeiro gráfico da figura 6, o risco só começa a cair quando se chega à fase de testes do sistema.
  • 14. Já no segundo gráfico da figura 6, a curva de riscos do Cascata está comparada com a curva do Ciclo de Vida Iterativo, que mostra queda do risco bem mais acentuada que no processo Cascata, devido às entregas parciais e às constantes reavaliações da lista de riscos do projeto. As entregas parciais de funcionalidades permitem o feedback dos usuários e as correções, se houver. Isso aumenta a chance de sucesso do projeto. No processo Iterativo, a cada iteração, deve-se fazer uma pausa e considerar quais são os riscos envolvidos naquele momento e nas etapas seguintes. Quanto mais se antecipam os riscos, menor a chance de sua ocorrência. Nesse processo, podemos selecionar qual incremento desenvolver em uma iteração a partir de uma lista de riscos-chave. Como cada iteração produz um executável testável, é possível verificar se o risco foi mitigado ou não, e se ele foi ou não bem aceito pelo cliente. Os riscos são mais bem tratados no processo Iterativo, pois são revistos a cada iteração. 7.3. Foca o desenvolvimento no produto do cliente Em um projeto de desenvolvimento, além do produto final entregue aos clientes, é comum a produção de artefatos intermediários. Cada processo de desenvolvimento de software sugere seus próprios artefatos, mas, geralmente, não mudam, de forma radical, de um processo para outro. A idéia, aqui, é gerar o menor número possível de artefatos intermediários, ou seja, direcionar o máximo de esforço para o artefato principal: o produto de software que será entregue ao usuário. Alguns artefatos podem ser estrategicamente indispensáveis durante o desenvolvimento de um projeto, mas, “para qualquer projeto, devemos nos
  • 15. esforçar para reduzir o número de artefatos produzidos a fim de reduzir o desperdício”. (KROLL, 2001). Focar os esforços no produto final reduz o desperdício do projeto. O foco no software executável, conforme Kent Beck (2000) é a melhor forma de verificar como está o andamento do projeto e de se manter concentrado em entregar ao cliente o que realmente ele necessita, direcionando menos esforço para outras atividades acessórias. 7.4. Aumenta a qualidade do produto final Se, de um lado, as mudanças podem ser um obstáculo para os que desenvolvem e para os que controlam prazo e orçamento do projeto, elas podem também indicar que o produto de software está passando por ajustes e vai, paulatinamente, aproximando-se da solução ideal para o cliente. É uma outra forma de olhar para as mudanças em um projeto de software. Mudanças permitem melhorar a solução de software. É importante entender que as mudanças fazem parte de um projeto de desenvolvimento (raramente um projeto tem todos os requerimentos, análise e design sem mudanças ao longo do Ciclo de Vida do Desenvolvimento). 8. Por que o processo Cascata é o mais utilizado Se os modelos iterativos, como o Processo Unificado, são melhores que o processo Cascata, então por que este é, ainda, o mais utilizado? Certamente, o primeiro motivo é porque é muito mais fácil para os que desenvolvem e para os que usam entenderem a seqüência do modelo Cascata do que a dinâmica dos modelos Iterativos.
  • 16. Além disso, a aplicação de modelos espirais exige treinamento e mudança cultural. Deve haver sinergia muito maior entre os que usam e os que desenvolvem do que se costuma ter (o processo Cascata também exige isso, mas, no modelo Iterativo, é essencial). Para utilização de um processo iterativo, os usuários devem ter grande confiança naqueles que desenvolvem, a comunicação deve ser intensa e o projeto deve ter uma gerência capaz de controlar as características de um projeto iterativo (essa gerência, por si só, é um capítulo à parte). Se a gerência do projeto não for adequada, corre-se o risco de perder o foco das iterações, gerando-se iterações desnecessárias, em nome do refinamento incremental -o que prolongaria, em demasia, o projeto e, aí sim, consumiria muito mais tempo e orçamento do que o planejado. No processo Iterativo, é importante não perder o foco do trabalho a realizar. Aumentos de escopo devem ser tratados e aprovados devidamente, aliados com os ajustes nas previsões de custo e prazo. Todavia, o fator cultural é ainda o preponderante. A inércia dos processos instalados nas empresas traz resistência às mudanças. O conceito popularmente conhecido como “eu sempre fiz desse jeito” mostra o quanto é difícil convencer alguém a mudar. Nesses casos, a mudança cultural deve vir de cima, patrocinada pelo alto escalão da empresa, que deve ser convencido de que o novo modo de trabalho é vantajoso. Conclusão Apesar de suas deficiências, o modelo Cascata é de fácil compreensão para os que usam e para os que desenvolvem e, se for bem trabalhado, pode trazer, ainda, resultados muito satisfatórios para a empresa. Mesmo com tantas vantagens, os modelos Iterativos não permitem aplicação imediata sem treinamento e aculturação prévios. Deve haver grande entrosamento das partes envolvidas e é necessário que esteja muito
  • 17. claro para todos a nova forma de trabalho. Se isso não estiver bem entendido, o projeto tende ao fracasso. Nesse caso, é melhor a utilização do tradicional processo Cascata. Considerado esse panorama, vale a pena aprofundar o conhecimento sobre os processos iterativos, investindo tempo para conhecê-lo e empregá- lo em projetos-piloto, visto que suas vantagens são bastante consideráveis.