Engenharia de Software #02 – Processos de Software

Olá! Este é o segundo de uma série de resumos baseados no livro Engenharia de Software de Ian Sommerville. Meu objetivo com essa série é reforçar meus estudos e compartilhar com a comunidade de tecnologia os principais conceitos da área, com uma linguagem acessível.

Espero que este conteúdo possa ser útil para quem está começando ou revisando fundamentos. Feedbacks são sempre bem-vindos!

Caso tenha interesse no artigo anterior "Introdução à Engenharia de Software": artigo #01.

1. Introdução

Devido à grande variedade de sistemas de softwares, não temos um método de produção definitivo, porém, todo software profissional deve ser produzido seguindo uma série de atividades gerenciadas que resultam na produção de um sistema de software – A esse conjunto de atividades damos o nome de processo de software. Ainda que não possua um método universal, todos softwares devem incluir quatro atividades fundamentais, conforme discutido no artigo #01: Especificação; Desenvolvimento; Validação; Evolução. Essas atividades são complexas e possuem suas próprias sub atividades.

Ao falarmos de processos de software, normalmente falamos sobre as atividades desenvolvidas e sobre os resultados esperados. É importante também descrever quem está envolvido, o que será produzido e as condições que podem afetar a sequência dessas atividades:

Um processo de atividade deve resultar em um produto ou entrega. Por exemplo, a etapa de especificação deve resultar em um documento de requisitos de sistema.
Os papeis devem refletir as atribuições de quem está envolvido no processo. Exemplos de papeis: Gerente de projetos, programador.
Podem haver condições a serem estabelecidas antes e/ou após a aprovação do processo ou produção do produto. Por exemplo a revisão de documentação após cada etapa de desenvolvimento.

Processos de Software são complexos e isso exige tomada de decisão e julgamento pessoal. Na ausência de um método universal cada empresa buscou seus próprios processos de desenvolvimento. Os processos evoluíram e passaram a aproveitar melhor os desenvolvedores em uma organização e também as características dos sistemas. Dentre os processos de software temos dois grandes grupos:

Os processos que planejam suas atividades antecipadamente e são desenvolvidos com base no planejamento, são conhecidos como processos dirigido por planos.
Os processos em que o planejamento é realizado de forma incremental e continua, são conhecidos como processos ágeis.

2. Modelos de Processos de Software

Modelos de processos, são representações simplificadas de processos de software através de uma perspectiva particular. Isso quer dizer que um modelo de processo não precisa representar o processo como um todo, somente fornecer informações relevantes a sua finalidade.

Modelos genéricos, como o nome diz, são descrições generalizadas e mais abstratas dos processos de software. Eles funcionam como estruturas de processos que podem ser ampliados e adaptados para modelos específicos:

Modelo em Cascata: Representa em fases distintas e sequenciais, as atividades fundamentais do processo como especificação, desenvolvimento, validação e evolução.
Desenvolvimento Incremental: As atividades fundamentais do processo como especificação, desenvolvimento, validação e evolução são realizadas de forma intercalada. O sistema é desenvolvido em versões, cada versão adiciona uma funcionalidade ao sistema.
Integração e Configuração: Fundamentado na utilização de componentes ou sistemas reutilizáveis. O processo se baseia em configurar componentes já prontos, para ser reutilizado em novos sistemas.

O processo correto depende de fatores como requisitos, ambiente de utilização e o tipo de software a ser produzido. Na prática boa parte dos processos se baseiam em um dos modelos genéricos, incorporando uma ou mais características de outros modelos. Por exemplo, o processo principal de um software pode ser desenvolvido utilizando o método em cascata, mas em subprocessos onde os requisitos são difíceis de especificar antecipadamente pode ser usado o método incremental.

2.1. Modelo em Cascata

O modelo em cascata recebe o nome devido a representação das suas atividades. O modelo em cascata é um exemplo de processo dirigido por plano, nele as atividades são divididas em etapas sequenciais, que devem ser realizadas após a conclusão da etapa anterior.

Essas etapas refletem diretamente nas atividades fundamentais de desenvolvimento de Software:

