Tópicos Avançados em Engenharia de Software

Manutenção e evolução de software

Nesta aula mergulharemos na classificação e nos tipos de atividades de manutenção de software, explorando a engenharia reversa e reengenharia, bem como a evolução contínua do software. Esses temas são essenciais para a prática profissional na área de desenvolvimento de software, permitindo compreender e lidar com os desafios da manutenção e evolução dos sistemas ao longo do tempo. Prepare-se para adquirir insights valiosos e aprimorar suas habilidades nesta área em constante evolução da engenharia de software!

Ponto de Partida

Nesta aula, exploramos um aspecto fundamental no ciclo de vida do software: manutenção de software. A manutenção de software é uma etapa essencial após o desenvolvimento inicial, envolvendo atividades como correção de bugs, adaptação a novos requisitos e melhorias de desempenho. Compreender a importância da manutenção é crucial, pois ela garante a funcionalidade contínua e a eficácia do software ao longo do tempo, atendendo às necessidades dos usuários e mantendo-o competitivo no mercado.

Em seguida, exploraremos a engenharia reversa e reengenharia como abordagens para lidar com sistemas legados ou desatualizados. A engenharia reversa consiste em analisar um sistema existente para compreender sua estrutura e funcionamento, enquanto a reengenharia visa reestruturar e melhorar o sistema com base nessa análise. Essas práticas são cruciais para modernizar sistemas legados, garantindo que permaneçam relevantes e funcionais em um ambiente tecnológico em constante evolução, além de facilitar a integração com novas tecnologias e requisitos de negócios.

Por fim, discutiremos o conceito de evolução de software, enfatizando a importância de adaptar continuamente o software às mudanças no ambiente operacional e nos requisitos do usuário. Isso inclui a adição de novas funcionalidades, correção de bugs e atualizações para garantir a competitividade e a eficácia contínua do software. Compreender e aplicar práticas eficazes de evolução de software é essencial para manter a relevância e o valor do software ao longo do tempo, garantindo sua capacidade de atender às necessidades em constante mudança dos usuários e do mercado.

Para exercitar esses conceitos, vamos imaginar que você está analisando um sistema de gestão de bibliotecas desenvolvido há mais de uma década, que utiliza tecnologias que, ao longo dos anos, se tornaram obsoletas. Embora o sistema ainda funcione, enfrenta problemas de desempenho, dificuldades de integração com novos sistemas e uma interface de usuário antiquada. A equipe de TI da biblioteca reconheceu a necessidade de modernizar o sistema para melhorar sua eficiência, usabilidade e capacidade de adaptação a novas tecnologias.

Desafios identificados:

• Tecnologia obsoleta: o sistema foi construído usando uma pilha tecnológica que não é mais suportada, dificultando a manutenção e a atualização.
• Código Monolítico: a arquitetura monolítica do sistema dificulta a implementação de novas funcionalidades e a correção de bugs.
• Interface de usuário antiquada: a interface do usuário não é intuitiva e não segue as práticas modernas de UX/UI, resultando em uma experiência de usuário pobre.
• Desempenho: problemas de desempenho afetam a escalabilidade do sistema e a satisfação do usuário.
• Integração: dificuldades em integrar o sistema com novas plataformas e serviços on-line.

Com os conceitos de manutenção, evolução e reengenharia, proponha objetivos e soluções para minimizar esses desafios identificados.

Bons estudos!

Vamos Começar!

Classificação e tipos de atividades de manutenção de software

Após um período de uso prolongado, os sistemas operacionais eventualmente deixam de receber suporte das empresas, o que implica na interrupção das correções e atualizações disponibilizadas para eles. Por outro lado, os sistemas operacionais de código aberto não são descontinuados, pois a comunidade que os sustenta os aprimora continuamente, implementando correções e introduzindo novas funcionalidades de forma regular.

É notável como diferentes abordagens são adotadas para lidar com o envelhecimento do software. Os processos de evolução e manutenção acompanham o ciclo de vida do sistema e, em algumas situações, quando alcançam o ponto de maturidade, o software pode ser descontinuado. Nesta seção de aprendizado, exploraremos a necessidade de evolução e manutenção do software, discutiremos a classificação e os tipos de atividades de manutenção geralmente realizadas. Também examinaremos o papel das ferramentas nos processos de manutenção, e, por fim, veremos como a engenharia reversa e a reengenharia podem contribuir para a manutenção e a evolução dos softwares.

Antes de nos aprofundarmos nessas discussões, é importante compreendermos a motivação para estudar esses tópicos. Vamos considerar, por exemplo, o desenvolvimento de um aplicativo para rastreamento de animais de estimação por meio de um chip de localização. Quando lançado, o aplicativo tinha um número limitado de usuários e oferecia apenas métodos de pagamento por cartão (crédito e débito). Com o tempo, o número de usuários cresceu significativamente, novos métodos de pagamento, como o PIX, foram introduzidos, e surgiram novas tecnologias de rastreamento.

Podemos observar como a evolução de outras tecnologias teve um impacto direto na aplicação. Para entendermos melhor os processos de evolução e manutenção, é fundamental compreendermos inicialmente como ocorre o envelhecimento de um software.

Os softwares são construídos como sequências lógicas de algoritmos com o objetivo de cumprir os requisitos estabelecidos, os quais podem ser sujeitos a mudanças de requisitos e ao ambiente operacional. O processo de envelhecimento é inevitável e requer uma análise das causas, a fim de permitir sua evolução e/ou manutenção, garantindo assim sua continuidade. Vetorazzo (2018) identifica dois tipos de envelhecimento de software:

• Falha de adequação: ocorre quando a equipe encarregada da evolução do software comete erros ou falhas na adaptação ou implementação dos requisitos, resultando muitas vezes na perda da integridade e confiabilidade da aplicação. Exemplo prático: um software de conversão de formatos de vídeo que funcionava em uma versão específica do sistema operacional não é compatível com a versão mais recente desse sistema operacional. Se o software é usado por um usuário comum, é provável que ele busque outra solução. No entanto, se uma empresa depende desse software em suas operações e, em certo ponto, atualiza seus computadores para uma versão não compatível do sistema operacional, isso se torna um problema significativo.
• Falha na mudança: ocorre quando uma atualização, manutenção ou implementação afeta negativamente outras funcionalidades já em pleno funcionamento. Exemplo prático: Um e-commerce tem apenas um gerador de boletos funcionando, mas devido a demandas dos usuários, precisa adicionar outras formas de pagamento. Para isso, uma API de módulo de pagamentos é implementada incorretamente. O impacto desse erro é a falha no funcionamento tanto do sistema gerador de boletos quanto do módulo de pagamentos diversos, devido ao desconhecimento da estrutura do gerador de boletos.

Você percebeu a importância da evolução e manutenção dos softwares? São muitos aspectos a serem considerados: mudanças nos sistemas operacionais, padrões de consumo, novas modalidades e métodos de pagamento, questões de segurança, e uma variedade de outros elementos. No entanto, como podemos prever o envelhecimento do software? Isso só seria possível se tivéssemos acesso a informações de todas as empresas de tecnologia da informação, as quais, com uma simples alteração, poderiam influenciar o funcionamento do sistema de alguma forma – o que é praticamente impossível.

Entretanto, compreender a classificação e os tipos de atividades de manutenção de softwares oferece uma vantagem em termos de prontidão para lidar com ajustes, manutenções, atualizações e adaptações do sistema em situações de falhas.

Nesse sentido, Pressman (2021) argumenta que a evolução de um sistema pode ter diferentes propósitos, que vão além da simples correção de falhas, bugs, erros e inconsistências. Para entender melhor como são classificadas as atividades de manutenção, o Quadro 1 apresenta essas diferenças.

CLASSIFICAÇÃO	CONCEITO	APLICAÇÃO
Adaptativa	São modificações necessárias para estar de acordo com novos requisitos, os quais podem ser provenientes de leis, regras, ameaças, meios ou métodos novos.	Recentemente (no ano de 2020) o Banco Central autorizou as instituições financeiras a utilizarem o PIX como método de pagamento. Isso exigiu uma adaptação do sistema de internet banking para que essa nova funcionalidade estivesse disponível aos clientes.
Corretiva	Sua função é corrigir falhas ou qualquer outro aspecto que seja motivo de degradação dos serviços de software. Além disso, a manutenção corretiva pode ocorrer antes, nas fases de desenvolvimento, ou depois, com o software já em funcionamento.	Nas eleições municipais de 2020, para que as pessoas que não foram votar pudessem justificar o voto, o governo federal disponibilizou um aplicativo para mobile conhecido como e-título. No primeiro turno, ele apresentou problemas desde a sua instalação até o processo de realizar a justificativa. A única funcionalidade em conformidade era a consulta da situação do eleitor quanto à Justiça Eleitoral. No segundo turno, o aplicativo teve de passar por uma manutenção corretiva para que fossem efetuados os ajustes necessários.
Evolutiva	A manutenção evolutiva tem o objetivo de inserir novas funcionalidades no sistema.	Os chats eram um recurso bastante presente no e-commerce para atendimento aos clientes. Uma evolução desse tipo de atendimento é, em vez de ter um colaborador de plantão para atendimento no chat, utilizar atendimento virtual. Para isso, foram desenvolvidos algoritmos que utilizam inteligência artificial, os quais, com a evolução tecnológica, conseguem responder grande parte das dúvidas dos clientes.

Quadro 1 | Classificação e tipos de manutenção de software. Fonte: adaptado de Pressman (2021).

O conhecimento da classificação dos tipos de manutenção, em termos profissionais, permite que tanto um desenvolvedor quanto um gestor se posicione quanto às reais necessidades dentro da estrutura do sistema, facilitando o direcionamento de recursos dentro do ciclo de vida de desenvolvimento de software. Para tal, é necessário conhecer os processos e as ferramentas utilizados na manutenção de software, os quais são recursos de extrema importância para que, de fato, os processos sejam otimizados.

Engenharia reversa e reengenharia

A reengenharia de software é um processo destinado a reorganizar e/ou modificar um sistema de forma a restaurar seu desempenho para um nível aceitável. Alguns fatores, como a falta de atualização do software ou um excesso de mudanças frequentes (especialmente quando realizadas por equipes distintas), podem levar à degradação dos serviços prestados pelo sistema (Pádua, 2019).

Nessas circunstâncias, tentar encontrar soluções dentro de um sistema comprometido pode não resultar no desempenho desejado e ainda consumir recursos significativos. Assim, optar por uma reconstrução que inclua a correção de erros e falhas, juntamente com as atualizações necessárias, emerge como uma abordagem eficaz na busca por soluções.

O objetivo da reengenharia de software é reimplementar sistemas legados, buscando (Pádua, 2019):

• Aprimorar a manutenção: ao reestruturar o sistema, as futuras atividades de manutenção se tornam mais acessíveis, uma vez que os erros antigos são corrigidos na nova versão.
• Atualizar a documentação do software: durante a reestruturação do software, a documentação é atualizada, possibilitando a inclusão de novas informações nos scripts.
• Refazer a estrutura do sistema: as estruturas que anteriormente dependiam de soluções paliativas e correções podem ser reformuladas, permitindo a criação de um sistema otimizado que atenda aos requisitos de forma mais eficaz.

Quando um software é desenvolvido, certas funcionalidades e módulos demandam consideráveis esforços de desenvolvimento. Apesar de passar por testes, ao longo do tempo, é comum que o sistema possa apresentar falhas. No entanto, no contexto da reengenharia de software, que pode ser compreendida como uma revisão dos algoritmos, é possível afirmar que a probabilidade de erro é reduzida. Pádua (2019) sustenta que os processos de reengenharia tendem a ter riscos mitigados, uma vez que alguns problemas já foram previamente tratados.

Esses processos são apoiados em metodologias de operacionalização, como apresentado na Figura 1.

Siga em Frente...

Observe que, ao longo dessa discussão, esses processos foram explorados e exemplificados. Porém, um novo termo muito importante quanto à manutenção e à evolução dos softwares foi citado no modelo representado na Figura 1: engenharia reversa.

A engenharia reversa é o processo de reconstrução do software que parte do princípio de recuperação do código para tornar compreensíveis suas funcionalidades. Assim, elas podem ser reescritas com vistas a serem otimizadas e corrigidas (Pressman, 2021).

É evidente que a aplicação da engenharia reversa em hardware torna a técnica visualmente mais acessível, pois podemos mentalmente desmontar os componentes, o que facilita a compreensão da ordem de montagem. Além disso, podemos analisar individualmente cada componente para compreender seu propósito e funcionamento.

No entanto, como a engenharia reversa é abordada no contexto do software? Antes de responder a essa pergunta, é instrutivo observar a Figura 3.

Observe que os métodos de engenharia reversa gradualmente se concentram na reestruturação do código, facilitando a compreensão das funcionalidades, incluindo entradas e saídas, interface e operações.

De acordo com Pádua (2019), ao empregar os processos e as técnicas de engenharia reversa, é possível examinar o software de diversas perspectivas, como:

• Nível de implementação: possibilita entender as características e as peculiaridades da linguagem de programação utilizada na implementação.
• Nível estrutural: permite compreender os diferentes módulos, funcionalidades e suas interdependências funcionais, analisando a estrutura da linguagem de programação empregada.
• Nível funcional: facilita a compreensão das partes que constituem o sistema, com foco na lógica aplicada durante o desenvolvimento.
• Nível de domínio: oferece insights sobre os ambientes em que o software é aplicado.

