Processos de Software: o que você precisa saber (2023)

Você está começando na área de ES e não faz ideia do que são processos de software? Você só vai precisar de 6 minutos aqui.

O que é processo de software?

Um processo de software é uma sequência de atividades que são realizadas durante a produção de um software. Existem quatro atividades fundamentais que são comuns a todos os processos de software:

Um processo de software é uma sequência de atividades que são realizadas durante a produção de um software. Existem quatro atividades fundamentais que são comuns a todos os processos de software:

1. Especificação. Aqui, os clientes e engenheiros de software definem os requisitos (condições, exigências) que o sistema a ser produzido deverá cumprir e quais as restrições quanto ao seu funcionamento.
2. Desenvolvimento. O software é projetado e programado.
3. Validação. O software é verificado e testado para garantir que possui o que o cliente exige.
4. Evolução. O software é modificado para atender novos requisitos do cliente e exigências do mercado.

Todos os processos seguem o modelo acima?

Sim, todos os processos contêm as atividades acima, mas não somente elas. Para descomplicar, os processos são representados como modelos, e existem vários. Cada modelo representa um processo de uma perspectiva particular, e, portanto, difere-se do outro em muitos aspectos. Em outras palavras, um modelo é como uma estrutura de processo de software que pode ser ampliado e adaptado para criar processos de engenharia de software mais específicos. Exemplos de modelos de processos de software mais conhecidos, que serão tratados aqui, são:

1. Modelo em cascata. Nesse modelo, as atividades principais são consideradas como fases separadas seguindo uma ordem estrita, formando uma cascata (origem de seu nome) ou o ciclo de vida do software.
2. Desenvolvimento Incremental. Nessa abordagem, as atividades de especificação, desenvolvimento e validação são intercaladas. O desenvolvimento do sistema gera uma série de versões (incrementos), onde cada versão adiciona uma nova funcionalidade à versão anterior.
3. Engenharia de software orientada à reutilização. A base dessa abordagem é a existência de um número significativo de componentes reutilizáveis, tornando o processo de desenvolvimento do sistema mais focado na integração desses componentes do que no desenvolvimento do zero.

Vamos aos modelos!

Modelo Cascata

As principais etapas do modelo em cascata (Figura 1) são:

1. Análise e definição de requisitos. As funcionalidades, serviços e restrições são definidas em conjunto com o cliente ou com os usuários do sistema. Eles são então refinados e detalhados para gerarem uma especificação do sistema.
2. Design de sistema. O processo de design considera os requisitos de hardware e/ou de software e estabelece uma arquitetura geral do sistema. O design de software envolve identificar e descrever as abstrações fundamentais do sistema e seus relacionamentos.
3. Implementação e testes unitários. Durante esta etapa, pequenas unidades individuais do programa são implementadas. O teste de unidade verifica se cada unidade atende à sua especificação.
4. Integração e teste do sistema. As unidades individuais do programa são integradas e testadas como um sistema completo para garantir que os requisitos de software tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente.
5. Operação e manutenção. Provavelmente essa é a fase mais longa do ciclo de vida do software. O sistema é instalado e utilizado. A manutenção envolve a correção de erros que não foram descobertos em estágios anteriores do ciclo de vida, melhoria na implementação de unidades do sistema e aprimoramento dos serviços do sistema à medida que novos requisitos aparecem.

(Video) 🔴 Como Ser Um Desenvolvedor de Software? - Tudo Sobre a Profissão Desenvolvedor de Software.

Nesse modelo, a fase seguinte não deve começar até que a fase anterior tenha terminado. Embora que, na prática, esses estágios se sobrepõem e alimentam informações entre si. O processo de software não é um modelo linear simples, mas envolve feedback de uma fase para outra. Os documentos produzidos em cada fase podem ser modificados para expor as mudanças feitas. O modelo cascata é um exemplo de um processo orientado pelo plano: em princípio, você deve planejar e agendar todas as atividades do processo antes de começar a trabalhar nelas.

Modelo Incremental

O modelo incremental se baseia na ideia de desenvolver uma implementação inicial do sistema, deixando-a para o cliente analisar e comentar, e várias versões subsequentes até que o sistema fique adequado, gerando a versão final (Figura 2). Especificação, desenvolvimento e validação são intercaladas e não separadas, com um feedback rápido entre as atividades.

