Esta lição permitirá que você compreenda os diferentes métodos de desenvolvimento de software e em que momento um ou outro método pode ser melhor aplicado. A compreensão das metodologias (formas de fazer) de desenvolvimento de um software é importante porque permitirá que você siga conhecimentos já validados e evite o desenvolvimento de softwares de baixa qualidade.

O ciclo de vida clássico de desenvolvimento de um sistema segue uma sequência em que se inicia no levantamento de requisitos, passa pela etapa de análise, projeto, codificação, testes e manutenção. Essas etapas são realizadas, linearmente, ou seja, uma só inicia após a outra ser finalizada.

Assim, eu lhe pergunto: Existe algum problema em seguir esta sequência no desenvolvimento de um software? A resposta é sim. O ciclo de vida clássico apresenta um grave problema devido à sua ordem fixa de execução das tarefas. O principal problema está na necessidade de se estabelecer todos os requisitos na fase de levantamento de requisitos ou análise. Qualquer mudança nos requisitos forçará você, projetista do software, a voltar no processo de desenvolvimento e refazer tudo que já foi realizado.

Observe as Figuras 1 e 2 a seguir, que representam os modelos clássicos de desenvolvimento de sistemas:

Conforme discutido, o problema está na necessidade de se identificar TODOS os requisitos no início para só então dar continuidade no processo de desenvolvimento do software. Esta abordagem sofre com o problema da mudança dos requisitos na etapa da implementação e ter a necessidade de mudar o sistema em termos de codificação, pois ele não permite esta situação. Outro problema está associado à demora na entrega de funcionalidades para os stakeholders (partes interessadas – os principais interessados em ver o sistema pronto – ex.: dono/proprietário da empresa ou um diretor de área que solicitou o sistema) do sistema.

Quando os stakeholders não percebem, rapidamente, uma evolução no desenvolvimento do software – entenda evolução com funcionalidades entregues (ex.: uma tela de cadastro de funcionários, produtos, vendas etc.) – pode haver a percepção de que o software não está sendo desenvolvido, ou que está demorando mais do que deveria demorar.

Para minimizar estas percepções e os riscos associados ao modelo de desenvolvimento clássico, a literatura apresenta abordagens baseadas em protótipos ou por incrementos. Não se preocupe com estes termos se eles forem novidades para você. Discutiremos todos eles na sequência desta lição.

Vamos, agora, definir um cenário associado ao problema do desenvolvimento de software usando a abordagem clássica. João é o analista júnior de uma organização de médio porte, localizada no sul do Paraná. Após uma reunião com o dono da empresa e o gerente da área de vendas (stakeholders), decidiu-se que é necessário desenvolver um sistema de vendas (e-commerce) para que a organização amplie os seus canais de vendas e seja mais competitiva no mercado.

João formou-se recentemente, e a sua disciplina de Análise e Projeto de Sistemas não foi muito boa, apresentando para ele apenas o modelo clássico de desenvolvimento de sistemas que sugere uma abordagem sequencial (prescritiva) de desenvolvimento de software. João segue o processo como aprendeu na escola, inicia pelo levantamento de requisitos junto aos principais stakeholders. Na sequência, João precisa compreender os requisitos funcionais e não funcionais do sistema, mas só quem pode dizer isso a ele são as pessoas diretamente envolvidas no processo central do sistema (os funcionários do Departamento de Vendas).  João realiza entrevistas com os funcionários mais antigos do departamento e com o gerente do setor (de acordo com o que aprendeu em Engenharia de Requisitos). Após quatro semanas de entrevistas, João tem os requisitos funcionais e não funcionais documentados e está pronto para iniciar o projeto do sistema (Modelagem).