Dessa forma, em termos profissionais, tanto a reengenharia quanto a engenharia reversa demandam técnicas relativamente simples, porém, desafiadoras de operacionalizar. Essas técnicas são frequentemente utilizadas em práticas diárias para reduzir o tempo de desenvolvimento. Como resultado, espera-se melhorias substanciais, uma vez que muitas das funcionalidades já foram desenvolvidas anteriormente.

Evolução de software

Assim como em todos os processos de software, não há um método padrão único para mudança ou evolução de software. O tipo de evolução mais adequado para um sistema de software depende da natureza do software em questão, dos processos de desenvolvimento de software adotados pela organização e das habilidades das pessoas envolvidas. Para certos tipos de sistemas, como aplicativos móveis, a evolução pode ser um processo informal, em que as alterações são geralmente sugeridas em conversas entre os usuários e os desenvolvedores do sistema. Por outro lado, para sistemas críticos embarcados, a evolução do software pode ser formalizada, com documentação estruturada produzida em cada fase do processo.

Propostas de mudança, tanto formais quanto informais, são impulsionadoras da evolução dos sistemas em todas as organizações. Uma proposta de mudança envolve um indivíduo ou grupo sugerindo modificações e atualizações em um sistema de software existente. Essas propostas podem se originar de requisitos existentes que não foram implementados no sistema original, solicitações de novos requisitos, relatórios de defeitos emitidos por partes interessadas no sistema, ou novas ideias da equipe de desenvolvimento para melhorar o software (Sommerville, 2018). Os processos de identificação de mudanças e evolução do sistema são cíclicos e continuam ao longo de toda a vida útil de um sistema, apresentado na Figura 4.

Antes que uma proposta de mudança seja aceita, é necessário realizar uma análise detalhada do software para determinar quais componentes precisam ser alterados. Essa análise permite a avaliação do custo e do impacto da mudança, sendo parte integrante do processo global de gerenciamento de mudanças. Esse processo também visa garantir que as versões corretas dos componentes sejam incluídas em cada lançamento do sistema.

A Figura 5 ilustra algumas das atividades envolvidas na evolução do software. O processo engloba atividades fundamentais, como análise da mudança, planejamento de lançamento, implementação do sistema e lançamento do sistema para os clientes. Durante esse processo, o custo e o impacto das mudanças são cuidadosamente avaliados para determinar em que medida o sistema será afetado pela mudança e qual seria o custo de sua implementação.

Se as mudanças propostas forem aceitas, é iniciado o planejamento de um novo lançamento do sistema, no qual todas as mudanças propostas, sejam elas para reparar defeitos, adaptar ou adicionar novas funcionalidades, são cuidadosamente consideradas. Em seguida, uma decisão é tomada sobre quais mudanças serão implementadas na próxima versão do sistema. Após a implementação e a validação das mudanças, uma nova versão do sistema é lançada. Esse processo é então iterado com um novo conjunto de mudanças propostas para o próximo lançamento (Sommerville, 2018).

Em situações em que o desenvolvimento e a evolução são integrados, a implementação da mudança é simplesmente uma iteração do processo de desenvolvimento. As revisões no sistema são projetadas, implementadas e testadas. A única diferença entre o desenvolvimento inicial e a evolução é que o feedback do cliente após a entrega precisa ser considerado no planejamento dos novos lançamentos de uma aplicação.

Vamos Exercitar?

Este estudo de caso demonstra a importância da reengenharia e manutenção de software para adaptar sistemas antigos às exigências atuais e futuras. Essa são possíveis sugestões para enfrentar o desafio de um sistema legado de uma biblioteca.

Objetivos da Reengenharia

• Atualizar a pilha tecnológica: migrar para tecnologias modernas e suportadas para facilitar a manutenção e a expansão futura.
• Refatorar o código: transformar o código monolítico em uma arquitetura baseada em microserviços para melhorar a modularidade e facilitar a introdução de novas funcionalidades.
• Melhorar a interface de usuário: redesenhar a interface do usuário para melhorar a usabilidade e a acessibilidade, seguindo as práticas atuais de UX/UI.
• Otimizar o desempenho: identificar e corrigir gargalos de desempenho para melhorar a eficiência e escalabilidade.
• Facilitar a integração: implementar APIs RESTful para facilitar a integração com outros sistemas e serviços.

Processo de Reengenharia

• Análise e planejamento: realização de uma auditoria completa do sistema existente para identificar componentes críticos, funcionalidades e dados a serem preservados ou melhorados.
• Seleção de tecnologias: escolha das tecnologias modernas adequadas para a reengenharia do sistema, incluindo frameworks, bancos de dados e ferramentas de desenvolvimento.
• Desenvolvimento incremental: aplicação de uma abordagem ágil para o desenvolvimento, permitindo a entrega iterativa de funcionalidades e facilitando o feedback contínuo dos usuários finais.
• Testes rigorosos: implementação de testes automatizados para garantir a qualidade do código, a funcionalidade e a segurança do sistema remodelado.
• Migração de dados: planejamento e execução de uma estratégia de migração de dados para transferir informações existentes para o novo sistema sem perda de dados.

Saiba Mais

Existem métricas de Manutenção. Para ler mais sobre esse assunto, leia o capítulo 23.5 do livro Engenharia de Software - Pressman.

Quer saber mais sobre Gerenciamento de mudanças? Leia o Capítulo 25.3 de Engenharia de Software - Sommerville.

Para saber mais sobre a Engenharia reversa, leia o Capítulo 27.2.3 do livro Engenharia de Software - Pressman.

Referências Bibliográficas

PÁDUA, W. Engenharia de Software. 1ª Ed. Rio de Janeiro: LTC, 2019.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

VETORAZZO, A. de S. Engenharia de software. Porto Alegre: SAGAH, 2018.

Gestão de risco

Na aula de hoje abordaremos os riscos de software, técnicas de identificação e previsão de riscos, além de estratégias de mitigação, monitoramento e gestão de riscos (RMMM). Esses temas são essenciais para a prática profissional na área de desenvolvimento de software, permitindo uma abordagem proativa na identificação e tratamento de potenciais problemas que podem surgir durante o ciclo de vida do projeto. Prepare-se para aprender a lidar com os desafios do gerenciamento de riscos e a garantir o sucesso dos seus projetos de software.

Ponto de Partida

Nesta aula será abordado os fundamentos dos riscos de software, começando com a sua definição e importância na gestão de projetos de desenvolvimento de software. Em seguida, são discutidas as etapas de identificação e previsão do risco, destacando a necessidade de antecipar e compreender os potenciais problemas que podem surgir ao longo do projeto. A importância dessa fase reside na capacidade de tomar medidas proativas para evitar ou minimizar os impactos negativos dos riscos identificados.

Outro ponto abordado na aula é a mitigação, o monitoramento e a gestão de riscos (RMMM). Essa etapa envolve o desenvolvimento de estratégias para lidar com os riscos, tanto antes quanto durante a execução do projeto. A mitigação visa reduzir a probabilidade de ocorrência de riscos, enquanto o monitoramento é essencial para acompanhar a evolução dos riscos ao longo do tempo e garantir a implementação eficaz das medidas de mitigação. Por fim, a gestão de riscos envolve a elaboração de planos de contingência para lidar com os riscos que se materializam, garantindo assim a continuidade e o sucesso do projeto.

Esses conceitos são fundamentais para os profissionais de desenvolvimento de software, uma vez que ajudam a garantir a entrega de projetos dentro do prazo, do orçamento e com a qualidade esperada. Ao compreender e aplicar técnicas de identificação, previsão, mitigação, monitoramento e gestão de riscos, os profissionais podem minimizar os impactos negativos dos imprevistos e aumentar as chances de sucesso em seus projetos de software.

Para exercitar esses conceitos, vamos imaginar a seguinte situação: um grande sistema de informações hospitalares estava enfrentando desafios significativos devido a tecnologias obsoletas, problemas de segurança de dados e ineficiências operacionais. A direção do hospital decidiu empreender uma migração completa do sistema para uma plataforma moderna e mais segura. Dada a criticidade dos dados de saúde e a necessidade de manter operações ininterruptas, a gestão de riscos e a aplicação do Modelo de Mitigação de Riscos, Monitoramento e Manutenção (RMMM) tornaram-se fundamentais para o sucesso do projeto.

Desafios identificados:

• Interrupção das operações hospitalares: riscos associados à transição de sistemas que poderiam impactar as operações diárias do hospital.
• Segurança de dados: potencial de violação de dados durante a migração, afetando a privacidade e a segurança do paciente.
• Compatibilidade de dados: desafios na migração de dados existentes para o novo sistema sem perda ou corrupção.
• Aceitação dos usuários: resistência do pessoal do hospital à adoção do novo sistema.
• Sobrecarga de custos e prazos: riscos de exceder o orçamento e os prazos devido a complicações imprevistas.

Com os conceitos de gestão de riscos e RMMM, proponha objetivos e soluções para minimizar esses desafios identificados.

Bons estudos!

Vamos Começar!

Riscos de software

Ao abordar riscos na engenharia de software é importante ter uma preocupação com o futuro, examinando quais riscos podem afetar negativamente o projeto de software. A mudança é outra área de foco, considerando como alterações nos requisitos do cliente, tecnologias de desenvolvimento e outros fatores impactam o andamento e o sucesso do projeto. Além disso, as escolhas são cruciais, exigindo considerações sobre métodos, ferramentas e alocação de recursos para garantir o progresso e a qualidade adequada.

O conceito de débito técnico surge como uma preocupação relacionada aos custos associados ao adiamento de atividades essenciais, como a documentação de software e a refatoração. Ignorar o débito técnico pode resultar em produtos de software com funcionalidades deficientes, comportamentos inconsistentes e documentação inadequada. A analogia com juros financeiros destaca como o débito técnico aumenta ao longo do tempo, ressaltando a importância de resolver problemas técnicos durante fases anteriores do desenvolvimento para evitar complicações futuras.

Embora o desenvolvimento ágil de software seja amplamente adotado, não elimina a necessidade de uma gestão de riscos eficaz. Estudos demonstram que equipes ágeis podem acumular débito técnico devido a demandas crescentes por código e falta de dedicação para reduzi-lo (Sommerville, 2018). Além disso, equipes inexperientes podem produzir mais defeitos e utilizar ferramentas não padronizadas, resultando em processos menos documentados e propensos a repetir erros. No entanto, a conscientização e o planejamento cuidadoso durante sprints definidos podem ajudar a mitigar esses riscos e garantir o sucesso dos projetos.

Embora haja controvérsias sobre a definição precisa de risco de software, existe um consenso geral de que o risco sempre possui duas características essenciais: incerteza e perda. A incerteza implica que um risco pode ou não se concretizar, não existindo riscos com uma probabilidade de 100%. Já a perda refere-se às consequências indesejadas que ocorrerão se o risco se materializar. Ao analisar os riscos, é crucial quantificar tanto o nível de incerteza quanto o grau de perda associado a cada um, considerando diferentes categorias de risco.

Os riscos de projeto representam ameaças ao plano do projeto, podendo resultar em atrasos no cronograma e aumento nos custos caso se materializem. Eles abrangem problemas potenciais relacionados ao orçamento, ao cronograma, à equipe, aos recursos e aos requisitos, bem como à complexidade, ao tamanho e à incerteza estrutural do projeto. Por outro lado, os riscos técnicos ameaçam a qualidade e a entrega do software, dificultando ou impossibilitando sua implementação. Eles englobam problemas relacionados ao projeto, à implementação, à interface, à verificação, às manutenção, às especificações ambíguas, à incerteza técnica e à tecnologia obsoleta (Pressman, 2021).

Os riscos de negócio colocam em risco a viabilidade do software a ser desenvolvido e frequentemente afetam o projeto ou o produto como um todo. Eles incluem criar um produto que não atende às demandas do mercado, não se alinha à estratégia de negócios da empresa, não é compreendido pela equipe de vendas, perde o apoio da alta gerência devido a mudanças organizacionais ou enfrenta restrições orçamentárias. Identificar e gerenciar esses riscos é crucial para o sucesso de um projeto de software.

É crucial ressaltar que uma simples classificação de riscos nem sempre é eficaz, pois alguns riscos são simplesmente impossíveis de serem previstos. Os riscos conhecidos são aqueles que podem ser identificados por meio de uma avaliação cuidadosa do plano do projeto, do ambiente técnico e comercial envolvido, e de outras fontes confiáveis de informação. Por exemplo, datas de entrega irrealistas, falta de documentação de requisitos ou escopo do software e ambientes de desenvolvimento inadequados são considerados riscos conhecidos. Os riscos previsíveis, por sua vez, são derivados da experiência em projetos anteriores, como a rotatividade da equipe, comunicação deficiente com o cliente e diluição do esforço da equipe à medida que novas solicitações de manutenção surgem. Já os riscos imprevisíveis são uma incógnita. Embora possam ocorrer, são extremamente difíceis de serem identificados com antecedência (Pressman, 2021).

Identificação e previsão do risco

