Univesp - 2021 - Revisao - Engenharia de Software

Texto de apoio - Revisão | Plínio Vilela\n\nTexto-base - Revisão | Plínio Vilela\n\nO que irei abordar nesta revisão:\n- processos de desenvolvimento de software;\n- metodologias ágeis – XP e Scrum;\n- requisitos de software;\n- elicitação e análise de requisitos;\n- modelagem de sistemas;\n- projeto de arquitetura;\n- padrões de arquitetura;\n- gerenciamento de configuração;\n- teste de software;\n- reuso e engenharia de software baseada em componentes.\n\nAbertura\nA disciplina Engenharia de Software está focada nos problemas relacionados a necessidade de se ampliar a produtividade das equipes de desenvolvimento de software e ao mesmo tempo melhorar a qualidade do que se estava produzindo em termos de produtos engajáveis aos clientes.\n\nA área vem evoluindo com o passar do tempo, técnicas e metodologias são propostas, avaliadas, adotadas ou aposentadas. É uma área muito ampla e que está em constante evolução.\n\nA seguir, apresento as partes mais importantes de cada um dos tópicos abordados pela disciplina, mas esse resumo não deve ser usado em substituição à leitura dos capítulos em si; deve ser visto mais como um reforço ao que já foi lido e estudado.\n\nTópico 1: Processos de software e desenvolvimento ágil\n\nA engenharia de software\nA engenharia de software tem por objetivo apoiar o desenvolvimento profissional de software, incluindo técnicas que apoiam especificação, projeto e evolução de programas. Engenheiros de software se preocupam em desenvolver produtos de software, ou seja, softwares que podem ser vendidos para um cliente.\n\nExistem dois tipos de produtos de software:\n\n1. Produtos genéricos, sistemas produzidos por uma organização de desenvolvimento e vendidos no mercado para qualquer cliente que esteja interessado em comprá-los (exemplos: softwares para computadores pessoais, aplicativos, banco de dados, processadores de texto, editores de planilhas, pacotes gráficos, jogos, gerenciadores de projetos etc.); e\n2. Produtos sob encomenda, sistemas encomendados por um cliente em particular, desenvolvidos por uma empresa de software especialmente para o cliente (exemplos: sistemas de controle de dispositivos eletrônicos, sistemas escritos para apoiar um processo de negócio específico etc.).\n\nUma diferença importante entre esses tipos de software é que, quanto a softwares genéricos, a organização que o desenvolve controla sua especificação. Para produtos sob encomenda, a especificação é normalmente desenvolvida e controlada pela empresa que o está adquirindo. No entanto, a distinção entre esses tipos de produtos de software está se tornando cada vez mais obscura. Mais e mais sistemas vêm sendo construídos tendo por base um produto genérico, que é então adaptado para atender aos requisitos do um cliente. Sistemas ERP (sistema integrado de gestão empresarial, do inglês enterprise resource planning), como o sistema SAP, são os exemplos dessa abordagem. Nesse caso, um sistema grande e complexo é adaptado para uma empresa, incorporando informações sobre as regras e os processos de negócio, relatórios necessários etc.\n\nProcessos de desenvolvimento de software\nUm processo de software é um conjunto de atividades relacionadas que levam a produção de um software. Essas atividades podem incluir desenvolvimento, a partir do zero, em uma linguagem padrão de programação como Java ou C. No entanto, aplicações de negócios não são desenvolvidas dessa forma. Atualmente, novos softwares de negócios são desenvolvidos por meio da extensão e modificação de sistemas existentes ou por meio da configuração e integração de prateleira ou componentes do sistema. Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades fundamentais para a engenharia de software:\n\n1. Especificação de software: a funcionalidade do software e as restrições a seu funcionamento devem ser definidas;\n2. Projeto e implementação de software: produzir para atender às especificidades;\n3. Validação de software: o software deve ser validado para garantir que atenda às demandas do cliente; e\n4. Evolução do software: o software deve evoluir para atender às necessidades de mudança dos clientes.\n\nExistem alguns modelos genéricos de processo de software, muitas vezes chamados de paradigmas de processos. Os principais são:\n- O modelo cascata, que considera as atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução e representa cada uma delas como fases distintas;\n- Desenvolvimento incremental, o software é desenvolvido por incrementos, com o cliente especificando os requisitos a serem atendidos em cada iteração. 1. Produtos genéricos, sistemas produzidos por uma organização de desenvolvimento e vendidos no mercado para qualquer cliente que esteja interessado em comprá-los (exemplos: softwares para computadores pessoais, aplicativos, banco de dados, processadores de texto, editores de planilhas, pacotes gráficos, jogos, gerenciadores de projetos etc.); e\n2. Produtos sob encomenda, sistemas encomendados por um cliente em particular, desenvolvidos por uma empresa de software especialmente para o cliente (exemplos: sistemas de controle de dispositivos eletrônicos, sistemas escritos para apoiar um processo de negócio específico etc.).\n\nUma diferença importante entre esses tipos de software é que, quanto a softwares genéricos, a organização que o desenvolve controla sua especificação. Para produtos sob encomenda, a especificação é normalmente desenvolvida e controlada pela empresa que o está adquirindo. No entanto, a distinção entre esses tipos de produtos de software está se tornando cada vez mais obscura. Mais e mais sistemas vêm sendo construídos tendo por base um produto genérico, que é então adaptado para atender aos requisitos do um cliente. Sistemas ERP (sistema integrado de gestão empresarial, do inglês enterprise resource planning), como o sistema SAP, são os exemplos dessa abordagem. Nesse caso, um sistema grande e complexo é adaptado para uma empresa, incorporando informações sobre as regras e os processos de negócio, relatórios necessários etc.\n\nProcessos de desenvolvimento de software\nUm processo de software é um conjunto de atividades relacionadas que levam a produção de um software. Essas atividades podem incluir desenvolvimento, a partir do zero, em uma linguagem padrão de programação como Java ou C. No entanto, aplicações de negócios não são desenvolvidas dessa forma. Atualmente, novos softwares de negócios são desenvolvidos por meio da extensão e modificação de sistemas existentes ou por meio da configuração e integração de prateleira ou componentes do sistema. Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades fundamentais para a engenharia de software:\n\n1. Especificação de software: a funcionalidade do software e as restrições a seu funcionamento devem ser definidas;\n2. Projeto e implementação de software: produzir para atender às especificidades;\n3. Validação de software: o software deve ser validado para garantir que atenda às demandas do cliente; e\n4. Evolução do software: o software deve evoluir para atender às necessidades de mudança dos clientes.\n\nExistem alguns modelos genéricos de processo de software, muitas vezes chamados de paradigmas de processos. Os principais são:\n- O modelo cascata, que considera as atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução e representa cada uma delas como fases distintas; - Desenvolvimento incremental, o software é desenvolvido por incrementos, com o cliente especificando os requisitos a serem atendidos em cada iteração; e\n- Desenvolvimento iterativo: o software é desenvolvido através de um ciclo contínuo de revisões e aperfeiçoamentos, onde cada iteração busca a melhoria contínua do produto.\n\nEngenharia de software orientada a reuso, que se baseia na existência de um número significativo de componentes reusáveis - o processo de desenvolvimento do sistema concentra-se na integração desses componentes em um sistema já existente, ao invés de desenvolvê-lo a partir do zero.\n\nMetodologias ágeis\nA filosofia por trás dos métodos ágeis é refletida no manifesto ágil, que foi acordado por muitos dos principais desenvolvedores desses métodos. Esse manifesto afirma que o objetivo é descobrir melhores maneiras de desenvolver softwares. Pretende-se valorizar mais indivíduos e interações do que processos e ferramentas, software em funcionamento do que documentação abrangente, colaborações com o cliente do que negociação de contrato, respostas a mudanças do que seguir um plano.\n\nOs processos ágeis compartilharam um conjunto de princípios baseados no manifesto ágil:\n- Envolvimento do cliente: os clientes devem estar intimamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar suas iterações;\n- Desenvolvimento incremental: o software é desenvolvido por incrementos, com o cliente especificando os requisitos a serem atendidos em cada iteração;\n- Pessoal, na equipe de trabalho: as habilidades da equipe de desenvolvimento devem ser desenvolvidas de acordo com as necessidades do cliente e dos stakeholders;\n- Aceitar as mudanças: deve-se ter em mente que os requisitos do sistema vão mudar. Por isso, projete o sistema de maneira a acomodar mudanças;\n- Manter a simplicidade: foque na simplicidade, tanto do software a ser desenvolvido quanto do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade.\n\nApesar do relativo sucesso que as metodologias ágeis têm obtido no mercado, sua aplicação não é livre de críticas e dificuldades, algumas delas são:\n- Envolver o cliente no desenvolvimento é uma ideia atraente, mas seu sucesso depende de um cliente disposto e capaz de passar tempo com a equipe de desenvolvimento, e que possa representar todos os stakeholders do sistema;\n- Alguns membros da equipe podem não ter a personalidade adequada para o intenso envolvimento que é típico dos métodos ágeis e, portanto, não interagem bem com os outros membros da equipe;\n- Priorizar as mudanças pode ser extremamente crítico, especialmente em sistemas nos quais existem muitos stakeholders. Cada um pode dar uma prioridade diferente a mudanças diferentes;\n- Manter a simplicidade exige um trabalho extra. Sob a pressão de cronogramas de entrega, os membros da equipe podem não ter tempo para fazer as simplificações desejáveis. Muitas organizações, principalmente as grandes empresas, passaram anos mudando sua cultura para que os processos fossem definidos e seguidos. É difícil, para eles, mudar para um modelo de trabalho em que os processos são informais e definidos pelas equipes de desenvolvimento.\n\nOs dois principais representantes das metodologias ágeis são o eXtreme Programming (XP) e o Scrum.\n\nO XP adota as seguintes práticas: planejamento incremental, pequenas entregas, projeto simples, desenvolvimento orientado a testes, refatoração, programação em pares, propriedade coletiva, integração contínua, ritmo sustentável (semana de 40 horas) e cliente no local.\n\nO Scrum é baseado na definição de Sprints curtos (2 a 4 semanas), em que o escopo de desenvolvimento é fixo. As tarefas do Sprint são priorizadas pelo cliente a partir do Product Backlog, formando assim o Sprint Backlog. São realizadas rápidas revisões de alinhamento, além de planejamento no início do Sprint e no final, uma chamada Sprint Review, em que é feita a entrega ao cliente, e outra chamada Sprint Retrospective, na qual são definidos possíveis processos de desenvolvimento que seja possa melhorar continuamente.\n\nTópico 2: Engenharia de requisitos\n\nRequisitos de software\n\nOs requisitos de um sistema são as definições do que o sistema deve fazer, os quais refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada. O termo \"requisito\" não é utilizado de forma consistente pela indústria de software. Em alguns casos, o requisito é apenas uma declaração abstrata em alto nível de um serviço que o sistema deve oferecer. No outro extremo, é uma definição detalhada e formal de uma função do sistema.\n\nPara facilitar a distinção entre esses dois extremos, usa-se a terminologia \"requisito de usuário\" para expressar os requisitos abstratos de alto nível e \"requisitos de sistema\" para expressar a representação detalhada do que o sistema deve fazer.\n\nOs requisitos são frequentemente classificados também como requisitos funcionais e não funcionais. Requisitos funcionais são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Requisitos não funcionais são restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas por normas específicas. Os requisitos funcionais podem ainda ser classificados como requisitos de produto, organizacionais e externos, e cada uma dessas classificações também é dividida em outras. Elucidação e análise de requisitos\n\nAs atividades envolvidas no processo de elucidação e análise de requisitos são:\n\n- Descoberta de requisitos, em que existe uma interação com os stakeholders do sistema para descobrir seus requisitos;\n- Classificação e organização de requisitos, em que o conjunto de requisitos é organizado em grupos coerentes, em geral já direcionando para o que vai formar a arquitetura do sistema;\n- Priorização e negociação de requisitos, em que requisitos conflitantes são identificados e priorizados para remoção dos conflitos; e\n- Especificação de requisitos, em que os requisitos são documentados e inseridos no próximo ciclo da espiral.\n\nVárias técnicas podem ser utilizadas para fazer a descoberta de requisitos, como: entrevistas, construção de cenários, casos de uso e etnografia (observação).\n\nTópico 3: Modelagem de software\n\nModelagem de sistemas\n\nModelagem de sistemas é o processo de desenvolvimento de modelos abstratos de um sistema, representando diferentes visões ou perspectivas do sistema. A UML (linguagem unificada de modelagem) é a notação gráfica preferida atualmente. Os diagramas abaixo são considerados principais para representar a essência de um sistema:\n\n- Diagrama de atividades: mostra as atividades envolvidas em uma implementação;\n- Diagrama de casos de uso: mostra as funcionalidades do sistema que estarão disponíveis para os diversos atores (tipos de usuários), ou seja, as interações entre o sistema e seu ambiente;\n- Diagramas de sequência: mostram as interações (trocas de mensagens) entre os atores e os componentes do sistema (objetos das classes);\n- Diagrama de classes: apresenta as classes do sistema e as associações entre elas;\n- Diagrama de estados: utilizada para descrever como o sistema reage a ocorrências de eventos externos. Em geral útil para sistemas que podem reagir de forma diferente, dependendo de como está seu estado interno.\n\nNeste resumo, não vou detalhar cada um desses diagramas, mas é importante estudar cada um deles mais detalhadamente nos livros e textos. Tópico 4: Projeto de software\n\nProjeto de arquitetura\n\nO projeto de arquitetura define como o sistema está organizado e qual é a sua estrutura geral. No processo de desenvolvimento de software, o projeto de arquitetura é o primeiro estágio do projeto de software, sendo o crítico entre o projeto e a engenharia de requisitos e identificando os principais componentes estruturais de um sistema e os relacionamentos entre eles. Em processos ágeis, geralmente se aceita que esse estágio inicial do processo de desenvolvimento se preocupe com o estabelecimento de uma arquitetura global do sistema. O desenvolvimento incremental de arquiteturas geralmente não é bem-sucedido.\n\nPode-se projetar a arquitetura de um sistema em dois níveis de abstração: arquitetura em pequena escala e em grande escala. A arquitetura em pequena escala está preocupada com a arquitetura de programas individuais e como eles são decompostos em componentes. A arquitetura em grande escala preocupa-se com a arquitetura de sistemas corporativos complexos que incluem outros sistemas, programas e componentes distribuídos em diversas empresas.\n\nExiste uma relação entre os requisitos não funcionais e a arquitetura do software, o estilo e a estrutura da arquitetura escolhida por um sistema devem depender dos requisitos não funcionais. Se cada um dos requisitos favorizar um requisito crítico, como dever ser planejada a arquitetura.\n\n- Desempenho: a arquitetura deve ser projetada para localizar as operações críticas dentro de um pequeno número de componentes, implantados em um único computador, ao invés de em muitos diferentes. A ideia é reduzir o overhead de comunicação.\n- Proteção: deve-se usar uma estrutura em camadas para proteção, com os ativos mais críticos protegidos nas camadas internas. A ideia é reduzir o overhead de proteção aplicado a isso.\n- Segurança: a arquitetura deve ser projetada de modo que as operações relacionadas com a segurança estejam localizadas em um único componente ou em um pequeno número de componentes. Isso reduz os custos e os problemas de validação e segurança e torna possível fornecer sistemas de proteção relacionados que podem desligar o sistema de maneira segura em caso de falha.\n- Disponibilidade: a arquitetura deve ser projetada para incluir componentes redundantes, de modo que seja possível substituir e atualizar componentes sem parar o sistema.\n- Manutenção: a arquitetura do sistema deve ser projetada a partir de componentes autônomos de baixa granularidade que podem ser rapidamente alterados. Os produtores de dados devem ser separados dos consumidores e as estruturas de dados compartilhadas devem ser evitadas.\n\nPara projetar a arquitetura do software, pode-se considerar diferentes visões. O modelo de visão 4 + 1 sugere haver quatro visões fundamentais de arquitetura, relacionando-as usando casos de uso em cenários. As visões são:\n\n- a visão lógica, que mostra as abstrações fundamentais do sistema como objetos ou classes de objetos (em que deveria ser possível relacionar os requisitos de sistema às entidades);\n- a visão de processo, que mostra como, em tempo de execução, o sistema é composto por processos interativos (útil para fazer julgamentos sobre as características não funcionais do sistema);\n- a visão do desenvolvimento, que mostra como o sistema é decomposto para o desenvolvimento, ou seja, apresenta a distribuição de software em componentes que são. implementados por um único desenvolvedor ou por uma equipe de desenvolvimento (útil para gerentes de software e programadores); e\n• a visão física, que mostra o hardware do sistema e como os componentes de software são distribuídos entre os processadores (útil para a implantação do sistema).\n\nPadrões de arquitetura\n\nPode-se pensar em padrão de arquitetura como uma arquitetura abstrata, estilizada, de boas práticas experimentadas e testadas em diferentes sistemas e ambientes. Assim, um padrão de arquitetura deve descobrir uma organização de sistema bem-sucedida em sistemas anteriores. Deve também incluir informações de quando o uso desse padrão é adequado e seus pontos fortes e fracos.\n\nO padrão MVC (modelo-visão-controlador, do inglês, model-view-controller) é a base do gerenciamento de interação em muitos sistemas baseados em Web. Esse padrão separa a apresentação e a interação dos dados, que são extraídos em outros componentes lógicos que interagem entre si. O modelo é responsável pela lógica de negócios e das operações associadas a esses dados. A visão é gerenciada como os dados apresentados aos usuários (por exemplo, tela, modelo etc.) e a controladora é responsável por uma camada de funcionalidade, onde um requisito de proteção multilevel. A vantagem é que, desde que a interface seja mantida, a substituição de camadas inteiras é possível. A desvantagem é que na prática costuma ser difícil proporcionar uma clara separação entre as camadas de baixo nível, ao invés de através da camada imediatamente abaixo dela. O desempenho pode ser um problema por causa dos múltiplos níveis de interpretação de uma solicitação de serviço, uma vez que processados em cada camada.\n\nNa arquitetura repositório, todos os dados de um sistema são gerenciados em um repositório central, acessível a todos os componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório. Deve-se usar esse padrão em um sistema no qual grandes volumes de informação são gerados e precisam ser armazenados por longo tempo. A vantagem é que os componentes podem ser independentes, eles não precisam saber da existência de outros componentes. A desvantagem é que o repositório é um ponto único de falha. A arquitetura cliente-servidor é uma em que a funcionalidade do sistema está organizada em serviços, cada um prestado por um servidor. A principal vantagem é a possibilidade de distribuição em uma rede. A desvantagem é que cada servidor é um ponto de falha e o desempenho do sistema é imprevisível.\n\nGerenciamento de configuração\n\nO gerenciamento de configuração de um produto de software envolve quatro atividades:\n\n1. Gerenciamento de mudanças: envolve manter o acompanhamento das solicitações dos clientes e desenvolvedores por mudanças no software, definir os custos e o impacto da realização de tais mudanças, bem como decidir se e quando as mudanças devem ser implementadas.\n\n2. Gerenciamento de versões: envolve manter o acompanhamento de várias versões de componentes do sistema e assegurar que as mudanças nos componentes, relacionadas a diferentes desenvolvimentos, não interfiram umas nas outras.\n\n3. Construção do sistema: é o processo de montagem de componentes de programa, dados e bibliotecas, e em seguida, criar novos sistemas para criar um sistema\n\n4. Gerenciamento de releases: envolve a preparar o software para o release externo ao cliente e o acompanhamento das versões de diferentes sistemas prontos. Esses são chamados técnicas estratégicas.\n\nTópico 5: Arquitetura SOA e gestão de configuração\n\nAs arquiteturas orientadas a serviços são uma forma de desenvolvimento de sistemas distribuídos em que os componentes de sistema são serviços autônomos, executando em computadores geograficamente distribuídos. Protocolos padrões baseados em XML, SOAP e WSDL foram projetados para oferecer suporte à comunicação de serviços e a troca de informações. Assim, os serviços são plataforma e implementação independentes de linguagem. Os sistemas de software podem ser constituídos pela composição de serviços locais e serviços externos de provedores diferentes, com interação perfeita entre os serviços no sistema. Os principais padrões de SOA para Web são:\n\n• SOAP: padrão de troca de mensagens que oferece suporte à comunicação entre serviços. Define os componentes essenciais e opcionais das mensagens passadas entre os serviços.\n\n• WSDL: linguagem de definição de web services (web service definition language) é um padrão para a definição de serviços. Estabelece como as operações de serviço (nome de operação, parâmetros e seus tipos) e associações devem ser definidas.\n\n• WS-BPEL: padrão para linguagem de workflow, usada para definir programas de processos que envolvem vários serviços diferentes.\n\n• UDDI: padrão de descoberta de serviços que não foi amplamente adotado (universal description, discovery and integration), define e documenta como uma especificação de serviço e pode ser. utilizado para descobrir a existência do serviço. Acabou sendo substituído por mecanismos de busca padrão.\n\nTópico 6: Teste de software\n\nO processo de teste tem dois objetivos distintos:\n\n1. demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos; e\n\n2. descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente da especificação.\n\nO primeiro objetivo leva a testes de validação, nos quais se espera que o sistema seja executado corretamente, usando determinado conjunto de teste que refletem o uso esperado do sistema. O segundo objetivo leva a testes de defeitos, nos quais os casos de teste são projetados para expor defeitos.\n\nOs testes não podem demonstrar que o software é livre de defeitos ou que ele se comportará conforme o especificado em qualquer situação. É sempre possível que um teste que tenha conseguido evitar algumaque poderia ter descoberto mais problemas nos sistema.\n\nAssim como testes de software, o processo de verificação e validação pode incluir inspeções e revisões. Elas analisam e verificam os requisitos de sistemas e testes prontos. Essas são chamadas técnicas estratégicas de verificação e validação, e não é necessário executar código para aplicar.\n\nAs inspeções centram-se principalmente no código-fonte de um sistema, mas qualquer representação legível do software pode ser inspecionada. Ao inspecionar um sistema, usa-se o conhecimento do sistema, seu domínio de aplicação e a linguagem de programação ou modelagem para descobrir erros.\n\nExistem três vantagens da inspeção de software sobre os testes:\n\n1. durante o teste, erros podem mascarar outros erros, como a inspeção é um processo estático não há necessidade de se preocupar com a interação entre os erros;\n\n2. versões incompletas de um sistema podem ser inspecionadas sem custos adicionais;\n\n3. uma inspeção pode considerar outros atributos de qualidade de um programa além da presença de defeitos, como conformidade com padrões, portabilidade e manutenibilidade.\n\nGeralmente, um sistema de software comercial tem que passar por três estágios de teste:\n\n1. Teste de desenvolvimento, em que o sistema é testado durante o desenvolvimento para descobrir bugs e defeitos. Projetistas e programadores podem estar envolvidos no processo de teste.\n\n2. Teste de release, em que uma equipe de teste independente testa uma versão completa do sistema antes que ele seja liberado para o usuário. O objetivo dos testes de release é assegurar que o sistema atenda aos requisitos dos stakeholders. 3. Testes de usuário, em que os usuários ou potenciais usuários de um sistema testam o sistema em seu próprio ambiente.\n\nDurante o desenvolvimento, o teste pode ocorrer em três níveis de granularidade:\n\n1. teste unitário, em que as unidades individuais do programa são testadas individualmente;\n2. teste de componentes, em que várias unidades individuais são integradas para criar componentes compostos (testes de componentes devem centrar-se em testar as interfaces dos componentes); e\n3. teste de sistema, em que alguns ou todos os componentes de um sistema estão integrados e o sistema é testado como um todo.\n\nTeste de usuário é um estágio no processo de teste em que os usuários fornecem entradas e conselhos sobre o teste de sistema. Na prática, existem três tipos de testes de usuários:\n\n1. teste alfa, em que os usuários do software trabalham com o ciclo de desenvolvimento para testar o software no local do desenvolvedor;\n2. teste beta, em que um release do software é disponibilizado aos usuários externos para passar a experimentar e resolver os problemas que descobriram, no ambiente do próprio usuário; e\n3. teste de aceitação, em que os clientes testam um sistema para verificar se o mesmo pode ser aceito para implantação no ambiente do cliente.\n\nTópico 7: Reuso e engenharia de software baseada em componentes\n\nA engenharia de software baseada em reuso é uma estratégia da engenharia de software em que o processo de desenvolvimento é orientado para o reuso de software já existente. Apesar de o reuso ter sido proposto como estratégia de desenvolvimento há mais de 40 anos (1968), só em 2000 o desenvolvimento com reuso se tornou a norma para novos sistemas de negócios. Basicamente em resposta às exigências de menores custos de produção e manutenção de software, entrega mais rápida e software de maior qualidade.\n\nO custo e a pressão por prazos fazem com que se busquem alternativas para o desenvolvimento de software \"do zero\" e uma delas é a abordagem baseada em reuso de software existente. O reuso é possível em vários níveis diferentes:\n\n- Nível de abstração: não se reusa o software diretamente, mas sim o conhecimento das abstrações de sucesso no projeto de software. Os padrões de projeto e de arquitetura são formas de representar o conhecimento abstrato para reuso.\n- Nível de objeto: reusa-se objetos diretamente da biblioteca, ao invés de se escrever o código.\n- Nível de componente: são coleções de objetos e classes de objetos que funcionam em conjunto para fornecer funções e serviços relacionados.\n- Nível de sistema: em que se reusa um sistema de aplicação inteiro com algum tipo de configuração desses sistemas. As unidades de software reusadas podem ter tamanhos radicalmente diferentes, por exemplo:\n\n- reuso de sistema de aplicação, em que a totalidade de um sistema de aplicação pode ser reusada sem alterações;\n- reuso de componentes, variando em tamanho desde subsistemas até objetos únicos; e\n- reuso de objetos e funções, componentes de software que implementam uma função única, como uma função matemática ou uma classe de objeto que podem ser reusados.\n\nUma vantagem óbvia do reuso de software é a redução dos custos globais de desenvolvimento. Um número menor de componentes de software precisa ser especificado, concebido, implementado e validado. No entanto, a redução de custos é apenas uma das vantagens do reuso, outras vantagens podem ser citadas, como:\n\n- aumento da confiança sobre o software;\n- menor risco de processos;\n- uso mais eficaz de especialistas;\n- aumento da conformidade com padrões; e\n- aceleração do desenvolvimento.\n\nContudo, existem custos e problemas associados ao reuso. Há um custo significativo associado ao processo de compreensão de um sistema, uma situação, um componente é adequado para o reuso e testares como garantia de conformação. Esses custos adicionais significam que às vezes isso se torna desincentivo ao reuso. Outros problemas associados ao reuso:\n\n- falta de ferramentas de suporte;\n- síndrome do \"não inventado aqui\";\n- criação, manutenção e uso de uma biblioteca de componentes;\n- localização, compreensão e adaptação dos componentes reusáveis.\n\nEncerramento\n\nQualquer um dos tópicos apresentados neste resumo é detalhado nos livros e textos da disciplina e também pode ser explorado mais a fundo em outras bibliografias ou em recursos disponíveis na internet. Uma noção geral da área é importante para qualquer profissional que atue com desenvolvimento de software, para que possa se aprofundar nos tópicos mais importantes para o seu ambiente de trabalho e no tipo de software com o qual ele está envolvendo.\n\nBons estudos!