teorico02

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>Estudar a reengenharia a fim de melhorar a estrutura dos sistemas legados</p><p>(antigos) e seu entendimento para manutenção.</p><p>˨ Material Teórico</p><p>˨ Material Complementar</p><p>˨ Referências</p><p>Reengenharia de Software</p><p>Um Modelo de Processo de Reengenharia de Software</p><p>Podemos utilizar como exemplo um software que foi utilizado durante muitos anos em uma</p><p>empresa, passando por correções e adaptações, sendo inclusive aperfeiçoado algumas vezes. A</p><p>equipe responsável pela manutenção desse software sempre teve ótimas intenções durante todo</p><p>o ciclo de vida do sistema, porém deixou de lado os princípios da engenharia de software, por</p><p>conta do prazo, deixando assim a aplicação instável (PRESSMAN; MAXIN, 2016).</p><p>Nessa situação mencionada, a aplicação continua operando, mas sempre que alguma alteração é</p><p>realizada diversos problemas em cascata são encontrados, porém, o sistema deve continuar</p><p>evoluindo, o que deve ser realizado?</p><p>Esse problema não é nenhuma novidade nas empresas de desenvolvimento de software,</p><p>portanto a reengenharia de software ganha cada vez mais espaço há quase meio século devido</p><p>aos problemas encontrados na manutenção dos sistemas (PRESSMAN; MAXIN, 2016).</p><p>TEMA 1 de 3</p><p>˨ Material Teórico</p><p>Saiba Mais</p><p>A reengenharia de software é demorada, possui um custo elevado e</p><p>utiliza recursos (equipamentos e pessoas) que poderiam estar alocados</p><p>em problemas que demandam maior urgência, portanto ela não é</p><p>Podemos dizer que a reengenharia é um trabalho de reforma, Pressman e Maxin (2016) utilizam</p><p>uma forma análoga ao trabalho de reforma de uma casa, onde você acaba de realizar a compra de</p><p>uma casa em um outro estado e nunca viu o imóvel, pagou um preço relativamente baixo, porém</p><p>foi avisado que a casa poderia precisar de uma reforma completa, quais ações você tomaria nessa</p><p>situação?</p><p>realizada em alguns meses e sim em alguns anos, fazendo com que as</p><p>empresas tomem medidas de estratégias pragmáticas.</p><p>Antes do início da reforma seria interessante realizar uma inspeção na casa,</p><p>determinando se a reforma necessária é simples ou completa, gerando critérios</p><p>rigorosos para uma inspeção profunda, podendo inclusive ser realizada por um</p><p>profissional especializado na área;</p><p>Antes de demolir você deve verificar se a casa possui uma boa estrutura, pois caso</p><p>ela seja aceitável talvez seja possível remodelar, custando menos e gastando menos</p><p>tempo;</p><p>Antes de iniciar a reforma deve-se verificar como a casa foi construída, enfatizando</p><p>paredes, fiação, hidráulica e partes internas da estrutura, pois mesmo em uma</p><p>situação de descarte de tudo, as informações obtidas podem ser úteis na</p><p>reconstrução;</p><p>Na reforma a prioridade é a utilização de materiais modernos e duráveis, a princípio</p><p>tendo um custo elevado, porém pensando em manutenções futuras se evitaria gasto</p><p>e tempo;</p><p>Caso você optasse pela reforma, teria disciplina e utilizaria práticas que trariam alta</p><p>qualidade no presente e no futuro.</p><p>Apesar de estarmos utilizando esses princípios analogamente para a reforma de uma casa, eles</p><p>se aplicam integralmente com a reengenharia de sistemas utilizada na engenharia de software.</p><p>Segundo Pressman e Maxin (2016), para realizar a implementação dos princípios de</p><p>reengenharia de software, pode-se utilizar um modelo de processo que possui seis atividades:</p><p>Reestruturação de documentos;</p><p>Reestruturação dos dados;</p><p>Engenharia direta;</p><p>Análise do inventário;</p><p>Reestruturação do código;</p><p>Engenharia reversa.</p><p>Figura 1 – Um modelo de processo de reengenharia de</p><p>software</p><p>Fonte: Adaptada de PRESSMAN; MAXIN, 2016, p. 803</p><p>Em algumas situações, as atividades mencionadas por Pressman e Maxin (2016) podem ocorrer</p><p>em uma sequência linear, porém isso não é uma regra, podendo acontecer de a engenharia</p><p>reversa, que é o entendimento do funcionamento interno do sistema, ocorrer antes do início da</p><p>reestruturação dos documentos.</p><p>Atividades de Reengenharia de Software</p><p>O modelo demonstrado na Figura 1 é cíclico, portanto, cada uma das atividades pode ser</p><p>retomada e o processo pode ser concluído após qualquer uma das atividades ocorrerem.</p><p>Segundo Pressman e Maxin (2016), as atividades que compõem a reengenharia de software são:</p><p>A análise de inventário deve ser realizada pelas empresas em todas as aplicações que possuem.</p><p>De forma simplificada, esse inventário pode ser realizado por meio de uma planilha com</p><p>informações detalhadas, como por exemplo: tamanho, idade e fatores críticos de negócios. Após</p><p>a organização das informações poderá encontrar como resultado as aplicações que são fortes</p><p>candidatas a reengenharia (PRESSMAN; MAXIN, 2016).</p><p>A reestruturação dos documentos é utilizada quando a documentação dos sistemas legados é</p><p>ineficiente e precisa ser gerada uma documentação mínima para seu entendimento, pois em</p><p>algumas situações os sistemas são essenciais e realizar mudanças nos mesmos pode ser algo</p><p>traumático.</p><p>Já na engenharia reversa o foco é analisar o software com intuito de criar uma representação de</p><p>alto nível de abstração em relação ao código-fonte, portanto, é um processo de recuperação do</p><p>projeto do software. Existem ferramentas específicas para a engenharia reversa, que são</p><p>responsáveis por extrair informações do projeto de dados, da arquitetura procedural com base</p><p>no sistema existente (PRESSMAN; MAXIN, 2016).</p><p>O mais comumente tipo de reengenharia utilizado é a reestruturação do código, pois alguns</p><p>sistemas legados possuem uma arquitetura sólida, porém codificado em módulos que dificultam</p><p>Análise de inventário;</p><p>Reestruturação dos documentos;</p><p>Engenharia reversa;</p><p>Reestruturação do código;</p><p>Reestruturação dos dados;</p><p>Engenharia direta.</p><p>seu entendimento, portanto, o foco desse tipo de reengenharia é a reestruturação dentro dos</p><p>módulos. A reestruturação de código ocorre em um nível baixo de abstração.</p><p>Por fim, a engenharia direta foca em uma situação chamada “mundo ideal”, onde os sistemas</p><p>seriam recriados por meio de um processo automatizado, onde o sistema legado seria</p><p>automaticamente analisado, reestruturado e recriado de forma a apresentar as melhores</p><p>práticas de software do momento. É improvável que isso ocorra em algum momento, porém as</p><p>ferramentas de reengenharia a cada dia buscam inserir funcionalidades para prover esse tipo de</p><p>funcionalidade.</p><p>Engenharia Reversa</p><p>Segundo Pressman e Maxin (2016), a engenharia reversa relembra uma imagem do “slot</p><p>mágico” onde você insere nesse slot uma lista de código sem documentação, desenvolvida de</p><p>qualquer forma, e de um outro lado é gerada a documentação completa do sistema. Claro que</p><p>esse “slot mágico” não existe, mas a engenharia reversa pode abstrair informações de um</p><p>projeto a partir de seu código-fonte, porém o nível de abstração e a documentação comparados</p><p>com um analista pode ser bem variado.</p><p>Você Sabia?</p><p>O nível de abstração em um projeto de engenharia reversa e as</p><p>ferramentas utilizadas para sua realização irão refletir na sofisticação</p><p>das informações do projeto a serem extraídas diretamente do código-</p><p>fonte, portanto, o ideal é que o nível de abstração possua o maior nível</p><p>possível.</p><p>O nível de qualidade de um processo de engenharia reversa está altamente ligado ao nível de</p><p>detalhes fornecidos no nível de abstração, portanto, a qualidade é reduzida drasticamente</p><p>conforme o nível de abstração aumenta. Segundo Pressman e Maxin (2016), dado um código-</p><p>fonte, é relativamente simples desenvolver uma abstração completa do projeto procedural,</p><p>porém é muito mais complexo o desenvolvimento de um conjunto completo de diagramas UML</p><p>ou outros modelos.</p><p>A qualidade da engenharia reversa melhora na mesma dimensão em que a qualidade da análise</p><p>realizada pelo profissional que está realizando a engenharia reversa melhora.</p><p>Podemos definir como interatividade o grau segundo qual as pessoas são integradas às</p><p>ferramentas automatizadas para realizar a criação de um processo eficaz de engenharia reversa,</p><p>portanto, na medida</p>
<p>em que a abstração se eleva a interatividade também deve subir para que a</p><p>qualidade não seja afetada (PRESSMAN; MAXIN, 2016).</p><p>Definimos direcionalidade como um processo de engenharia reversa unidirecional, portanto,</p><p>todas as informações extraídas do código-fonte são disponibilizadas para um engenheiro de</p><p>software, que pode realizar seu uso durante qualquer momento na manutenção.</p><p>Figura 2 – O processo de engenharia reversa</p><p>Fonte: Adaptada de PRESSMAN; MAXIN, 2016, p. 806</p><p>A Figura anterior representa o processo de engenharia reversa, onde um código-fonte não</p><p>estruturado é recebido e são realizados processos para que ele seja reestruturado e se torne mais</p><p>fácil de ser lido/entendido (SOMMERVILLE, 2016).</p><p>A atividade central da engenharia reversa é a extração das abstrações contidas em um sistema de</p><p>software, avaliando assim um sistema legado, baseando-se muitas vezes no código-fonte,</p><p>devido à comumente falta de documentação, desenvolver uma documentação significativa do</p><p>processamento executado, da interface do usuário e das estruturas de dados ou banco de dados</p><p>existente (SOMMERVILLE, 2016).</p><p>Quando falamos em engenharia reversa dos dados podemos dizer que ela ocorre em diferentes</p><p>níveis de abstração, normalmente ela é a primeira tarefa da reengenharia, tendo como primeira</p><p>atividade a construção de um diagrama de classes UML.</p><p>- PRESSMAN; MAXIN, 2016, p. 263</p><p>“Estruturas de dados internas. As técnicas de engenharia reversa para dados</p><p>internos de programa foram-se na definição de classes de objetos. Isso é feito</p><p>examinando-se o código do programa para agrupar variáveis de programa</p><p>relacionadas. Em muitos casos, a organização dos dados dentro do código</p><p>identifica tipos de dados abstratos. Por exemplo, estruturas de registro, arquivos,</p><p>listas e outras estruturas de dados muitas vezes fornecem um indicador inicial das</p><p>classes. Estrutura de banco de dados. Seja qual for sua organização lógica e</p><p>estrutura física, um banco de dados permite a definição de objetos de dados e</p><p>suporta algum método para estabelecer relações entre objetos. Portanto, para fazer</p><p>a reengenharia de um esquema de banco de dados para outro é necessário entender</p><p>os objetos e suas relações. ”</p><p>Segundo Pressman e Maxin (2016), alguns passos podem ser utilizados para a definição de um</p><p>modelo de dados existente, sendo precursor para a reengenharia de um novo modelo de</p><p>sistemas de banco de dados:</p><p>No que diz respeito ao processamento, a engenharia reversa se inicia com um grande esforço</p><p>para entender e extrair abstrações procedurais por meio do código-fonte da aplicação. O código</p><p>é analisado em diversos níveis de abstração:</p><p>Realizar a criação de um modelo do objeto inicial;1</p><p>Encontrar e determinar os atributos candidatos às chaves;2</p><p>Realizar o refinamento das classes provisórias;3</p><p>Realizar a definição das generalizações;4</p><p>Realizar a descoberta das associações.5</p><p>Sistema;</p><p>Programa;</p><p>Componente;</p><p>Padrão;</p><p>Instruções.</p><p>Primeiramente, tenta-se entender o sistema em sua totalidade, posteriormente passando-se a</p><p>níveis mais detalhados da engenharia reversa.</p><p>Por fim, temos engenharia reversa focada nas interfaces de usuário, essas se tornaram muito</p><p>sofisticadas e obrigatórias para sistemas atuais, portanto, a reengenharia de interfaces se</p><p>tornou o tipo mais comum de atividade da reengenharia, porém antes de recriar uma interface</p><p>de usuário a engenharia reversa deve ser realizada (PRESSMAN; MAXIN, 2016).</p><p>Para se ter o entendimento completo de uma interface de usuário, sua estrutura e seu</p><p>comportamento devem ser muito bem compreendidos. Segundo Pressman e Maxin (2016), três</p><p>questões básicas devem ser respondidas quando se inicia com a engenharia reversa em uma</p><p>interface de usuário, são elas:</p><p>Para responder as duas primeiras perguntas utiliza-se a modelagem comportamental, pois</p><p>grande parte das informações pode ser obtida por meio da manifestação externa da interface.</p><p>Uma interface gráfica remodelada pode não refletir exatamente a anterior, podendo ser</p><p>completamente diferente (PRESSMAN; MAXIN, 2016).</p><p>Reestruturação</p><p>Quando falamos em reestruturação de software estamos nos referindo à modificação do próprio</p><p>código-fonte com intuito de deixá-lo mais amigável, facilitando assim o trabalho futuro de</p><p>manutenção. A reestruturação não modifica a arquitetura geral do sistema, pois seu trabalho é</p><p>Quais são as ações básicas (por exemplo, teclas e cliques de mouse) que a interface</p><p>deve processar?</p><p>Qual é a descrição compacta da resposta comportamental do sistema para essas</p><p>ações?</p><p>O que significa substituição ou, mais especificamente, que conceito de equivalência</p><p>de interfaces é relevante aqui?</p><p>concentrado nos módulos e estruturas locais, caso a reestruturação vá além dos limites dos</p><p>módulos e adentra a arquitetura do sistema, ela se torna engenharia direta (PFLEEGER, 2004).</p><p>Segundo Pressman e Maxin (2016), a reestruturação pode ser dividida em dois tipos:</p><p>Existem diversas técnicas de reestruturação para uso com ferramentas de reengenharia, dentre</p><p>elas podemos citar o diagrama de intercâmbio de recursos, que, segundo Pressman e Maxin</p><p>(2016), realiza o mapeamento de cada módulo do programa e os recursos como:</p><p>Reestruturação de código;</p><p>Reestruturação de dados.</p><p>Importante!</p><p>A reestruturação de código é realizada com a ideia de gerar um projeto</p><p>que contenha a mesma função, porém com um maior nível de</p><p>qualidade em relação ao sistema inicial.</p><p>Tipos de dados;</p><p>Procedimentos;</p><p>Variáveis</p><p>Antes de se iniciar a reestruturação de dados, realiza-se uma atividade de engenharia reversa</p><p>chamada análise do código-fonte. Nessa atividade são realizadas avaliações de todas as</p><p>instruções de linguagem de programação que contenham:</p><p>Denomina-se análise de dados, a tarefa de extrair itens de dados e objetos para a obtenção de</p><p>informações de fluxo de dados e também para entendimento das estruturas dos dados</p><p>existentes que necessitam de implementação.</p><p>Após a conclusão da análise de dados, inicia-se o reprojeto dos dados que é uma fase de</p><p>padronização do registro de dados e tem por objetivo esclarecer definições de dados com o</p><p>intuito de gerar consistência entre nomes de itens de dados ou formatos de registros físicos em</p><p>uma estrutura de dados ou formato de arquivo existente (PAULA FILHO, 2009).</p><p>Também podemos mencionar a racionalização de nomes de dados, que assegura que todas as</p><p>convenções existentes para nomes de dados sejam aplicadas com os padrões locais exigidos</p><p>(PRESSMAN; MAXIN, 2016).</p><p>Caso a reestruturação ultrapasse a padronização e a racionalização, são realizadas alterações</p><p>físicas nas estruturas de dados existentes, para assim gerar um projeto de dados mais adequado,</p><p>possibilitando assim a transformação dos formatos de arquivo ou mesmo tipo do banco de</p><p>dados (PRESSMAN; MAXIN, 2016).</p><p>Definições de dados;</p><p>Descrições de arquivos;</p><p>Entrada e saída;</p><p>Descrições da interface.</p><p>Engenharia Direta</p><p>De acordo com Pressman e Maxin (2016), analogamente podemos comparar um programa com</p><p>fluxo de controle a um prato de espaguete, possuindo módulos com duas mil instruções,</p><p>algumas linhas de comentários úteis e 290 mil instruções de código-fonte e nenhuma</p><p>documentação, devendo ser alterado para englobar alterações nos requisitos do usuário,</p><p>seguindo as seguintes opções:</p><p>É muito difícil mencionar uma opção correta, porém as circunstâncias podem recomendar a</p><p>primeira, mesmo sabendo que as outras opções sejam mais coerentes, porém ao invés de</p><p>aguardar até que a manutenção seja efetivamente solicitada, utiliza-se resultados da análise de</p><p>inventário para escolher um programa que irá permanecer em uso por alguns anos e está sendo</p><p>utilizado com sucesso no momento, podendo passar por alterações importantes ou</p><p>melhoramentos futuros. Na sequência se passa para as próximas opções (PRESSMAN; MAXIN,</p><p>2016).</p><p>Em um primeiro momento, a ideia de que se crie um novo sistema quando existe uma versão</p><p>ainda em funcionamento pode ser bastante extravagante, porém antes de pensar no trabalho é</p><p>necessário</p>
<p>considerar alguns argumentos:</p><p>Você pode trabalhar duro, realizando diversas alterações, encontrando problemas</p><p>de projeto improvisado e de código-fonte confuso para implementar as alterações</p><p>necessárias;</p><p>Você pode tentar entender os detalhes internos do sistema em um esforço para</p><p>tornar as modificações mais eficazes;</p><p>Você pode reprojetar, recodificar e testar todas as partes do sistema que necessitam</p><p>de modificação, aplicando uma abordagem de engenharia de software a todos os</p><p>segmentos revisados;</p><p>Você pode reprojetar completamente, recodificando e testando o programa</p><p>utilizando ferramentas de reengenharia para ajudar a entender o projeto atual.</p><p>Custo;</p><p>Referente ao custo podemos mencionar que ele pode ser até quarenta vezes o do</p><p>desenvolvimento inicial. Já o reprojeto da arquitetura de software usando conceitos mais</p><p>modernos pode ajudar muito na futura manutenção do sistema. O sistema em funcionamento</p><p>serve como protótipo para o sistema que será desenvolvido, portanto, a produtividade do</p><p>desenvolvimento certamente será muito mais alta do que o normal. O sistema antigo está em</p><p>uso e já existe experiência suficiente do usuário, portanto, novos requisitos e a ordem das</p><p>mudanças são facilmente decididas. As ferramentas automatizadas de reengenharia irão facilitar</p><p>algumas etapas do trabalho a ser desenvolvido e por fim irá existir uma configuração de</p><p>software completa com documentos, programas e dados depois de uma manutenção preventiva</p><p>(PRESSMAN; MAXIN, 2016).</p><p>Facilidade de manutenção futura;</p><p>Aumento de produtividade por conta do protótipo pronto;</p><p>Experiência do usuário;</p><p>Ferramentas de automatização de reengenharia;</p><p>Configuração completa do software.</p><p>Importante!</p><p>Podemos dizer que na maioria das vezes a engenharia direta não cria</p><p>apenas um sistema equivalente e moderno de um sistema legado,</p><p>porém novos requisitos de usuário e tecnologias são incluídos nesse</p><p>trabalho e o programa redesenvolvido amplia as funcionalidades do</p><p>sistema legado (SOMMERVILLE, 2016).</p><p>Segundo Pressman e Maxin (2016), a engenharia direta é aplicada a dois tipos de sistemas, são</p><p>eles:</p><p>Nos últimos anos, os sistemas centralizados foram sendo distribuídos entre diversas</p><p>plataformas clientes, embora diferentes ambientes distribuídos possam ser projetados, a</p><p>aplicação centralizada clássica que passou pelo processo de reengenharia se transformou em</p><p>uma arquitetura cliente-servidor, possuindo as seguintes características:</p><p>A reengenharia para as aplicações cliente-servidor se inicia com uma análise completa do</p><p>ambiente comercial, abrangendo o mainframe existente. Utiliza-se três leis de abstração:</p><p>Engenharia direta para arquiteturas cliente-servidor;</p><p>Engenharia direta para arquiteturas orientadas a objetos.</p><p>A funcionalidade da aplicação migrada para cada computador</p><p>cliente;</p><p>Novas interfaces gráficas de usuário são implementadas nas instalações dos</p><p>clientes;</p><p>Funções de banco de dados são atribuídas ao servidor;</p><p>Funcionalidades especializadas podem permanecer no servidor.</p><p>O banco de dados é a base para uma aplicação cliente--servidor, pois gerencia</p><p>transações e consultas dentro de um conjunto de regras de negócio definidas;</p><p>Já na engenharia direta para arquiteturas orientadas a objetos, o foco é o paradigma orientado a</p><p>objetos, utilizado por diversas empresas no mundo todo e cada vez mais ganhando espaço.</p><p>Nesse tipo de reengenharia, primeiramente o software passa por engenharia reversa para que</p><p>possam ser criados apropriadamente:</p><p>Caso o sistema em que foi aplicada a reengenharia amplie suas funcionalidades ou</p><p>comportamentos em relação à aplicação original, criam-se diagramas de casos de uso. Esses</p><p>modelos seguem hierarquia de classe, modelos de relacionamento de objetos, modelos de</p><p>comportamento de objeto e subsistemas são definidos, iniciando assim o projeto orientado a</p><p>objetos.</p><p>Aspectos Econômicos da Reengenharia</p><p>Em uma situação ideal, todo sistema que não absorve mais manutenções poderia ser aposentado</p><p>e substituído por uma outra aplicação de alta qualidade, utilizando modernas tecnologias e</p><p>metodologias da engenharia de software, porém o mundo em que vivemos possui recursos</p><p>limitados e a reengenharia utiliza recursos que podem ser utilizados para outros aspectos do</p><p>negócio (PRESSMAN; MAXIN, 2016).</p><p>A camada de regras de negócio representa o software tanto do lado do cliente,</p><p>quanto do lado do servidor, executando tarefas de controle e coordenação para</p><p>assegurar que as transações e consultas entre a aplicação cliente e o banco estejam</p><p>em conformidade com as regras de negócio;</p><p>A camada das aplicações cliente realiza a implementação de negócio exigida por um</p><p>grupo específico de usuários e a comunicação é controlada pela camada de negócios.</p><p>Modelos de dados;</p><p>Modelos funcionais;</p><p>Modelos comportamentais.</p><p>Ao pensar em realizar uma atividade de reengenharia, devemos fazer uma análise referente ao</p><p>custo-benefício. Segundo Pressman e Maxin (2016), foram definidos nove parâmetros de</p><p>análise de custo-benefício para a reengenharia:</p><p>A fórmula para se chegar ao custo associado à manutenção de um sistema candidato à</p><p>reengenharia é:</p><p>CustoManutenção = [P3 – (P1 + P2)] x L</p><p>Os custos relacionados à reengenharia são definidos seguindo a seguinte relação:</p><p>CustoReengenharia = P6 – (P4 + P5) x ( L – P8) – (P7 x P9)</p><p>P1: Custo anual corrente de manutenção para uma aplicação;</p><p>P2: Custo anual corrente das operações para uma aplicação;</p><p>P3: Valor de negócio anual corrente de uma aplicação;</p><p>P4: Custo de manutenção anual previsto após a reengenharia;</p><p>P5: Custo anual previsto das operações após a reengenharia;</p><p>P6: Valor de negócio anual previsto após a reengenharia;</p><p>P7: Custos estimados da reengenharia;</p><p>P8: Prazo estimado para fazer a reengenharia;</p><p>P9: Fator de risco da reengenharia (P9 = 1,0 nominal);</p><p>L: Expectativa de vida do sistema.</p><p>Utilizando os custos calculados anteriormente podemos calcular o benefício total da</p><p>reengenharia:</p><p>CustoBenefício = CustoReengenharia – CustoManutenção</p><p>De acordo com Pressman e Maxin (2016), a análise de custo-benefício pode ser realizada para</p><p>todas as aplicações de alta prioridade levantadas durante o inventário. As aplicações que</p><p>possuem custo-benefício mais elevado podem ser selecionadas para a reengenharia, já o</p><p>trabalho com as outras aplicações pode ser alocado até que mais recursos estejam disponíveis.</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Livros</p><p>Engenharia de Software: Qualidade e Produtividade com</p><p>Tecnologia</p><p>Leia o capítulo 10.1 – Reuso de Software do livro.</p><p>HIRAMA, K. Engenharia de Software: Qualidade e Produtividade com Tecnologia. 1. ed. Rio de</p><p>Janeiro: Elsevier, 2011.</p><p>Engenharia de Software</p><p>Leia o capítulo 2 – Técnicas para Estimativa de Tamanho e de Custo do livro.</p><p>VETORAZZO, A. de S. Engenharia de Software. 1. ed. Porto Alegre: Grupo A, 2018.</p><p>Metodologias Ágeis: Engenharia de Software</p><p>Leia o capítulo 4 – Metodologias de Desenvolvimento Tradicionais do livro.</p><p>SBROCCO, J. H. T. de C. Metodologias Ágeis: Engenharia de Software. 1. ed. 2012.</p><p>TEMA 2 de 3</p><p>˨ Material Complementar</p><p>Engenharia de Software: Os Paradigmas Clássico e Orientado</p><p>a Objetos</p><p>Leia o capítulo 8 – Reusabilidade e Portabilidade do livro.</p><p>SCHACH, S. R. Engenharia de Software: Os Paradigmas Clássico e Orientado a Objetos. 7. ed. Porto</p><p>Alegre: AMGH, 2010.</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</p><p>Software 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,</p><p>2004.</p><p>PINTO, A. da S. A Importância de Criar Uma Cultura DevOps nas Organizações. IETEC,</p><p>28/05/2018. Disponível em: .</p>
<p>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>