A identificação de riscos é um processo sistemático para especificar ameaças ao plano do projeto, incluindo estimativas, cronogramas e recursos. Ao reconhecer os riscos conhecidos e previsíveis, o gerente de projeto dá o primeiro passo para evitar ou controlar essas ameaças, quando possível. Há dois tipos de riscos: os genéricos, que representam ameaças potenciais a qualquer projeto de software, e os específicos do produto, identificados apenas por aqueles familiarizados com a tecnologia, as pessoas e o ambiente específico do software. Embora os riscos genéricos sejam importantes, são os riscos específicos do produto que frequentemente causam os maiores problemas. Portanto, é crucial dedicar tempo à identificação minuciosa desses riscos.

Uma abordagem para identificar riscos é criar uma lista de verificação de itens de risco, concentrando-se em subconjuntos dos riscos conhecidos e previsíveis. Essa lista pode incluir subcategorias genéricas como o tamanho do produto, o impacto nos negócios, as características dos envolvidos, a definição do processo, o ambiente de desenvolvimento, a tecnologia envolvida e a experiência da equipe. Ao examinar o plano do projeto e a definição do escopo, é possível desenvolver respostas para perguntas como "Quais características especiais deste produto podem ameaçar nosso plano de projeto?" Esta abordagem estruturada ajuda a garantir que os riscos sejam identificados de maneira abrangente e que as estratégias apropriadas possam ser implementadas para mitigá-los.

Mas como podemos determinar se o projeto de software em que estamos envolvidos está enfrentando sérios riscos? As seguintes questões foram elaboradas com base em dados de risco coletados por meio de entrevistas com experientes gerentes de projetos de software em diversas partes do mundo. Essas questões foram organizadas por sua importância relativa para o sucesso do projeto (Pressman, 2021).

• A alta gerência e o cliente estão formalmente comprometidos em apoiar o projeto?
• Os usuários estão genuinamente comprometidos com o projeto e o sistema/produto a ser desenvolvido?
• Os requisitos são claramente compreendidos pela equipe de engenharia de software e pelos clientes?
• Os clientes foram totalmente envolvidos na definição dos requisitos?
• As expectativas dos usuários são realistas?
• O escopo do projeto permanece estável?
• A equipe de engenharia de software possui as habilidades necessárias?
• Os requisitos de projeto estão bem definidos e estáveis?
• A equipe de projeto possui experiência com a tecnologia a ser utilizada?
• O tamanho da equipe de projeto é adequado para a tarefa?
• Todos os clientes e usuários concordam com a importância do projeto e os requisitos do sistema/produto a ser desenvolvido?

Se alguma dessas questões receber uma resposta negativa, medidas de mitigação, monitoramento e gerenciamento devem ser imediatamente implementadas. O nível de risco do projeto está diretamente relacionado ao número de respostas negativas a essas perguntas.

A Força Aérea Americana publicou um livreto contendo diretrizes valiosas para a identificação e gestão de riscos de software. Segundo a abordagem da Força Aérea, o gerente de projeto deve identificar os fatores de risco que afetam os componentes cruciais do software: desempenho, custo, suporte e cronograma. Esses componentes de risco são definidos da seguinte maneira (Pressman, 2021):

• Risco de desempenho: refere-se à incerteza sobre se o produto atenderá aos requisitos e será adequado para o uso pretendido.
• Risco de custo: indica a incerteza sobre a manutenção do orçamento do projeto.
• Risco de suporte: relaciona-se à incerteza sobre a facilidade de correção, adaptação e melhoria do software resultante.
• Risco de cronograma: reflete a incerteza sobre a manutenção do cronograma do projeto e a entrega oportuna do produto.

O impacto de cada fator de risco sobre esses componentes é categorizado como negligenciável, marginal, crítico ou catastrófico. Um impacto negligenciável resulta apenas em inconvenientes, com um custo adicional de mitigação muito baixo. Um impacto marginal pode afetar requisitos secundários ou objetivos de missão, mas não compromete o sucesso geral da missão, com um custo um pouco mais elevado, porém, factível (Pádua, 2019). Um impacto crítico afeta diretamente o desempenho do sistema e parte ou todos os requisitos, colocando em risco o sucesso da missão, com um custo significativamente mais alto para mitigação. Por fim, um impacto catastrófico resultaria no fracasso da missão, com um custo de mitigação inaceitável.

A previsão de risco, também conhecida como estimativa de risco, busca classificar cada risco de duas maneiras distintas: (1) a probabilidade de o risco se materializar e (2) as consequências associadas caso o risco se concretize. Em colaboração com outros gerentes e profissionais técnicos, são executadas quatro etapas para a projeção de risco (Pressman, 2021):

1. Estabelecimento de uma escala que represente a probabilidade percebida de um risco.
2. Descrição das possíveis consequências do risco.
3. Avaliação do impacto do risco sobre o projeto e o produto.
4. Análise da precisão geral da projeção de risco para evitar mal-entendidos.

O propósito dessas etapas é abordar os riscos de maneira a definir prioridades, uma vez que nenhuma equipe de software dispõe de recursos para lidar com todos os riscos de forma igualmente rigorosa. Ao priorizar os riscos, é possível direcionar os recursos para áreas em que terão o maior impacto.

Elaborar uma tabela de riscos é uma técnica simples para a projeção de riscos. Um exemplo é apresentado na Figura 1.

O processo de priorização de riscos inicia-se com a listagem de todos os riscos na primeira coluna de uma tabela, independentemente de sua probabilidade de ocorrência. Em seguida, cada risco é caracterizado na segunda coluna, indicando sua natureza, como risco de tamanho do projeto ou risco de negócio (Pádua, 2019). A probabilidade de cada risco é estimada pelos membros da equipe e registrada na terceira coluna da tabela. Posteriormente, o impacto de cada risco é avaliado com base em componentes como desempenho, custo e cronograma, e é determinada uma categoria de impacto para cada um.

Após o preenchimento das primeiras quatro colunas, a tabela é ordenada por probabilidade e impacto, priorizando os riscos de alta probabilidade e alto impacto. O gerente de projetos estabelece uma linha de corte na tabela, acima da qual todos os riscos devem ser gerenciados. As estratégias de mitigação, monitoramento e gestão de risco são então definidas no plano RMMM ou em formulários de informações específicos para cada risco, discutidos em seções subsequentes (Pressman, 2021).

Embora a probabilidade dos riscos possa ser determinada inicialmente por estimativas individuais e, posteriormente, por consenso, abordagens mais avançadas, como o uso de lógica difusa, têm sido desenvolvidas para avaliar a probabilidade de riscos mais complexos e inter-relacionados em projetos de software. Essas técnicas buscam compreender melhor o impacto combinado dos riscos, especialmente em situações em que a incerteza é elevada e múltiplos fatores estão envolvidos.

Siga em Frente...

Mitigação, monitoramento e gestão de riscos (RMMM)

Todas as etapas de análise de risco até agora têm um objetivo único: auxiliar a equipe de projeto na formulação de uma estratégia para lidar com os riscos. Uma estratégia eficiente precisa abordar três aspectos essenciais: como evitar, monitorar e gerenciar os riscos, além de planejar a contingência (Sommerville, 2018).

Quando a equipe adota uma postura proativa em relação aos riscos, a prevenção se torna a estratégia primordial. Isso envolve a criação de um plano de mitigação de riscos. Por exemplo, se a alta rotatividade de pessoal é identificada como um risco significativo, medidas para reduzi-lo podem incluir investigar suas causas, abordá-las antes do início do projeto e desenvolver técnicas para garantir a continuidade mesmo em caso de saída de membros da equipe.

Durante o projeto, é fundamental antecipar a possibilidade de rotatividade e implementar práticas para minimizar seu impacto. Isso pode incluir a disseminação ampla das informações entre as equipes, o estabelecimento de padrões para os produtos do projeto e a designação de substitutos para membros críticos da equipe, garantindo assim a continuidade das operações (Pressman, 2021).

À medida que o projeto avança, iniciam-se as atividades de monitoramento de risco, nas quais o gerente de projeto acompanha fatores que indicam a evolução da probabilidade de ocorrência dos riscos. No caso da alta rotatividade de pessoal, são observados aspectos como a dinâmica da equipe, as relações interpessoais, questões salariais e a disponibilidade de oportunidades externas.

Além disso, é fundamental monitorar a eficácia das medidas de mitigação adotadas. Por exemplo, se foram estabelecidos padrões para os produtos, é necessário garantir que cada um seja autossuficiente e contenha as informações essenciais para integrar novos membros à equipe, se necessário.

Em situações em que as medidas de mitigação falham e o risco se materializa, entra em vigor a gestão de riscos e o plano de contingência. Por exemplo, se um grupo de pessoas anuncia sua saída durante o projeto, é crucial contar com substitutos disponíveis, documentação adequada e transferência de conhecimento para garantir a continuidade das operações e minimizar o impacto da transição (Pressman, 2021).

As etapas de mitigação, monitoramento e gestão de risco, embora essenciais, implicam custos adicionais para o projeto. Por exemplo, criar backups para tecnologias críticas consome recursos financeiros e de tempo. Portanto, é crucial realizar uma análise de custo-benefício para determinar se os benefícios das medidas de gerenciamento de risco superam os custos associados à sua implementação. Em alguns casos, pode ser mais sensato continuar monitorando o risco em vez de mitigá-lo, especialmente se os custos de mitigação forem consideráveis em relação à exposição ao risco.

Ao identificar e avaliar os riscos de um grande projeto, é importante aplicar a regra de Pareto, conhecida como regra 80-20. Esta sugere que a maior parte do risco geral do projeto está associada a uma minoria dos riscos identificados. Portanto, é fundamental concentrar os esforços de gerenciamento nos riscos mais críticos, que representam 20% dos riscos identificados. Nem todos os riscos identificados precisam ser incluídos no plano de mitigação, pois muitos podem não contribuir significativamente para a exposição ao risco.

Para incentivar os desenvolvedores a seguir procedimentos de conformidade com processos, como qualidade e gestão de riscos, a gamificação tem sido proposta como uma abordagem eficaz. Isso envolve conceder recompensas não monetárias, como pontos ou medalhas, aos membros da equipe por seguir as melhores práticas. No entanto, é crucial garantir que essa abordagem não encoraje comportamentos prejudiciais, como introduzir problemas no processo para resolvê-los posteriormente e ganhar recompensas. Além disso, os riscos associados ao software não se limitam ao desenvolvimento; é necessário considerar também os riscos após a entrega do software ao cliente, como problemas de segurança e imprevistos que podem afetar negativamente o sistema.

O plano RMMM

A estratégia de gestão de risco pode ser integrada ao plano geral do projeto de software ou ser delineada em um plano separado de mitigação, monitoramento e gestão (RMMM). O plano RMMM registra todas as atividades realizadas durante a análise de risco e serve como parte integrante do plano global do projeto.

Algumas equipes de software optam por não elaborar um documento formal RMMM. Em vez disso, cada risco é registrado individualmente por meio de um formulário de informações de risco (RIS). Esses formulários são frequentemente mantidos em um sistema de banco de dados na nuvem para facilitar a inserção de dados, a priorização, as análises e o compartilhamento entre as equipes de software. Essa abordagem pode favorecer a implementação da gamificação no processo de gestão de riscos e facilitar a colaboração entre as equipes de software da organização. O formato do RIS é exemplificado no Quadro 1:

Formulário de informações de risco
ID do risco: P02-4.32	Data: 09/05/19	Prob: 80%	Impacto: alto
Descrição: Somente 70% dos componentes de software programados para reutilização serão, de fato, integrados na aplicação. A funcionalidade restante terá de ser desenvolvida de maneira personalizada.
Refinamento/contexto: Subcondição 1: Certos componentes reutilizáveis foram desenvolvidos por uma equipe terceirizada que não conhecia os padrões internos de projeto. Subcondição 2: O padrão de projeto para as interfaces do componente não foi completamente estabelecido e pode não estar em conformidade com certos componentes reutilizáveis existentes. Subcondição 3: Certos componentes reutilizáveis foram implementados em uma linguagem não suportada no ambiente em que serão usados.
Mitigação/monitoramento: 1. Contate a equipe terceirizada para determinar a conformidade com os padrões de projeto. 2. Pressione para que haja padronização da interface; considere a estrutura de componente ao decidir sobre o protocolo de interface. 3. Determine o número de componentes que estão na categoria da subcondição; determine se pode ser adquirido o suporte de linguagem.
Gerenciamento/plano de contingência/disparo: Foi calculada a exposição ao risco: US$ 20.200. Reserve esse valor no custo de contingência do projeto. Desenvolva um cronograma revisado assumindo que 18 componentes adicionais terão de ser criados de forma personalizada; defina e adote um padrão de interface consistente. Estarão disponíveis as provisões para mitigação imprevistas em 01/07/19.
Estado atual: 12/05/19: Providências para mitigação iniciadas.
Autor. D. Gagne		Designado: B. Laster

Quadro 1 | Formulário de informações de risco. Fonte: adaptado de Pressman (2021).

