Manutenção de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

<p>Conteudista: Prof. Me. Luiz Carlos Machi Lozano</p><p>Revisão Textual: Esp. Jéssica Dante</p><p>Objetivo da Unidade:</p><p>Abordar a necessidade de manutenção em sistemas de software devido às</p><p>constantes necessidades de modificações.</p><p>˨ Material Teórico</p><p>˨ Material Complementar</p><p>˨ Referências</p><p>O Ciclo de Vida do Software em Constante</p><p>Modificação</p><p>O Sistema em Constante Modificação</p><p>Podemos dizer que o desenvolvimento de um sistema está completo quando ele pode ser</p><p>utilizado pelos usuários em um ambiente de produção, ou seja, um ambiente real. Todas as</p><p>modificações realizadas no sistema após sua entrada em operação chama-se manutenção e, ao</p><p>contrário do que muitos pensam, a manutenção em um sistema de software não acontece da</p><p>mesma forma que nos dispositivos de hardware, onde são trocadas as peças defeituosas</p><p>(PFLEEGER, 2004).</p><p>Independentemente do domínio da aplicação, sua complexidade ou dimensão, o sistema</p><p>continuará evoluindo durante o tempo, essa é uma premissa do desenvolvimento de software, a</p><p>constante evolução. Em um software as alterações ocorrem para correções de erros, para</p><p>adaptação a um novo ambiente ou por solicitações realizadas por clientes devido às novas</p><p>características ou funções que ele deve possuir (PRESSMAN e MAXIN, 2016).</p><p>TEMA 1 de 3</p><p>˨ Material Teórico</p><p>Importante!</p><p>O maior objetivo dos desenvolvedores de software é produzir um</p><p>A manutenção de software não sofre igual à manutenção de hardware, onde em um determinado</p><p>tempo de vida útil uma peça deve ser substituída, portanto, pode vir de diferentes demandas e</p><p>modificações externas, desde correções de defeitos até solicitações de novas funcionalidades</p><p>pelos usuários, sendo essas por necessidades internas ou externas.</p><p>No geral, as pessoas pensam que um projeto de desenvolvimento de software terá início e fim,</p><p>porém não existe um final definido, pois devido às necessidades tecnológicas ou de negócios, a</p><p>manutenção de software é uma fase que acompanha o sistema durante todo o seu ciclo de vida.</p><p>Nos dias atuais as empresas têm investido um valor muito alto no setor de Tecnologia, a maior</p><p>parte desse recurso é direcionado para a evolução e manutenção do sistema. Segundo</p><p>(SOMMERVILLE, 2016) a manutenção de software chega a custar 66% do orçamento destinado à</p><p>TI.</p><p>Segundo (PRESSMAN e MAXIN, 2016) nas últimas décadas ocorreram diversos estudos dentro</p><p>da Engenharia de Software com afinco de desenvolver uma teoria unificada para a evolução do</p><p>software, esse estudo originou as seguintes leis:</p><p>produto confiável para seus clientes, portanto, que seja livre de bugs e</p><p>que atendam suas especificações.</p><p>Lei da Mudança Contínua;</p><p>Lei da Complexidade Crescente;</p><p>Lei da Autorregulação;</p><p>Lei da Conservação da Estabilidade Organizacional;</p><p>A Lei da Mudança Contínua surgiu em 1974, inter-relacionada com a computação real, ou seja,</p><p>com evolução no decorrer do tempo e sofrendo adaptações contínuas e se tornando cada vez</p><p>menos satisfatória (PRESSMAN e MAXIN, 2016).</p><p>A Lei da Complexidade Crescente surgiu em 1974, na dimensão em que um sistema cresce sua</p><p>complexidade aumenta, a menos que sejam realizadas ações para mitigá-las (PRESSMAN e</p><p>MAXIN, 2016).</p><p>A Lei da Autorregulação surgiu em 1974 e é um processo de evolução de sistemas autorregulados</p><p>com processos próximos dos procedimentos normais (PRESSMAN e MAXIN, 2016).</p><p>A Lei da Conservação da Estabilidade Operacional surgiu em 1980 sem se preocupar com a taxa</p><p>de atividade efetiva média invariante durante o ciclo de vida do software (PRESSMAN e MAXIN,</p><p>2016).</p><p>A Lei da Conservação da Familiaridade surgiu em 1980 e está associada à evolução do sistema,</p><p>sendo reduzido o domínio caso ocorra um crescimento excessivo (PRESSMAN e MAXIN, 2016).</p><p>A Lei do Crescimento Contínuo surgiu em 1980 e o conteúdo funcional dos sistemas deve ser</p><p>continuamente aumentado durante o ciclo de vida para manter a satisfação do usuário em níveis</p><p>aceitáveis de aprovação (PRESSMAN e MAXIN, 2016).</p><p>A Lei da Qualidade em Declínio surgiu em 1996 e a qualidade dos sistemas diminui a menos que</p><p>eles sejam mantidos e adaptados com rigor devido às mudanças do ambiente em que o sistema</p><p>Lei da Conservação da Familiaridade;</p><p>Lei do Crescimento Contínuo;</p><p>Lei da Qualidade em Declínio;</p><p>Lei do Sistema de Realimentação.</p><p>opera (PRESSMAN e MAXIN, 2016).</p><p>Por fim, a Lei do Sistema de Realimentação surgiu em 1996, focada em sistemas em evolução</p><p>nos sistemas multinível, e devem ser tratados com objetivo de prover melhoria em qualquer</p><p>base razoável do sistema (PRESSMAN e MAXIN, 2016).</p><p>Podemos definir manutenção de software como um processo de melhorias e correções que um</p><p>sistema em desenvolvimento ou já concluído, portanto, qualquer mudança realizada após o</p><p>sistema estar disponível em produção.</p><p>Ao contrário do que muitos pensam, a vida de um sistema não termina na sua implantação, ou</p><p>seja, para que um sistema continue útil no decorrer do tempo é necessário que seja realizado</p><p>investimento em manutenção.</p><p>Um dos motivos principais para a realização da manutenção de um sistema é o aperfeiçoamento</p><p>tecnológico dele, pois assim o sistema se tornará sempre atual, aumentando assim sua vida útil</p><p>e também sua estabilidade.</p><p>Saiba Mais</p><p>Outro fator primordial é que os negócios vivem em constante mudança</p><p>e para que os sistemas acompanhem essa evolução é fundamental que</p><p>Segundo Sommerville (2016), ao classificarmos as manutenções existentes nos softwares</p><p>podemos encontrar três tipos:</p><p>As manutenções adaptativas são as manutenções que possuem objetivo de adaptar o sistema a</p><p>um novo requisito, portanto, uma nova regra de negócio. Esse tipo de manutenção possui a</p><p>finalidade de adequar o sistema ao ambiente no qual ele está inserido (SOMMERVILLE, 2016).</p><p>Um exemplo desse tipo de manutenção é a alteração nas alíquotas de imposto de renda pelo</p><p>governo, isso faz com que os sistemas que geram folhas de pagamento tenham que se adaptar</p><p>às novas regras para emissão correta das folhas de pagamento dos funcionários de uma</p><p>empresa.</p><p>Outro tipo de mudança muito utilizada são as mudanças corretivas, como o próprio nome diz,</p><p>são as mudanças que possuem o escopo de resolver problemas e defeitos encontrados no</p><p>sistema. Defeitos em sistemas devem ser tratados como situações comuns e em alguns casos</p><p>devem ser corrigidos de forma emergencial.</p><p>atendam as novas regras de negócios estabelecidas, incrementem</p><p>novas funcionalidades e se adequem às novas legislações vigentes</p><p>(PAULA FILHO, 2009).</p><p>Manutenção Adaptativa;</p><p>Manutenção Corretiva;</p><p>Manutenção Evolutiva.</p><p>Para mitigar esse tipo de defeito e consequentemente esse tipo de manutenção, utilizam-se</p><p>rotinas de testes automatizados nos sistemas, tendo hoje em dia departamentos dentro das</p><p>empresas de desenvolvimento de software responsáveis pela realização de rotinas de testes nos</p><p>aplicativos desenvolvidos, porém, como mencionado, isso minimiza, mas não acaba com</p><p>possíveis defeitos.</p><p>Por fim, temos as mudanças evolutivas, que possuem a característica de inserir novas</p><p>funcionalidades e prover melhorias aos sistemas. Em um mercado em constante mudança, é</p><p>comum que sejam exigidas novas funcionalidades e mudanças para que os sistemas continuem</p><p>atuais e competitivos.</p><p>Tipos de Sistemas</p><p>Os sistemas de software se diferenciam dos sistemas de hardware pelo fato de que os sistemas de</p><p>software são desenvolvidos para incorporar mudanças, pois os sistemas evoluem durante o ciclo</p><p>de vida, portanto, podemos dizer que as alterações em um sistema são partes importantes de seu</p><p>ciclo de vida e desenvolvimento, uma vez que um sistema que pouco sofre modificações pode se</p><p>tornar obsoleto em pouco tempo.</p><p>Saiba Mais</p><p>Os sistemas de software podem sofrer modificações não apenas devido</p><p>às solicitações de clientes, mas também pela sua própria natureza. Um</p><p>exemplo é o sistema que calcula a folha de pagamento de funcionários</p><p>de uma empresa, caso ocorra uma alteração nas alíquotas de imposto</p><p>de renda pelo governo, portanto uma alteração na lei, esse sistema</p><p>necessitará de modificações para</p>
<p>que as folhas de pagamento sejam</p><p>A seguir, segundo Pfleeger (2004), vamos entender um pouco mais de como os sistemas podem</p><p>ser classificados:</p><p>Os sistemas S são definidos e derivados de uma especificação, portanto, nesse tipo de sistema</p><p>um problema em específico é declarado em termos de todo o conjunto de circunstâncias às</p><p>quais ele se aplica. Um sistema S é estático, não se adaptando às mudanças do problema que o</p><p>gerou. Uma calculadora é um exemplo de um sistema S, pois ela foi definida para realizar as</p><p>operações básicas e sempre irá trabalhar da mesma forma, não sofrendo alterações por conta de</p><p>fatores externos (PFLEEGER, 2004).</p><p>Já os sistemas P são definidos para lidar com problemas abstratos, portanto, em situações onde</p><p>se utilizaria sistema S, porém em situações difíceis de serem abstraídas do mundo real. Um</p><p>exemplo de um sistema P é uma fase de um jogo, onde cada situação pode envolver diversos</p><p>cálculos, pois o número de movimentos é enorme e o tempo de resposta deve ser pequeno.</p><p>Nesses casos se desenvolve uma solução aproximada (PFLEEGER, 2004).</p><p>Em sistemas P os requisitos são levantados por aproximação, portanto, a solução depende muito</p><p>da interpretação do analista ao gerar os requisitos. Mesmo em situações em que a solução seja</p><p>calculadas corretamente, nesse caso podemos dizer que o sistema</p><p>necessitou de alteração mesmo estando funcionando perfeitamente</p><p>(SOMMERVILLE, 2016).</p><p>Sistemas S;</p><p>Sistemas P;</p><p>Sistemas E.</p><p>exata, em um sistema P a solução desenvolvida sofre pela influência do ambiente em que ela irá</p><p>operar. Em um sistema P muitas coisas podem ser alteradas.</p><p>Por fim, chegamos ao Sistema E, que considerando os sistemas S e P, onde as situações do</p><p>mundo real permanecem estáveis, podemos ter uma terceira classe de sistemas, que</p><p>incorporam alterações da natureza do mundo real em si. Podemos dizer que um sistema E está</p><p>embarcado no mundo real e sofre alterações na medida em que o mundo muda, portanto, o</p><p>sistema é parte integrante do mundo em que ele se modela (PFLEEGER, 2004).</p><p>Um exemplo de sistema P é um sistema bancário que prevê a estabilidade econômica de um país,</p><p>por exemplo, tendo como base as informações de como a economia opera. Nesse caso as</p><p>mudanças ocorrem no mundo em que ele está incluído, porém a economia não é completamente</p><p>conhecida e dominada, portanto, o modelo se modifica de acordo com nosso entendimento</p><p>(SOMMERVILLE, 2016).</p><p>Modificações Durante o Ciclo de Vida do Software</p><p>Ao examinarmos um sistema a partir de sua categoria, conforme estudamos anteriormente,</p><p>podemos notar em que momento durante o desenvolvimento poderá ocorrer alterações e</p><p>podemos dimensionar o quanto ela poderá afetar o sistema (PFLEEGER, 2004).</p><p>A manutenção de um sistema começa no momento em que ele é disponibilizado para os</p><p>usuários em produção. Na sequência, em alguns dias começam a surgir solicitações referentes a</p><p>bugs encontrados durante o uso do sistema (PRESSMAN e MAXIN, 2016).</p><p>Após algumas semanas os usuários podem indicar que o software precisa se adaptar às</p><p>necessidades e características do ambiente em que o sistema está sendo utilizado, em alguns</p><p>meses um outro grupo de usuários corporativo que até então não havia se interessado no</p><p>sistema pode reconhecer vantagens em seu uso e solicitar ajustes para o uso em outros setores</p><p>da empresa (PRESSMAN e MAXIN, 2016).</p><p>De forma similar, caso ocorra uma falha, você pode facilmente identificar o componente que</p><p>contém as causas e, assim, realizar as correções no projeto, código e plano de testes, ao invés de</p><p>realizar a correção apenas no código (PFLEEGER, 2004).</p><p>Portanto, os princípios da Engenharia de Software contribuem, não apenas para obtenção de um</p><p>código correto, mas também para tornar as mudanças mais fáceis de serem realizadas e rápidas</p><p>de serem resolvidas.</p><p>Podemos utilizar diversas ferramentas e técnicas dentro do processo de gerenciamento de</p><p>software, dentre elas podemos mencionar:</p><p>Importante!</p><p>A engenharia de software pode facilitar mudanças durante a</p><p>manutenção de um sistema de software, independentemente do tipo de</p><p>sistema que está sendo modificado, por exemplo, modularizando um</p><p>projeto e os componentes do código e realizando referência cruzada</p><p>dos componentes com os respectivos requisitos, você pode facilmente</p><p>acompanhar uma mudança, caso uma falha seja identificada, podendo</p><p>assim encontrar o componente que ela afeta e realizar os devidos</p><p>testes.</p><p>Documentação;</p><p>Versionamento;</p><p>Esquecida por muitos, a documentação possui papel fundamental não apenas no</p><p>desenvolvimento de um novo sistema, mas também durante o período de manutenção. Um dos</p><p>fatores mais importantes para se manter uma documentação completa e atualizada está no fato</p><p>da grande rotatividade dentro das equipes de desenvolvimento. A documentação possibilita a</p><p>transferência de conhecimento sobre o sistema de forma eficaz, não ficando dependente de</p><p>uma outra pessoa.</p><p>O versionamento tem por objetivo documentar todas as alterações realizadas em um sistema a</p><p>cada entrega, de forma que seja possível retomar a versões anteriores em caso de erros (MORAIS</p><p>e ZANIN, 2017).</p><p>Já o status reporting é um documento que visa realizar o alinhamento entre todos os envolvidos</p><p>em um projeto em relação ao estado atual de desenvolvimento.</p><p>Duração da Vida do Sistema</p><p>Para desenvolver um sistema de manutenção simples, devemos fazer o seguinte</p><p>questionamento: É possível desenvolver um sistema na primeira tentativa? Utilizando</p><p>componentes com alta coesão e baixo acoplamento, possuindo documentação completa e</p><p>atualizada, mesmo assim precisaremos nos preocupar com a fase de manutenção? A resposta</p><p>para esses questionamentos é "sim" (PFLEEGER, 2004).</p><p>Status reporting.</p><p>Trocando Ideias...</p><p>Não há forma de garantir que os sistemas não irão precisar de</p><p>Uma outra preocupação que devemos ter é: Qual será o nível de modificações que devem ser</p><p>esperadas no desenvolvimento do sistema? A resposta a esse questionamento irá depender da</p><p>natureza do sistema desenvolvido (SOMMERVILLE, 2016).</p><p>Vimos que sistemas S praticamente não sofrem mudanças e sistemas P sofrem uma incidência</p><p>muito maior de alterações durante o ciclo de vida, já os sistemas E vivem em constante</p><p>modificação, devido a isso diversos profissionais da engenharia de software denominam a fase</p><p>de manutenção do desenvolvimento em fase evolutiva (PFLEEGER, 2004).</p><p>Um sistema legado é um sistema desenvolvido anteriormente, quando havia outras</p><p>necessidades e ambientes, portanto devem ser analisados com intuito de evoluírem de acordo</p><p>com a evolução da tecnologia e necessidades do negócio, porém em algum momento podemos</p><p>decidir trocá-lo por um novo sistema e descartá-lo (PFLEEGER, 2004).</p><p>Quadro 1 – Exemplos de mudanças durante o desenvolvimento de software</p><p>Atividade da qual as mudanças</p><p>iniciais resultam</p><p>Artefatos que requerem</p><p>mudanças consequentes</p><p>Análise de requisitos Especificação de requisitos</p><p>Projeto do sistema Especificação do projeto</p><p>arquitetural</p><p>manutenção, portanto, devemos planejá-los de forma que eles possam</p><p>ser modificados durante seu ciclo de vida.</p><p>Especificação do projeto técnico</p><p>Projeto do programa</p><p>Especificação do projeto de</p><p>programa</p><p>Implementação de programa</p><p>Código do programa</p><p>Documentação do programa</p><p>Teste de unidade</p><p>Planos de teste</p><p>Roteiros de teste</p><p>Teste do sistema</p><p>Planos de teste</p><p>Roteiros de teste</p><p>Entrega do sistema</p><p>Documentação do usuário</p><p>Auxílio ao treinamento</p><p>Documentação do operador</p><p>Guia do sistema</p><p>Guia do programador</p><p>Aulas de treinamento</p><p>Fonte: PFLEEGER, 2004, p. 383</p><p>Podemos utilizar como base o tempo de desenvolvimento e manutenção em outros projetos de</p><p>desenvolvimento de software para ter uma base de tempo em que a fase evolutiva irá durar.</p><p>Segundo (PRESSMAN e MAXIN, 2016) o projeto de desenvolvimento de software tem duração</p><p>entre um e dois anos, porém requer outros cinco anos dedicados à sua manutenção.</p><p>Devido a isso podemos concluir que a fase de manutenção concentra boa parte do esforço no</p><p>desenvolvimento</p>
<p>de sistemas, portanto, os custos reservados para essa fase devem ser</p><p>calculados no início do projeto para que ele não venha trazer prejuízos.</p><p>Para um sistema que demande modificações significativas de forma contínua, devemos</p><p>questionar se não é melhor descartá-lo e desenvolver um novo sistema para atuar em seu lugar.</p><p>Para ajudar a tomar essa decisão, Pfleeger (2004) nos propõe algumas questões:</p><p>Caso ocorra resposta positiva para uma ou mais questões mencionadas, deve-se considerar que</p><p>é o momento de realizar a substituição do sistema existente por um novo sistema.</p><p>O custo de manutenção é muito alto?</p><p>O sistema não apresenta confiabilidade aceitável?</p><p>O software pode não conseguir se adaptar a alterações adicionais em um período</p><p>aceitável?</p><p>O sistema apresenta desempenho fora do padrão adequado mencionado na</p><p>documentação?</p><p>A utilização das funcionalidades do sistema estão se tornando limitadas?</p><p>Existem outros softwares que realizam as mesmas tarefas de forma dinamizada e</p><p>com um menor custo?</p><p>O hardware está apresentando um custo elevado e sua substituição por um hardware</p><p>mais moderno e barato justifica a substituição do sistema.</p><p>Importante!</p><p>Definimos como custo do ciclo de vida de um software o conjunto total</p><p>de custos relacionados ao desenvolvimento e manutenção do sistema,</p><p>desde a criação até sua substituição.</p><p>“Durante sua carreira, Lehman tem observado o comportamento de sistemas, à</p><p>medida que eles evoluem. Ele resumiu suas conclusões em cinco leis da evolução</p><p>de programas:</p><p>Mudança Contínua: Um programa que é utilizado passa por contínuas</p><p>mudanças ou, então, progressivamente se tornará menos útil. O processo de</p><p>mudança ou declínio continua até que a substituição do sistema, por uma</p><p>versão recriada, apresente melhor relação custo-benefício;</p><p>Aumento da complexidade: Quando um programa em evolução é</p><p>continuamente modificado, sua estrutura se deteriora. Consequentemente, a</p><p>complexidade aumenta, a menos que seja feito um retrabalho para mantê-la</p><p>estacionada ou reduzi-la;</p><p>Lei fundamental de evolução do programa: A evolução do programa está</p><p>sujeita a uma dinâmica que realiza o processo de programação e, portanto, as</p><p>medidas dos atributos do projeto global e dos atributos do sistema, se</p><p>A primeira lei menciona que os sistemas de grande porte nunca estão completos, portanto,</p><p>evoluem constantemente durante o tempo. Já a segunda lei diz que à medida que os sistemas</p><p>evoluem, os sistemas de grande porte agregam complexidade, a menos que se tomem ações</p><p>com afinco de reduzir a complexidade deles. O aumento de complexidade muitas vezes se dá pelo</p><p>fato de os desenvolvedores tomarem decisões precipitadas ao prepararem as mudanças e</p><p>correções dos problemas. Isso se dá pelo fato de normalmente não existir muito tempo entre a</p><p>solicitação de uma correção e a entrega da mesma (PFLEEGER, 2004).</p><p>Na terceira lei os softwares demonstram comportamentos e tendências regulares, essas</p><p>podendo ser medidas e previstas. A quarta lei menciona que não existem amplas ou intensas</p><p>alterações nos atributos organizacionais.</p><p>A Natureza da Mudança</p><p>Dentro do desenvolvimento de sistemas é comum que os desenvolvedores de software se</p><p>concentrem em desenvolver um código que implemente os requisitos e funcionalidades para</p><p>que a aplicação funcione corretamente, portanto, para cada uma das fases de desenvolvimento a</p><p>equipe segue os trabalhos realizados anteriormente (PRESSMAN e MAXIN, 2016).</p><p>- PRESSMAN e MAXIN, 2016</p><p>autorregulando com tendências e invariâncias estatisticamente</p><p>determináveis;</p><p>Conservação da estabilidade organizacional (taxa de trabalho invariante):</p><p>Durante a vida útil de um programa, a taxa de atividade global em um projeto</p><p>de programação é estatisticamente invariante;</p><p>Conservação da familiaridade (complexidade percebida): Durante a vida útil de</p><p>um programa, o conteúdo publicado (modificações, adições, remoções) de</p><p>sucessivas versões de um programa em evolução é estatisticamente</p><p>invariante.</p><p>Na fase de manutenção isso ocorre de forma completamente diferente, pois deve-se considerar</p><p>em reestabelecer as operações de trabalho dos usuários do sistema e descobrir se eles estão</p><p>satisfeitos com o seu funcionamento (PFLEEGER, 2004).</p><p>Deve-se também considerar o futuro, tentando prever o que pode acontecer de errado e mitigar</p><p>sobre as mudanças funcionais requeridas por uma alteração das regras de negócio.</p><p>Podemos dizer que a manutenção possui um enorme escopo, comparado com o</p><p>desenvolvimento, visto que diversos aspectos devem ser acompanhados e controlados.</p><p>Atividades e Funções na Manutenção de Software</p><p>Podemos dizer que as atividades que envolvem a manutenção de software são similares às</p><p>atividades realizadas durante a etapa de desenvolvimento de software, dentre as principais</p><p>atividades podemos mencionar:</p><p>Análise de requisitos;</p><p>Avaliação do Sistema e Projeto do Programa;</p><p>Programação;</p><p>Revisão do código;</p><p>Teste de modificações;</p><p>Atualização da documentação.</p><p>A manutenção de software envolve diversas pessoas, dentre elas estão os analistas de sistemas,</p><p>programadores e projetistas, todos com papéis parecidos (PFLEEGER, 2004).</p><p>Pelo fato de a manutenção exigir um conhecimento mais amplo de toda a estrutura e conteúdo</p><p>do código fonte do sistema, os programadores acabam trabalhando mais na manutenção do que</p><p>no desenvolvimento de um software (PFLEEGER, 2004).</p><p>Segundo Pfleeger (2004), a manutenção trabalha de forma simultânea com quatro</p><p>características fundamentais na evolução de um software, são elas:</p><p>Ainda segundo Pfleeger (2004), podemos mencionar algumas formas de manutenção, dentre</p><p>elas:</p><p>Controle de funcionalidades cotidianas do sistema;</p><p>Controlar as modificações do sistema;</p><p>Melhorar as funcionalidades admissíveis existentes;</p><p>Realizar medidas de prevenção a fim de que o desempenho do sistema se mantenha</p><p>em níveis aceitáveis.</p><p>Manutenção corretiva;</p><p>Manutenção adaptativa;</p><p>Manutenção perfectiva;</p><p>Manutenção preventiva.</p><p>A manutenção corretiva serve para controlar as funcionalidades cotidianas do sistema, portanto</p><p>a equipe de manutenção cuida de problemas relacionados a defeitos.</p><p>A manutenção adaptativa serve para inserir uma mudança em uma parte do sistema que foi</p><p>resultante de uma mudança em uma outra parte, portanto, é a inserção de mudanças</p><p>secundárias dentro de um sistema.</p><p>Já a manutenção perfectiva serve para aprimorar o projeto, portanto ao realizar alguma</p><p>manutenção no sistema são examinados os documentos, projeto, código e testes com afinco de</p><p>aperfeiçoamento.</p><p>Por fim, a manutenção preventiva, possui uma grande semelhança com a manutenção</p><p>perfectiva, porém sua maior finalidade é prevenir o acontecimento de falhas, portanto, são</p><p>inseridos diversos níveis de verificação no sistema, incluindo planos de testes.</p><p>Responsabilidades das Equipes</p><p>Existem pontos positivos e pontos negativos em atribuir a manutenção a uma equipe específica,</p><p>separada do desenvolvimento, podemos dizer que a equipe de desenvolvimento está</p><p>familiarizada com o sistema e também se os desenvolvedores souberem que eles mesmos farão</p><p>manutenção no sistema que estão desenvolvendo, certamente irão procurar facilitar essa</p><p>manutenção (PFLEEGER, 2004).</p><p>Saiba Mais</p><p>A manutenção de um sistema não necessariamente é realizada pela</p><p>equipe que o desenvolveu. Comumentemente uma equipe de</p><p>Porém, em algumas situações os desenvolvedores, pelo excesso de confiança sobre seu</p><p>desenvolvimento no sistema, não se preocupam em manter a documentação atualizada,</p><p>causando possíveis transtornos em futuras manutenções, ocasionadas por esquecimento ou</p><p>mesmo por mudança no quadro de funcionários da equipe de manutenção.</p><p>O trabalho de manutenção de um sistema deve envolver todos os membros da equipe, portanto,</p><p>usuários, operadores, representantes das partes interessadas (clientes) e equipe de</p><p>manutenção.</p><p>Os analistas ou os desenvolvedores delimitam as partes do código que deverão sofrer</p><p>modificações, o impacto gerado pelas modificações e os recursos que serão utilizados, como por</p><p>exemplo tempo</p>
<p>e esforço necessário.</p><p>Segundo Pfleeger (2004), as principais atividades realizadas pela equipe são:</p><p>manutenção é alocada após o sistema entrar em operação com a</p><p>incumbência de assegurar o bom funcionamento dele.</p><p>Entender o sistema;</p><p>Localizar informações na documentação do sistema;</p><p>Manter a documentação do sistema atualizada;</p><p>Ampliar as funcionalidades existentes, a fim de incluir novos requisitos ou</p><p>requisitos modificados;</p><p>Adicionar novas funções ao sistema;</p><p>Outra função importante para ressaltar é que os membros da equipe de manutenção devem</p><p>trabalhar com os usuários do sistema, operadores e clientes, primeiramente tentando entender</p><p>o problema no ponto de vista e da linguagem do usuário, posteriormente esse problema é</p><p>transformado em uma solicitação de modificação, que inclui características do funcionamento</p><p>atual do sistema e como o usuário espera que ele funcione. Na sequência são detalhadas as</p><p>modificações necessárias no sistema para atender essa solicitação de mudança. Após o sistema</p><p>ser modificado, ele deve ser testado e caso seja necessário se realiza um treinamento com os</p><p>usuários.</p><p>Podemos ver que a manutenção é um processo que envolve a interação entre pessoas, hardware</p><p>e software (PFLEEGER, 2004).</p><p>Descobrir a fonte das falhas ou problemas do sistema;</p><p>Localizar e corrigir defeitos;</p><p>Responder às questões sobre como o sistema funciona;</p><p>Reestruturar o projeto e os componentes do código;</p><p>Reescrever o projeto e os componentes do código;</p><p>Excluir o projeto e os componentes do código que não são mais utilizados;</p><p>Gerenciar as mudanças que são realizadas no sistema.</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Livros</p><p>Engenharia de Software: Projetos e Processos</p><p>Leia o capítulo 5 – Gestão das Alterações.</p><p>PAULA FILHO, W. de P. Engenharia de software: projetos e processos.  4. ed. Rio de Janeiro: LTC,</p><p>2019.</p><p>Engenharia de Software: Qualidade e Produtividade com</p><p>Tecnologia</p><p>Leia o capítulo 2 – Processos de Software.</p><p>HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de Janeiro:</p><p>Elsevier, 2011.</p><p>Metodologias Ágeis: Engenharia de Software</p><p>Leia o capítulo 3 – Engenharia de Software: Conceitos Básicos.</p><p>TEMA 2 de 3</p><p>˨ Material Complementar</p><p>SBROCCO,  J. H. T. de C.; MACEDO, P. C. Metodologias ágeis: engenharia de software. Editora Érica,</p><p>2012.</p><p>Processos de Desenvolvimento de Software – Capítulo</p><p>Manutenção de Software: Conceitos Gerais</p><p>MORAIS, I. S. de. Manutenção de software: conceitos gerais. In: MASCHIETTO, L. G. et al.</p><p>Processos de desenvolvimento de software. Porto Alegre: Grupo A, 2020. .</p><p>MORAIS, I.; ZANIN, A. Engenharia de software. Porto Alegre: SAGAH, 2017. (e-book)</p><p>MUNIZ, A. et al. Jornada Devops: unindo cultura ágil, Lean e tecnologia para entregar software</p><p>com qualidade.  2. ed. Rio de Janeiro: Brasport, 2019. (e-book)</p><p>PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de</p><p>Janeiro: LTC, 2008. (e-book)</p><p>PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Editora Pearson, 2004.</p><p>PINTO, A. da S. A importância de criar uma cultura DevOps nas organizações. IETEC, 28/05/2018.</p><p>Disponível em: . Acesso em: 05/05/2021.</p><p>PRESSMAN, R. S.; MAXIN, B. R. Engenharia de software: uma abordagem profissional. 8. ed.</p><p>Porto Alegre: Editora Bookman, 2016.</p><p>SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Editora Pearson, 2019.</p><p>TEMA 3 de 3</p><p>˨ Referências</p>