Análise e definição de requisitos: Através de consultas aos usuários são definidos os serviços, metas e as restrições do sistema. Depois são especificados com mais detalhes.
Projeto do Sistema e do Software: Esse processo separa os requisitos de hardware e de software, além de, definir a arquitetura global do sistema.
Implementação e Teste de Unidade: Nessa etapa o software é produzido como um conjunto de programas ou unidades isoladas. Testes são realizados a fim de conferir se cada unidade atende a sua especificação.
Integração e Teste de Sistema: Nessa etapa os programas ou unidades são integrados em um sistema completo. Testes são realizados a fim de garantir que os requisitos de software foram atendidos. Após essa etapa o software é entregue para o cliente.
Operação e Manutenção: Nessa etapa o software é colocado em uso. Essa etapa é a mais longa do ciclo de vida de um software, com a finalidade de corrigir eventuais erros, melhorar a implantação e aprimorar os serviços do sistema.

Essas etapas se sobrepõem e fornecem informações uma as outras. Durante um processo atual pode ser identificado erros ou problemas em processos anteriores e assim por diante. Na prática o processo de software necessita de feedback constante e nunca segue um caminho linear simples. Quando novas informações são introduzidas, toda a documentação já produzida deve ser atualizada a fim de refletir essas mudanças. Dessa forma o modelo em cascata exige compromisso inicial e retrabalho quando mudanças surgirem.

Devido a esse processo engessado, o modelo em cascata é indicado apenas para alguns casos, como:

Sistemas Embarcados: O Software precisa interagir com sistemas de hardwares, não sendo possível adiar ou prolongar as decisões sobre suas funcionalidades.
Sistemas Críticos: Sistemas críticos exigem ampla análise de segurança, segurança da informação, e especificação do software. Problemas relacionado a segurança durante a implantação podem comprometer o projeto e são caros de se corrigir.
Grandes Sistemas de Software: Sistemas grandes normalmente são desenvolvidos por várias empresas parceiras. O planejamento antecipado evita falhas na comunicação e a especificação completa promove a independência entre as equipes.

O Modelo em cascata não é adequado para ocasiões onde a equipe possui comunicação informal, e nas quais o software e seus requisitos mudam rapidamente. Nesses casos, como veremos a seguir os processos incrementais são mais recomendados.

2.2. Desenvolvimento Incremental

No desenvolvimento incremental, a ideia principal é fornecer uma estrutura inicial para o cliente, e através do feedback recebido dos usuários evoluir esse sistema, incrementando funcionalidades em cada versão até que se chegue no sistema necessário. As atividades fundamentais são realizadas de forma intercalada, com feedback rápido ao decorrer de todas elas.

O desenvolvimento incremental é hoje a abordagem mais comum para o desenvolvimento de aplicações e produtos de software. Além de ser parte fundamental dos métodos ágeis, nos sistemas onde os requisitos podem mudar constantemente, como em sistemas de negócios e produtos de software, ele se destaca em relação ao método em cascata. Algumas de suas vantagens são:

O custo de implementação das mudanças nos requisitos é reduzido.
É mais fácil obter feedback do cliente.
A entrega e implementação antecipada de um software útil, agregando valor para o cliente.

Apesar de suas vantagens, a abordagem incremental possui dois grandes problemas gerenciais:

Os gerentes necessitam de resultados regulares para medir o progresso, mas não é economicamente viável produzir documentos para cada versão do sistema.
Os códigos podem ficar bagunçados pelas mudanças e quando novas funcionalidades são implementadas, degradando o a estrutura do sistema. Para evitar esse problema, os métodos ágeis sugerem a refatoração do código em intervalos regulares.

Vale lembrar que o desenvolvimento incremental não exige a entrega de cada incremento. É possível desenvolver o sistema, expondo-o a comentários e gerando feedbacks sem a necessidade de implementa-lo no ambiente do cliente.

2.3. Integração e configuração

O reuso de software é uma prática comum na maioria dos projetos. Normalmente ocorre de maneira informal quando pessoas que estão envolvidas conhecem ou procuram por códigos similares. Esse código é modificado de acordo com a necessidade e integrado no projeto.

Há três componentes que são reusados frequentemente:

