Engenharia de Software: Requisitos e Modelagem - Unidade 3

Engenharia de Software 1ª edição 2019 Autoria Parecerista Validador Juliana Padilha Sandra Gavioli Puga Paulo Lacerda Todos os gráficos tabelas e esquemas são creditados à autoria salvo quando indicada a referência Informamos que é de inteira responsabilidade da autoria a emissão de conceitos Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização A violação dos direitos autorais é crime estabelecido pela Lei nº 961098 e punido pelo artigo 184 do Código Penal 30 3 Unidade 3 3 Engenharia de Requisitos e Modelagem de Software Para iniciar seus estudos Nesta unidade você verá os conceitos de requisitos de software e os processos envolvidos na descoberta e documentação de requisitos A compreensão dos requisitos de software está entre as tarefas mais difíceis da engenharia de software Vamos lá Objetivos de Aprendizagem Definir requisitos de software Definir os requisitos de usuário e de sistemas Identificar e explicar as diferenças entre os requisitos de software funcionais e não funcionais Identificar a importância do levantamento dos requisitos para projetos de software Identificar as técnicas ideais para descobrir levantar os requisitos do software a ser desenvolvido 31 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Introdução da unidade Nesta unidade iniciaremos os estudos sobre conceitos que lhe permitirão entender a importância dos requisitos de software e também realizar a descoberta e a validação destes Apresentaremos algumas técnicas utilizadas para a elicitação ou levantamento dos requisitos de software Para isso trabalharemos com base nos seguintes questionamentos O que são requisitos de software Quais são os tipos de requisitos de software e como diferenciar requisitos funcionais dos requisitos não funcionais Quais são as técnicas utilizadas para levantamento dos requisitos de software É possível combinar uma ou mais técnicas no momento do levantamento de requisitos 31 Engenharia de requisitos Segundo Sommerville 2011 os requisitos de software consistem em detalhar o que o sistema deve fazer quais serviços deve oferecer e quais as limitações em relação ao seu funcionamento A compreensão de requisitos de software está entre as tarefas mais difíceis enfrentadas pelos engenheiros de software Isso ocorre porque o cliente muitas vezes não sabe verbalizar suas necessidades ou não sabe o que é realmente necessário que o seu software faça Outro problema é a alteração de requisitos ao longo do processo do software pois à medida que o desenvolvimento avança o cliente pode sentir a necessidade de alguma funcionalidade ou mesmo considerar outra como desnecessária Diante dessas dificuldades surgiu a necessidade da criação de uma técnica a engenharia de requisitos para facilitar o entendimento das necessidades dos clientes antes de se projetar o software A engenharia de requisitos fornece um mecanismo para entender aquilo que o cliente deseja por meio da análise de suas necessidades avaliação da viabilidade negociação de uma solução razoável especificação da solução sem ambiguidades validação da especificação e gerenciamento das necessidades à medida que são transformadas em um sistema operacional PRESSMAN 2016 A engenharia de requisitos abrange sete tarefas distintas algumas delas ocorrem em paralelo e todas são adaptadas às necessidades do projeto De acordo com Pressman 2016 as sete tarefas são 1 Concepção consiste em compreender o problema propor uma solução para resolvêlo e entender o que o cliente deseja A eficácia da comunicação e colaboração iniciais entre o cliente e a equipe de software também é essencial 2 Levantamento esta tarefa transparece ser a mais simples no entanto é um equívoco Inicialmente parece que basta perguntar ao cliente o que ele deseja que o seu software tenha e faça qual será a sua utilização quantos usuários finais o sistema terá entre outras informações Porém existem alguns problemas como i problemas de escopo os clientesusuários especificam de forma precária ou com detalhes desnecessários as necessidades do sistema o que pode levar à confusão dos objetivos globais do software que será desenvolvido ii problemas de entendimento os clientesusuários têm dificuldade em transmitir suas necessidades omitem informações que para eles parecem ser desnecessárias ou então especificam requisitos ambíguos tal fato ocorre porque os clientesusuários não estão 32 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software completamente certos do que será preciso no software que desejam iii problemas de volatilidade os requisitos mudam à medida que o projeto do software avança para amenizar esse problema devemos realizar o levantamento de requisitos de forma organizada 3 Elaboração consiste em descrever o problema com base nas informações obtidas nas duas tarefas anteriores dessa forma será estabelecida uma base concreta para o projeto A elaboração é orientada pela criação e refinamento de cenários de usuários que descrevem como o usuário final interagirá com o sistema Após a análise desses cenários será possível extrair classes seus atributos e métodos As relações e a colaboração entre as classes serão identificadas além disso outros diagramas da UML unified modeling language poderão ser produzidos 4 Negociação esta tarefa é a responsável por mediar possíveis conflitos Por exemplo clientes e usuários podem solicitar mais recursos do que o permitido considerando a limitação dos recursos de negócio ou então clientes e usuários podem propor necessidades conflitantes argumentando que sua necessidade é mais importante do que a do outro Por exemplo clientes e usuários podem solicitar mais recursos do que é possível atingir devido à limitação dos recursos de negócio ou então propor necessidades conflitantes argumentando que sua necessidade é maior do que a do outro Todos esses conflitos devem ser conciliados por meio da negociação Para que a negociação aconteça é solicitado aos clientes e usuários que decidam qual será a prioridade dos requisitos a serem implementados Após a reunião dos clientes e usuários alguns requisitos podem ser eliminados combinados ou modificados de forma que todos os envolvidos no projeto fiquem satisfeitos 5 Especificação esta tarefa pode ser um documento por escrito um conjunto de modelos gráficos um modelo matemático formal um conjunto de cenários diagramas de casos de uso um protótipo ou qualquer combinação dos fatores anteriores Para sistemas pequenos bastam diagramas de casos de uso no entanto para sistemas grandes se faz necessário um documento por escrito que contenha descrições claras para o cliente e modelos gráficos O importante é que a especificação seja clara e relate a necessidade que o cliente solicitou nas tarefas anteriores A Figura 1 ilustra o sumário títulos e subtítulos esperados de um pequeno modelo de especificação de requisitos de software Tratase de um documento com uma descrição mais detalhada de todas as características do software que se pretende desenvolver A especificação de requisitos deve ser feita antes do início do projeto do software Quadro 1 Modelo de especificação de requisitos de software Sumário Histórico de Revisão 1 Introdução 11 Propósito 12 Convenções do documento 13 Públicoalvo e sugestão de leitura 14 Escopo do projeto 15 Referências 33 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software 2 Descrição geral 21 Perspectiva do produto 22 Características do produto 23 Classes de usuários e características 24 Ambiente operacional 25 Restrições de projeto e implementação 26 Documentação para usuários 27 Hipóteses e dependências 3 Características do sistema 31 Características do sistema 1 32 Características do sistema 2 33 Características do sistema n 4 Requisitos de interfaces externas 41 Interfaces do usuário 42 Interfaces de hardware 43 Interfaces de software 44 Interfaces de comunicação 5 Outros requisitos não funcionais 51 Necessidades de desempenho 52 Necessidades de proteção 53 Necessidades de segurança 54 Atributos de qualidade de software 6 Outros requisitos Apêndice A Glossário Apêndice B Modelos de análise Apêndice C Lista de problemas Fonte Adaptado de PRESSMAN MAXIM 2016 34 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software 6 Validação é nesta tarefa que se avalia a qualidade dos artefatos documentos diagrama UML Essa avaliação é feita através da verificação da especificação de requisitos assim é possível garantir que todos os requisitos tenham sido declarados sem ambiguidade sem inconsistências sem omissões e sem erros A tarefa de validação também permite verificar se os artefatos seguem o padrão estabelecido para o processo e projeto do software A principal forma de validação é por meio da revisão técnica cuja equipe responsável é formada geralmente pelos desenvolvedores clientes e usuários Essa equipe tem a tarefa de examinar a especificação de requisitos procurando por erros no conteúdo do documento por informações faltantes inconsistências de requisitos requisitos heterogêneos ou mesmo requisitos falsos 7 Gestão de requisitos a gestão de requisitos é relevante pois a necessidade de alterações nos requisitos de software persiste ao longo da vida de um sistema Essa tarefa consiste em um conjunto de atividades para ajudar a equipe da revisão técnica a reconhecer inspecionar e conduzir as alterações que decorrem enquanto o projeto continua 32 Requisitos de software Requisitos de software consistem no detalhamento dos serviços e restrições do software que será desenvolvido Todos os requisitos que os clientesusuários desejam eou precisam devem ser reproduzidos em um documento denominado documento de especificação do sistema O processo que envolve as tarefas de levantamento descobrir análise documentação e verificação de requisitos é denominado engenharia de requisitos conforme explicado na seção anterior A tarefa de levantamento de requisitos pode produzir diferentes níveis de descrição do sistema Essas descrições podem se aproximar mais dos usuários ou dos desenvolvedores Sommerville 2011 apresenta dois níveis de abstração Requisitos de usuário são utilizados para expressar os requisitos abstratos de alto nível Referemse às declarações de quais serviços o sistema fornecerá a seus usuários e as restrições com as quais este deve operar Utilizase de uma linguagem natural com diagramas Requisitos de sistema são utilizados para expressar a descrição detalhada do que o sistema deve fazer Referemse às descrições mais detalhadas das funções dos serviços e restrições operacionais do sistema de software O documento de requisitos do sistema deve definir exatamente o que deverá ser implementado Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores do software O Quadro 2 apresenta a distinção entre os requisitos de usuários e de sistemas Apresenta também como um requisito de usuário pode ser expandido em vários requisitos de sistemas Para ilustrar esses tipos de requisito utilizaremos um exemplo de um sistema de vendas Quadro 2 Requisitos de usuário e de sistemas Definição de Requisitos de Usuários 1 O sistema deve gerar relatórios mensais que mostrem a quantidade de produtos vendidos no mês vigente 35 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Especificação de Requisitos de Sistemas 11 No último dia útil de cada mês deve ser gerado um resumo dos produtos mais vendidos 12 O acesso aos relatórios deve ser restrito a usuários autorizados Fonte Elaborado pela autora Os requisitos precisam ser escritos em termos de detalhamento de acordo com o tipo de leitores existentes Os requisitos de usuários possuem os seguintes leitores gerentes clientes usuários finais do sistema engenheiros clientes engenheiros contratantes e arquitetos de sistema Esses leitores geralmente não se preocupam com a forma como o sistema será implementado Já os leitores dos requisitos de sistemas são usuários finais do sistema engenheiros clientes arquitetos de sistemas e desenvolvedores de software Esses leitores precisam saber as informações com mais detalhes pois eles estão envolvidos na implementação do sistema Fique atento Além dos tipos de requisitos de usuário e de sistema os requisitos de software são classificados como requisitos funcionais e requisitos não funcionais conforme veremos na seção abaixo 33 Requisitos funcionais Os requisitos funcionais descrevem o que um sistema deve fazer e como deve se comportar em determinadas situações ou seja capturam as funcionalidades sob o ponto de vista do cliente No entanto os requisitos funcionais dependem do tipo de software que será desenvolvido de quem são seus possíveis usuários e da metodologia de escrita dos requisitos adotada pela empresa Por exemplo em um sistema de comércio eletrônico alguns requisitos funcionais seriam i permitir a consulta de produtos por preço ii permitir a consulta dos produtos por nome iii permitir a consulta dos produtos mais vendidos iv permitir pagamento online via cartão de crédito ou boleto bancário e v cadastramento de clientes A imprecisão na especificação dos requisitos causa muitos problemas na engenharia de software Por isso a especificação dos requisitos funcionais de um sistema deve ser completa todos os serviços requeridos pelo usuário devem ser definidos e consistente os requisitos não devem ter definições contraditórias 36 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software 34 Requisitos não funcionais Os requisitos não funcionais referemse às restrições a serviços ou funções oferecidos pelo sistema ou seja tratase dos requisitos que não estão diretamente relacionados com os serviços oferecidos pelo sistema a seus usuários Em um sistema de comércio eletrônico por exemplo normalmente os clientes não têm paciência para aguardar o carregamento de uma página demorada e desistem da compra Assim esse tipo de sistema deverá ter como requisito não funcional o carregamento rápido de páginas com o limite de tempo de no máximo 2 segundos por exemplo Ao desenvolver um novo software os desenvolvedores e engenheiros de software indicam um conjunto de requisitos não funcionais que o software deverá possuir como Confiabilidade referese à capacidade do software de preservar o seu nível de desempenho quando usado em condições predeterminadas Exemplo o software deve evitar falhas resultantes de defeitos Desempenho referese ao tempo de execução e aos recursos disponíveis no computador Exemplo o sistema não deve consumir muitos recursos como memória do computador nem demorar muito para executar os processos Segurança referese à capacidade do software de proteger informações e dados de forma que usuários não autorizados não tenham acesso nem mesmo para leitura Exemplo o sistema deve garantir a segurança dos dados por meio do uso de senhas criptografadas Os requisitos não funcionais surgiram da necessidade dos usuários e também das restrições de orçamento das políticas das organizações das necessidades de interoperabilidade com outros sistemas de software ou hardware e de fatores externos como regulamentos de segurança ou leis sobre privacidade A Figura 10 apresenta a classificação dos requisitos não funcionais que estão divididos em Requisitos de produto são utilizados para especificar ou restringir o comportamento do software como por exemplo os requisitos de confiabilidade que estabelecem a taxa aceitável de falhas Requisitos organizacionais são os requisitos gerais de sistemas derivados a partir da política interna da empresa do cliente e do desenvolvedor Exemplo os requisitos operacionais que definem como o sistema será usado Requisitos externos abrangem todos os requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento como por exemplo os requisitos legais que devem ser seguidos para garantir que o sistema opere dentro da lei 37 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Figura 10 Tipos de requisitos não funcionais Requisitos não funcionais Requisitos do produto Requisitos de eficiência Requisitos de facilidade de uso Requisitos de desempenho Requisitos de espaço Requisitos de privacidade Requisitos de segurança Requisitos de entrega Requisitos de implementação Requisitos de padrões Requisitos legais Requisitos de confiabilidade Requisitos de portabilidade Requisitos de interoperabilidade Requisitos éticos Requisitos organizacionais Requisitos externos Fonte SOMMERVILLE 2011 35 Levantamento de requisitos O levantamento de requisitos também conhecido como elicitação de requisitos é uma atividade que combina elementos de resolução de problemas elaboração negociação e especificação de requisitos Nesta atividade os engenheiros de software trabalham com clientes e usuários finais do software que será produzido para obter informações sobre os serviços que o sistema deve oferecer o contexto da aplicação o desempenho do sistema as restrições de hardware entre outros A Figura 11 apresenta um modelo do processo de levantamento de requisitos É importante ressaltar que cada empresa deve ter sua própria versão pois essa atividade sofre influência de fatores locais como conhecimento dos usuários finais do tipo e tamanho do sistema a ser produzido da política interna da empresa entre outros 38 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Figura 11 Processo de levantamento e análise de requisitos 1 Descoberta de requisitos 2 Classificação e organização de requisitos 3 Priorização e negociação de requisitos 4 Especificação de requisitos Fonte SOMMERVILLE 2011 As atividades do processo de levantamento e análise de requisitos são 1 Descoberta de requisitos nesta atividade ocorre um diálogo com os clientes e usuários finais a fim de se descobrir os requisitos do software a ser desenvolvido 2 Classificação e organização de requisitos após a realização da atividade de descoberta dos requisitos são feitas a classificação e a organização destes Assim os requisitos comuns são agrupados no mesmo grupo e os requisitos redundantes são descartados Essa atividade permite a eliminação de requisitos desnecessários e garante que todos os requisitos comuns tenham sido agrupados corretamente para facilitar a criação das funcionalidades do software 3 Priorização e negociação de requisitos essa atividade está relacionada à priorização ou seja dentre os requisitos listados pelos clientes e usuários finais quais deverão ser desenvolvidos primeiro Para decidir a priorização dos requisitos é realizada uma reunião entre os clientes e usuários finais para que eles decidam qual a prioridade ou qual a precedência das funcionalidades na hora da implementação do software 4 Especificação de requisitos consiste em escrever os requisitos de usuários e de sistema em documento de requisitos Documentos formais podem ser produzidos conforme modelo apresentado anteriormente No estágio inicial uma versão do documento de requisitos com seções faltantes e requisitos incompletos pode ser produzida Uma alternativa a esse modelo fechado é documentar em cartões os requisitos pois é mais fácil para os clientes e usuários finais se organizarem e modificarem os requisitos 39 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software O processo de elicitar e compreender requisitos é árduo pois frequentemente os clientes e usuários finais também chamados de partes interessadas possuem opiniões distintas sobre a importância e prioridade dos requisitos e geralmente as opiniões são conflitantes Diante desse problema a engenharia de software propôs as seguintes técnicas de elicitação de requisitos Descoberta de requisitos sob ponto de vista Entrevistas Casos de uso Etnografia Assista ao vídeo httpwwwnoadsyoutubecomvideobsontreinamentosoque levantamentoderequisitostpicosdeengenhariadesoftwarevVcOeM2AD8Yk para saber sobre os requisitos de software Saiba mais 36 Descoberta de requisitos sob ponto de vista A descoberta de requisitos consiste no processo de reunir informações como documentação clientes e usuários finais e especificações similares sobre o sistema a ser produzido Dessas informações serão separados os requisitos de usuários e de sistemas As partes interessadas de um software variam muito seja pelo tamanho da empresa quantidade de usuários partes interessadas tipos de sistemas que interagem ou simplesmente pelo tamanho do sistema a ser desenvolvido Durante o processo de levantamento de requisitos todas essas fontes de requisitos devem ser consideradas Porém como existem muitas fontes consequentemente têmse muitos pontos de vistas distintos sobre o mesmo problema Em suma pessoas distintas enxergam o mesmo requisito sob um ponto de vista diferente umas das outras mas apesar de os requisitos serem expressados de formas distintas não são completamente independentes basta os engenheiros de software realizarem uma filtragem dos requisitos duplicados e inconsistentes Portanto a técnica de descoberta de requisitos sob pontos de vistas é utilizada para estruturar a elicitação e a documentação dos requisitos do software A Figura 12 apresenta os requisitos sob o ponto de vista de um titular e de um não titular de uma conta em alguma agência bancária 40 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Figura 12 Exemplo de descoberta de requisitos sob pontos de vista Titular da conta Lista de Serviços Sacar dinheiro Depositar dinheiro Consultar saldo Solicitar extratos Transferir dinheiro Não Titular da conta Lista de Serviços Depositar dinheiro Fonte Elaborada pela autora 37 Entrevistas Outra técnica para descobrir os requisitos de software são entrevistas formais ou informais As entrevistas podem ser de dois tipos Entrevistas fechadas consistem nas partes interessadas responderem a um questionário com perguntas predefinidas Entrevistas abertas não têm um conjunto de perguntas predefinidas A equipe dos engenheiros de software se adapta para explorar o conhecimento das partes interessadas Assim desenvolve uma melhor compreensão das necessidades desses usuáriosclientes A técnica de entrevista é considerada uma boa forma de compreensão dos requisitos de modo global mas não para os requisitos do domínio da aplicação pois o conhecimento desse tipo de requisito é tão familiar às partes interessadas que elas têm dificuldades em expôlos ou simplesmente não mencionam por não julgar necessário aos engenheiros de software A técnica de entrevistas pode não capturar informações essenciais do sistema não devendo ser utilizada sozinha mas sim em conjunto com outras técnicas de elicitação de requisitos Fique atento Assista ao vídeo Gerenciamento de Requisitos sem Mistério no YouTube para saber sobre como gerenciar os requisitos de software e saber mais sobre as técnicas de levantar requisitos Saiba mais 41 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software 38 Casos de uso Os diagramas de casos de uso também são uma técnica de elicitação de requisitos Sua forma simples permite ilustrar às partes interessadas a interação com o sistema por meio de atores usuário que interagirá com determinada tela do sistema e casos de uso telas dos sistemas A Figura 13 representa um conjunto de casos de usos de todas as possíveis interações que o usuário final terá de acordo com os requisitos descobertos Os atores o bonequinho palito representam todas as possíveis interações que os usuários finais ou outros sistemas terão com o software a ser desenvolvido Já as linhas representam a ligação dos atores com os seus respectivos casos de uso Figura 13 Exemplo de um caso de uso para parte do sistema de uma biblioteca Atendente Emprestar Livro Devolver Livro Incluir Livro Comprar Livro Bibliotecária Fonte Elaborada pela autora Casos de uso são considerados boas técnicas para descobertas de requisitos por mostrar a interação das partes interessadas usuários por exemplo com o sistema No entanto devido ao fato de o foco do diagrama de caso de uso estar nas interações com o sistema ou seja com quais funcionalidades os usuários interagirão o diagrama caso de uso não é eficaz para descobrir 42 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software As restrições do sistema que se referem às limitações internas ou externas ao projeto do software Por exemplo toda a equipe do projeto deverá ser contratada via CLT portanto não poderá haver contrato terceirizado Os requisitos de negócio ou regras de negócio que se referem às políticas de negócio ou seja declarações em relação à forma da empresa realizar as suas atividades As regras de negócio servem para atender os objetivos do negócio em relação ao sistema e do cliente e também para cumprir às leis regras do negócio Por exemplo o professor somente poderá lecionar disciplinas relacionadas à sua linha de pesquisa do mestrado ou então o cliente do Banco do Brasil só poderá realizar um saque na sua conta de apenas mil reais por dia Os requisitos não funcionais já explicados e exemplificados anteriormente Conforme apresentado o diagrama de caso de uso tem algumas limitações que impedem a captura de todos os tipos de requisitos do projeto do sistema Devido a esse fato o diagrama de caso de uso deve ser utilizado em conjunto com outros diagramas por exemplo o diagrama de atividades e os diagramas de sequência e de colaboração O diagrama de atividades descreve o fluxo de atividades de um caso de uso Já os diagramas de sequência e de colaboração descrevem as interações entre o ator e o comportamento dos objetos de um caso de uso do sistema Visite o site da OMG Object Management Group httpswwwomgorgtechnology readingroomUMLhtm para saber mais informações sobre os diagramas de casos de uso pertencentes à modelagem UML unified modeling language Para saber mais sobre os diagramas de atividades sequência e de colaboração acesse o site httpwwwdscufcgedubrjacquescursosmaphtmlumldiagramasdiagramashtm Saiba mais 39 Etnografia A etnografia consiste em uma técnica de observação utilizada para descobrir os requisitos sociais e organizacionais Para tal o engenheiro de software ou analista se insere no ambiente de trabalho da empresa para qual será desenvolvido o software e observa o dia a dia de trabalho ou seja a rotina da empresa São observadas e anotadas todas as tarefas realizadas pelas partes interessadas A vantagem dessa técnica em relação às outras é que ela ajuda na descoberta dos requisitos implícitos pois com ela é possível capturar informações sobre situações reais em vez de processos formais definidos pela empresa A desvantagem da etnografia é que o seu foco está voltado para o usuário final o que muitas vezes não permite a descoberta dos requisitos organizacionais ou de domínio Consequentemente esses usuários não sabem identificar e informar novos recursos que devam ser adicionados ao sistema 43 Engenharia de Software Unidade 3 Engenharia de Requisitos e Modelagem de Software Síntese da unidade Os requisitos de software são muito importantes pois definem as restrições do sistema e o que ele deve fazer Os requisitos funcionais têm o papel de descrever o que o usuário deseja que o sistema tenha Já os requisitos não funcionais descrevem não o que o sistema fará mas como ele fará como por exemplo desempenho portabilidade e segurança É muito importante documentar todos os requisitos extraídos das partes interessadas Para se obter os requisitos dos clientesusuários finais existem várias técnicas e o engenheiro de software deve escolher quais são as recomendadas para o tipo e tamanho de software que será desenvolvido 44 Considerações finais Esperamos que você tenha assimilado da melhor forma possível o conteúdo aqui apresentado Para ampliar o seu conhecimento consulte o aprofundamento de conteúdo e assista à videoaula da unidade pois ambos contêm informações relevantes para seu aprendizado