O desenvolvimento incremental de um software, que é uma parte fundamental das abordagens ágeis, é melhor do que o modelo em cascata para a maioria dos negócios, e-commerce e sistemas pessoais. O desenvolvimento incremental reflete a maneira como resolvemos problemas. Raramente chegamos a uma solução concreta para o problema de uma única vez, mas realizamos uma série de etapas em direção à solução, retrocedendo quando percebemos que cometemos um erro.

É mais fácil fazer alterações enquanto o software está em desenvolvimento. Cada incremento ou versão do sistema incorpora algumas das funcionalidades necessárias ao cliente. Geralmente, os primeiros incrementos do sistema incluem a funcionalidade mais importante ou urgente.

Além disso, o cliente pode ter acesso ao sistema em seu estágio inicial e avaliar se ele possui o que foi pedido. Se algo estiver incorreto, somente o incremento atual deve ser alterado e, caso haja novas funcionalidades, devem ser atendidas nos incrementos posteriores.

O desenvolvimento incremental tem três vantagens importantes em comparação com o modelo em cascata:

1. O custo de acrescentar mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação que precisa ser refeita é muito menor do que com o modelo em cascata.
2. É mais fácil obter feedback do cliente sobre o trabalho desenvolvido. O cliente pode comentar sobre as demonstrações do software e ver o quanto foi implementado, ao invés de avaliar o progresso dos documentos de design de software, como seria se fosse com o de cascata.
3. É possível ter uma entrega e implantação mais rápida de softwares úteis, mesmo que todas as funcionalidades não tenham sido incluídas. Os clientes podem usar e obter valor do software mais cedo do que é possível com um processo em cascata.

Engenharia de software orientada à reutilização

A reutilização de software se baseia na programação modular, onde pequenos sistemas são reutilizados para criar a aplicação final, ou seja, procedimentos, funções e classes pré existentes (criadas ou não por terceiros) servirão para montar um novo sistema.

Na maioria dos projetos de software, há alguma reutilização do código. Geralmente, essa reutilização ocorre informalmente. Por exemplo, quando as pessoas que trabalham em um novo projeto conhecem projetos ou códigos semelhantes ao que é requisitado, eles procuram por esses códigos, modificam conforme necessário e os incorporam ao sistema. Essa reutilização informal ocorre independente do processo de desenvolvimento usado.

A engenharia de software orientada à reutilização tem o objetivo de especificar como o reuso de pequenos módulos (chamados componentes) deve ser feito para garantir maior confiabilidade, reduzir a quantidade de software a ser desenvolvido e riscos de processo, aumentar a velocidade de produção e realizar a entrega do produto mais rapidamente.

Um modelo que representa o processo geral da engenharia de software orientada à reutilização é mostrado na Figura 3.

Em comparação com os outros processos de software, os estágios da especificação de requisitos e de validação são semelhantes, porém os estágios intermediários são diferentes. Eles são:

1. Análise de componentes. Dada a especificação de requisitos, é feita uma pesquisa sobre os componentes que satisfazem essa especificação. Normalmente, não há uma combinação de componentes que atenda exatamente à especificação e aqueles que podem ser usados ​​fornecem apenas algumas das funcionalidades necessárias.
2. Modificação de requisitos. Durante este estágio, os requisitos são analisados ​​usando as informações dos componentes que foram definidos na fase anterior. Eles podem ser modificados para se adequar aos componentes disponíveis. Quando algum requisito não pode ser modificado, a atividade de análise de componentes pode ser revisada para procurar soluções alternativas.
3. Design de sistema com reutilização. Nessa fase, a estrutura do sistema é projetada ou uma já existente é reutilizada. Os designers levam em conta os componentes que serão reutilizados e organizam a estrutura para atender a isso. Novos softwares podem precisar ser projetados quando não houver componente adequado.
4. Desenvolvimento e integração. Durante essa fase, são desenvolvidos os códigos que não foram adquiridos externamente e os componentes e sistemas COTS são integrados para criar o novo sistema.

Uma desvantagem desse modelo é que nem sempre há a adequação ideal dos componentes aos requisitos ​​e isso pode levar a um sistema que não atenda às reais necessidades do cliente. Além disso, as novas versões dos componentes reutilizados podem não estar sob o controle da organização que as utiliza, prejudicando em algum ponto a evolução do sistema.