Após a documentação do RMMM e o início do projeto, entram em cena as etapas de mitigação e monitoramento de risco. Como já explorado, a mitigação de risco visa evitar problemas, enquanto o monitoramento de risco é uma atividade contínua durante o projeto, com três objetivos principais: (1) avaliar se os riscos antecipados realmente se materializam; (2) garantir a implementação adequada das medidas de mitigação definidas para cada risco; e (3) reunir informações úteis para análises de riscos futuras. Em muitas situações, os problemas que surgem ao longo do projeto podem estar associados a diversos riscos. Portanto, outra função crucial do monitoramento de risco é tentar identificar a causa raiz, isto é, quais riscos contribuíram para a ocorrência de determinados problemas durante o projeto (Pressman, 2021).

Vamos Exercitar?

Este estudo de caso destaca a importância do RMMM na gestão de projetos complexos e de alta stakes, como a migração de sistemas de informações hospitalares. Ao identificar, analisar, mitigar e monitorar continuamente os riscos, a equipe de projeto foi capaz de navegar com sucesso pelos desafios, garantindo a segurança dos dados dos pacientes e a continuidade das operações hospitalares. A abordagem RMMM provou ser uma ferramenta valiosa na garantia do sucesso do projeto e na manutenção da confiança das partes interessadas.

Objetivos do RMMM

• Identificação e análise de riscos: mapear todos os riscos potenciais e avaliar sua probabilidade e impacto.
• Desenvolvimento de estratégias de mitigação: criar planos de ação específicos para reduzir, evitar ou transferir riscos.
• Implementação de monitoramento contínuo: estabelecer processos para monitorar o status dos riscos e a eficácia das estratégias de mitigação ao longo do projeto.
• Manutenção e ajustes: adaptar e refinar estratégias de mitigação com base no feedback do monitoramento contínuo.

Processo de Implementação do RMMM

1. Fase de Planejamento:

• Identificação de riscos: realização de sessões de brainstorming com as partes interessadas para identificar riscos.
• Análise de riscos: utilização de técnicas como análise qualitativa e quantitativa para priorizar riscos.

2. Desenvolvimento de estratégias de mitigação:

• Para interrupções operacionais, foi planejada uma implementação faseada, com migração durante horas de menor atividade.
• Em relação à segurança de dados, adotaram-se protocolos rigorosos de criptografia e transferência segura.
• Para enfrentar a compatibilidade de dados, realizou-se uma validação cruzada intensiva dos dados antes da migração final.
• Para a aceitação dos usuários, foram organizadas sessões de treinamento e suporte contínuo.
• Sobre sobrecarga de custos e prazos, estabeleceu-se um fundo de contingência e um cronograma flexível.

3. Monitoramento contínuo:

• Implementação de um sistema de relatórios periódicos e checkpoints de projeto para avaliar o progresso e identificar novos riscos.

4. Manutenção e ajustes:

• Ajustes nas estratégias de mitigação com base no monitoramento contínuo e no feedback das partes interessadas.

Resultados

A aplicação do RMMM permite à equipe de projeto gerenciar efetivamente os riscos durante a migração do sistema de informações hospitalares. A implementação faseada minimiza as interrupções operacionais, e as estratégias de segurança de dados garantiram uma transição segura dos registros dos pacientes.

Saiba Mais

Para ler mais sobre a Gestão de riscos, leia o Capítulo 26 do livro Engenharia de Software - Pressman.

Quer saber mais sobre o gerenciamento de riscos? Leia o Capítulo 22.1 de Engenharia de Software - Sommerville.

Veja no artigo Gerência de riscos em desenvolvimento de software, os aspectos e impactos da utilização de métodos relacionados a uma área específica da engenharia de software, a Gerência de riscos.

Referências Bibliográficas

PÁDUA, W. Engenharia de software. 1. ed. Rio de Janeiro: LTC, 2019.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

Métricas e análise de software

Na aula de hoje vamos explorar a medição de software, incluindo métricas de produtos, processos e projetos. Esses conceitos são fundamentais para a prática profissional na área de desenvolvimento de software, permitindo avaliar a qualidade, o desempenho e a eficiência dos produtos desenvolvidos, bem como dos processos e os projetos envolvidos em sua criação. Prepare-se para adquirir conhecimentos valiosos sobre como medir e melhorar continuamente a sua prática profissional na engenharia de software.

Ponto de Partida

Na aula de hoje iremos explorar os conceitos fundamentais relacionados à medição de software e ao uso de métricas para avaliar diferentes aspectos dos projetos de desenvolvimento. A medição de software é essencial para quantificar características como tamanho, complexidade e desempenho dos sistemas em desenvolvimento. As métricas de processos e projetos são cruciais para monitorar o progresso do projeto, identificar áreas de melhoria e garantir que os objetivos sejam alcançados dentro do prazo e do orçamento estabelecidos. Por fim, estabelecer um programa de métricas auxilia a ter um comprometimento com essa prática.

Compreender a medição de software e o uso de métricas é fundamental para o sucesso de qualquer projeto de desenvolvimento de software. Ao quantificar diferentes aspectos do software e do processo de desenvolvimento, as equipes podem identificar áreas de risco, tomar decisões informadas e implementar melhorias contínuas ao longo do ciclo de vida do projeto. As métricas fornecem uma base objetiva para avaliar o progresso, tomar decisões estratégicas e garantir que os padrões de qualidade sejam atendidos, resultando em produtos finais mais eficientes e confiáveis.

Ao integrar a medição de software e o uso de métricas em seus processos de desenvolvimento, as organizações podem melhorar a eficiência, reduzir custos e minimizar riscos. As métricas fornecem dados tangíveis que ajudam as equipes a identificar tendências, implementar melhores práticas e tomar medidas corretivas quando necessário. Em última análise, a medição de software e o uso de métricas capacitam as equipes a realizar entregas de alta qualidade de forma consistente, atendendo às necessidades dos clientes e alcançando os objetivos organizacionais.

Para sintetizar o conteúdo, vamos imaginar que você precise alinhar as operações da engenharia de software com os objetivos estratégicos de uma empresa de tecnologia. A primeira etapa envolve entender profundamente as aspirações comerciais da organização. O que a empresa está tentando alcançar? Com essa compreensão, você será capaz de determinar os conhecimentos que são necessários para apoiar essas aspirações. Apresente o motivo que uma implementação de um programa de métricas de software é importante para esta empresa.

Bons estudos!

Vamos Começar!

Medição de software

A medição é um componente essencial em qualquer processo de engenharia. No contexto do desenvolvimento de software, as medições desempenham um papel fundamental na melhoria contínua do processo. Elas são aplicadas ao longo do ciclo de vida do projeto para diversas finalidades, como aprimoramento das estimativas, garantia da qualidade, aumento da produtividade e controle do projeto. As medidas fornecem insights valiosos sobre os atributos dos modelos desenvolvidos e permitem a avaliação da qualidade dos produtos ou sistemas construídos.

Os engenheiros de software utilizam medições para avaliar a qualidade dos artefatos e apoiar decisões táticas durante o progresso do projeto. No entanto, ao contrário de outras disciplinas de engenharia, a engenharia de software não se baseia em leis quantitativas da física, o que torna as medidas e métricas indiretas e sujeitas a debate.

No contexto do desenvolvimento de software e dos projetos associados, a equipe se concentra principalmente em métricas de produtividade e qualidade. Isso inclui medir a saída do desenvolvimento em relação ao esforço e ao tempo aplicados, bem como a adequação dos artefatos produzidos para uso (Pádua, 2019). Para planejamento e estimativa, o foco está no histórico de produtividade e qualidade dos projetos anteriores, buscando extrapolar esses dados para o presente.

A medição serve tanto como ferramenta técnica quanto de gerenciamento, proporcionando maior entendimento ao gerente de projeto e ajudando na tomada de decisões para o sucesso do projeto. Este capítulo apresenta medidas para avaliar a qualidade do produto durante o processo de desenvolvimento e para gerenciar projetos de software, oferecendo uma visão em tempo real da eficácia dos processos e da qualidade geral do software em criação.

Embora os termos medida, medição e métricas sejam frequentemente utilizados de forma intercambiável, é essencial observar as sutis diferenças entre eles. Quando um único dado é coletado, como o número de erros descobertos em um componente de software, uma medida é estabelecida. A medição ocorre quando são coletados um ou mais pontos de dados, como ao investigar um conjunto de revisões de componente e testes de unidade para coletar medidas do número de erros em cada um. Por sua vez, uma métrica de software relaciona as medidas individuais de alguma maneira, como o número médio de erros encontrados por revisão ou por teste de unidade.

Os engenheiros de software coletam medidas e desenvolvem métricas para obter indicadores. Um indicador é uma métrica ou uma combinação delas que fornecem informações sobre o processo de software, em um projeto de software ou no produto em si (Pádua, 2019).

Já foram propostas centenas de métricas para programas de computadores, porém, nem todas são viáveis para os engenheiros de software. Algumas exigem medições complexas, outras são tão abstratas que poucos profissionais do mundo real conseguem compreendê-las, e outras ainda contradizem as noções básicas do que constitui um software de alta qualidade (Pressman, 2021). A experiência mostra que uma métrica só será amplamente adotada se for clara e fácil de calcular. Se demandar dezenas de contagens e cálculos complexos, é improvável que seja amplamente aceita.

Um conjunto de atributos que devem ser contemplados por métricas de software eficazes. Elas devem ser relativamente fáceis de aprender a derivar, sem exigir esforço ou tempo excessivo. Além disso, devem estar alinhadas às noções intuitivas dos engenheiros sobre o atributo do produto considerado. Por exemplo, uma métrica que avalia a coesão de módulos deve aumentar à medida que a coesão aumenta. As métricas também devem produzir resultados inequívocos e evitar combinações de unidades bizarras durante o cálculo matemático. Devem ser baseadas no modelo de requisitos, no modelo de projeto ou na estrutura do programa, sem depender das nuances sintáticas ou semânticas das linguagens de programação. Por fim, as métricas devem fornecer informações que possam contribuir para um produto de melhor qualidade. 

Métricas de processos e de projetos

As métricas de processo são coletadas ao longo de todos os projetos e durante períodos prolongados, visando fornecer um conjunto de indicadores que contribuem para aprimorar o processo de software em longo prazo. Por outro lado, as métricas de projeto permitem que o gerente de projeto de software avalie o progresso de um projeto em andamento, identifique potenciais riscos, detecte áreas problemáticas antes que se tornem críticas, ajuste o fluxo de trabalho ou tarefas e avalie a capacidade da equipe de controlar a qualidade dos artefatos de software.

As medidas coletadas pela equipe de projeto e transformadas em métricas para uso durante o projeto também podem ser compartilhadas com os responsáveis pelo aprimoramento do processo de software. Portanto, muitas dessas métricas são empregadas tanto no âmbito do processo quanto no do projeto. Ao contrário das métricas de processo de software, que têm finalidade estratégica, as métricas de projeto de software têm caráter tático. Em outras palavras, as métricas de projeto e os indicadores derivados delas são utilizados pelo gerente de projeto e pela equipe de software para ajustar o fluxo de trabalho do projeto e as atividades técnicas.

Aprimorar qualquer processo requer uma abordagem lógica que envolve a medição de atributos específicos, o desenvolvimento de métricas significativas com base nesses atributos e o uso dessas métricas para orientar estratégias de aprimoramento. No entanto, antes de explorarmos as métricas de software e seu impacto na melhoria do processo de software, é crucial reconhecer que o processo é apenas um dos vários elementos que influenciam a qualidade do software e o desempenho organizacional. Conforme ilustrado na Figura 1, o processo está no cerne do triângulo que interconecta três fatores-chave que exercem profunda influência sobre a qualidade do software e o desempenho organizacional. Estudos anteriores demonstraram que a habilidade e a motivação das pessoas representam os fatores mais influentes na qualidade e no desempenho. Além disso, a complexidade do produto pode ter um impacto significativo sobre a qualidade e o desempenho da equipe, enquanto a tecnologia – ou seja, os métodos e ferramentas de engenharia de software – que sustenta o processo também desempenha um papel crucial.

Além disso, o triângulo do processo é situado dentro de um contexto ambiental mais amplo, que engloba o ambiente de desenvolvimento (por exemplo, ferramentas de software integradas), as condições de negócios (como prazos de entrega e regras do negócio) e as características do cliente (incluindo facilidade de comunicação e colaboração) (Pressman, 2021).

A avaliação da eficácia de um processo de software ocorre de forma indireta. Isso significa que um conjunto de métricas é desenvolvido com base nos resultados alcançados pelo processo. Esses resultados incluem medidas como erros identificados antes da entrega do software, defeitos relatados pelos usuários finais, produtividade (medida pelos artefatos entregues), esforço humano empregado, tempo utilizado, aderência ao cronograma e outras variáveis relevantes. Também é possível obter métricas de processo ao medir características específicas das tarefas de engenharia de software.

Normalmente, as métricas de projeto são aplicadas pela primeira vez durante o processo de estimativa em projetos de software. Métricas provenientes de projetos anteriores servem como base para estimativas de esforço e tempo para o trabalho de software atual. À medida que o projeto avança, as métricas de esforço e tempo são comparadas com as estimativas iniciais e com o cronograma do projeto. O gerente de projeto utiliza esses dados para monitorar e controlar o progresso do projeto.