Sistemas de aplicação stand-alone configurados para um ambiente em particular. São generalizados e necessitam de adaptação para uso em uma aplicação especifica.
Coleções de objetos desenvolvidos como um componente ou pacote a ser integrado a um framework de componentes como o Java Spring framework.
Web services desenvolvidos de acordo com os padrões de serviço e que estão disponíveis para uso remoto na internet.

O processo genérico fundamentado no reuso de software, normalmente segue as seguintes etapas:

Especificação dos requisitos: Descrições breves dos requisitos essenciais do sistema, bem como as características esperadas.
Descoberta e avaliação de software: Através do resultado da especificação dos requisitos, é realizada uma busca de componentes que atendam as funcionalidades desejadas e que sejam adequados ao sistema.
Refinamento dos requisitos: Nessa etapa é realizada a compatibilização dos requisitos com os componentes ou aplicações encontradas. No caso de uma modificação dos componentes disponíveis não atender os requisitos, pode ser realizada uma nova busca para componentes alternativos.
Configuração da aplicação: No caso de uma aplicação de prateleira que atenda aos requisitos estar disponível, ela pode ser configurada para utilização no novo sistema.
Adaptação e integração dos componentes: Se não houver uma aplicação de prateleira disponível, componentes podem ser modificados ou desenvolvidos a fim de serem integrados ao sistema posteriormente.

A grande vantagem da abordagem baseada no reuso, através da configuração e integração, está na redução da quantidade de software a ser desenvolvido, diminuindo custos e riscos de produção. Consequentemente também resulta numa entrega mais rápida do software

3. Atividades do Processo

Os processos de softwares reais são uma série de atividades sequenciais ou intercaladas, com a finalidade de produzir um software. Esses processos envolvem atividades básicas: especificação; Desenvolvimento; validação; evolução.

Essas atividades são organizadas de modo distinto, elas podem ser sequenciais ou intercaladas, a depender do método utilizado. A escolha do método depende do tipo de software, da equipe de desenvolvimento e da empresa desenvolvedora.

3.1. Especificação do Software

A especificação do software também é conhecida como engenharia de requisitos. Ela é responsável por entender e atribuir os serviços necessários e quais as restrições para sua operação e desenvolvimento. A especificação é uma etapa critica e qualquer erro cometido irá comprometer processos posteriores no projeto.

A finalidade da especificação é, que ao final do processo seja elaborado um documento de requisitos acordado que atenda às necessidades dos stakeholders (partes interessadas). Os requisitos devem idealmente apresentar dois níveis de detalhes do sistema:

Requisitos de usuário: declarações abstratas fornecendo uma visão superficial do sistema para os usuários e clientes.
Requisitos de sistema: descrição técnica fornecendo uma visão detalha dos requisitos do sistema para os desenvolvedores.

O processo de especificação ou engenharia de requisitos possui três atividades fundamentais:

Elicitação e análise de requisitos: Nessa etapa é realizado o levantamento e seleção dos requisitos, através de observações de sistemas, reuniões com clientes e stakeholders, análise de tarefas e etc.
Especificação: Nessa etapa, toda a informação coletada na etapa anterior é refinada e traduzida em um documento detalhado. Podem ser utilizados dois níveis de detalhes: requisitos de usuários e requisitos de sistema.
Validação de requisito: Nessa etapa é realizada a conferencia dos requisitos com a finalidade de garantir que eles atendam as necessidades, levando em conta a viabilidade, consistência e integridade.

É possível que um requisito não atenda as necessidades, apresente erros, ou ainda que novos requisitos surjam, nesses casos o documento de requisitos deve ser modificado a fim de refletir a nova realidade do projeto.

3.2. Projeto e Implementação do software

No processo de implantação do software é onde será elaborado um sistema executável do projeto. Esse processo pode ser dividido em duas etapas, que são as etapas de projeto e de programação. No caso dos métodos ágeis, essas etapas não são separadas e ocorrem de forma intercalada, não sendo necessário a elaboração de registros em documentação formal.

O projeto do software se trata de uma descrição da estrutura do software, do modelo utilizado, estrutura de dados do sistema, interface dos componentes de sistema e algoritmo utilizado.