João finaliza o projeto do sistema e já está quase terminando a codificação, quando, numa bela manhã, recebe uma ligação do gerente do Departamento de Vendas informando que o processo de Vendas e emissão de notas fiscais foi alterado devido a uma nova legislação imposta pelo estado do Paraná. Além da necessidade de mudança no processo de emissão de notas que João já havia compreendido, projetado e implementado, o gerente de vendas pede a João que o sistema também envie mensagens para o WhatsApp do comprador quando uma compra for realizada.

Diante das mudanças ocorridas, percebe-se que a primeira mudança está associada a um requisito normativo externo (estado do Paraná), e a segunda é interna, da própria organização. João, que estava seguindo o modelo prescritivo (clássico), precisa redefinir a sua documentação de requisitos, conversar novamente com o pessoal de vendas e/ou contabilidade para compreender o novo processo de emissão de notas fiscais e alterar o projeto que não contemplava o envio de mensagens para WhatsApp do comprador. Ou seja, João terá um grande retrabalho porque os requisitos mudaram antes que ele finalizasse o software.

O cenário descrito acima é bastante comum e pode levar o desenvolvimento de um software a atrasos consideráveis na entrega porque exigirá um retrabalho nos processos já executados.

Para minimizar o efeito das mudanças que poderão ocorrer ao longo do desenvolvimento de um software, outras abordagens metodológicas poderão ser realizadas. Vamos a elas.

A prototipagem é um processo que possibilita ao desenvolvedor criar um modelo do software para uma avaliação prévia tanto do cliente quanto do desenvolvedor. É importante lembrar que o protótipo pode tanto ser utilizado para validar os requisitos de software com o usuário quanto para discutir a entrega de funcionalidades parciais. A Figura 3 apresenta o processo de prototipagem. 

De acordo com a Figura 3, o primeiro passo a ser realizado pelo desenvolvedor/gerente de projeto do software é obter os requisitos do software. Nesse momento, sugiro que você use as nossas lições sobre Engenharia de Requisitos. O segundo passo é desenvolver um projeto rápido, que pode ser realizado por meio de um Diagrama de Caso de Uso da UML (veremos mais à frente no curso esse diagrama) ou por meio de uma lista de funcionalidades principais do sistema (requisitos funcionais) (PFLEEGER, 2004; PRESSMAN; MAXIM, 2016).

