Engenharia de Software I - Unidade II

Prévia do material em texto

<p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>1</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Metodologias de desenvolvimento de software.</p><p> Metodologias tradicionais:</p><p> Modelo em Cascata ou Sequencial Linear.</p><p> Modelo de Prototipação.</p><p> Desenvolvimento Rápido de Aplicação – RAD.</p><p> Modelos Evolucionários.</p><p> Metodologias ágeis.</p><p>3</p><p>METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE</p><p>Conforme a necessidade de desenvolvimento de sistemas foi crescendo, as</p><p>atividades realizadas pelos responsáveis no desenvolvimento se repetiam a</p><p>cada novo software.</p><p>A partir do estudo dessas atividades, foram surgindo metodologias e</p><p>processos, visando padronizar e agilizar o tempo do projeto.</p><p>4</p><p>METODOLOGIAS TRADICIONAIS</p><p>O Modelo Sequencial Linear</p><p>(Ciclo de Vida Clássico ou Modelo Cascata)</p><p>O Modelo Espiral</p><p>O Modelo Baseado em Componentes</p><p>O Paradigma de Prototipação</p><p>Processo Unificado</p><p>5</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p> Rumores dessa metodologia surgiu durante a segunda guerra mundial.</p><p> Baseado em projetos de engenharia clássicos ou ciclo da engenharia convencional, foi</p><p>consolidado em 1970 por Royce.</p><p> Organiza o processo em uma sequência linear de fases.</p><p> É utilizada quando os requisitos são muito bem definidos.</p><p> O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em engenharia de</p><p>software e está na base de muitos ciclos de vida utilizados hoje em dia. Este consiste</p><p>basicamente num modelo linear em que cada passo deve ser completado antes que o próximo</p><p>passo possa ser iniciado.</p><p> O modelo em cascata é um exemplo de um processo dirigido a planos, isto é, as atividades</p><p>devem ser programadas e planejadas antes de serem iniciadas.</p><p>6</p><p> Características:</p><p> Ajuda os desenvolvedores a descrever o que precisam fazer (útil);</p><p> Ajuda a explicar o processo de desenvolvimento aos clientes</p><p>(simples e fácil);</p><p> Os produtos intermediários são finalizados para começar próximo</p><p>estágio e servem de insumo para o seu desenvolvimento;</p><p> Seu enfoque está nos documentos e artefatos (requisitos,</p><p>projetos, códigos).</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>7</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Pressman – Engenharia de Software</p><p>8</p><p>Engenharia de Sistemas</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p> Envolve a elicitação de requisitos do sistema, com uma pequena quantidade de</p><p>projeto e análise de alto nível;</p><p> Preocupa-se com aquilo que conhecemos como engenharia progressiva de produto</p><p>de software;</p><p> Iniciar com um modelo conceitual de alto nível para um sistema e prosseguir com o</p><p>projeto, implementação e teste do modelo físico do sistema;</p><p> Esta etapa é essencial quando o software deve fazer interface com outros</p><p>elementos (hardware, pessoas e banco de dados).</p><p>9</p><p> As funções, as restrições e os objetivos do sistema são estabelecidos por meio da</p><p>consulta aos usuários do sistema.</p><p> Deve-se compreender o domínio da informação, a função, desempenho e interfaces</p><p>exigidos.</p><p> Os requisitos (para o sistema e para o software) são documentados e revistos com o</p><p>Cliente.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Análise</p><p>10</p><p> Realiza todo o planejamento.</p><p> São realizados os testes e as estimativas do desenvolvimento e criados os cronogramas</p><p>para posterior acompanhamento do desenvolvimento do software.</p><p> Define a arquitetura do sistema geral. É a tradução dos requisitos do software para um</p><p>conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a</p><p>codificação se inicie.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Projeto</p><p>11</p><p> Escreve os códigos, as interfaces com os clientes, a arquitetura do software e a</p><p>estrutura de dados, para atender a todas as regras de negócio levantadas na primeira</p><p>fase.</p><p> Recomenda-se realizar testes unitários nos módulos durante essa fase.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Codificação</p><p>12</p><p> O teste se concentra nos aspectos lógicos internos do software, garantindo que todas as</p><p>instruções tenham sido testadas;</p><p> Se concentra nos aspectos funcionais externos, para descobrir erros e garantir que a</p><p>entrada definida produza resultados que concordem com os esperados.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Testes</p><p>13</p><p> Normalmente, é a fase mais longa do processo, pois tratará do suporte ao cliente,</p><p>resolvendo os problemas quando o cliente der o feedback e implementando novos</p><p>requisitos conforme necessidade.</p><p> Existe uma probabilidade grande do software sofrer mudanças depois que for entregue</p><p>ao cliente.</p><p> Causas das mudanças: erros, adaptação do software para acomodar mudanças em seu</p><p>ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>Manutenção</p><p>14</p><p>Apesar do modelo ser encadeado, passando de fase apenas com o término da fase</p><p>anterior, na prática, acaba acontecendo uma sobreposição de algumas fases, ou seja,</p><p>uma fase serve de insumo para a próxima fase e pode descobrir um problema na fase</p><p>anterior, levando a fase anterior a ser modificada.</p><p>Essa abordagem apresenta a vantagem de produzir uma documentação muito</p><p>consistente em cada fase, porém é recomendada apenas quando os requisitos são pré-</p><p>estabelecidos, bem conhecidos e com pouca probabilidade de mudança com o passar</p><p>do tempo.</p><p>MODELO EM CASCATA OU SEQUENCIAL LINEAR</p><p>15</p><p>BIBLIOGRAFIA</p><p> UA – Modelos tradicionais x métodos ágeis</p><p> UA - Conhecer os modelos tradicionais</p><p> https://www.semeru.com.br/blog/as-metodologias-tradicionais-de-desenvolvimento-de-software/</p><p> http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_I_2015_2/Aula04_ModelosProcessos.pdf</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> MORAIS, Izabelly Soares de. Engenharia de software [recurso eletrônico] / Izabelly Soares de Morais,</p><p>Aline Zanin ; revisão técnica : Jeferson Faleiro Leon. – Porto Alegre : SAGAH, 2017.</p><p>https://www.semeru.com.br/blog/as-metodologias-tradicionais-de-desenvolvimento-de-software/</p><p>http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_I_2015_2/Aula04_ModelosProcessos.pdf</p><p>16</p><p>REFERÊNCIAS</p><p>Imagens utilizadas nos slides:</p><p> https://www.semeru.com.br/blog/wp-content/uploads/2012/09/waterfall.jpg</p><p> https://unsplash.com/ Acesso <30/04/2022>.</p><p>https://www.semeru.com.br/blog/wp-content/uploads/2012/09/waterfall.jpg</p><p>https://unsplash.com/</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>2</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Metodologias tradicionais:</p><p> Modelo de Prototipação.</p><p> Desenvolvimento Rápido de Aplicação – RAD.</p><p>3</p><p>MODELO DE PROTOTIPAÇÃO</p><p> Apropriado para quando o cliente definiu um conjunto</p><p>de objetivos gerais para o software, mas não</p><p>identificou requisitos de entrada, processamento e</p><p>saída com detalhes.</p><p> A utilização do protótipo do software pelo usuário</p><p>servirá para verificar como o software o auxiliará no</p><p>seu trabalho, para validar se os requisitos já definidos</p><p>estão sendo atendidos em sua plenitude, para</p><p>identificar pontos positivos e negativos e, assim, gerar</p><p>novos requisitos.</p><p> Software final tende a ficar muito próximo da real</p><p>necessidade do cliente, visto que foram sendo</p><p>realizados ajustes durante os desenvolvimentos e</p><p>divulgações dos protótipos.</p><p>“... o protótipo é uma versão</p><p>simulada ou amostra de um</p><p>produto final, utilizada para testes</p><p>antes do lançamento...”</p><p>“consiste em montar um sistema</p><p>experimental rapidamente e sem</p><p>muitos gastos para submetê-lo à</p><p>avaliação de usuários finais.”</p><p>“o protótipo é uma versão funcional</p><p>de um sistema de informação, ou de</p><p>parte dele, mas deve ser</p><p>considerado apenas um modelo</p><p>preliminar.”</p><p>4</p><p>MODELO DE PROTOTIPAÇÃO</p><p>Coleta e refinamento dos requisitos: ocorre</p><p>a identificação dos requisitos junto ao cliente.</p><p>Nessa fase, o engenheiro</p><p>mantém contato</p><p>direto com o cliente apenas para captar as</p><p>necessidades básicas de informação.</p><p>Projeto rápido: fase que define como será a</p><p>iteração da prototipação e na qual acontece</p><p>a criação de um projeto rápido, que</p><p>contempla a parte do software que estará</p><p>visível ao cliente. Abordagens de entrada e</p><p>formatos de saída.</p><p>5</p><p>MODELO DE PROTOTIPAÇÃO</p><p>Construção Protótipo: implementação</p><p>rápida do projeto.</p><p>Avaliação do protótipo pelo cliente:</p><p>fase de utilização do protótipo</p><p>desenvolvido na fase anterior pelo</p><p>usuário final, a fim de validar o software,</p><p>sugerir mudanças e aperfeiçoamentos.</p><p>Refinamento do Protótipo: cliente e</p><p>desenvolvedor refinam os requisitos do</p><p>software a ser desenvolvido. Ocorre neste</p><p>ponto um processo de interação que pode</p><p>conduzir à primeira atividade até que as</p><p>necessidades do cliente sejam satisfeitas e o</p><p>desenvolvedor compreenda o que precisa</p><p>ser feito.</p><p>6</p><p>MODELO DE PROTOTIPAÇÃO</p><p>Engenharia do Produto: identificados</p><p>os requisitos, o protótipo deve ser</p><p>descartado e a versão de produção</p><p>deve ser construída considerando os</p><p>critérios de qualidade.</p><p>7</p><p>MODELO DE PROTOTIPAÇÃO</p><p> Vantagens:</p><p> Todo o requisitos de sistema não tem que ser completamente determinado</p><p>antecipadamente.</p><p> A satisfação e interação do cliente no desenvolvimento do protótipo.</p><p> Testes através do protótipo para atingir o objetivo final proposto.</p><p> Desvantagens:</p><p>O processo de prototipação pode dar ao usuário final a impressão que praticamente</p><p>qualquer sugestão pode ser implementada, não importa qual estágio do processo de</p><p>desenvolvimento se está.</p><p>Além disso, para o usuário final não está claro o porquê da demora para entregar a</p><p>aplicação final depois que uma versão demo do sistema foi exibida.</p><p>O desenvolvedor frequentemente faz uma implementação comprometida (utilizando o</p><p>que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um</p><p>tempo ele se familiariza com essas escolhas, e esquece que elas não são apropriadas para</p><p>o produto final.</p><p>8</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p> É o modelo sequencial linear mas que enfatiza um desenvolvimento extremamente</p><p>rápido.</p><p> A “alta velocidade” é conseguida através de uma abordagem de construção baseada em</p><p>componentes.</p><p> O desenvolvimento rápido de aplicação é adequado para construção de aplicações em</p><p>curto espaço de tempo, utilizando o método incremental da prototipação, com o ciclo</p><p>extremamente curto de desenvolvimento, que só é possível quando temos grande</p><p>entendimento dos requisitos e o projeto é curto e simples.</p><p> É um modelo de processo de desenvolvimento de software iterativo e incremental que</p><p>enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias).</p><p>9</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p> As restrições de tempo impostas pelo projeto demandam um escopo de escala.</p><p> A aplicação deve ser modularizada de forma que cada função deva ser completada em pelo</p><p>menos 3 meses.</p><p> Cada modulo pode ser alocado a uma equipe distinta e depois serem integradas para</p><p>formar um todo.</p><p> Criação e reutilização de componentes.</p><p> No RAD, há o sequenciamento existente no modelo cascata e a ideia de apresentações</p><p>parciais ao cliente para validação e continuação do desenvolvimento, vinda do modelo de</p><p>prototipação, porém, nesse modelo, o que é apresentado ao cliente é, de fato, parte do</p><p>software, e não apenas um protótipo.</p><p>10</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p>Processo que tem a duração</p><p>de 30 a 90 dias.</p><p>Testes e</p><p>Modificação</p><p>Modelagem</p><p>dos Dados</p><p>Modelagem</p><p>do Processo</p><p>Geração da</p><p>Aplicação</p><p>Modelagem</p><p>do Negócio</p><p>Equipe 1</p><p>Testes e</p><p>Modificação</p><p>Modelagem</p><p>dos Dados</p><p>Modelagem do</p><p>Processo</p><p>Geração da</p><p>Aplicação</p><p>Modelagem do</p><p>Negócio</p><p>Equipe 2</p><p>11</p><p>Modelagem do negócio: fase de análise e negociação do projeto, na qual</p><p>são definidos o escopo e os requisitos da aplicação.</p><p>Nessa fase, é feita a estruturação do fluxo de informações entre as funções</p><p>do negócio, o que garante uma visão dos processos que serão suportados</p><p>pelo software. A partir disso, pode-se traçar o plano de trabalho da equipe</p><p>de desenvolvimento.</p><p>Testes e</p><p>Modificação</p><p>Modelagem</p><p>dos Dados</p><p>Modelagem</p><p>do Processo</p><p>Geração da</p><p>Aplicação</p><p>Modelagem</p><p>do Negócio</p><p>Modelagem dos Dados: Após analise do fluxo de informações</p><p>obtido na fase anterior, são determinados os objetos de dados</p><p>cruciais para o negócio, separando-os em grupos de acordo com</p><p>sua utilidade.</p><p>Nesse momento, também é feita a análise da composição dos</p><p>objetos de dados, das relações estabelecidas entre eles e do</p><p>relacionamento que cada um tem com os processos que vão</p><p>manipulá-los.</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p>12</p><p>Modelagem do Processo: os objetos de dados definidos na fase anterior são</p><p>convertidos em informações necessárias para montar o fluxo de</p><p>implementação das funções do negócio. Durante o percurso, otimizações e</p><p>mudanças nos objetos de dados também podem ser feitas.</p><p>No mais, ainda são estruturadas as regras que vão delimitar a modificação,</p><p>recuperação, descarte e adição de objetos ao sistema.</p><p>Testes e</p><p>Modificação</p><p>Modelagem</p><p>dos Dados</p><p>Modelagem</p><p>do Processo</p><p>Geração da</p><p>Aplicação</p><p>Modelagem</p><p>do Negócio</p><p>Geração da Aplicação: Nessa etapa as informações coletadas serão</p><p>transformadas em código com objetivo de criar um protótipo testável</p><p>do sistema. Como o RAD trabalha a ideia do reaproveitamento, sempre</p><p>que possível a aplicação utiliza componentes de programas já</p><p>existentes.</p><p>Quando não há essa possibilidade, são criados componentes que</p><p>poderão ser utilizados em outras partes do sistema. Além de que, para</p><p>facilitar o desenvolvimento, geralmente são usadas ferramentas</p><p>automatizadas nessa fase.</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p>13</p><p>Testes e Modificação: Cada protótipo é testado separadamente,</p><p>reduzindo o tempo de teste global, e por se tratar de um processo</p><p>de desenvolvimento iterativo que conta com vários componentes</p><p>reutilizados que já foram testados, é possível testar apenas o que</p><p>foi criado neste momento.</p><p>Aplicando o teste individual em cada componente, consegue-se</p><p>identificar as melhorias e modificações que precisam ser feitas</p><p>para atingir a construção de um produto mais eficaz.</p><p>DESENVOLVIMENTO RÁPIDO DE APLICAÇÃO - RAD</p><p>Testes e</p><p>Modificação</p><p>Modelagem</p><p>dos Dados</p><p>Modelagem</p><p>do Processo</p><p>Geração da</p><p>Aplicação</p><p>Modelagem</p><p>do Negócio</p><p>14</p><p>BIBLIOGRAFIA</p><p> UA – Modelos tradicionais x métodos ágeis</p><p> UA - Conhecer os modelos tradicionais</p><p> https://blog.betrybe.com/tecnologia/rad/</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª</p><p>Edição. São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9.</p><p>ed. – Porto Alegre: AMGH, 2021. E-pub.</p><p> MORAIS, Izabelly Soares de. Engenharia de software [recurso eletrônico] / Izabelly Soares de</p><p>Morais, Aline Zanin ; revisão técnica : Jeferson Faleiro Leon. – Porto Alegre : SAGAH, 2017.</p><p>https://blog.betrybe.com/tecnologia/rad/</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>3</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Modelos Evolucionários:</p><p> Incremental;</p><p> Espiral;</p><p> Montagem de componente;</p><p> Desenvolvimento concorrente.</p><p> Métodos Formais.</p><p> Técnicas de 4ª Geração.</p><p>3</p><p>MODELOS EVOLUCIONÁRIOS</p><p>Existem situações em que a engenharia de software necessita de um modelo de processo</p><p>que possa acomodar um produto que evolui com o tempo.</p><p> quando os requisitos de produto e de negócio mudam conforme o desenvolvimento procede</p><p> quando há uma data de entrega apertada (mercado) - impossível a conclusão de um produto</p><p>completo</p><p> quando um conjunto de requisitos importantes é bem conhecido, porém os detalhes ainda</p><p>devem ser definidos.</p><p>Modelos evolutivos são iterativos,</p><p>possibilitando o desenvolvimento de</p><p>versões cada vez mais completas do</p><p>software.</p><p>“O método iterativo é comparado ao trabalho de um escultor:</p><p>primeiramente, é selecionado uma pedra do tamanho</p><p>adequado</p><p>para o trabalho; depois ele começa a esculpir a peça de um modo</p><p>geral, sendo que já é possível ter uma ideia de qual será o seu</p><p>desfecho; na última etapa, ocorre o refinamento de detalhes,</p><p>resultando em uma arte que cumpre com o seu propósito.”</p><p>4</p><p>MODELO INCREMENTAL</p><p> O primeiro modelo evolucionário que surgiu é o modelo incremental de desenvolvimento de</p><p>software.</p><p> Para Sommerville o sistema incremental tem o objetivo de reduzir o retrabalho custoso do</p><p>modelo cascata, possibilitando ao cliente postergar decisões e requisitos conforme</p><p>necessidade, mas mantendo o poder de gerenciamento que o modelo oferece.</p><p> O modelo incremental combina elementos do modelo cascata (aplicado repetidamente) com a</p><p>filosofia iterativa da prototipação com o objetivo de trabalhar junto do usuário para descobrir</p><p>seus requisitos, de maneira incremental, até que o produto final seja obtido.</p><p> Essa metodologia divide a fase de desenvolvimento do software em ciclos completos,</p><p>passando por todas as fases existentes no modelo clássico, levantamento e análise de</p><p>requisitos, projeto, implementação e testes.</p><p>5</p><p>MODELO INCREMENTAL</p><p>1.Comunicação: trata das informações do negócio,</p><p>como são geradas, processadas e quem utilizará.</p><p>Define os requisitos.</p><p>2.Planejamento: define os objetos, suas</p><p>características e como se relacionarão entre si.</p><p>3.Modelagem: desenha o processo, visando</p><p>atender à função do negócio, e define os</p><p>procedimentos necessários para a manipulação</p><p>dos objetos de dados definidos na etapa anterior.</p><p>4. Construção: ocorre a geração da aplicação, normalmente por meio de reutilização de componentes que</p><p>serão integrados posteriormente.</p><p>5. Implantação: acontece alguns pequenos testes e a entrega de parte do produto.</p><p>6</p><p>MODELO ESPIRAL</p><p>Engloba as melhores características do Modelo Cascata e da Prototipação, adicionando um novo</p><p>elemento: a Análise de Riscos.</p><p> Risco: algo que pode dar errado.</p><p> Segue a abordagem de passos sistemáticos do Modelo Cascata, incorporando-os numa</p><p>estrutura iterativa.</p><p> É dividido em uma série de regiões, tipicamente de 3 a 6, que delimitam atividades de</p><p>arcabouço.</p><p> Usa a prototipação em qualquer etapa da evolução do produto, como mecanismo de redução</p><p>de riscos.</p><p> É uma abordagem realista para o desenvolvimento de sistemas e software de grande porte.</p><p> Exige a consideração direta dos riscos técnicos em todos os estágios do projeto.</p><p>7</p><p>MODELO ESPIRAL</p><p>Para cada volta na espiral:</p><p> Determinar os objetivos, alternativas e</p><p>restrições relacionadas à iteração que vai se</p><p>iniciar.</p><p> Identificar e resolver os riscos relacionados.</p><p> Avaliar alternativas disponíveis. Podem ser</p><p>feitos protótipos para analisar a viabilidade</p><p>de diferentes alternativas.</p><p> Desenvolver os artefatos relacionados à</p><p>iteração corrente e valida-los.</p><p> Planejar a próxima iteração.</p><p> Obter concordância em relação ao</p><p>planejamento.</p><p>Modelo padrão - quatro regiões definidas</p><p>8</p><p>MODELO ESPIRAL</p><p>1. Planejamento e Requisitos - nessa fase, é feito o</p><p>levantamento de requisitos junto ao cliente,</p><p>estabelecendo as restrições e as diretrizes do software,</p><p>bem como os riscos. É criado um plano de</p><p>gerenciamento, com cronogramas e estimativas de</p><p>custos.</p><p>2. Análise de Riscos - nesse ponto, é realizado uma análise</p><p>para cada um dos riscos levantados e estudado</p><p>maneiras de reduzi-los.</p><p>3. Desenvolvimento e Validação – o protótipo é</p><p>desenvolvido e validado.</p><p>4. Entrega e Avaliação de Continuidade - nessa fase,</p><p>ocorre uma entrega para o cliente e uma avaliação, para</p><p>decidir se o projeto continuará para o próximo loop da</p><p>espiral. Caso seja decidida a continuidade, o custo, o</p><p>cronograma e o planejamento da quantidade de</p><p>iterações planejadas anteriormente serão refinados de</p><p>acordo com os feedbacks recebidos do usuário.</p><p>Modelo padrão - quatro regiões definidas</p><p>9</p><p>MODELO MONTAGEM DE COMPONENTE</p><p> Faz reuso de software visando ao ganho em agilidade e confiabilidade, utilizando</p><p>tecnologias de orientação a objetos.</p><p> Sendo que agilidade desse modelo se deve ao fato de o reuso dos componentes,</p><p>obtido por meio de adaptações e de combinações.</p><p> Pressman define que “a engenharia de software baseada em componentes identifica,</p><p>constrói, cataloga e dissemina um conjunto de componentes de software em</p><p>determinado domínio de aplicação. Esses componentes são então qualificados,</p><p>adaptados e integrados para uso em um novo sistema...”</p><p> O modelo de montagem de componentes incorpora muitas das características do</p><p>modelo espiral.</p><p>10</p><p>MODELO MONTAGEM DE COMPONENTE</p><p> incorpora características de</p><p>tecnologias orientada a objetos</p><p>no Modelo Espiral .</p><p> a atividade de Engenharia</p><p>começa com a identificação de</p><p>classes candidatas;</p><p> se a classe existe, ela será</p><p>reutilizada;</p><p> se a classe não existe, ela será</p><p>desenvolvida nos moldes do</p><p>paradigma de Orientação a</p><p>Objetos.</p><p>11</p><p>MODELO MONTAGEM DE COMPONENTE</p><p>Exemplo:</p><p>Um software para controle de academias.</p><p>Para ele, é criado o componente de login e o componente de cadastro de usuários.</p><p>Um software para controle de uma loja de carros.</p><p>Pode ser reutilizado os dois componentes criados para o software de controle da</p><p>academia para compor o software da loja de carros, visto que já estão em uso,</p><p>funcionando e testados.</p><p>Dessa maneira, teríamos um considerável ganho de tempo, cabendo ao engenheiro</p><p>de software desenhar formas desses módulos interagirem com os outros módulos</p><p>que são diferentes de cada sistema.</p><p>12</p><p>MODELO DESENVOLVIMENTO CONCORRENTE</p><p> Pressman afirma que “o modelo de desenvolvimento concorrente, possibilita à equipe de software</p><p>representar elementos concorrentes e iterativos de qualquer um dos modelos de processos.”</p><p> Esse modelo é adequado quando temos diferentes equipes no projeto, trabalhando em paralelo.</p><p> É representado como uma série de grandes atividades técnicas, tarefas e seus estados associados.</p><p> Define uma série de eventos que podem disparar transições de um estado para outro, para cada</p><p>uma das atividades da engenharia de software.</p><p> Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como</p><p>está o estado do projeto.</p><p>13</p><p>MODELO DESENVOLVIMENTO CONCORRENTE</p><p> Inativo - a atividade ainda não foi iniciada.</p><p> Em Desenvolvimento - a atividade começou a ser</p><p>desenvolvida e não foi finalizada.</p><p> Aguardando Modificações - indica uma atividade que já foi</p><p>concluída e que poderá ter mudanças, ou uma atividade</p><p>que estava em desenvolvimento e foi paralisada por</p><p>mudanças em outras atividades.</p><p> Em Revisão - nessa fase, serão levantadas e revisadas as</p><p>mudanças necessárias.</p><p> Em Exame - nessa fase, as validações do que foi</p><p>desenvolvido são feitas pelo cliente.</p><p> Ponto de Partida - quando as atividades foram testadas e</p><p>aprovadas pelo cliente.</p><p> Concluído - a atividade fica nesse ponto ao ser finalizada e</p><p>enquanto não é necessário realizar nenhuma mudança</p><p>14</p><p>MODELO MÉTODOS FORMAIS</p><p> Pressman define como sendo “um conjunto de atividades que conduzem à</p><p>especificação matemática formal do software. Os métodos formais possibilitam</p><p>especificar, desenvolver e verificar um sistema baseado em computador através da</p><p>aplicação de uma notação matemática rigorosa.”</p><p> Por se tratar de um modelo matemático que não permite falhas, é muito indicado para</p><p>softwares com alto fator de segurança, como sistemas de aviões, por exemplo.</p><p> Contudo o desenvolvimento de um software nesse modelo consome muito tempo e</p><p>dinheiro, além de ser mais complexo, são necessários treinamentos, visto a escassez de</p><p>mão de obra especializada.</p><p>15</p><p>TÉCNICAS DE 4ª GERAÇÃO</p><p> As técnicas de quarta geração englobam um conjunto de ferramentas de softwares que</p><p>visa permitir ao desenvolvedor especificar as características do software em alto nível.</p><p> A técnica de quarta geração tem o objetivo de que os requisitos descritos pelo cliente</p><p>sejam capazes de ser introduzidos em uma ferramenta que automaticamente geraria a</p><p>estratégia do projeto, as codificações e realizaria</p><p>os testes.</p><p> Concentra-se na capacidade de se especificar o software a uma máquina em um nível</p><p>que esteja próximo à linguagem natural.</p><p> Engloba um conjunto de ferramentas de software que possibilitam que: o sistema seja</p><p>especificado em uma linguagem de alto nível e o código fonte seja gerado</p><p>automaticamente a partir dessas especificações.</p><p>16</p><p>TÉCNICAS DE 4ª GERAÇÃO</p><p>Obtenção dos Requisitos: o cliente descreve os requisitos os quais são</p><p>traduzidos para um protótipo operacional.</p><p>• O cliente pode estar inseguro quanto aos requisitos;</p><p>• O cliente pode ser incapaz de especificar as informações de um</p><p>modo que uma ferramenta 4GL possa consumir.</p><p>Estratégia de "Projeto": para pequenas aplicações é possível mover-se</p><p>do passo de Obtenção dos Requisitos para o passo de Implementação</p><p>usando um linguagem 4GL.</p><p>• para grandes projetos é necessário desenvolver uma estratégia</p><p>de projeto. De outro modo ocorrerão os mesmos problemas</p><p>encontrados quando se usa abordagem convencional (baixa</p><p>qualidade).</p><p>Implementação usando 4GL: os resultados desejados são</p><p>representados de modo que haja geração automática de</p><p>código. Deve existir uma estrutura de dados com informações</p><p>relevantes e que seja acessível pela 4GL</p><p>Testes: o desenvolvedor deve efetuar testes e</p><p>desenvolver uma documentação significativa. O</p><p>software desenvolvido deve ser construído de maneira</p><p>que a manutenção possa ser efetuada prontamente.</p><p>17</p><p>BIBLIOGRAFIA</p><p> UA – Modelos tradicionais x métodos ágeis</p><p> UA - Conhecer os modelos tradicionais</p><p> https://blog.betrybe.com/tecnologia/rad/</p><p> https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula02.pdf</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª</p><p>Edição. São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9.</p><p>ed. – Porto Alegre: AMGH, 2021. E-pub.</p><p> MORAIS, Izabelly Soares de. Engenharia de software [recurso eletrônico] / Izabelly Soares de</p><p>Morais, Aline Zanin ; revisão técnica : Jeferson Faleiro Leon. – Porto Alegre : SAGAH, 2017.</p><p>https://blog.betrybe.com/tecnologia/rad/</p><p>https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula02.pdf</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>4</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Desenvolvimento Ágil de Software.</p><p> Metodologias Ágeis.</p><p>3</p><p>DESENVOLVIMENTO ÁGIL DE SOFTWARE</p><p> As empresas operam em um ambiente global com mudanças rápidas.</p><p> Softwares fazem parte de quase todas as operações de negócios.</p><p> Desta forma novos softwares são desenvolvidos rapidamente para as empresas</p><p>obterem proveito de novas oportunidades e responder as pressões competitivas.</p><p> Com a mudança rápida do mercado é impossível obter um conjunto completo de</p><p>requisitos de software estável.</p><p> Processos de desenvolvimento rápido de software são concebidos para produzir, de</p><p>forma rápida, software úteis.</p><p>4</p><p>DESENVOLVIMENTO ÁGIL DE SOFTWARE</p><p> Desenvolvimento ágil de software ou Método ágil é um conjunto de metodologias de</p><p>desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de</p><p>software, providencia uma estrutura conceitual para reger projetos de engenharia de software.</p><p> As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de</p><p>1990 como parte de uma reação contra métodos "pesados", caracterizados por uma pesada</p><p>regulamentação, regimentação e micro gerenciamento usado o modelo em cascata para</p><p>desenvolvimento.</p><p> A expressão “Metodologias Ágeis” tornou-se conhecida em 2001, quando especialistas em</p><p>processos de desenvolvimento de software representando entre outros, os métodos Scrum e</p><p>Extreme Programming (XP), foram estabelecidos princípios e características comuns destes</p><p>métodos. Assim foi criada a “Aliança Ágil” e efetuou-se o estabelecimento do “Manifesto Ágil”.</p><p>5</p><p>DESENVOLVIMENTO ÁGIL DE SOFTWARE</p><p>Manifesto Ágil</p><p>Métodos ágeis focam em simplicidade, software funcional</p><p>no início das iterações, flexibilidade e intensa comunicação</p><p>tanto internamente quanto com clientes.</p><p>Indivíduos e interações são mais importantes que processos e ferramentas.</p><p>Software funcionando é mais importante do que documentação completa e</p><p>detalhada.</p><p>Colaboração com o cliente é mais importante do que negociação de contratos.</p><p>Adaptação a mudanças é mais importante do que seguir o plano inicial.</p><p>6</p><p>PRINCÍPIOS DOS MÉTODOS ÁGEIS</p><p>Princípios Descrição</p><p>Envolvimento do</p><p>cliente</p><p>Os clientes devem estar envolvidos no processo de desenvolvimento. Seu papel é</p><p>fornecer e priorizar novos requisitos dos sistema e avaliar suas interações.</p><p>Entrega</p><p>incremental</p><p>O software desenvolvido em incrementos com o cliente, especificando os requisitos</p><p>para serem incluídos em cada um.</p><p>Pessoas não</p><p>processos</p><p>As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas.</p><p>Os membros da equipe tem a liberdade de desenvolver suas próprias maneiras de</p><p>trabalhar.</p><p>Aceitar as</p><p>mudanças</p><p>Deve-se ter em mente que os requisitos do sistema vão mudar. Por isso o sistema</p><p>projetado de acomodar tais mudanças.</p><p>Manter a</p><p>simplicidade</p><p>Foco na simplicidade, tanto do software a ser desenvolvido como do processo de</p><p>desenvolvimento. Trabalhar de forma ativa para eliminar a complexidade do sistema.</p><p>7</p><p>METODOLOGIAS ÁGEIS</p><p>Métodos de desenvolvimento de software ágil aplicam desenvolvimento iterativo e</p><p>incremental, planejamento adaptativo, flexibilidade e rápida resposta para mudanças.</p><p>Planejamento</p><p>Adaptativo</p><p> É adequado para desenvolvimento de novos produtos.</p><p> Requisitos são escritos para um contexto e ambiente específico</p><p>que estão em constante mudança.</p><p> Desenvolvimento de novos produtos solicita um certo grau de</p><p>pesquisa, inovação e criatividade.</p><p> A tecnologia envolvida exige ferramentas que podem estar ou</p><p>em desenvolvimento ou estabilização.</p><p>8</p><p>DESENVOLVIMENTO ITERATIVO E INCREMENTAL</p><p>Desenvolvimento Incremental é uma estratégia de planejamento estagiado</p><p>em que várias partes do sistema são desenvolvidas em paralelo, e</p><p>integradas quando completas.</p><p>9</p><p>DESENVOLVIMENTO ITERATIVO E INCREMENTAL</p><p>Desenvolvimento iterativo é uma estrategia de planejamento de retrabalho</p><p>em que o tempo de revisão e melhorias de partes do sistema é pré-definido.</p><p>10</p><p>METODOLOGIAS TRADICIONAIS X ÁGEIS</p><p> É necessário conhecer um pouco de todas para que seja</p><p>possível adaptar a realidade da empresa e do cliente.</p><p> Não há receita de bolo ou ferramentas milagrosas para a</p><p>gestão de projeto eficaz.</p><p> O que existem são empresas comprometidas com a</p><p>redução de esforços desnecessários, com foco na</p><p>otimização de processos e de ganho operacional, além do</p><p>aumento da lucratividade e a satisfação do cliente.</p><p>E agora, qual usar?</p><p>11</p><p>BIBLIOGRAFIA</p><p> UA – Modelos tradicionais x métodos ágeis</p><p> UA – Metodologias ágeis de desenvolvimento</p><p> UA - Métodos ágeis</p><p> UA - Modelagem ágil</p><p> https://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis/10596</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p>Recomendação de leitura:</p><p> https://www.youtube.com/watch?v=5oFzY1_-pXI</p><p> https://www.youtube.com/c/codigofontetv/search?query=metodologias%20ageis</p><p>https://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis/10596</p><p>https://www.youtube.com/watch?v=5oFzY1_-pXI</p><p>https://www.youtube.com/c/codigofontetv/search?query=metodologias%20ageis</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>5</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Metodologias Ágeis.</p><p> Scrum.</p><p> Programação Extrema – XP.</p><p>3</p><p>METODOLOGIAS ÁGEIS – SCRUM</p><p> O termo surgiu do jogo no qual Scrum é uma estratégia</p><p>em que, quando uma bola está quase perdida, o time</p><p>consegue colocar em jogo</p><p>novamente, por meio do</p><p>trabalho em equipe.</p><p> A metodologia Scrum tem como principal objetivo</p><p>reduzir o tempo de entrega de produtos.</p><p> Seu método é realizado a partir de pequenos ciclos de</p><p>atividades dentro de um projeto.</p><p> Cada ciclo de atividade é planejado previamente e se</p><p>chama Sprint, composto por um período de tempo</p><p>predefinido em que as tarefas devem ser realizadas</p><p>pela equipe.</p><p> A metodologia Scrum permite potencializar o trabalho</p><p>em equipe, acompanhar a evolução do produto,</p><p>sempre com foco na qualidade da produção e nos</p><p>prazos estipulados.</p><p>... o Scrum é um framework ágil que auxilia</p><p>no gerenciamento de projetos complexos e</p><p>no desenvolvimento de produtos. É</p><p>conhecido como um framework que</p><p>prescreve um conjunto de práticas leves e</p><p>objetivas, muito utilizadas na área de</p><p>desenvolvimento de software...</p><p>4</p><p>METODOLOGIAS ÁGEIS – SCRUM</p><p> Para utilizar essa metodologia é</p><p>necessário formar as equipes, criar</p><p>o Product backlog, planejar o</p><p>Sprint, organizar o processo de</p><p>forma visual, realizar as reuniões</p><p>diárias, proporcionar transparência</p><p>em todas as etapas e dar/receber</p><p>feedbacks.</p><p> Produtos construídos em 3 a 4</p><p>meses.</p><p>5</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p> Extreme Programming, ou simplesmente XP é uma das mais conhecidas metodologia de</p><p>desenvolvimento de software que segue os princípios do Manifesto Ágil. Embora seu marco de</p><p>criação seja o ano de 1996, a junção de princípios e boas práticas de programação são frutos de</p><p>um processo de evolução de pelo menos uma década de trabalho.</p><p> Criada em 96 por Kent Beck, é voltada principalmente para projetos em que os requisitos</p><p>mudam constantemente e OO.</p><p> Sommerville afirma que o modelo de desenvolvimento por programação extrema, também</p><p>conhecido por Extreme Programming (XP), os requisitos são descritos por meio de histórias do</p><p>usuário, também conhecidos como cenários. Na fase de desenvolvimento, os programadores</p><p>trabalham em pares, sempre criando, primeiramente, os testes para cobrir o que será</p><p>desenvolvido e, posteriormente, o código de fato.</p><p>6</p><p>Valores do XP:</p><p> Comunicação: XP foca em construir um entendimento pessoa-a-pessoa do problema, com o uso mínimo de</p><p>documentação formal e com o uso máximo de interação “cara-a-cara” entre as pessoas envolvidas no projeto.</p><p>As práticas de XP como programação em pares, testes e comunicação com o cliente têm o objetivo de</p><p>estimular a comunicação entre gerentes, programadores e clientes.</p><p> O XP exige sempre a simplicidade durante o desenvolvimento, não podem ocorrer perdas de tempo em</p><p>desenvolvimentos complexos que não serão utilizados, devemos garantir que seja feito apenas o que agregue</p><p>valor ao cliente. Aliado à simplicidade, temos o princípio da coragem para informar ao cliente que</p><p>determinado desenvolvimento não poderá ser finalizado e será replanejado no próximo release.</p><p> Feedback: Os programadores obtêm feedback sobre a lógica dos programas escrevendo e executando casos</p><p>de teste. Os clientes obtêm feedback através dos testes funcionais criados para todas as estórias (casos de</p><p>uso simplificados). O feedback é importante, pois possibilita que as pessoas aprendam cada vez mais sobre o</p><p>sistema e assim corrijam os erros e melhorem o sistema.</p><p> Respeito: Ambiente respeitoso entre os membros do time.</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>7</p><p>Princípios do XP:</p><p> Feedback rápido — Se existe a oportunidade para feedback, use;</p><p> Presumir simplicidade — Codificar de forma simples;</p><p> Mudanças incrementais — XP está aberto para mudanças no seu projeto;</p><p> Abraçar mudanças — Aceitar as mudanças que chegam no seu projeto;</p><p> Trabalho de alta qualidade — Realizar um trabalho que gera valor.</p><p>Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe</p><p>uma série de práticas, essas são divididas em 3 grupos:</p><p> Práticas organizacionais;</p><p> Práticas de equipe;</p><p> Práticas de pares.</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>8</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>Práticas Organizacionais:</p><p> Equipe Inteira:</p><p> É composto pelo cliente, a equipe (desenvolvedores, analistas de negócios, equipe de qualidade)</p><p>e gerente.</p><p> Jogos de Planejamento:</p><p> Planejamento e priorização das entregas e releases (lançamentos para o usuário final).</p><p> No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades, as</p><p>estórias já devem estar criadas.</p><p> Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e</p><p>prontas para serem liberadas em produção.</p><p>9</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>Práticas Organizacionais:</p><p> Entregas Curtas</p><p> Liberação de pequenas versões (releases) em curtos períodos de tempo, é importante para obter-</p><p>se feedback.</p><p> Testes de Usuário/Aceitação</p><p> São testes construídos pelo cliente em conjunto com analistas e testadores, para aceitar o</p><p>requisito do sistema.</p><p> Reuniões em pé</p><p> Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas</p><p>abordando tarefas realizadas e tarefas a realizar pela equipe.</p><p>10</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>Práticas de Equipe:</p><p> Propriedade Coletiva</p><p> O código não possui um dono ou responsável, toda a equipe pode trabalhar nele, sem</p><p>necessidade de solicitar permissão.</p><p> Padronização de Código</p><p> Criar padronização de código para que todos possam ter o mesmo entendimento.</p><p> Ritmo Sustentável</p><p> Trabalhar em ritmo sustentável (40 horas/semana, 8 horas/dia), evitando excesso de horas extras.</p><p> Manter a equipe sempre motivada.</p><p> Metáfora</p><p> Criar metáforas para compartilhar designs e visão técnica. Facilitar a comunicação entre cliente e</p><p>programadores (negócio x técnico).</p><p> Integração Contínua</p><p> Testes automatizados cada vez que um código é atualizado no repositório. Juntamente com a</p><p>integração contínua das funcionalidades.</p><p>11</p><p>METODOLOGIAS ÁGEIS - PROGRAMAÇÃO EXTREMA</p><p>Práticas de Pares:</p><p> Desenvolvimento Orientado a Teste</p><p> Primeiro crie os testes unitários e depois crie o código para que os testes funcionem. Os testes</p><p>unitários são essenciais para que a qualidade do projeto seja mantida.</p><p> Refatoração</p><p> Refatorar o código melhorando a codificação existente sem alterar o comportamento da</p><p>funcionalidade, permitindo a melhoria contínua da programação.</p><p> Design Simples</p><p> Focar na simplicidade. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais</p><p>simples ao cliente. Código fácil deve ser identificado e substituído por código simples.</p><p> Programação em Par</p><p> Enquanto uma pessoa escreve o código, a outra pessoa observa, comenta e fornece feedback.</p><p>Esse conceito ajuda a disseminar e compartilhar o conhecimento. Além do sistema sempre ser</p><p>revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos.</p><p>12</p><p>BIBLIOGRAFIA</p><p> UA – Metodologias ágeis de desenvolvimento</p><p> UA - Métodos ágeis</p><p> UA - Modelagem ágil</p><p> https://www.tecnicon.com.br/upload/public/Blog/post-scrum.png</p><p> http://www.desenvolvimentoagil.com.br/scrum/</p><p> https://www.digite.com/pt-br/agile/programacao-extrema-xp/</p><p> https://medium.com/codengage/um-pouco-sobre-o-m%C3%A9todo-xp-ea2e6baae561</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p>Recomendação de leitura:</p><p> https://www.youtube.com/watch?v=XfvQWnRgxG0&t=3s</p><p>https://www.tecnicon.com.br/upload/public/Blog/post-scrum.png</p><p>http://www.desenvolvimentoagil.com.br/scrum/</p><p>https://www.digite.com/pt-br/agile/programacao-extrema-xp/</p><p>https://medium.com/codengage/um-pouco-sobre-o-m%C3%A9todo-xp-ea2e6baae561</p><p>https://www.youtube.com/watch?v=XfvQWnRgxG0&t=3s</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>2</p><p>6</p><p>2</p><p>CONTEÚDO</p><p> Unidade II:</p><p> Metodologias Ágeis.</p><p> Família Crystal.</p><p> Desenvolvimento</p><p>de Software Adaptativo.</p><p> Desenvolvimento Guiado por Funcionalidades.</p><p> Metodologia de Sistemas Dinâmicos.</p><p> Método Kanban.</p><p>3</p><p>METODOLOGIAS ÁGEIS – CRYSTAL</p><p> A família Crystal é uma abordagem de desenvolvimento de software que prioriza a adaptação, em que,</p><p>durante a primeira iteração, é necessário garantir a entrega de um software útil e, posteriormente,</p><p>preparar-se para as próximas iterações.</p><p> Criada em 1991 pelo Alistair Cockburn a pedido da IBM .</p><p> “os membros da família Crystal são identificados por cores que indicam a intensidade do método. Neste caso,</p><p>quanto mais escura a cor, maior é a complexidade do projeto”.</p><p> As cores:</p><p> Crystal Clear é considerada uma metodologia leve, sendo, assim, para equipes de 2 a 8 pessoas, podendo chegar</p><p>até 12 em casos especiais.</p><p> Yellow é para equipes por volta de 10 a 20 membros.</p><p> Orange, para times de 20 a 75 participantes.</p><p> Red, para equipes de 75 a 100 membros.</p><p> Marrom, acima de 200 pessoas.</p><p>4</p><p>DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO</p><p> O desenvolvimento de Software Adaptativo (ASD) é baseado na</p><p>colaboração humana e em equipes auto organizáveis. É uma</p><p>técnica criada visando à construção de sistemas complexos.</p><p> As fases que compõem essa metodologia:</p><p> Especulação – são utilizados os requisitos e a missão</p><p>estabelecida pelo cliente, as restrições e os riscos para definir</p><p>os ciclos que serão realizados, visando ao incremento do</p><p>software.</p><p> Colaboração - Ela envolve o trabalho em equipe aliado à</p><p>criatividade individual. Os membros da equipe devem,</p><p>principalmente, confiar um no outro.</p><p> Aprendizagem - essa fase visa o aprendizado obtido com o</p><p>passar das versões que incrementam o produto final. A equipe</p><p>de desenvolvimento fica mais experiente e entendida no</p><p>assunto.</p><p>5</p><p>DESENVOLVIMENTO GUIADO POR FUNCIONALIDADES</p><p>Funcionalidade é uma função possível de ser implementada, em um prazo inferior a um mês e</p><p>que agregue valor ao cliente.</p><p>É um processo ágil adaptativo, que pode ser aplicado a projetos de software de porte moderado e</p><p>grande.</p><p>É uma metodologia que:</p><p> foca na colaboração entre os participantes da equipe.</p><p> utiliza a decomposição em funcionalidades e posterior integração dos incrementos para</p><p>gerenciar os problemas encontrados nos projetos de software.</p><p> utiliza meios verbais, gráficos e textos para comunicação.</p><p> foca na garantia da qualidade, utilizando, para isso, desenvolvimento incremental, uso</p><p>de padrões, medições, inspeções, testes e auditorias nos códigos e no projeto.</p><p>6</p><p>DESENVOLVIMENTO GUIADO POR FUNCIONALIDADES</p><p>O modelo apresenta 5 fases:</p><p>1. Desenvolver por funcionalidade - fase de criação da lista de requisitos a partir do consenso acerca do</p><p>escopo e das funcionalidades.</p><p>2. Construir por funcionalidade - criação da lista de funcionalidades com detalhamento para o</p><p>desenvolvimento.</p><p>3. Planejar por funcionalidade - o programador chefe ordena em pacotes as funcionalidades que serão</p><p>repassadas aos desenvolvedores e entregue aos clientes.</p><p>4. Projetar por funcionalidade - o programador chefe monta equipes que atuarão paralelamente para</p><p>desenvolver conjunto de atividades.</p><p>5. Desenvolver por funcionalidade - fase de desenvolvimento, testes e auditorias no código criado. O</p><p>programador chefe valida o desenvolvimento, integra-o ao projeto principal e inicia um novo conjunto</p><p>de atividades.</p><p>7</p><p>METODOLOGIA DE SISTEMAS DINÂMICOS</p><p>Etapas:</p><p> Pré-projeto definição do orçamento e o prazo do projeto.</p><p> Estudo de viabilidade, trabalha com requisitos básicos e restrições.</p><p> Estudo de negócio – requisitos funcionais.</p><p> O desenvolvimento evolutivo utiliza a prototipação evolutiva, colhendo os feedbacks dos</p><p>clientes.</p><p> Com a aprovação, os protótipos serão revisados e reavaliados e teremos a evolução para um</p><p>protótipo operacional, que será, de fato, entregue ao cliente e colocado em operação.</p><p>Assim, entra em ação a fase de pós-projeto, que engloba as possíveis manutenções e</p><p>melhorias.</p><p>Visa atender a projetos com restrições de prazos por meio de prototipagem incremental em um ambiente de</p><p>projeto controlado.</p><p>Essa metodologia é mantida por um grupo mundial de empresas-membro que, coletivamente, assume o papel</p><p>de “mantenedor”.</p><p>8</p><p>MÉTODO KANBAN</p><p> Você já ouviu falar sobre o método Kanban?</p><p> Você inicia muitas tarefas, porém acaba poucas? De que forma suas</p><p>tarefas são gerenciadas?</p><p> Kanban é um termo de origem japonesa e significa literalmente “cartão”</p><p>ou “sinalização”.</p><p> A empresa japonesa de automóveis Toyota, 1950, foi a responsável pela</p><p>introdução desse método devido a necessidade de manter um eficaz</p><p>funcionamento do sistema de produção em série.</p><p> O quadro de Kanban gera transparência ao processo por mostrar o que</p><p>está sendo realmente realizado. Ele também ajuda a medir a</p><p>produtividade por enxergar as tarefas do backlog a serem feitas, além das</p><p>tarefas sendo feitas e as já feitas.</p><p>9</p><p>BIBLIOGRAFIA</p><p> UA – Metodologias ágeis de desenvolvimento</p><p> UA - Métodos ágeis</p><p> UA - Modelagem ágil</p><p> https://kanbanize.com/pt/recursos-kanban/primeiros-passos/o-que-e-kanban</p><p> https://dionatanmoura.files.wordpress.com/2016/07/kanban.png</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p>Recomendação de leitura:</p><p>https://www.youtube.com/watch?v=LJOiFRsp0Z8&t=4s</p><p>https://dionatanmoura.files.wordpress.com/2016/07/kanban.png</p><p>https://dionatanmoura.files.wordpress.com/2016/07/kanban.png</p><p>https://www.youtube.com/watch?v=LJOiFRsp0Z8&t=4s</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Metodologias de Desenvolvimento de Software</p><p>metodologias tradicionais</p><p>Modelo em Cascata ou Sequencial Linear</p><p>Modelo em Cascata ou Sequencial Linear (2)</p><p>Modelo em Cascata ou Sequencial Linear</p><p>Modelo em Cascata ou Sequencial Linear (3)</p><p>Modelo em Cascata ou Sequencial Linear (2)</p><p>Modelo em Cascata ou Sequencial Linear (4)</p><p>Modelo em Cascata ou Sequencial Linear (5)</p><p>Modelo em Cascata ou Sequencial Linear (6)</p><p>Modelo em Cascata ou Sequencial Linear (7)</p><p>Modelo em Cascata ou Sequencial Linear (8)</p><p>BIBLIOGRAFIA</p><p>Referências</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Modelo de prototipação</p><p>Modelo de prototipação (2)</p><p>Modelo de prototipação (3)</p><p>Modelo de prototipação (4)</p><p>Modelo de prototipação (5)</p><p>Desenvolvimento Rápido de Aplicação - RAD</p><p>Desenvolvimento Rápido de Aplicação - RAD (2)</p><p>Desenvolvimento Rápido de Aplicação - RAD (3)</p><p>Desenvolvimento Rápido de Aplicação - RAD (4)</p><p>Desenvolvimento Rápido de Aplicação - RAD (5)</p><p>Desenvolvimento Rápido de Aplicação - RAD (6)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Modelos Evolucionários</p><p>Modelo Incremental</p><p>Modelo Incremental (2)</p><p>Modelo espiral</p><p>Modelo espiral (2)</p><p>Modelo espiral (3)</p><p>Modelo Montagem de Componente</p><p>Modelo Montagem de Componente (2)</p><p>Modelo Montagem de Componente (3)</p><p>Modelo Desenvolvimento Concorrente</p><p>Modelo Desenvolvimento Concorrente (2)</p><p>Modelo métodos formais</p><p>Técnicas de 4ª Geração</p><p>Técnicas de 4ª Geração (2)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Desenvolvimento Ágil de Software</p><p>Desenvolvimento Ágil de Software (2)</p><p>Desenvolvimento Ágil de Software (3)</p><p>Princípios dos métodos ágeis</p><p>Metodologias ágeis</p><p>Desenvolvimento Iterativo e Incremental</p><p>Desenvolvimento Iterativo e Incremental (2)</p><p>Metodologias Tradicionais X ágeis</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Metodologias ágeis – scrum</p><p>Metodologias ágeis – scrum (2)</p><p>Metodologias ágeis - Programação Extrema</p><p>Metodologias ágeis - Programação Extrema (2)</p><p>Metodologias ágeis - Programação Extrema (3)</p><p>Metodologias ágeis - Programação Extrema (4)</p><p>Metodologias ágeis - Programação Extrema (5)</p><p>Metodologias ágeis - Programação Extrema (6)</p><p>Metodologias ágeis - Programação Extrema (7)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Metodologias ágeis – crystal</p><p>Desenvolvimento de Software Adaptativo</p><p>Desenvolvimento Guiado</p><p>por Funcionalidades</p><p>Desenvolvimento Guiado por Funcionalidades (2)</p><p>Metodologia de Sistemas Dinâmicos</p><p>Método kanban</p><p>BIBLIOGRAFIA</p>