O projeto evolui conforme é desenvolvido, sendo adicionado detalhes e realizando uma revisão constante. Dessa forma as atividades realizadas no projeto são intercaladas e interdependentes. Sendo assim a medida que novas informações são geradas é necessário modificar o projeto anterior, tornando o retrabalho nessa etapa inevitável.

Embora as atividades desenvolvidas no projeto possam variar a depender do tipo de sistema, quatro atividades comuns podem fazer parte de um projeto de sistemas:

Projeto de arquitetura: Onde é definida a estrutural global do projeto, bem como seus componentes, suas relações e distribuição.
Projeto de banco de dados: Onde é elaborada a estrutura de dados e sua representação em bancos de dados. Podendo ainda optar pela escolha de utilizar um banco de dados já existente.
Projeto de interface: Definição das interfaces entre os componentes de sistema, sendo necessário uma especificação inequívoca, permitindo assim que os componentes sejam desenvolvidos separadamente.
Seleção e projeto de componentes: Onde é realizada uma busca por componentes prontos a serem aproveitados no sistema, na ausência de componentes adequados produzir novos.

Os resultados do processo de projeto em sistemas críticos devem ser documentos detalhados e precisos do sistema. No caso de métodos dirigidos por planos, serão diagramas. Em abordagens ágeis serão representados no código do programa e não em documentos separados.

A próxima etapa do ciclo do projeto, é desenvolver um programa para implementar o sistema. Aqui podem ser utilizadas ferramentas para gerar o esqueleto do programa a partir do projeto. Por se tratar de uma atividade individual, na programação não existem processos genéricos que sejam seguidos habitualmente, cada programador segue a abordagem que se sente mais familiarizado ou confortável.

Frequentemente são encontrados erros durante a programação e os próprios desenvolvedores executam algum tipo de teste no código que desenvolvem. Ainda assim, o processo de buscar e corrigir defeitos (bugs) é chamado de depuração (debugging). Os testes e a depuração são atividades diferentes, os testes apenas revelam a existência de erros ou defeitos, enquanto a depuração está relacionada a localização e correção deles.

3.3. Validação do Software

O processo de validação tem a finalidade de verificar a conformidade do sistema com a sua especificação, e se ele atende as necessidades do cliente. A técnica utilizada nesse processo costuma ser o teste de programa, utilizando dados simulados de testes. Se o software for personalizado, o teste pode ser realizado utilizado dados do cliente.

Primeiro os componentes são testados individualmente, após são integrados no sistema, então é realizado um novo teste do sistema integrado. Os sistemas não devem ser testados em unidades isoladas, exceto em caso de pequenos programas.

Os testes normalmente incluem três atividades:

Teste de componente: Os componentes são testados de forma individual, componentes podem ser entidades simples como funções de objetos e classes, ou ainda um agrupamento dessas entidades. Ferramentas de automação podem ser utilizadas.
Teste de sistema: Nessa etapa os componentes são integrados ao sistema. O sistema completo é testado, revelando problemas de interação ou de interface entre os componentes. Essa etapa também busca garantir que o sistema satisfaça os requisitos. Em sistemas muito grandes, é possível formar subsistemas e testa-los individualmente antes de integra-los ao sistema completo.
Teste do cliente: Etapa final de teste, o sistema é testado pelo cliente antes de ir para uso operacional. Essa etapa pode revelar erros e omissões nos requisitos, pois os dados reais testam o sistema de forma diferente dos dados simulados. Teste do cliente também ajuda a verificar se o desempenho do sistema no ambiente do cliente é aceitável.

Idealmente os defeitos no componente e problemas de interface deveriam ser descobertos cedo no processo de teste. Porém em muitos casos defeitos de componente são descobertos nos testes do sistema, o que faz necessário com que todo esse processo ocorra de forma iterativa, com as informações finais de uma etapa sendo retroalimentada em novas iterações.

No caso dos métodos incrementais, a cada novo incremento deve ser testada durante seu desenvolvimento e atender os requisitos daquele incremento.

Em métodos dirigidos por planos os testes são realizados por equipes independentes, seguindo um conjunto de planos de testes, elaborados a partir das especificações e do projeto do sistema.

Em sistemas a serem comercializados como produto de software, pode ser realizado um teste-beta. Nesse caso o sistema é distribuído para alguns clientes potenciais, que concordam em utilizar o sistema de forma experimental e fornecer feedback aos desenvolvedores do sistema.