À medida que o trabalho técnico é iniciado, outras métricas de projeto tornam-se relevantes. Isso inclui a medição das taxas de produção, representadas em modelos criados, revisões, pontos de função e linhas de código-fonte entregues. Além disso, são rastreados os erros identificados durante cada etapa da engenharia de software. Conforme o software evolui dos requisitos para o projeto, métricas técnicas são coletadas para avaliar a qualidade do projeto e fornecer indicadores que orientam a estratégia adotada para a geração de código e os testes (Pressman, 2021).

O propósito das métricas de projeto é duplo. Primeiramente, são empregadas para minimizar o cronograma de desenvolvimento, realizando os ajustes necessários para evitar atrasos e mitigar possíveis problemas e riscos. Em segundo lugar, as métricas de projeto são utilizadas para avaliar continuamente a qualidade do produto e, se necessário, adaptar a abordagem técnica para aprimorar sua qualidade.

Conforme a qualidade do produto se aprimora, a incidência de defeitos é reduzida, o que, por sua vez, diminui a necessidade de retrabalho durante o projeto. Isso resulta em uma diminuição no custo global do projeto.

As métricas de processo de software podem gerar benefícios substanciais quando uma organização busca melhorar seu nível geral de maturidade de processo. No entanto, assim como ocorre com todas as métricas, seu uso inadequado pode gerar mais problemas do que soluções (Pressman, 2021).

Uma sugestão de práticas adequadas para gerentes e profissionais ao implementar um programa de métricas de processo é apresentada como uma "etiqueta de métricas de software", descrito a seguir (Pressman, 2021):

• Use discernimento e sensibilidade organizacional ao analisar os dados das métricas.
• Forneça feedback regularmente às pessoas e equipes responsáveis pela coleta de medidas e métricas.
• Evite utilizar métricas para avaliar o desempenho individual.
• Colabore com profissionais e equipes para estabelecer metas claras e as métricas a serem utilizadas para alcançá-las.
• Evite ameaçar indivíduos ou equipes com base em métricas.
• Não interprete dados de métricas que apontam áreas problemáticas como "negativos". Esses dados são apenas indicativos de áreas que requerem melhoria no processo.
• Evite fixar-se excessivamente em uma única métrica, negligenciando outras métricas importantes.

À medida que uma organização se torna mais familiarizada com a coleta e aplicação de métricas de processo, a transição para uma abordagem mais rigorosa pode ocorrer, conhecida como Melhoria Estatística de Processo de Software (SSPI, do inglês Statistical Software Process Improvement). Essencialmente, a SSPI emprega a análise de falhas de software para reunir informações sobre todos os erros e defeitos encontrados durante o desenvolvimento e uso de uma aplicação, sistema ou produto (Pressman, 2021).

Siga em Frente...

Estabelecimento de um programa de métricas de software

O Software Engineering Institute (SEI) elaborou um guia abrangente [Par96b] para estabelecer um programa de métricas de software com foco em metas. Este livro sugere as seguintes etapas (Pressman, 2021): 

1. Identificar as metas de negócio.
2. Identificar o que se deseja saber ou aprender.
3. Identificar as submetas.
4. Identificar as entidades e atributos relacionados às submetas.
5. Formalizar as metas de medição.
6. Identificar questões quantificáveis e os indicadores associados que serão utilizados para alcançar as metas de medição.
7. Identificar os elementos de dados a serem coletados para construir os indicadores.
8. Identificar as medidas a serem utilizadas e definir suas operacionalizações.
9. Identificar as ações a serem tomadas para implementar as medidas.
10. Elaborar um plano para a implementação das medidas. 

Uma discussão detalhada dessas etapas está disponível no guia do SEI. No entanto, o exemplo a seguir oferece uma visão geral sucinta dos pontos principais.

Dado que o software desempenha funções críticas para o negócio, seja suportando operações, diferenciando sistemas ou produtos baseados em computadores, ou atuando como um produto em si mesmo, os objetivos estabelecidos para os negócios podem ser diretamente relacionados a metas específicas no nível da engenharia de software. Em colaboração entre a equipe de engenharia de software e os gestores de negócios, uma lista de metas comerciais com prioridades é desenvolvida (Pressman, 2021):

• Melhorar a satisfação de nossos clientes com nossos produtos.
• Tornar os seus produtos mais fáceis de usar.
• Reduzir o tempo necessário para ter um novo produto no mercado.
• Tornar o suporte aos nossos produtos mais fáceis.
• Melhorar nossa lucratividade geral.

A empresa de software examina cada meta de negócio e busca compreender: "Quais são as atividades que gerenciamos, executamos ou suportamos e o que queremos melhorar nessas atividades?". Para responder a essas indagações, o SEI recomenda a elaboração de uma "lista entidade-questão", na qual são enumeradas todas as áreas (entidades) dentro do processo de software que são gerenciadas ou influenciadas pela organização de software. Exemplos de entidades incluem recursos de desenvolvimento, artefatos, código-fonte, casos de teste, solicitações de alteração, tarefas de engenharia de software e cronogramas. Para cada entidade listada, os profissionais de software desenvolvem uma série de questões que exploram características quantitativas da entidade (por exemplo, tamanho, custo, tempo de desenvolvimento). As questões resultantes da criação da lista entidade-questão levam à definição de uma série de submetas diretamente relacionadas às entidades identificadas e às atividades realizadas como parte do processo de software.

Considere a quarta meta: “Tornar o suporte aos nossos produtos mais fácil”. Para essa meta, pode ser criada a seguinte lista de questões (Pressman, 2021):

• As solicitações de alterações do cliente contêm as informações de que precisamos para avaliar adequadamente a alteração e então implementá-la dentro do prazo normal?
• Qual é o acúmulo de solicitações de alteração?
• Nosso tempo de resposta para corrigir os erros é aceitável com base nas necessidades do cliente?
• Nosso processo de controle de alterações é seguido?
• As alterações de alta prioridade são implementadas dentro do prazo normal?

A partir dessas questões, a organização de software pode derivar a seguinte submeta: Aperfeiçoar o desempenho do processo de gerenciamento de alterações. As entidades e os atributos pertinentes ao processo de software relacionados à submeta são identificados, e são delineadas as metas de medição associadas a eles.

O SEI oferece diretrizes detalhadas para as etapas 6 a 10 de sua estratégia de medição orientada por metas, que envolvem o refinamento das metas de medição em questões, entidades, atributos e finalmente métricas.

Para empresas de desenvolvimento de software com menos de 20 profissionais, desenvolver programas extensos de métricas pode não ser prático. No entanto, é recomendável que organizações de todos os tamanhos implementem medições para melhorar os seus processos e a qualidade de seus produtos. Empresas menores podem começar focalizando nos resultados e estabelecendo objetivos claros para melhorias, como reduzir o tempo para avaliar e implementar solicitações de alterações.

A maioria dos desenvolvedores de software ainda não realiza medições e, infelizmente, muitos não estão dispostos a começar. Tentar introduzir medidas em um ambiente em que elas não foram utilizadas antes muitas vezes encontra resistência. "Por que precisamos fazer isso?" questiona o gerente de projeto apressado. "Não vejo necessidade disso", concorda um programador sobrecarregado. Por que é tão crucial medir o processo de engenharia de software e os artefatos que ele produz? A resposta é bastante clara. Sem medição, não há maneira real de determinar se houve melhorias. E se não houver melhorias, é fácil se perder (Pressman, 2021).

Vamos Exercitar?

A seguir está uma descrição esperada para a atividade, destacando os conceitos-chave de uma implementação de um programa de métricas de software.

Ao se considerar a implementação de um programa de métricas de software em uma organização, é essencial começar com uma compreensão clara dos objetivos de negócios da empresa. Com esses objetivos em mente, é possível determinar o que se deseja saber ou aprender para apoiar esses objetivos. Isso envolve uma análise detalhada para identificar submetas mais específicas e mensuráveis. Cada submeta está vinculada a entidades e atributos específicos que são críticos para a sua realização, e é vital reconhecer e entender essas conexões.

A próxima fase consiste em formalizar as metas de medição, estabelecendo definições claras de sucesso. Isto requer a identificação de questões específicas que possam ser respondidas por meio de dados e a definição de indicadores correspondentes. Estes indicadores, por sua vez, são baseados em elementos de dados que devem ser meticulosamente coletados e analisados. Com esses dados em mãos, as medidas específicas podem ser identificadas e suas operacionalizações definidas, garantindo que cada medida seja implementada de forma eficaz.

Por último, é crucial planejar as ações necessárias para a implementação das medidas e desenvolver um plano abrangente para guiar o processo de implantação. Este plano não apenas detalha os passos a serem tomados, mas também considera a forma como as medidas serão integradas às operações diárias da empresa.

Concluindo, estabelecer um programa de métricas de software é um processo estratégico que envolve não apenas a identificação de metas e medidas, mas também um planejamento cuidadoso e uma execução considerada. Este processo é essencial para garantir que as funções críticas do software estejam alinhadas com os objetivos mais amplos da empresa, desde melhorar a satisfação do cliente e a usabilidade do produto até acelerar o tempo de lançamento no mercado, facilitar o suporte ao produto e, finalmente, aumentar a lucratividade geral.

Saiba Mais

Para ler mais sobre Métricas de software, leia o Capítulo 23 do livro Engenharia de Software - Pressman.

Quer saber mais sobre a Medição de software? Leia o Capítulo 24.5 de Engenharia de Software - Sommerville  

Leia o artigo Como medir a qualidade do desenvolvimento de software?  E conheça mais sobre esse tema.

Referências Bibliográficas

PÁDUA, W. Engenharia de software. 1. ed. Rio de Janeiro: LTC, 2019.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

Reúso de software

Na aula de hoje, vamos explorar o reúso de software, abordando o panorama, os benefícios e os desafios associados a essa prática. Além disso, discutiremos os frameworks de aplicação, ferramentas essenciais para facilitar e promover o reúso de componentes de software em diversos projetos. Dominar esses conceitos é fundamental para aumentar a eficiência e a produtividade no desenvolvimento de software. Prepare-se para aprender como aproveitar ao máximo o potencial do reúso na sua prática profissional em engenharia de software.

Ponto de Partida

Nesta aula vamos explorar o conceito fundamental de aproveitar componentes de software existentes em novos projetos, em vez de desenvolvê-los do zero. Discutimos o panorama do reúso, que abrange várias abordagens, como reúso de sistemas, aplicações, componentes e objetos. Essa visão geral permite aos alunos entenderem as diferentes formas de implementar o reúso e identificar as estratégias mais adequadas para seus projetos específicos.

Uma compreensão aprofundada do reúso de software é essencial, pois oferece inúmeras vantagens para o desenvolvimento de software. O reúso permite economizar tempo, esforço e recursos, além de promover a consistência e a qualidade do software produzido. Ao dominar as técnicas de reúso, os profissionais podem acelerar o ciclo de desenvolvimento, reduzir custos e manter um alto padrão de excelência em seus projetos.

Além disso, exploramos os frameworks de aplicação, que são estruturas fundamentais para facilitar o desenvolvimento de software. Esses frameworks oferecem um conjunto de funcionalidades pré-implementadas e padronizadas, permitindo aos desenvolvedores criar aplicações de forma mais eficiente e consistente. Compreender o funcionamento e a aplicação dos frameworks de aplicação é crucial para maximizar a eficácia do reúsode software e promover a produtividade no desenvolvimento de sistemas complexos.

Para aplicarmos esses conceitos, vamos pensar na seguinte situação:  você é um engenheiro de software em uma empresa de desenvolvimento de sistemas e foi encarregado de projetar uma plataforma de e-commerce escalável. A empresa deseja reduzir o tempo de desenvolvimento e os custos, mantendo a qualidade e a flexibilidade do software. O reúso de software foi identificado como um componente-chave para alcançar esses objetivos. A arquitetura Model-View-Controller (MVC) é proposta para facilitar o reúso e a manutenção do sistema. Com isso, você deve elaborar um relatório discutindo a importância do reúso de software na engenharia de software moderna, com foco na aplicação da arquitetura MVC como um meio de promover o reúso eficiente de software. O seu relatório deve conter os seguintes pontos:

• Explorar a Importância do Reúso de Software.
• Descrever a Arquitetura MVC.
• Relacionar Reúso de Software com MVC.
• Reflexão sobre Reúso Estratégico.

Bons estudos!

Vamos Começar!

Reúso de Software

Engenharia de software baseada em reúso é uma estratégia na qual o processo de desenvolvimento é direcionado para aproveitar o software existente. Até aproximadamente o ano 2000, o reúso sistemático de software era pouco comum, porém, hoje é amplamente utilizado no desenvolvimento de novos sistemas de negócios (Hirama, 2011). Essa mudança para o desenvolvimento baseado em reúso foi uma resposta às demandas por redução de custos de produção e manutenção de software, entrega mais rápida de sistemas e maior qualidade de software. As empresas agora veem o software como um ativo valioso e estão promovendo o reúso de sistemas existentes para aumentar o retorno sobre os investimentos em software.

Atualmente, existe uma ampla gama de software reusável disponível em diversos formatos. O movimento de código aberto gerou uma extensa base de código pronta para ser reaproveitada, seja na forma de bibliotecas de programas ou de aplicações completas. Muitos sistemas de aplicação específicos para domínios, como os sistemas ERP, estão prontamente disponíveis e podem ser adaptados para atender aos requisitos do cliente. Algumas empresas de grande porte oferecem uma variedade de componentes reutilizáveis para seus clientes. Além disso, os padrões, como os padrões de web services, têm facilitado o desenvolvimento e o reúso de serviços de software em uma variedade de aplicações.

