Olá pessoal espero que estejam todos bem Hoje nós teremos uma vídeo aula de revisão da disciplina engenharia de software Então o que eu apresentarei para vocês é uma revisão dos principais tópicos que vocês estudaram ao longo do bimestre Vamos iniciar Nossa vídeo aula de revisão falando sobre o que é engenharia de software então estamos resgatando a primeira semana de aula que você estiver na verdade pessoal a engenharia de software ela aparece né com esse nome né esse termo ele foi cunhado a partir daquilo que se chamou de crise do software que é algo que foi
identificado ali no final da década de 1960 em que você percebeu que era necessária uma uma estratégia né uma forma mais sistematizada de desenvolver software e para isso obviamente logo se pensou que desenvolver software deveria ser algo como uma engenharia semelhante a outras engenharias para o desenvolvimento de produtos no caso aqui produto software então aí gente software É uma disciplina de engenharia que se preocupa com os aspectos da produção de software desde sua concepção inicial até sua operação e manutenção quando dizemos que é uma disciplina de engenharia significa que deve ser adotado procedimento sistematizados uso
de processos de métodos técnicas e ferramentas nós queremos descobrir com a engenharia de software todos os aspectos de produção do software tanto para melhorar a produtividade do software como também a qualidade garantir uma boa qualidade ao software produzido E para isso a grosso modo independente do processo do ciclo de vida de desenvolvimento de software que se adota as principais atividades da engenharia de software envolve a especificação do software que vai ser desenvolvido então toda aquela parte de requisitos né de análise de requisitos caminhando para o projeto do software Então dentro do desenvolvimento a gente tem
um pouco de projeto né ou bastante na verdade de projeto e na sequência a implementação do projeto que significa principalmente traduzir o projeto em código né escrever código escrever programas a partir disso temos que testar validar o software que foi desenvolvido garantindo uma evolução posterior né que vai se dar manutenção alterações novas funcionalidades mudanças para garantir a qualidade do software então grosso modo Essas são as principais atividades da engenharia de software ainda no início da disciplina Nós estudamos modelos de processo de software bom esse é um tema muito importante porque todo o processo de desenvolvimento
de software ele deve ser guiado por modelos então o que que é um modelo de processo de software é uma abstração que vai focalizar nas principais etapas ou fases do desenvolvimento de software mostrando a sequência e a interação entre essas fases o primeiro modelo de software proposto né chamado de modelo convencional ou tradicional da engenharia de software é o chamado modelo em Cascata em que as etapas do desenvolvimento de software ocorrem de uma forma sequencial linear outro modelo que também é bastante utilizado né bastante conhecido chamado de modelo de plano que é um modelo espiral
em que a previsão de retornar as fases de se repetir essas algumas das principais fases várias vezes ao longo do desenvolvimento e também nesse modelo espiral se introduziu a etapa de análise de riscos o modelo incremental é o modelo que sugere um desenvolvimento em versões né em pequenos incrementos que vai sendo introduzido em cada nova versão que se propõe para o software o modelo orientado ao reuso se baseia na utilização de partes que já estão prontas do software então pequenos componentes que podem ser realizados para o desenvolvimento de um novo software e o modelo rupe
que é o hashtag processos é um modelo que embute várias ideias do modelo espiraldo incremental e orientado a reuso trabalhando sempre com interações então de uma forma geral Esses foram os modelos de processos e sofre que foram estudados né e normalmente se adota um desses modelos ou um híbrido entre eles para o desenvolvimento de software importante destacar aqui novamente que sempre que um software vai ser desenvolvido é muito importante definir o modelo que ele vai servir como um guia orientando todo o processo de desenvolvimento agora vamos falar um pouco sobre métodos de desenvolvimento ágeis ainda
fazendo parte do início da disciplina né discutimos sobre métodos ágeis na primeira semana da disciplina esses métodos eles aparecem na virada dos anos 2000 com uma nova forma uma nova filosofia de desenvolvimento de software e nessa nova visão de desenvolvimento de software que contrapõe algumas visões que o desenvolvimento tradicional Quais são as principais diferenças né então estou destacando aqui nesse slide as principais diferenças e que de fato caracterizam marcam bem qual a filosofia de desenvolvimento ágil por exemplo indivíduos e interações mas mais que processos e ferramentas então nos métodos ágeis procura se valorizar mas as
interações entre os indivíduos entre os colaboradores e o desenvolvimento do que os processos de ferramentas que são utilizados também se espera que o software em funcionamento seja mais valorizado do que a documentação que é gerada nos desenvolvimentos mais tradicionais né se sugere que muita documentação seja gerada né claro que essa documentação ela é importante mas de fato mais importante do que a documentação é o software em funcionamento outro aspecto importante do desenvolvimento ágil é a colaboração com o cliente né valorizar mais a colaboração com o cliente do que a negociação de contratos Muitas vezes os
contratos acabam sendo muito rígidos né e ao longo do desenvolvimento pela pela evolução do que está se desenvolvendo e ganhar mais conhecimento sobre o problema que o software trata a colaboração com o cliente ela acaba dando um tom de mais flexibilidade né então o desenvolvimento ágil ele ele opta por se ter mais flexibilidade no desenvolvimento e responder as mudanças mais do que seguir um plano justamente né por essa ideia de flexibilidade no desenvolvimento de software a gente traça um plano mas ao longo das etapas que vão ser o desenvolvidas vários problemas podem surgir e algumas
mudanças de rotas muitas vezes são necessárias né então responder adequadamente essas mudanças não ficando assim tão preso tão engessado a um plano é um valor importante dentro dessa filosofia dos métodos de desenvolvimento ágeis agora na sequência nós vamos revisar os temas que foram tratados a partir da segunda semana da disciplina vocês devem ter reparado que a partir da segunda semana os temas foram exatamente aquelas atividades que apareceram né que são mostradas nos modelos de processo de software então a disciplina foi organizada dessa maneira né apresenta apresentou-se um um ou mais modelos de processo de software
depois entrando nas principais atividades de cada um desses modelos a gente foi discutindo cada um daqueles temas a importância daquelas atividades que compõem o processo de software como um todo e vocês viram que via de regra né A primeira atividade ou primeira etapa principal de qualquer modelo de processo de software foca requisitos na identificação na análise na definição dos requisitos do software e o que são requisitos né um requisito de software é uma descrição de algum serviço que o software deve oferecer ou de alguma característica de qualidade que pode implicar em algum tipo de restrição
na hora de utilização do software esses requisitos eles tipicamente são classificados em requisitos funcionais e não funcionais os requisitos funcionais são a descrição dos serviços da parte funcional das funcionalidades que o software deve oferecer e os não funcionais são aquelas características de qualidade do software por exemplo características que dizem respeito ao desempenho a segurança a integridade do software muito bem agora para que a gente possa definir adequadamente os requisitos do software que é a base de todo o processo de desenvolvimento é muito importante que a gente adote um processo de engenharia de requisitos Lembrando que
engenharia é um processo de construção baseado em método sistemáticos então a engenharia de requisitos é um processo que vai envolver descobrir analisar documentar verificar e validar serviços e restrições que são exatamente os requisitos do software o processo de engenharia de requisitos ele parte da atividade de ele citação dos requisitos então ele citar é descobrir quais são os requisitos relevantes para o software então no início Existe alguma clareza sobre quais seriam os principais requisitos Mas eles ainda precisam ser lapidados a gente precisa conversar bastante com os stakeholders né que são os interessados no sistema envolvendo o
potenciais usuários os clientes do software para que a gente possa de fato aprofundar no entendimento de Quais são os requisitos relevantes do software então a ele citação é a descoberta né é esse levantamento de informações sobre as principais características que se espera do software para que a gente possa de fato atender as necessidades dos usuários desse futuro software que vai ser desenvolvido e disponibilizar após essa licitação né que se descobriu que se tem já uma percepção bem melhorada sobre os principais requisitos os requisitos precisam ser analisados e negociados analisados no sentido de por exemplo definir
Quais são os requisitos prioritários Quais são as relações independências que existem esses requisitos Quais os requisitos que precisam ser implementados inicialmente né depois na sequência quais os outros de acordo com o seu grau de importância e depois uma vez tendo essa análise feita entendendo bem a dependência entre os requisitos o relacionamento entre os requisitos precisamos fazer uma documentação documentar os requisitos e documentar os requisitos é essencialmente fazer uma especificação dos requisitos especificar é descrever com detalhes então todos os requisitos precisam ser descritos com detalhes isso forma a especificação dos requisitos do software uma vez tem
dos requisitos especificados essa documentação de especificação Ela precisa passar por uma atividade de verificação e validação Verificar se os requisitos estão consistentes se eles estão escritos de uma forma Clara se eles não apresentam ambiguidade se eles estão o mais completo possíveis e a validação é uma forma de nos certificarmos se de fato os requisitos atendem as reais necessidades tanto dos clientes né que esperam que o software seja desenvolvido e muitas vezes estão bancando né o desenvolvimento do software como as necessidades dos potenciais usuários que farão a utilização do software porém a que se acrescentar uma
atividade de gerenciamento dos requisitos isso também faz parte do processo de engenharia de requisitos porque todas essas atividades anteriores elas provavelmente serão executadas várias vezes elas vão produzindo novas informações então elas precisam ser gerenciadas então a gente diz que o a que se tem um gerenciamento sobre os requisitos que ocorre de uma forma contínua normalmente de uma forma contínua muito difícil você ter uma especificação que se congela ao longo de todo o processo de desenvolvimento dos requisitos tende a evoluir e portanto eles precisam passar também por um processo de gerenciamento então de uma forma geral
é assim que se enxerga o processo de engenharia de requisitos e ele é fundamental para que as próximas etapas as próximas fases do processo de desenvolvimento após a etapa de engenharia de requisitos entramos na etapa de definição do projeto de software que envolve principalmente a especificação da arquitetura do software ela se desenvolvido bom muito importante aqui o conceito de arquitetura então o arquitetura de software é um modelo que descreve como um sistema de software deve ser organizado como um conjunto de componentes que se comunicam bom E aí nós temos vários estilos arquiteturais que podem ser
adotados por exemplo um deles é o estilo arquitetural chamado de mvc que significa Model vi o controle onde o controle né que é o controlador é quem mapeia as ações do usuário com atualizações do modelo e seleciona a visão a visão né é quem vai então renderizar o modelo requisito atualizações do modelo envia eventos do usuário para o controlador e o modelo encapsulou estado da aplicação notifica a visão das mudanças de estado um outro estilo arquitetural bem conhecido é arquitetura de repositório que é o tipo de arquitetura utilizar para sistemas fortemente baseado em banco de
dados onde vai existir muitas transações de inclusão consulta e atualização de dados em tabelas outro modelo que também é bastante conhecido é um modelo em camadas em que normalmente se divide nas camadas interface com usuário gerenciamento de interface com usuário a camada de lógica principal do negócio e uma camada de apoio ao sistema o outro padrão arquitetural Ou estilo arquitetural conhecido é o padrão muito utilizado em aplicações web finalmente o estilo arquitetura adulto e filtro que é um estilo arquitetural mais antigo podemos dizer assim que trabalha essencialmente com o processamento em lote um tema importante
que nós estudamos na disciplina de engenharia de software é o tema reuso de software o riso de software ele busca principalmente diminuir custo e diminuir tempos de desenvolvimento e também aumentar a qualidade do software desenvolvido uma vez que vamos tentar utilizar reusar porções de código pedaços de código pequenos componentes ou trechos de código que já foram utilizados anteriormente e que portanto já foram testados já foram refinados e estão em funcionamento de forma efetiva então eu usando software que já passou por todos esses dessas etapas de teste a tendência aumentar a qualidade Existem algumas abordagens de
reuso as principais Que Nós Vamos citar aqui são padrões de projeto com abordagem de reuso componentes de sof tware entre outros Então como falamos uma das abordagens de reuso de software seria o padrões padrões de projeto então um padrão de projeto ele descreve um problema e o cerne da sua solução de forma que possa ser reusado fazendo os ajustes necessários para cada caso Lembrando que padrões de projeto é uma abordagem que surgiu no contexto desenvolvimento de software orientado objetos Quais são os elementos essenciais de um padrão de projeto o nome do padrão O problema que
ele aborda a solução que ele dá para aquele problema e as consequências de utilização desse padrão mas o padrão de projeto também pode e deve ser descrito em mais detalhes além desses elementos essenciais podemos citar como outros elementos do padrão de projeto a intenção e o objetivo do padrão a motivação de uso aplicabilidade a estrutura do padrão de projeto quais colaborações o padrão de projeto tem que consequências de uso formas de implementação e exemplos de código e usos conhecidos Então essa é uma abordagem de reuso interessante bastante recomendada dentro do desenvolvimento de software orientado a
objetos uma outra abordagem de reuso de software que nós estudamos nesta disciplina é abordagem de desenvolvimento baseado em Componentes de software então nesta abordagem os componentes eles são utilizados para a sistematizar o reuso então abordagem usada para sistematizar o reuso de componentes no desenvolvimento de software e é uma abordagem também fortemente orientada objetos ou baseado em orientação objetos Então os movimentos baseado em Componentes envolvem um processo em que nós devemos definir implementar integrar em Sistemas ou aplicações componentes que são independentes e fracamente acoplados essa é uma característica importante dos componentes de software sempre tentando buscar
uma alta independência dos componentes fazendo com que eles sejam fracamente acoplados um componente software é uma abstração de um nível mais alto do que objetos e componentes são sempre definidos por suas interfaces ou seja os serviços que podem ser realizados por um componente são definidos especificados por suas interfaces é por meio das interfaces que nós sabemos quais serviços um componente pode oferecer então componentes são maiores do que objetos individuais e detalhes de implementação são ocultos dos demais componentes outras características interessantes dos componentes de software é que eles são passíveis de composição ou seja podemos lançar
mão de vários componentes e utilizando eles de forma integrada podemos compor uma aplicação ou compor algo que tem uma funcionalidade maior ou mais complexa componentes são implantáveis são fortemente documentados são independentes entre si e são padron izados Então essa é uma abordagem importante dentro do contexto de reuso de software muito bem uma etapa muito importante dentro do processo de desenvolvimento de software a etapa de teste de software existem muitas estratégias e técnicas de teste de software e nós vimos várias delas ao longo desta disciplina de engenharia de software bom o teste de software é uma
atividade realizada para revelar os defeitos existentes no software então é uma atividade fundamental porque vai indicar o quanto que o software atingiu uma qualidade no seu desenvolvimento né é fato que mesmo adotando técnica sistemáticas e desenvolvimento de software alguns defeitos vão acontecer na implementação do software e portanto o software evidentemente precisa ser testado mesmo que a gente faça testes exaustivamente nós não vamos conseguir provar que o software totalmente correto 100% livre de defeitos isso não é possível mas ainda assim é fundamental testar software Existem várias abordagens de teste de software e testes são classificados de
muitas formas uma delas é classificar os testes de software em testes funcional e teste estrutural entre os exemplos de técnicas de teste funcional que nós vimos a disciplina podemos citar o teste baseado em gráficos o teste de particionamento de equivalência teste da análise de valores limites teste de Matriz ortogonal e teste baseado em modelos a outra categoria de teste seria então o teste estrutural essa categoria também chamada de teste de caixa branca é uma categoria de teste que envolve técnicas de seleção de dados de entrada baseadas na estrutura interna do código a ser testado normalmente
usado para teste de unidade entre os exemplos de abordagem de teste estrutural podemos citar o teste do caminho básico o teste de condição teste de fluxo de dados e teste de ciclo uma abordagem de teste de software importante que nós vimos essa disciplina é o desenvolvimento dirigido por testes chamado de tdd do inglês teste drive in the principal característica do desenvolvimento dirigido por testes é que ele é uma abordagem de desenvolvimento de software em que se intercala testes e desenvolvimento de código então testa verifica se defeitos desenvolve faz ajustes e fica no ciclo de teste
e desenvolvimento Então se adota o conceito de código de desenvolvimento incremental dentro dessa abordagem em que o próximo incremento de software só começa depois que o anterior seja aprovado em todos os testes outras características do desenvolvimento dirigido por testes é que ele envolve um ambiente de teste automatizado por exemplo utilizando uma ferramenta que nós vimos a disciplina o nível de teste nessa rdagem é o teste de unidade e essa abordagem ajuda a programadores a esclarecer em suas ideias sobre o que o código deve fazer na última semana da disciplina Nós estudamos O tópico de entrega
contínua e dentro desse tema de entregar contínua nós vimos o conceito de integração contínua que é um conceito bastante relevante dentro do processo de desenvolvimento de software então a integração contínua é a prática de fundir componentes com incremento de software em evolução uma ou mais vezes ao dia então É aquela ideia de desenvolvimento incremental em que você vai o termo aqui né É bem colocado né fundindo componentes né Cada Vez baseado em novos incrementos e software Então você vai evoluindo o software que vai adicionando incrementos no software essa esse conceito de integração contínua ele é
bastante comum em métodos ágeis Na verdade o termo nasceu com a metodologia que do Grêmio né o XP e aqui o teste de integração ele deve ser ágil né adotar os valores de metros ágeis uma coisa que é importante de salientar é que a integração contínua difere da prática de construir novas funcionalidades de forma isolada e depois integrar essas novas funcionalidades no fim do ciclo de desenvolvimento não é assim que funciona na integração contínua na integração contínua você não tem essas quebras né É de fato algo que vai não contínuo vai fundindo esses componentes né
vai se estendendo os componentes embutindo né novas funcionalidades da vida que os componentes vão sendo incrementados Então esse é uma abordagem bastante útil vem sendo muito empregada nos processos de desenvolvimento de software está muito atrelada aos conceitos dos métodos chegamos ao último tópico que nós estudamos a disciplina que é o tópico de gestão de configuração de software que é necessária para controlar as alterações que ocorrem durante todo o ciclo de desenvolvimento de software bom alterações de Que itens né Qualquer item que compõe a informações produzidas como parte do processo de software e se envolve principalmente
programas de computador então código produzido né tanto código fonte como código executável E também o controle de alterações nos artefatos que descrevem os programas de computador quer de fato seriam esses por exemplo modelo arquitetural especificação de requisitos casos de testes e etc bom Pessoal espero que vocês tenham gostado dessa aula de revisão e espero que ela seja útil que vocês possam utilizá-la para o estudo dos estudos finais né que vocês possam se preparar bem para o exame final da disciplina procurei apresentar os principais tópicos destacando aqueles de maior importância que foram estudados ao longo da
disciplina acredito que a partir dessa vídeo aula de revisão vocês possam verticalizar esses temas e aproveitar melhor o tempo de vocês para os estudos finais então Desejo a todos um excelente estudo e um bom exame final