3.4. Evolução do Software

O processo de evolução ou manutenção do software está relacionado a manter o software útil após sua entrega para o cliente, envolve desde a correção de bugs até a implementação de novas funcionalidades a fim de satisfazer um novo requisito.

A verdade é que atualmente há pouca diferença entre o desenvolvimento e a manutenção, são poucos os sistemas de software completamente novos, e podemos encarar o desenvolvimento e a manutenção como uma coisa só.

O software é constantemente alterado durante sua vida útil devido a mudança de requisitos e necessidades do cliente, dessa forma podemos encarar a engenharia de software como um processo evolutivo.

4. Lidando com mudanças

No desenvolvimento de um software os requisitos mudam conforme as empresas respondem a pressões externas, concorrência e até mudanças de gestão. Além disso, quando novas tecnologias surgem, novas abordagens são possíveis.

Isso faz que a alteração nos grandes softwares seja inevitável, mesmo que isso eleve os custos de produção, já que o trabalho concluído precisará ser refeito. Ainda assim, há duas abordagens que visão minimizar os custos dessas mudanças:

Antecipação da mudança: Incluir no processo de software atividades que possam prever ou antecipar mudanças. Por exemplo a elaboração de um protótipo do sistema.
Tolerância a mudança: Projetar o processo e o software visando facilitar as mudanças no sistema. Normalmente nessa abordagem é utilizada o desenvolvimento incremental, onde as mudanças são implementadas em novos incrementos que não foram desenvolvidos.

Dessa forma para lidar com essas mudanças temos duas maneiras principais, a prototipação de sistema e a entrega incremental.

4.1. Prototipação de Sistema

O protótipo é uma versão inicial do sistema ou parte dele, desenvolvido de forma rápida, usado para verificar opções de projeto, descobrir problemas e desmonstrar conceitos.

O protótipo pode ser usado no desenvolvimento para antecipar mudanças:

Durante a especificação do sistema, pode ajudar na elicitação e validação de requisitos.
No processo de projeto pode ajudar a definir soluções de software e desenvolver a interface de usuário do sistema. A prototipação rápida é a maneira mais eficiente de desenvolver as interfaces de usuário, pois apenas descrições textuais e diagramas não são suficientes para especificar a interface de usuário.

Durante a prototipação, os objetivos do protótipo devem ser claros desde o inicio do processo. Se os objetivos não forem bem definidos, pode haver um mal entendido quanto a finalidade do protótipo, não sendo possível tirar proveito de seus benefícios.

O próximo passo seria definir o que deve e o que não deve ser incluído no protótipo. A depender da finalidade do protótipo, parte das funcionalidades podem ser removidas e os requisitos deixados de lado, a fim de reduzir o custo e agilizar a entrega.

A etapa final é a avaliação do protótipo. Após apresentar o objetivo do protótipo, deve ser realizado o treinamento dos usuários e ser respeitado o tempo para eles se acostumarem ao sistema. Com isso, é possível descobrir erros e omissões nos requisitos.

4.2. Entrega Incremental

A entrega incremental é uma abordagem em que novas funcionalidades do sistema são fornecidas ao cliente através de implementação por incrementos.

Os serviços que serão entregues em cada incremento dependem da sua prioridade – são entregues e implementados primeiro os de maior prioridade.

Após identificar os incrementos, são definidos os requisitos e serviços a serem entregues primeiro. Conforme novos incrementos são concluídos, eles são integrados ao sistema, melhorando suas funcionalidades a cada incremento.

As vantagens de se utilizar a abordagem incremental incluem:

Os incrementos iniciais funcionam como um protótipo que servirá para definir os próximos requisitos e também ajudam os usuários a se familiarizar com o sistema. Porém diferente dos protótipos, os incrementos são parte real do sistema o que dispensa reaprendizagem.
O primeiro incremento satisfaz as funcionalidades mais críticas, dessa forma o cliente tira proveito do sistema durante seu desenvolvimento e não apenas no final.
Facilidade para incorporar novas funcionalidades e mudanças.
Devido ao esquema de prioridade de incrementos, os usuários ficam em contato por mais temo com partes importantes do sistema, dessa forma a entrega final está menos propensa a falhas em partes críticas do sistema.