A abordagem de engenharia de software baseada em reúsobusca maximizar a utilização de software existente. As unidades de software reutilizadas podem variar significativamente em tamanho. Por exemplo (Sommerville, 2018):

• Reúso de sistemas: sistemas completos, compostos por uma série de programas de aplicação, podem ser reutilizados como parte de um sistema de sistemas.
• Reúso de aplicações: uma aplicação pode ser incorporada sem alterações em outros sistemas ou configurada para atender a diferentes clientes. Alternativamente, famílias de aplicações ou linhas de produtos de software com uma arquitetura comum, adaptadas para requisitos individuais, podem ser usadas para desenvolver um novo sistema.
• Reúso de componentes: componentes de uma aplicação, desde subsistemas até objetos únicos, podem ser reutilizados. Por exemplo, um sistema de reconhecimento de padrões desenvolvido como parte de um sistema de processamento de texto pode ser reutilizado em um sistema de gerenciamento de banco de dados. Esses componentes podem ser hospedados na nuvem ou em servidores privados e acessados como serviços por meio de uma API.
• Reúso de objetos e funções: componentes de software que implementam uma única função, como uma função matemática, ou uma classe de objeto, podem ser reutilizados. Esse tipo de reúso, centrado em torno de bibliotecas padrões, tem sido comum nas últimas quatro décadas. Muitas bibliotecas de funções e classes estão disponíveis gratuitamente. As classes e as funções nessas bibliotecas são reutilizadas quando vinculadas ao código da aplicação recém-desenvolvida. Em áreas como algoritmos matemáticos e gráficos, em que o conhecimento especializado é necessário para desenvolver objetos e funções eficientes, o reúso é particularmente econômico.

Todos os sistemas de software e componentes que contêm funcionalidades genéricas têm o potencial de serem reutilizáveis. No entanto, em algumas situações, esses sistemas ou componentes podem ser tão específicos que modificá-los para se adequarem a uma nova situação é bastante dispendioso. Nesses casos, em vez de reutilizar o código, é viável reutilizar as ideias subjacentes que deram origem ao software. Esse tipo de rreúso uso é denominado reúso de conceito.

No reúso de conceito, um componente de software em si não é reutilizado; em vez disso, são aproveitadas ideias, métodos de trabalho ou algoritmos. O conceito reutilizado é representado de forma abstrata, como um modelo de sistema, que não contém detalhes de implementação (Hirama, 2011). Assim, ele pode ser configurado e adaptado para diversas situações. O reúso de conceito está integrado a abordagens como a de padrões de design, produtos de sistema configuráveis e geradores de programas. Quando os conceitos são reutilizados, o processo de reúso deve incluir uma etapa na qual esses conceitos abstratos sejam transformados em componentes executáveis.

Uma vantagem evidente do reúso de software é a redução dos custos gerais de desenvolvimento (Pádua, 2019). Há menos componentes de software para especificar, projetar, implementar e validar. No entanto, a redução de custos é apenas um dos benefícios do reúso de software. Outras vantagens são detalhadas no Quadro 1.

Benefício	Explicação
Desenvolvimento acelerado	Lançar um sistema no mercado o mais brevemente possível costuma ser mais importante do que os custos totais do desenvolvimento. O reúso de software pode acelerar a produção do sistema, pois tanto o tempo de desenvolvimento quanto de validação podem ser reduzidos.
Uso eficaz de especialistas	Em vez de refazer o mesmo trabalho repetidamente, os especialistas de aplicação podem desenvolver um software reusável que encapsule o seu conhecimento.
Maior dependabilidade	O software reusado, que foi testado e aprovado em sistemas em funcionamento, deve ser mais confiável do que o novo software. Seus defeitos de projeto e implementação devem ter sido descobertos e corrigidos.
Custos de desenvolvimento mais baixos	Os custos de desenvolvimento são proporcionais ao tamanho do software que está sendo desenvolvido. Reusar o software significa que menos linhas de código têm de ser escritas.
Menos risco para o processo	O custo do software existente já é conhecido, enquanto os custos de desenvolvimento são sempre uma incógnita. Esse fator é importante para o gerenciamento do projeto porque reduz a margem de erro na estimativa de custo do projeto. Isso vale especialmente quando grandes componentes de software, como os subsistemas, são reusados.
Conformidade com os padrões	Alguns padrões, como os de interface com o usuário, podem ser implementados como um conjunto de componentes reusáveis. Por exemplo, se os menus em uma interface com o usuário forem implementados usando componentes reusáveis, todas as aplicações apresentam os mesmos formatos de menu para os usuários. O uso de uma interface com o usuário melhora a dependabilidade, porque os usuários cometem menos erros quando é apresentada a eles uma interface conhecida.

Quadro 1 | Benefícios do Reúso de Software. Fonte: adaptado de Sommerville (2018).

No entanto, há custos e desafios associados ao reúso, conforme apresentado no Quadro 2. Existe um custo significativo associado à avaliação da adequação de um componente para reúso em uma determinada situação e à realização de testes para garantir sua confiabilidade. Esses custos adicionais podem resultar em uma economia nos custos de desenvolvimento menor do que o inicialmente previsto. No entanto, os demais benefícios do reúso ainda são válidos.

Problema	Explicação
Criar, manter e usar uma biblioteca de componentes	Povoar uma biblioteca de componentes reusáveis e garantir que os desenvolvedores de software possam usar essa biblioteca pode custar caro. Os processos de desenvolvimento têm de ser adaptados para garantir que a biblioteca seja utilizada.
Encontrar, entender e adaptar componentes reusáveis	Os componentes de software têm de ser descobertos em uma biblioteca, compreendidos e, às vezes, adaptados para trabalhar em um novo ambiente. Os engenheiros devem estar razoavelmente confiantes de que encontrarão um componente na biblioteca antes de incluírem uma busca por componentes como parte de seu processo de desenvolvimento normal.
Maiores custos de manutenção	Se o código-fonte de um sistema de software ou componente reusado não estiver disponível, então os custos de manutenção podem ser mais altos porque os elementos reusados do sistema podem se tornar incompatíveis com as mudanças feitas no sistema.
Falta de suporte da ferramenta	Algumas ferramentas de software não fornecem suporte ao desenvolvimento com reúso. Pode ser difícil ou impossível integrar essas ferramentas com um sistema de biblioteca de componentes. O processo de software empregado por essas ferramentas pode não levar em conta o reúso. É mais provável que isso aconteça com as ferramentas que apoiam a engenharia de sistemas embarcados do que com as ferramentas de desenvolvimento orientado a objetos.
Síndrome do ‘não inventado aqui’	Alguns engenheiros de software preferem reescrever os componentes porque acreditam que podem aperfeiçoá-los. Isso tem a ver em parte com a confiança e em parte com o fato de que escrever o software original é encarado como algo mais desafiador do que reusar o software de outras pessoas.

Quadro 2 | Problemas do Reúso de Software. Fonte: adaptado de Sommerville (2018). 

É necessário adaptar os processos de desenvolvimento de software para incorporar o reúso. Especificamente, é essencial incluir uma fase de refinamento dos requisitos do sistema, na qual esses requisitos sejam ajustados para incorporar o software reutilizável disponível. Além disso, as etapas de projeto e a implementação do sistema podem incorporar atividades explícitas para identificar e avaliar possíveis componentes para reúso (Sommerville, 2018).

Siga em Frente...

Panorama do Reúso

Nos últimos 20 anos, foram desenvolvidas diversas técnicas para facilitar o reúso de software. Essas técnicas se baseiam na observação de que sistemas dentro de um mesmo domínio de aplicação compartilham semelhanças e têm potencial para reúso; na compreensão de que o reúso pode ocorrer em diferentes níveis, desde funções simples até aplicações completas; e na utilização de padrões para componentes reutilizáveis, o que simplifica o processo de reúso. A Figura 1 ilustra o panorama do reúso, demonstrando diferentes maneiras de implementar essa prática no desenvolvimento de software.

Algumas das abordagens citadas para o reúso está brevemente descrita no Quadro 3.

Abordagem	Descrição
Frameworks de aplicação	Coleções de classes abstratas e concretas são adaptadas e estendidas para criar sistemas de aplicação.
Integração de sistemas de aplicação	Dois ou mais sistemas de aplicação são integrados para proporcionar mais funcionalidade.
Padrões de arquitetura	Padrões de arquiteturas de software que apoiam tipos comuns de sistemas de aplicação são utilizados como base de aplicações.
Desenvolvimento de software orientado a aspectos	Componentes compartilhados são ‘entrelaçados’ em uma aplicação em diferentes lugares quando o programa é compilado.
Engenharia de software baseada em componentes	Sistemas são desenvolvidos integrando componentes (coleções de objetos) que se adaptam aos padrões de modelo de componente.
Sistemas de aplicação configuráveis	Sistemas específicos de domínio são projetados para que possam ser configurados para as necessidades de clientes de sistemas específicos.
Padrões de projeto	Abstrações genéricas que ocorrem entre aplicações são representadas como padrões de projeto que exibem objetos e interações abstratos e concretos.

Quadro 3 | Abordagens que apoiam o reúso de software. Fonte: adaptado Sommerville (2018).

Considerando o conjunto de técnicas disponíveis para o reúso, a pergunta central é: qual técnica é mais adequada para uma situação específica? Naturalmente, a resposta depende dos requisitos do sistema em desenvolvimento, da tecnologia disponível, dos ativos reutilizáveis disponíveis e da experiência da equipe de desenvolvimento. Os principais fatores a serem considerados ao planejar o reúso são os seguintes (Sommerville, 2018):

• Cronograma de desenvolvimento do software: se há uma necessidade de desenvolver o software rapidamente, a preferência pode ser pelo reúso de sistemas completos em vez de componentes individuais. Embora a adequação aos requisitos possa não ser perfeita, essa abordagem minimiza a quantidade de desenvolvimento necessária.
• Tempo de vida previsto para o software: ao desenvolver um sistema destinado a uma longa vida útil, é crucial considerar a capacidade de manutenção do sistema. Não se deve apenas considerar os benefícios imediatos do reúso, mas também suas implicações a longo prazo. Durante a vida útil de um sistema, é provável que ele precise ser adaptado a novos requisitos, o que implica mudanças em partes dele. Se não houver acesso ao código-fonte dos componentes reutilizáveis, pode ser preferível evitar componentes de prateleira e sistemas de fornecedores externos, pois esses fornecedores podem não oferecer suporte contínuo ao software reutilizado. Nesse caso, pode ser mais seguro reusar sistemas e componentes de código aberto, pois isso permite acessar e manter cópias do código-fonte.
• Formação, habilidades e experiência da equipe de desenvolvimento: todas as tecnologias de reúso são bastante complexas e exigem tempo para serem compreendidas e utilizadas com eficácia. Portanto, é crucial concentrar os esforços de reúso nas áreas em que a equipe de desenvolvimento tenha experiência.
• Criticidade do software e requisitos não funcionais: para um sistema crítico, que precisa ser certificado por um regulador externo, pode ser necessário criar um caso de segurança ou de segurança da informação para esse sistema. Isso pode ser difícil se não for possível ter acesso ao código-fonte do software.
• O domínio de aplicação: é outro ponto a considerar. Em diversos domínios, como sistemas de informação industriais e sistemas de informação médica, existem produtos genéricos disponíveis que podem ser reutilizados, bastando serem configurados para se adequarem a uma situação específica. Esta é uma das abordagens mais eficazes para o reúso e muitas vezes é mais econômico comprar do que desenvolver um sistema novo. 
• A plataforma na qual o sistema será executado: também desempenha um papel importante. Alguns modelos de componentes, como o .NET, são específicos para plataformas da Microsoft. Da mesma forma, sistemas de aplicação genéricos podem ser projetados para uma plataforma específica e só serão reutilizáveis se o novo sistema for compatível com essa plataforma.

A variedade de técnicas de reúso disponíveis é tão ampla que, na maioria das situações, existe a possibilidade de algum nível de reúso de software. No entanto, a decisão sobre se o reúso será realizado ou não é mais uma questão de gestão do que técnica. Isso ocorre porque os gestores podem hesitar em comprometer seus requisitos para permitir a utilização de componentes reutilizáveis (Sommerville, 2018). Eles podem não compreender os riscos associados ao reúso tão bem quanto compreendem os riscos do desenvolvimento original. Embora os riscos envolvidos no desenvolvimento de um novo software possam ser maiores, alguns gestores podem preferir lidar com os riscos conhecidos do desenvolvimento em vez dos riscos desconhecidos do reúso. Para promover o reúso em toda a empresa, pode ser necessário implementar um programa de reúso que se concentre na criação de ativos e processos reutilizáveis para facilitar a prática. 

Frameworks de Aplicação

Os pioneiros do desenvolvimento orientado a objetos sugeriram que um dos principais benefícios dessa abordagem era a possibilidade de reutilizar objetos em sistemas diferentes. No entanto, a experiência demonstrou que os objetos muitas vezes são granulares e especializados demais para uma aplicação específica. Frequentemente, é necessário mais tempo para entender e adaptar o objeto do que para implementá-lo. Hoje em dia, é evidente que a reutilização orientada a objetos é mais adequadamente suportada por um processo de desenvolvimento orientado a objetos, por meio de abstrações mais genéricas chamadas de frameworks.

