Algum tempo atrás eu desbravei a saga do software junto com vocês, onde apresentei tudo o que acontece desde que alguém tem uma ideia genial para um novo software até que ele chegue aos usuários.

Saga do software

O que eu não falei é que essa saga corresponde a algo chamado processo de software. Um processo de software é uma abordagem adaptável que possibilita equipe de software selecionar e organizar o conjunto apropriado de tarefas para entregar o software e artefatos relacionados dentro do prazo e com qualidade. Para isso, engloba etapas para compreensão, análise, projeto, implementação, testes, entrega e evolução de software (lembra de algo? Sim, todas as atividades que detalhamos ao longo da nossa saga!). Além disso, também inclui atividades de apoio, como gestão do projeto, garantia de qualidade, gerência de configuração etc.

A primeira escolha a ser feita no processo de software é o modelo de ciclo de vida adotado no projeto de desenvolvimento do software. Esses modelos estruturam as atividades envolvidas ao longo do desenvolvimento do software e a forma como estas atividades se relacionam, diferenciando entre si em relação a ordem/tempo/ênfase dados a cada fase/produtos entregues.

Repararam que falei modelos aí em cima? Isso porque não existe um modelo de ciclo de vida único e ideal para todos os projetos de desenvolvimento de software, uma vez que precisamos lidar com uma diversidade de tipos de sistemas e organizações que usam estes sistemas. Então, vamos conhecer alguns deles!

O modelo Cascata, também conhecido como modelo clássico, tem origem na indústria de manufatura e construção e foi a primeira tentativa de formalizar uma metodologia de desenvolvimento de software. Ele é um modelo sequencial e sistemático em que cada passo deve ser completado antes de iniciar o próximo.

Modelo Cascata

O modelo Cascata minimiza o planejamento, já que as atividades são organizadas em uma sequência com entregas bem definidas; funciona bem para requisitos estáveis e bem compreendidos, já que pressupõe que esses requisitos não mudarão ao longo do projeto; e é facilmente aplicável em equipes inexperientes. Porém, os projetos de desenvolvimento raramente seguem fluxo sequencial, com atividades podendo ocorrer em paralelo; podem existir dificuldade em concluir a etapa de análise devido a modificações nos requisitos, bem como propagação de erros se os requisitos estiverem mal formulados; e uma versão de produção do sistema não estará pronta até que o ciclo chegue ao final.

A Prototipagem é uma técnica complementar à análise de requisitos, adequada quando o “problema” não é bem conhecido ou o cliente não sabe exatamente o que precisa ou como deve ser a interface do sistema. Nela, o desenvolvedor interage com os usuários, projetando e desenvolvendo imediatamente um protótipo (esboço de alguma parte do sistema) que serve como fonte de feedback e aprimoração dos requisitos. É muito utilizada como auxílio a outro modelo de ciclo de vida, mas possui problemas como custo e a tendência dos usuários gostarem do protótipo e quererem transformá-lo no produto final (protótipos foram feitos para serem descartados).

Prototipagem

O modelo Iterativo e Incremental usa a estratégia “dividir para conquistar” para lidar com requisitos de sistema que sempre evoluem durante o projeto. O desenvolvimento do software ocorre em ciclos, onde são realizadas as fases de análise, projeto, implementação e testes considerando um subconjunto de requisitos que foram definidos antes do desenvolvimento do ciclo (usualmente os requisitos mais críticos são priorizados). Ao fim dessas fases, produz-se um incremento ou melhoria no software (entrega de produto operacional, mesmo sendo uma parte da funcionalidade requerida). Ou seja, temos uma “mini cascata” executada em cada iteração, progredindo até a entrega final do produto.

Modelo Iterativo e Incremental

O modelo Iterativo e Incremental incentiva a participação do usuário, que pode receber e avaliar as entregas do produto mais cedo; permite o replanejamento das próximas iterações de acordo com avaliação dos incrementos e identificação de problemas; diminui o risco do projeto fracassar, pois possibilita que as mudanças sejam monitoradas e que questões importantes sejam isoladas e resolvidas. Porém, é mais difícil de gerenciar, pois é difícil estabelecer um número exato de ciclos necessários para construir o produto já que a maioria das técnicas de gerenciamento e estimativas baseiam-se em layouts lineares de atividades.

O modelo Espiral representa o processo de software como uma espiral em vez de sequência de atividades. Não existem fases fixas, sendo a espiral dividida em regiões que apresentam as tarefas adaptadas às características do projeto, e cada volta na espiral representa uma fase, que pode produzir tanto uma especificação/modelo como versões do software.

Modelo Espiral

O modelo Espiral reduz os riscos do projeto; permite uma maior interação com o cliente; é adequado à maioria dos projetos/sistemas e metodologias existentes; e acrescenta aspectos gerenciais ao desenvolvimento de software (planejamento, tomada de decisão, análise de riscos). Porém, é um modelo complexo e que requer experiência na avaliação de riscos.

O Processo Unificado oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. É adaptável e pode ser configurada para selecionar os elementos apropriados às necessidades da organização/projeto de desenvolvimento, sugerindo um fluxo iterativo e incremental composto por 4 fases: (a) Concepção, em que ocorre a identificação e descrição das necessidades de negócio, objetivos do software, arquitetura preliminar, requisitos fundamentais e planejamento do projeto; (b) Elaboração, responsável por refinar os artefatos gerados na concepção, assegurando assim que os principais riscos foram diminuídos e uma arquitetura executável foi definida; (c) Construção, em que ocorre o desenvolvimento do software e realização de testes; e (d) Transição, momento de entrega do software aos usuários e obtenção de feedback.

Processo Unificado

Mas talvez vocês estejam se perguntando: Será que existem alternativas menos “engessadas”, sem esse excesso de formalismo e que se adequem a um mundo com necessidade de adaptação e grande competitividade? Existe sim, os chamados métodos ágeis. Mas isso é assunto para meu próximo texto! 😊