Embora apresente diversas vantagens, a abordagem de entrega incremental possui alguns problemas:

Usuários acostumados com um sistema pré-existente, estão menos propensos a querer testar um novo sistema incompleto. São poucos os casos onde é possível utilizar os dois sistemas em paralelos, devido a diferenças em banco de dados e interfaces de usuário.
Boa parte dos sistemas exigem um componente básico que será utilizado por diversas partes do sistema, porém como não há uma especificação detalhada, pode ser difícil encontrar os recursos comuns para cada parte do sistema.
Uma das características essenciais da abordagem incremental é de que a documentação é desenvolvida juntamente com o software. Porém essa característica vai contra as políticas de aquisição de algumas empresas que exigem uma especificação completa no contrato de desenvolvimento.

Há ainda alguns tipos de sistema para os quais não se recomenda a abordagem incremental, sistemas embarcados que dependem do desenvolvimento de hardware, sistemas muito grandes em que estão envolvidas diferentes equipes de desenvolvimento e sistemas críticos em que todos requisitos devem estar definidos a fim de garantir a segurança e segurança da informação do sistema.

5. Melhoria de Processo

Atualmente há uma demanda constante por software melhor, mais barato e com prazo apertado para o desenvolvimento. A melhoria de processo busca compreender esses processos e aprimorar a qualidade do produto e reduzir o prazo de entrega.

Para atingir essa melhoria nos processos são utilizadas duas principais abordagens:

Maturidade de processo: Se concentra em melhorar atividades relacionadas ao gerenciamento de projeto e na introdução de práticas recomendadas de engenharia de requisitos. Busca a melhoria através da qualidade e previsibilidade.
Abordagem ágil: Se concentra no desenvolvimento interativo e redução de custos gerais de produção do software. Busca a melhoria através da redução geral de custos (essa abordagem será mais aprofundada no próximo artigo, referente ao cap. 3).

A melhoria geral do processo através da abordagem de maturidade, segue os seguintes estágios de forma cíclica:

Medição de processo: Os atributos do processo são medidos e utilizados como referencia para medir se novas medidas serão eficazes.
Análise de processo: É realizada uma avaliação do processo ou do produto buscando identificar gargalos e pontos fracos.
Mudança no processo: Com base na análise mudança são propostas e introduzidas. O ciclo se reinicia continua coletando informações.

A maturidade do processo pode ser dividida em cinco níveis:

Inicial: Metas do processo são cumpridas, o escopo do trabalho a ser realizado é definido explicitamente para todos processos e comunicado ao time.
Gerenciado: Metas do processo são cumpridas e políticas organizacionais estão implementadas, definindo quando cada processo deve ser utilizado. Deve haver planos documentados que definam as metas do projeto. O gerenciamento de recursos e monitoramento de processos devem estar em vigor em toda instituição.
Definido: Se concentra na padronização organizacional e implementação dos processos. Cada projeto tem um processo gerido adaptado aos requisitos a partir de um conjunto definido de processos organizacionais. Recursos de projetos e suas medições devem ser coletados e aplicados em melhorias futuras.
Gerenciado quantitativamente: Há a responsabilidade organizacional de utilizar o método estatístico – entre outros métodos quantitativos – para controlar os subprocessos.
Em otimização: A organização deve utilizar as medições de processos e produtos para orientar as melhorias de processos. Tendencias devem ser analisadas e os processos adaptados para as necessidades mutáveis da empresa.

Vale a pena dizer que a abordagem de maturidade do processo é muito custosa para empresas pequenas, e estimar a maturidade com métodos ágeis é muito difícil. Dessa forma, atualmente a abordagem de maturidade de processo é utilizada apenas por grandes empresas.

6. Considerações sobre o capítulo

O capítulo apresenta os fundamentos essenciais da engenharia de software, destacando atividades chave, modelos de processo e abordagens de desenvolvimento. Compreender essas bases é crucial para aplicar práticas eficazes no desenvolvimento de sistemas.

Todo conteúdo foi baseado no capítulo 2 do livro Engenharia de Software de Ian Sommerville.