Um framework é uma estrutura genérica estendida para criar um subsistema ou uma aplicação mais específicos. Um framework pode ser definido como um conjunto integrado de artefatos de software, como classes, objetos e componentes, que colaboram para fornecer uma arquitetura reutilizável para uma família de aplicações relacionadas (Sommerville, 2018).

Os frameworks fornecem suporte a características genéricas que tendem a ser utilizadas em todas as aplicações de um tipo similar. Por exemplo, um framework de interface com o usuário oferece suporte para o tratamento de eventos de interface e inclui um conjunto de componentes de interface que podem ser usados para construir telas. Em seguida, cabe ao desenvolvedor especializar esse framework adicionando funcionalidades específicas para uma determinada aplicação. Por exemplo, em um framework de interface com o usuário, o desenvolvedor define os layouts de tela adequados para a aplicação que está sendo implementada.

Os frameworks promovem a reutilização de projeto ao fornecerem um esqueleto de arquitetura para a aplicação, além da reutilização de classes específicas no sistema. A arquitetura é implementada pelas classes e suas interações. As classes são reutilizadas diretamente e podem ser estendidas com o uso de características como herança e polimorfismo.

Os frameworks são coleções de classes concretas e abstratas implementadas em linguagens de programação orientadas a objetos, como Java, C#, C++, Ruby e Python. Eles são específicos para cada linguagem e são utilizados para facilitar o desenvolvimento de aplicações. Os frameworks podem ser incorporados uns aos outros e são projetados para dar suporte ao desenvolvimento de diferentes partes de uma aplicação, podendo ser utilizados para criar uma aplicação completa ou implementar partes específicas, como a interface gráfica do usuário.

Os frameworks mais comuns são os frameworks de aplicação web (WAFs), que auxiliam na construção de sites dinâmicos. Eles são geralmente baseados no padrão composto Modelo-Visão-Controlador (MVC), que separa o estado da apresentação em uma aplicação, permitindo a atualização do estado a partir de diferentes apresentações. O padrão MVC foi inicialmente proposto nos anos 1980 para o projeto de interfaces gráficas de usuário (GUI), permitindo múltiplas representações de um objeto e diferentes estilos de interação com cada uma dessas representações. A Figura 2, apresenta o padrão MVC.

Um framework MVC ajuda na apresentação dos dados de diferentes maneiras e permite a interação com cada uma dessas apresentações. Quando os dados são modificados em uma das apresentações, o modelo do sistema é modificado, e os controladores associados a cada visão atualizam a sua apresentação.

• Outras classes de frameworks, estão descritas a seguir (Sommerville, 2018):
• Os frameworks de infraestrutura de sistema auxiliam no desenvolvimento de infraestruturas de sistema, incluindo comunicações, interfaces com o usuário e compiladores.
• Os frameworks de integração e middleware consistem em conjuntos de padrões e classes associadas que facilitam a comunicação entre componentes e a troca de informações. Exemplos incluem o .NET da Microsoft e o Enterprise Java Beans (EJB), que suportam modelos de componentes padronizados.
• Os frameworks de aplicação corporativa são específicos para domínios de aplicação como telecomunicações ou sistemas financeiros. Eles incorporam conhecimento do domínio da aplicação e ajudam no desenvolvimento de aplicações para usuários finais. Embora não sejam amplamente utilizados, foram praticamente substituídos por linhas de produtos de software.

Aplicações desenvolvidas com frameworks podem servir como base para uma futura reutilização, seguindo o conceito de linhas de produtos de software ou famílias de aplicações. Como essas aplicações são construídas com base em um framework, modificar os membros da família para criar novas instâncias de sistema geralmente é um processo direto, envolvendo a modificação de classes e métodos específicos que foram adicionados ao framework (Sommerville, 2018).

Embora os frameworks sejam uma abordagem eficaz para o reúso, introduzi-los nos processos de desenvolvimento de software é dispendioso, pois são naturalmente complexos e pode levar meses para dominar seu uso. Avaliar os frameworks disponíveis e selecionar o mais adequado também pode ser uma tarefa difícil e custosa. Além disso, a depuração de aplicações baseadas em frameworks é mais desafiadora do que depurar o código original, pois nem sempre é claro como os métodos do framework interagem. Ferramentas de depuração podem fornecer informações sobre os componentes do framework reutilizados que podem ser difíceis de compreender para o desenvolvedor.

Vamos Exercitar?

Uma possível abordagem dos temas pedidos no relatório está apresentada a seguir:

Importância do Reúso de Software

• Conceito: reúso de software refere-se à prática de utilizar componentes de software existentes em novas aplicações, o que pode aumentar a eficiência e qualidade do desenvolvimento, ao mesmo tempo que reduz custos.
• Benefícios: incluem a aceleração do desenvolvimento, a padronização de componentes, e a redução de erros, já que os componentes reutilizados tendem a ser mais testados e confiáveis.
• Desafios: abrangem a integração de componentes com diferentes sistemas e a necessidade de manter a compatibilidade entre as várias partes do software.

Arquitetura MVC

• Descrição: a arquitetura MVC separa a lógica de negócios (Modelo), a interface do usuário (Visão) e a lógica de entrada (Controlador), promovendo uma organização clara do código e facilitando a manutenção e o reúso.
• Facilitação do Reúso: a separação de responsabilidades permite que cada componente seja desenvolvido, testado e reutilizado independentemente. 

Reúso de Software com MVC

• Promoção do Reúso: MVC apoia o reúso através de modelos que podem ser aplicados a diferentes funcionalidades e visões que podem ser adaptadas para múltiplos contextos, sem a necessidade de duplicação de código.
• Exemplos no e-commerce: modelos para gerenciamento de usuários e produtos podem ser reutilizados em diferentes módulos; componentes de visualização, como listas de produtos, podem ser padronizados e reutilizados.

Reflexão sobre Reúso Estratégico

• Estratégias para Promover Reúso: incluem o desenvolvimento de bibliotecas de componentes reutilizáveis, o emprego de frameworks MVC e a implementação de práticas de design modular.
• Impacto a Longo Prazo: o reúso estratégico pode significar facilidade de atualização e expansão da plataforma, adaptando-se eficientemente a mudanças de requisitos ou tecnologia. 

Reflexão sobre Reúso Estratégico

• Estratégias para Promover Reúso: incluem o desenvolvimento de bibliotecas de componentes reutilizáveis, o emprego de frameworks MVC e a implementação de práticas de design modular.
• Impacto a Longo Prazo: o reúso estratégico pode significar facilidade de atualização e expansão da plataforma, adaptando-se eficientemente a mudanças de requisitos ou tecnologia.

Saiba Mais

Quer saber mais sobre o Reúso de Software? Leia o Capítulo 15 de Engenharia de Software - Sommerville  

Leia o artigo A reutilização de software e suas aplicações para aprofundar seus conhecimentos nesse assunto.

Reúso de software é um processo recorrente no ciclo de desenvolvimento de software, o artigo Visão Geral Reuso de Software apresenta os principais conceitos e técnicas associados a este processo vital para competitividade das empresas de desenvolvimento de software.

Referências Bibliográficas

HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2011.

PÁDUA, W. Engenharia de software. 1. ed. Rio de Janeiro: LTC, 2019.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

Videoaula de Encerramento

Olá, estudante! Nesta aula você relembrará os pilares da manutenção de software, a gestão de riscos, as métricas de software e o reúso de componentes. Esses são aspectos fundamentais da engenharia de software, permitindo aprimorar a qualidade, eficiência e confiabilidade dos sistemas desenvolvidos. Ao compreender e aplicar esses conceitos, os profissionais estarão mais bem preparados para enfrentar os desafios do desenvolvimento e a manutenção de software, maximizando o valor entregue aos clientes e aos usuários. Prepare-se para uma jornada de aprendizado enriquecedora e prática!

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta Unidade, que é avaliar e saber utilizar as métricas e a análise de software, você deverá primeiramente conhecer os conceitos fundamentais da manutenção de software. Essa é uma atividade crucial no ciclo de vida do desenvolvimento de software, que envolve modificar, corrigir e aprimorar um sistema de software existente para garantir sua eficácia contínua e adaptação às necessidades em evolução. Essa prática abrange diversas atividades, como correção de bugs, implementação de melhorias funcionais, otimização de desempenho e atualizações de segurança. A manutenção de software não apenas prolonga a vida útil de um sistema, mas também contribui para sua confiabilidade, segurança e usabilidade, garantindo que ele permaneça relevante e competitivo no ambiente tecnológico em constante mudança.

Os softwares são desenvolvidos com algoritmos para atender requisitos específicos, porém, podem sofrer mudanças ao longo do tempo, sujeitos a falhas de adequação e falhas na mudança. A falha de adequação ocorre quando os requisitos não são implementados corretamente, levando à perda de integridade e confiabilidade do software (Pádua, 2019). Por exemplo, uma atualização de sistema operacional pode tornar um software incompatível. Já a falha na mudança acontece quando uma atualização afeta negativamente outras funcionalidades, como implementar uma nova forma de pagamento que interfere no funcionamento de outros sistemas. É essencial identificar e corrigir essas falhas para garantir a continuidade e a eficácia do software.

A manutenção de software abrange três principais tipos: adaptativa, corretiva e evolutiva. A manutenção adaptativa é realizada para ajustar o software a mudanças no ambiente operacional, como atualizações de sistemas ou hardware. Já a manutenção corretiva envolve a correção de defeitos ou bugs identificados no software, garantindo sua funcionalidade adequada. Por fim, a manutenção evolutiva tem como objetivo aprimorar o software, adicionando novos recursos ou melhorias de desempenho para atender às necessidades em constante evolução dos usuários. Cada tipo de manutenção desempenha um papel importante na garantia da qualidade e eficácia contínua do software ao longo do seu ciclo de vida.

Outro ponto importante da manutenção de software é a reengenharia de software, que visa reorganizar ou modificar um sistema para restaurar seu desempenho aceitável, sendo desencadeada por fatores como falta de atualização ou excesso de mudanças. Optar pela reconstrução pode ser mais eficaz do que tentar resolver problemas em um sistema comprometido, permitindo correção de erros, atualizações necessárias e melhorias estruturais. Seus objetivos incluem aprimorar a manutenção, atualizar a documentação e refazer a estrutura do sistema, facilitando futuras atividades.

A probabilidade de erro em sistemas revisados durante a reengenharia é reduzida, uma vez que os processos tendem a mitigar riscos já previamente tratados. A aplicação de técnicas como a engenharia reversa desempenha um papel crucial nesse contexto, permitindo a reconstrução do código para compreensão e otimização das funcionalidades. Por meio de métodos específicos, como análise em níveis de implementação, estrutura, funcionalidade e domínio, é possível examinar o software de diversas perspectivas e melhorar sua qualidade de maneira significativa (Pádua, 2019).

Profissionalmente, a reengenharia e a engenharia reversa exigem técnicas desafiadoras, mas valiosas, para reduzir o tempo de desenvolvimento e alcançar melhorias substanciais. Ao utilizar essas práticas, espera-se um aumento na eficiência e na confiabilidade do software, visto que muitas funcionalidades fundamentais já foram desenvolvidas anteriormente, proporcionando um ambiente mais propício à evolução e manutenção dos sistemas de software (Pressman, 2021).

A evolução de software faz parte da manutenção, e cabe destacar que não existe um método padrão único para a evolução do software, variando de acordo com a natureza do sistema, os processos de desenvolvimento adotados e as habilidades das pessoas envolvidas. Em sistemas como aplicativos móveis, a evolução pode ser informal, com alterações sugeridas em conversas entre usuários e desenvolvedores, enquanto em sistemas críticos embarcados, a evolução pode ser formalizada, com documentação estruturada em cada fase do processo. Propostas de mudança, formais ou informais, impulsionam a evolução dos sistemas, originando-se de requisitos não implementados, solicitações de novos requisitos, relatórios de defeitos ou ideias da equipe de desenvolvimento para melhorar o software (Sommerville, 2018).

Antes da aceitação de uma proposta de mudança, é realizada uma análise detalhada do software para determinar quais componentes precisam ser alterados, avaliando custo e impacto. Essa análise faz parte do gerenciamento global de mudanças e visa garantir a inclusão das versões corretas dos componentes em cada lançamento do sistema (Pressman, 2021). O processo de evolução de software envolve atividades como análise da mudança, planejamento de lançamento, implementação do sistema e lançamento para os clientes, com uma cuidadosa avaliação do custo e impacto das mudanças antes da decisão sobre a implementação na próxima versão.

Ao abordar os riscos na engenharia de software, é essencial considerar o impacto futuro e as mudanças nos requisitos do projeto, tecnologias e escolhas de desenvolvimento. O conceito de débito técnico destaca os custos associados ao adiamento de atividades essenciais, como documentação e refatoração, enfatizando a importância de abordar problemas técnicos precocemente para evitar complicações futuras. Apesar da adoção generalizada do desenvolvimento ágil, equipes podem acumular débito técnico devido a demandas crescentes por código e falta de dedicação para reduzi-lo, destacando a necessidade de conscientização e planejamento cuidadoso durante os sprints definidos.