A terceira etapa do processo é a Construção do Protótipo, que NÃO precisa, necessariamente, ter codificação, pode ser apenas baseado em telas do sistema com campos de formulário. Aqui, nesta etapa, sugiro que você faça uso de ferramentas que lhe auxiliem na criação de protótipos, como o Balsamiq (https://balsamiq.com/) e o FLUIDUI (https://www.fluidui.com/).

A quarta etapa é a Avaliação do Protótipo.  Nesse momento, o desenvolvedor e os principais stakeholders discutem se o protótipo realmente atende ao que foi pensado por parte dos stakeholders. O objetivo aqui é garantir que a implementação do sistema esteja realmente de acordo com as necessidades dos stakeholders. Caso o protótipo seja validado por parte dos stakeholders, a próxima etapa é o desenvolvimento dessa parte do sistema, que chamaremos de incremento. Para a implementação do incremento, seguiremos o modelo incremental, conforme Figura 4.

O modelo da Figura 4 sugere cinco etapas (Comunicação, Planejamento, Modelagem, Construção e Implantação) que relacionam a entrega do incremento e o tempo decorrido do projeto (PFLEEGER, 2004; PRESSMAN; MAXIM, 2016). O objetivo é realizar entregas de partes do software (pequenos requisitos funcionais) em curtos intervalos de tempo. Após a validação do incremento, por meio da Prototipação, você como desenvolvedor ou gerente do projeto segue para as fases de modelagem, construção (codificação) e implantação da funcionalidade.

A ideia central, aqui, é minimizar o problema de se passar um tempo muito longo sem que os stakeholders recebam partes do software funcionando. Ao contrário da abordagem clássica, o objetivo do modelo incremental é entregar parte do software rapidamente, mesmo que ainda não se tenha todos os requisitos ou todo o projeto do software pronto. Esta é uma forma de evitarmos retrabalho quando um requisito for alterado. Caso haja alteração, apenas aquele incremento entregue será alterado, e não todo o projeto.

Por fim, mas não menos importante, temos o Modelo Espiral, que, assim como o modelo incremental, tem cinco etapas (Comunicação com o Cliente; Planejamento; Análise de Riscos; Engenharia, Construção e Liberação; e Avaliação do Cliente). 

O modelo espiral foi criado para se minimizar o desenvolvimento de softwares que custavam muito em termos financeiros e demorava muito tempo para ser entregue. A novidade nesse modelo está na etapa de Análise de Risco. A cada ciclo da espiral é realizada uma análise do risco de continuar o desenvolvimento daquele software.

Atente-se para o fato de que o modelo espiral NÃO é sugerido para softwares pequenos, mas é bastante aplicado em sistemas de grande porte que exigem uma alocação de recursos financeiros considerável, assim como grandes equipes. A ideia central do modelo é evitar que se inicie desenvolvimento de um software e, após um longo período, se percebe que aquele não é mais útil, ou que ele está consumindo muito mais recurso do que foi inicialmente pensado.

Assim, após a comunicação com o cliente e a identificação dos principais requisitos funcionais, há um planejamento inicial do software (pode-se desenvolver aqui um Diagrama de Caso de Uso da UML – veremos em Lições posteriores). O objetivo da fase de planejamento é compreender as demandas do software e o esforço necessário para que ele seja desenvolvido. Logo após esta etapa, é realizada a Análise de Riscos, quando será verificado se as demandas necessárias para o desenvolvimento do software (saída da etapa de Planejamento) podem ser suportadas pela organização.

Um exemplo do cenário anterior seria o Departamento de Vendas solicitar um grande sistema de e-commerce para o Departamento de Tecnologia da Informação, mas este possui poucos funcionários, sem treinamento e os recursos financeiros disponíveis não permitem a contratação de novos funcionários e posterior treinamento. Nesse caso, a etapa de Análise dos Riscos pode identificar que não é viável desenvolver o software de e-commerce na própria organização porque comprometeria ou demandaria recursos que não existem. A solução aqui seria buscar, no mercado, um software que atenda aos requisitos funcionais e aos não funcionais da demanda do Departamento de Vendas.

É importante destacar que, independentemente do software ser desenvolvido internamente na empresa, ou for comprado no mercado, a Engenharia de Requisitos (identificação dos requisitos funcionais e não funcionais) deverá ocorrer. Caso contrário, corre-se o risco de adquirir um software que não atende às demandas da organização.

Nesta lição, aprendemos que há diferentes métodos (caminhos) para o desenvolvimento de um software, e que o melhor método é aquele que melhor se adequar às características da organização e ao problema proposto. Organizações menores e departamentos de tecnologia da informação pequenos, sem muita experiência em desenvolvimento de software, devem considerar uma análise de risco antes de iniciar o desenvolvimento. Talvez seja mais adequado comprar um software do que desenvolvê-lo. Caso se decida por desenvolver o software na própria organização, o uso de protótipos e o modelo incremental podem ser opções interessantes porque esses modelos permitem entregas de software em funcionamento em curtos períodos, minimizando o risco de alteração nos requisitos com consequente retrabalho.

Caso você esteja trabalhando em uma organização em que práticas de Engenharia de Software já são consolidadas, e grandes softwares são desenvolvidos, pode haver maior uso do modelo em Espiral ou mesmo uma mescla dos modelos baseados em incremento e o espiral. A mescla de métodos de desenvolvimento de software precisa ser realizada com bastante cuidado porque exige um conhecimento prévio das características (prós e contras) de cada um deles. Essa discussão será feita em lições posteriores.

Clique aqui, teste seus conhecimentos sobre esta lição e confirme sua participação nesta disciplina!