A análise de riscos na engenharia de software considera categorias como riscos de projeto, técnicos e de negócio, que ameaçam o cronograma, a qualidade e a viabilidade do produto. Identificar e gerenciar esses riscos são cruciais para o sucesso do projeto. Enquanto alguns riscos podem ser previstos por meio de uma avaliação cuidadosa do ambiente técnico e comercial, outros são imprevisíveis e representam desafios significativos durante o desenvolvimento do software.

A identificação de riscos é um processo importante para antecipar e controlar ameaças ao plano do projeto, abordando riscos genéricos e específicos do produto (Pressman, 2021). Uma abordagem comum para identificar riscos é criar uma lista de verificação de itens de risco, considerando subcategorias como tamanho do produto, impacto nos negócios e nas habilidades da equipe. Questões-chave, como comprometimento da alta gerência e compreensão dos requisitos, são fundamentais para avaliar o nível de risco do projeto.

A previsão de riscos busca classificar cada risco com base na probabilidade de ocorrência e nas consequências associadas, priorizando-os para direcionar os recursos de forma eficaz. Elaborar uma tabela de riscos é uma técnica comum, ordenando os riscos com base na probabilidade e no impacto para estabelecer estratégias de mitigação, monitoramento e gestão de risco. Abordagens avançadas, como o uso de lógica difusa, podem ser empregadas para avaliar riscos complexos e inter-relacionados, especialmente em cenários de alta incerteza.

O processo de análise de riscos na engenharia de software visa auxiliar a equipe do projeto na elaboração de estratégias para lidar com potenciais ameaças. Essas estratégias devem abordar como evitar, monitorar e gerenciar os riscos, além de planejar contingências (Sommerville, 2018). Uma postura proativa é crucial, com a prevenção como prioridade, incluindo a criação de planos de mitigação para riscos identificados, como a alta rotatividade de pessoal.

Durante o projeto, é essencial antecipar e implementar práticas para minimizar os riscos, como a disseminação de informações entre equipes e a designação de substitutos para membros críticos. O monitoramento contínuo dos riscos ao longo do projeto é fundamental, permitindo ajustes e avaliando a eficácia das medidas de mitigação adotadas.

A gestão de riscos e o plano de contingência entram em ação quando as medidas de mitigação falham e os riscos se materializam. A análise de custo-benefício é essencial para determinar se os benefícios das medidas de gerenciamento de risco superam os custos associados à sua implementação. A regra de Pareto sugere concentrar esforços nos riscos mais críticos, enquanto a gamificação pode incentivar a conformidade com processos, como qualidade e gestão de riscos. O plano RMMM é uma ferramenta valiosa que documenta todas as atividades relacionadas à análise de riscos e serve como parte integrante do plano global do projeto de software (Pressman, 2021).

A medição desempenha um papel importante no desenvolvimento de software, permitindo melhorias contínuas ao longo do ciclo de vida do projeto. Essas medidas são empregadas para aprimorar estimativas, garantir qualidade, aumentar produtividade e controlar o progresso do projeto. Elas oferecem insights sobre os atributos dos modelos desenvolvidos e possibilitam a avaliação da qualidade dos produtos ou sistemas construídos.

Engenheiros de software usam medições para avaliar a qualidade dos artefatos e auxiliar em decisões táticas durante o projeto. Métricas de produtividade e qualidade são focos principais, abrangendo a saída de desenvolvimento em relação ao esforço e tempo aplicados, além da adequação dos artefatos produzidos. Essas medições não apenas fornecem um entendimento técnico, mas também apoiam o gerenciamento do projeto, auxiliando na tomada de decisões para o sucesso do empreendimento (Pressman, 2021).

Embora os termos medida, medição e métricas sejam frequentemente intercambiáveis, há diferenças sutis entre eles. Uma medida é um único dado coletado, enquanto a medição envolve a coleta de um ou mais pontos de dados. Já uma métrica de software relaciona as medidas individuais de alguma maneira, oferecendo indicadores sobre o processo de software ou o produto em si. Métricas eficazes devem ser claras, fáceis de calcular, alinhadas às intuições dos engenheiros, produzir resultados inequívocos e contribuir para um produto de melhor qualidade.

As métricas de produto são usadas para quantificar atributos internos de sistemas de software, como tamanho e complexidade. Elas podem ser classificadas em métricas dinâmicas, obtidas durante a execução do programa, e métricas estáticas, medidas em representações do sistema. As métricas dinâmicas, como o número de defeitos relatados ou o tempo de execução de uma computação, ajudam a avaliar eficiência e confiabilidade. Já as métricas estáticas, como aquelas relacionadas à complexidade do código, têm uma relação mais indireta com atributos de qualidade, mas o tamanho do programa e a complexidade do controle emergem como indicadores confiáveis de compreensibilidade e manutenibilidade (Sommerville, 2018).

As métricas de processo são coletadas ao longo de vários projetos, proporcionando indicadores para aprimorar o processo de software a longo prazo. Por outro lado, as métricas de projeto permitem avaliar o progresso de um projeto em andamento, identificar riscos potenciais e ajustar o fluxo de trabalho conforme necessário (Pressman, 2021). Essas medidas, compartilhadas entre equipes de projeto e de aprimoramento de processos, desempenham um papel tanto estratégico quanto tático, fornecendo insights valiosos para a melhoria contínua.

A implementação de métricas de processo requer uma abordagem lógica, envolvendo a medição de atributos específicos, o desenvolvimento de métricas significativas e seu uso para orientar estratégias de melhoria. Além disso, é crucial reconhecer que o processo é apenas um dos vários elementos que influenciam a qualidade do software e o desempenho organizacional. Esses fatores incluem habilidade e motivação das pessoas, complexidade do produto, tecnologia utilizada e contexto ambiental mais amplo, como ferramentas de software, condições de negócios e características do cliente. O uso adequado das métricas, juntamente com práticas recomendadas de etiqueta de métricas de software, pode levar a melhorias substanciais no processo e na qualidade do produto ao longo do tempo.

A engenharia de software baseada em reúso tem se tornado uma estratégia essencial, impulsionada pela necessidade de reduzir custos, acelerar o desenvolvimento e melhorar a qualidade do software (Pressman, 2021). Atualmente, uma variedade de software reutilizável está disponível, incluindo bibliotecas de código aberto, sistemas de aplicação específicos para domínios e componentes oferecidos por empresas. Essa diversidade de recursos permite o reúso em diferentes níveis, desde sistemas completos até objetos e funções específicas, facilitando a adaptação e a configuração para atender a novas necessidades.

O reúso de software oferece diversos benefícios, incluindo redução de custos, menor tempo de desenvolvimento e maior qualidade. No entanto, existem desafios associados, como os custos de avaliação e teste de componentes para garantir sua adequação e confiabilidade (Sommerville, 2018). Para incorporar o reúso de forma eficaz, os processos de desenvolvimento de software devem ser adaptados para incluir fases específicas de refinamento de requisitos e atividades de identificação e avaliação de componentes reutilizáveis durante o projeto e implementação do sistema.

Nos últimos 20 anos, várias técnicas surgiram para facilitar o reúso de software, impulsionadas pela percepção de que sistemas dentro do mesmo domínio de aplicação compartilham semelhanças. Essas técnicas variam desde o reúso de funções simples até a reutilização de aplicações completas, com o suporte de padrões para componentes reutilizáveis (Sommerville, 2018).

Entretanto, a escolha da técnica de reúso mais adequada para uma situação específica depende de diversos fatores, como o cronograma de desenvolvimento, o tempo de vida previsto para o software, as habilidades da equipe de desenvolvimento, a criticidade do software e o domínio de aplicação. A gestão desempenha um papel crucial na decisão de adotar o reúso, pois os gestores podem relutar em comprometer requisitos para permitir o uso de componentes reutilizáveis, devido aos riscos associados e à falta de compreensão em comparação com o desenvolvimento original. Assim, promover o reúso em toda a empresa pode exigir a implementação de um programa focado na criação de ativos e processos reutilizáveis.

Os primeiros proponentes do desenvolvimento orientado a objetos sugeriram que a reutilização de objetos poderia ser um dos principais benefícios dessa abordagem. No entanto, a granularidade e a especialização dos objetos muitas vezes dificultavam sua aplicação direta em contextos específicos. Hoje, a reutilização orientada a objetos é mais eficazmente suportada por frameworks, estruturas genéricas que fornecem uma arquitetura reutilizável para diferentes aplicações. Os frameworks abstraem características comuns e genéricas que são necessárias em várias aplicações, permitindo que os desenvolvedores as personalizem conforme necessário.

Os frameworks são compostos por coleções de classes e objetos que colaboram para fornecer funcionalidades comuns a uma família de aplicações relacionadas. Eles são implementados em linguagens de programação orientadas a objetos e podem abranger diferentes domínios, desde aplicações web até sistemas corporativos específicos. Os frameworks mais comuns incluem os frameworks de aplicação web, baseados no padrão Model-View-Controller (MVC), que separam o estado da apresentação em uma aplicação, facilitando sua atualização a partir de diferentes visões. Além disso, existem frameworks para infraestrutura de sistema, integração e middleware, e aplicação corporativa, cada um com sua finalidade específica (Sommerville, 2018).

Embora os frameworks sejam uma estratégia eficaz para o reúso de software, sua introdução nos processos de desenvolvimento pode ser dispendiosa devido à sua complexidade. Selecionar e dominar um framework adequado pode levar tempo e recursos significativos, e a depuração de aplicações baseadas em frameworks pode ser mais desafiadora devido à complexidade das interações entre os componentes do framework. No entanto, uma vez dominados, os frameworks podem facilitar o desenvolvimento e a manutenção de aplicações, promovendo a reutilização de código e a eficiência no desenvolvimento de software (Sommerville, 2018).

É Hora de Praticar!

Esta atividade consiste na elaboração de relatório no qual o aluno deve explorar a relação entre o reúso de software e a manutenção de software. Este relatório deve abordar os seguintes pontos:

1. Definição de reúso de software: breve explicação sobre o que é reúso de software e suas principais formas (e.g., bibliotecas, frameworks, componentes, padrões de projeto).
2. Definição de manutenção de software: explicação sobre o que compreende a manutenção de software, incluindo suas categorias (corretiva, adaptativa, perfectiva e preventiva).
3. Impactos do reúso na manutenção: discussão sobre como o reúso de software pode influenciar cada tipo de manutenção de software, destacando tanto os aspectos positivos quanto os negativos.
4. Estratégias para maximizar os benefícios: propostas de estratégias ou práticas que podem ser adotadas para maximizar os benefícios do reúso de software na manutenção, minimizando os desafios e os riscos associados.

Conclusão: reflexões finais sobre a importância de considerar o reúso de software como uma estratégia para melhorar a eficiência e a eficácia da manutenção de sistemas.

Reflita

• Como a gestão eficaz da manutenção de software pode impactar não apenas a estabilidade e o desempenho dos sistemas, mas também a produtividade da equipe de desenvolvimento e a satisfação do cliente, e quais estratégias podem ser adotadas para maximizar os benefícios dessa prática enquanto se minimizam os custos e os riscos associados?
• Até que ponto as métricas de software são realmente eficazes para avaliar a qualidade e o progresso de um projeto de desenvolvimento de software?
• Até que ponto o reúso de software promove a eficiência e a inovação no desenvolvimento de novos sistemas, e quais são os desafios éticos e técnicos associados à prática do reúso em termos de segurança, propriedade intelectual e manutenção a longo prazo?

Resolução do estudo de caso

Para essa atividade, uma possível elaboração para o relatório está apresentada a seguir: 

1. Definição de reúso de doftware: reúso de software é a prática de usar código existente para novos desenvolvimentos, reduzindo o tempo e o custo de desenvolvimento e melhorando a qualidade do software ao aproveitar soluções já testadas.
2. Definição de manutenção de software: a manutenção de software é o processo de modificar um software após a entrega, para corrigir falhas, melhorar a performance ou outros atributos, ou adaptar o software a um ambiente alterado.
3. Impactos do reúso na manutenção:
4. Positivos: pode reduzir o esforço de manutenção ao usar componentes bem testados e documentados; facilita a manutenção corretiva e perfectiva ao promover a consistência no código; e pode acelerar a adaptação a novas plataformas ao reutilizar software compatível.
5. Negativos: pode introduzir dependências externas que complicam a manutenção adaptativa; a necessidade de compatibilidade com componentes reutilizados pode limitar as opções de atualização e melhoria.
6.  Estratégias para maximizar os benefícios:
   • Adotar políticas de documentação e versionamento rigorosas para componentes reutilizáveis.
   • Fomentar uma cultura de qualidade e testes abrangentes para o software reutilizável.
   • Utilizar ferramentas e plataformas que facilitam a gestão de dependências e a integração contínua.

Conclusão: o reúso de software, quando bem planejado e executado, pode ser uma poderosa ferramenta para melhorar a manutenção de software, mas requer atenção cuidadosa aos detalhes de implementação e gestão de dependências para maximizar seus benefícios.

Dê o play!

Assimile

O infográfico sobre métricas de produto, projeto e processo oferece uma visão sobre essas métricas e a importância de cada uma delas.

Referências

PÁDUA, W. Engenharia de software. 1. ed. Rio de Janeiro: LTC, 2019.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.