diff --git a/README.md b/README.md
index 489ef20..49f5d6d 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,3 @@
-[![pages-build-deployment](https://github.com/RianNegreiros/posts-md/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/RianNegreiros/posts-md/actions/workflows/pages/pages-build-deployment)
-
# Blog posts
- [O que é um Navegador e Como Funciona?](browser.md)
@@ -9,7 +7,6 @@
- [Frameworks de desenvolvimento web](frameworks.md)
- [O que é o Back-End?](backend.md)
- [O que é o Git e por que usá-lo?](git.md)
-- [DESENVOLVIMENTO ÁGIL DE SOFTWARE](agile.md)
- [Criação de URLs amigáveis (slugs) a partir de strings no ASP.NET Core](slug.md)
- [Usando o MongoDB com C# e .Net Core](mongodbnet.md)
- [HTTP Cookies](cookies.md)
diff --git a/agile.md b/agile.md
deleted file mode 100644
index 244be01..0000000
--- a/agile.md
+++ /dev/null
@@ -1,299 +0,0 @@
-# DESENVOLVIMENTO ÁGIL DE SOFTWARE
-
-Áte meados dos anos 1990, os processos de desenvolvimento de software prescritivos exigiam um detalhado planenjamento de projeto, um sistema de garantia da qualidade estabelecido, a aplicação de métodos de análise e projeto, tal como a modelagem de caso de uso, apoiados for ferramentas “CASE” ([Computer-Aided Software Engineering](https://pt.wikipedia.org/wiki/Ferramenta_CASE)) e controlados por um displinado e formal modelo de processo de desenvolvimento de software.
-
-Essa visão era influenciada por equipes de engenheiros de software engajados em sistemas de software complexos que exigiam um esforço significativo de planejamento, projeto e documentação de sistema.
-
-## MAS ESSE ESFORÇO JUSTIFICA-SE EM SISTEMAS DE MENOR GRAU DE COMPLEXIDADE?
-
-Em 2001, um grupo de 17 metodologistas e outros profissionais da indústria de software se reuiniram no estado norte-americano de Utah para discutir e propor uma alternativa aos processos prescetivos dominates á época. Ao final da reunião, esse grupo lançou as bases para um novo conceito de processo de software, as quais foram registradas em um documento que chamaram de [Manisfesto para o Desenvolvimento Ágil de Software](https://agilemanifesto.org/iso/ptbr/manifesto.html), que inclui quatro valores:
-
-- Indivíduos e interações, mais do que processos e ferramentas.
-- Software em funcionamento, mais do que documentação abragente.
-- Colaboração com o cliente, mais do que negociação de contratos.
-- Resposta a mudanças, mais do que seguir um plano.
-
-A maioria dos métodos ágeis de desenvolvimento de software têm foco no próprio software, em vez de em seu projeto e documentação, assumem um fluxo de processo iterativo e incremental para entegra def software e apoiam aplicações de negócios nas quais os requisitos possuem alta volatilidade durante o desenvolvimento.
-
-Um projeto de software ágil busca a capacidade de implantar um nova versão a cada incremento, enfatizando o software funcional como uma medida primária de progresso.
-
-A entrega de software rápida permite que os clientes validem de form imediata o incremento, indicando possíveis erros ou alterações de requisitos, bem como descrevendo novos requisitos para as próximas iterações.
-
-
-
-## EXTREME PROGRAMMING - XP
-
-A Extreme Programming, ou simplesmente XP, é considerada um processo de desnvolvimento de software ágil, tendo sido proposta por **Kent Beck** em 1999. A XP adota valores que servem como critérios que norteiam as partes interessadas de um projeto, incluindo: comunicação, simplicidade, feedback, coragem e respeito.
-
-
-
-Vejamos uma breve descrição de cada valor:
-
-- **COMUNICAÇÃO**
-
- A **comunicação** objetiva construir um entendimento dos requisitos com o mínimo de documentação formal eo máximo de interação entre equipe de desenvolvimento e clientes.
-
-- **SIMPLICIDADE**
-
- A **simplicidade** sugere que a equipe adote soluções mais simples, criando um ambiente onde o custo de mudanças no futuro seja baixo.
-
-- **FEEDBACK**
-
- O **feedback** permite que os programadores também tenham feedback quando da execução dos testes e quando da validação funcional por parte dos clientes, permitindo a correção de erros e alterações nos requisitos.
-
-- **CORAGEM**
-
- A **coragem** é necessária para lidar com o risco de erro, que deve ser considerado natural e se traduz em confiança nos seus mecanismos de prevenção e proteção
-
-- **RESPEITO**
-
- O **respeito** éo valor mais básico e que dá sustentação a todos os demais, sem o qual não haverá nada que possa salvar um projeto de software do insucesso.
-
-
-Assim como um segundo nível de abstração, a XP possui cinco princípios que servem para ajudar a equipe de software na escolha de alternaltivas de solução de problemas durante o projeto. Os princípios incluem: feedback rápido, assumir simplicidade, mudanças incremental, abraçando mudanças e trabalho de qualidade.
-
-A XP possui [doze práticas](https://www.tutorialspoint.com/extreme_programming/extreme_programming_practices.htm) que se enquadram nos valores e princípios descritos na table a seguir:
-
-| Prática | Descrição |
-| --- | --- |
-| Jogo de Planejamento | Os requisitos são registados em caroes, ou fichas, denominados “história de usuários”, sendo a descrição e a priorização realizadas pelos clientes. A equipe de desenvolvimento estima a duração de cada release. |
-| Pequenas Releases | Cada release dever ser a menor possível, incluindo os requisitos mais para o negócio. As releases frequentes permitem um maior feedback para lcientes e equipe de desnevolvimento, facilitando o aprendizado ea correção dos de feitos do software. |
-| Metáfora | Facilita a comunicação com o cliente, entendendo a sua realidade, isto é, procura traduzir as palavras do úsuario para o significado que ele espera dentro do projeto. Como exemplo, a metáfoa “Estoque 4.0” para um subsistema de gestão virtual dos estoques no contexto de um sistema de logística. |
-| Projeto Simples | Projeto simples inclui projetar somente as histórias de usuários, ou funcionalidades, previamente definidas, bem como se concentrar em soluções de projeto simples e bem estruturadas, tal como menor número possível de classes e métodos. |
-| Cliente no local de Trabalho | Incluir um cliente na equipe de desenvolvimento para responder perguntas, ou alquém da parte do cliente com conhecimento do negócio. O cliente é protagonista em um projeto XP. |
-| Semana de 40 horas | Estimula a busca de um ritmo sustentado de trabalho, tal como 40 horas semanais. Horas extras são permitidass quando trouxeram produtividade para a execução do projeto, devendo estar restringidas a duas semanas seguidas. |
-| Programação Pareada | Todo código deve ser gerado por dois programadores trabalhando em um único computador. O programador codifica e o parceiro revisa e sugere. Dessa forma, o programa sempre é revisto por duas pessoas, evitando e diminuindo, assim, a possibilidade de defeitos. Com isso, busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. |
-| Propriedade Coletiva | O código fonte pode ser alterado por qualquer membro da equipe de desenvolvimento, de modo que esta detém a propriedade do código. O objetivo com isso é fazer a equipe conhecer todas as partes do sistema. Os testes de unidade e integração garantem a estabilidade dessa prática. |
-| Padronização do Código | A prática da propriedade coletiva de código exige o estabelecimento de regras para programar a serem seguidas por todos. O objetivo é facilitar o entendimento do código. |
-| Desenvolvimento Orientado a Testes | Um framework automatizado é sugerido para a escrita dos testes unitários, antes que determinada funcionalidade seja implementada, técnica denominada “test first”. Os testes de integração também são realizados sistematicamente. Os testes de validação são especificados pelos clientes a partir das histórias de usuários. |
-| Refatoração | A refatoração é um processo de modificar a estrutura interna do software sem alterar o seu comportamento externo, permitindo a melhoria contínua da programação com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. |
-| Integração Contínua | O sistema deverá ser integrado sempre que produzir uma nova funcionalidade. Essa continuidade permite a detecção imediata de erros de integração, evitando problemas de compatibilidade e interface. |
-
-## PROCESSO XP
-
-A XP adota o paradigma orientado a objetos, aplicando seus valores, princípios e práticas em um processo com quatro atividades metodológicas: planejamento, projeto, codificação e testes. A Figura ilustra essas atividades metodológicas propostas por Pressman (2016).
-
-![Fonte: [https://blog.grancursosonline.com.br/t-i-em-foco-vamos-entender-a-engenharia-de-software](https://blog.grancursosonline.com.br/t-i-em-foco-vamos-entender-a-engenharia-de-software/)](https://blog-static.infra.grancursosonline.com.br/wp-content/uploads/2020/05/20154428/PU.png)
-
-Fonte: [https://blog.grancursosonline.com.br/t-i-em-foco-vamos-entender-a-engenharia-de-software](https://blog.grancursosonline.com.br/t-i-em-foco-vamos-entender-a-engenharia-de-software/)
-
-## O PROCESSO ÁGIL EXTREME PROGRAMMING (XP)
-
-Veja mais detalhes sobre o processo [XP e suas etapas](https://en.wikipedia.org/wiki/Extreme_programming#:~:text=XP%20describes%20four%20basic%20activities,testing%2C%20listening%2C%20and%20designing.):
-
-### PLANEJAMENTO
-
-A primeira atividade é ouvir o cliente, realizando um levantamento de requisitos que possibilite o entendimento do escopo do problema. Essa atividade gera um conjunto de histórias de usuários, escritas pelos clientes, juntamente à equipe de desenvolvimento que, de forma simplificada, compõem as necessidades destes. Cada história é colocada em uma ficha ou cartão, sendo priorizadas pelos clientes em função da agregação de valor ao negócio. Após a elaboração dos cartões, a equipe de desenvolvimento avalia as histórias e as divide em tarefas, estimando o esforço e os recursos necessários à implementação. Caso o esforço exija mais do que três semanas de desenvolvimento, é preciso que o cliente fatore a história analisada em histórias menores. As histórias que farão parte de cada incremento são selecionadas de forma conjunta por equipe de desenvolvimento e clientes, considerando os seguintes critérios: as histórias de maior risco serão priorizadas, em seguida, as que agregam maior valor ao negócio. Após a implantação da primeira versão do software, é calculada a velocidade do projeto que é o número de histórias de usuários implementadas na primeira release. Essa velocidade serve para avaliar se o compromisso firmado está compatível e auxiliar na estimativa de prazos das versões seguintes.
-
-### PROJETO
-
-Aqui temos a máxima: “Não complique!” A XP estimula a modelagem com cartões [CRC (Classe-Responsabilidade-Colaborador)](https://www.inf.ufpr.br/silvia/ES/requisitos/pdf/CRCAl.pdf), que permitem identificar as classes orientadas a objetos relevantes para a iteração corrente do software. Os cartões CRC são os únicos artefatos de projeto gerados durante o processo XP. Caso algum requisito necessite ser validado em função de sua complexidade, é recomendada a prototipação, como solução pontual, a fim de reduzir o risco dessa especificação no projeto. A refatoração também é estimulada, tendo em vista uma melhor organização do código interno do software sem impactar a sua funcionalidade, o que minimiza as possibilidades de erros.
-
-### CODIFICAÇÃO
-
-A XP sugere que dois programadores trabalhem juntos em um mesmo computador a fim de criarem código para uma história, fornecendo um mecanismo de solução de problemas emtempo real, cabendo a máxima de que duas cabeças pensam melhor que uma, além de garantir a qualidade do código, pois a sua revisão é imediata. Ambos desenvolvedores têm papéis distintos, tal como, uma pessoa implementa o código, outro verifica os padrões de codificação. Quando da conclusão da codificação, esse código é integrado aos demais. A estratégia de integração contínua possibilita a identificação precoce de erros.
-
-### TESTE
-
-Como afirmado anteriormente, a equipe de desenvolvimento avalia cada história e a divide em tarefas, que representa uma característica discreta do sistema. Antes da codificação, a equipe de desenvolvimento elabora os testes de unidades a serem aplicados nas tarefas. A automação desses testes é fortemente recomendada, o que estimula a realização dos **testes de regressão** toda vez que o código for alterado. A estratégia de integração contínua está vinculada aos testes de integração, realizados de forma sistemática a cada novo código gerado a ser integrado, o que permite lançar alertas logo no início, evitando propagações indesejadas. Os testes de aceitação são elaborados pelos clientes com base nas histórias de usuários especificadas anteriormente e que serão implementadas na próxima release. O foco está nas funcionalidades externas visíveis aos clientes. Em outras palavras, os testes verificam se o sistema atende às reais necessidades dos usuários.
-
-
-
-## RESUMINDO
-
-Compreendemos as principais características das metodologias ágeis e, em particular, da Extreme Programming – XP. A partir do questionamento do excesso de formalismo dos processos prescritivos dominantes em meados da década de 1990, foi redigido o Manifesto para o Desenvolvimento Ágil de Software, com quatro valores:
-
-1. Indíviduos e interações, mais do que processos e ferramentas
-2. Software em fucionamento, mais do que documentação abrangente
-3. Colaboração com o cliente mais do que negociação de contratos
-4. Resposta a mudanças, mais do que sequir um plano.
-
-A maioria dos métodos ágeis de desenvolvimento de software tem como foco o software, em vez de formalismos de projeto e documentação, assumem um fluxo de processo iterativo e incremental e apoiam aplicações com requisitos altamente voláteis durante o desenvolvimento. A XP possui um conjunto de valores, princípios e práticas como base aos que assumem a metodologia XP. O processo XP possui quatro atividades metodológicas:
-
-1. O planejamento está fundamentado nas histórias de usuários.
-2. O projeto tem um mínimo de formalismo em função de gerar um único tipo de artefato, os cartões CRC, sendo sugeridas a prototipação e refatoração nessa etapa.
-3. A codificação sugere o trabalho em par de programadores alocados em um único computador, permitindo uma revisão de código em tempo real.
-4. Os testes têm uma característica peculiar, são escritos antes da codificação e aplicados de forma sistemática em ambiente automatizado; na sequência, temos os testes unitários, de integração e aceitação.
-
-# METODOLOGIA ÁGIL SCRUM
-
-O termo Scrum, cujo significado se reporta a um método de reinício de jogada no esporte rugby, foi concebido fora da indústria de software como um estilo de gerenciamento de produtos. A partir de conceitos relacionados com este termo, Jeffrey Sutherland e Ken Schwaber, no início da década de 1990, desenvolveram o denominado [Processo de Desenvolvimento SCRUM](https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf), publicado em 1995. Desde então, esse processo passou a ser aplicado no desenvolvimento de software em todo o mundo.
-
-A metodologia Scrum sofreu, posteriormente, desenvolvimentos adicionais abrangendo o gerenciamento de projetos, não necessariamente relacionados a projetos de software. Entretanto, o Scrum é empregado de forma sistemática no gerenciamento de projetos de desenvolvimento de software, utilizando-se dos valores e princípios do manifesto ágil junto aos conceitos definidos em seu framework. Tal metodologia tem sua aplicação recomendada principalmente quando, em função da complexidade do projeto, não é possível estabelecer todos os requisitos nas fases iniciais do planejamento.
-
-O Scrum possui três pilares fundamentais:
-
-### TRANSPARÊNCIA
-
-A equipe de desenvolvedores deve dispor de um mesmo entendimento dos aspectos significativos do processo com base num padrão, tal como uma linguagem comum referente ao processo.
-
-### INSPEÇÃO
-
-A máxima é “inspeção constante de todos os artefatos”, ou seja, a equipe de desenvolvedores deve sistematicamente inspecionar os artefatos Scrum e o progresso desses, de modo a detectar não conformidades; entretanto, a inspeção não deve ser um entrave à própria execução das tarefas.
-
-### ADAPTAÇÃO
-
-Inclui a adaptação do produto software, que pode sofrer mudanças em função da volatilidade dos requisitos e/ou mudanças da tecnologia, bem como a adaptação do processo em função de alguma falha; os ajustes devem ser realizados o mais rápido possível de forma a evitar a propagação de desvios.
-
-## PAPÉIS NO SCRUM
-
-Uma equipe Scrum é composta pelo **Product Owner** (Dono de Produto), **Scrum Master** e **Scrum team**.
-
-O Dono do Produto, ou **Product Owner**, faz o papel do cliente, determinando os requisitos e funcionalidades que deverão ser entregues, incluindo as suas mudanças, além de manter e comunicar às partes interessadas uma visão clara do projeto e estar disponível para esclarecer eventuais questionamentos.
-
-O **Scrum Master** é o responsável por garantir que as regras do método Scrum estejam sendo seguidas, desempenhando, também, funções de um facilitador na resolução de problemas ou nas interferências externas. O Scrum Master é o mantenedor das regras e dos procedimentos do Scrum durante a execução do projeto, auxiliando a todos da equipe aentenderem seus papéis no processo.
-
-A **Scrum Team**, ou equipe scrum, é multidisciplinar, incluindo os especialistas necessários para desenvolver o produto de forma a não depender de membros externos, tais como programadores, administradores de banco de dados, web designers etc.
-
-## ARTEFATOS SCRUM
-
-Os Artefatos Scrum são concebidos com a finalidade de garantir que as equipes Scrum sejam bem-sucedidas na geração de um incremento. Vejamos os principais artefatos:
-
-- **PRODUCT BACKLOG**
-
- Lista incluindo todos os requisitos ou funcionalidades levantados para o produto, estando sob responsabilidade do product owner; no início do desenvolvimento, são estabelecidos os requisitos inicialmente conhecidos e mais bem compreendidos, evoluindo à medida que o produto e o ambiente em que ele será utilizado também evoluem, ou seja, o product backlog é dinâmico.
-
-- **SPRINT BACKLOG**
-
- Subconjunto de requisitos do product backlog selecionados para determinada iteração, denominada de Sprint; inclui, também, o plano para entregar um incremento do produto e atingir a meta da Sprint, isto é, estabelece quais funcionalidades estarão na próxima versão e o trabalho necessário para a referida entrega, também denominada de “Done”. A equipe de desenvolvimento é a responsável, quando necessário, pelas modificações no sprint backlog.
-
-
-## EVENTOS SCRUM
-
-Os eventos permitem otimizar a organização das inspeções e iterações, sendo por meio deles que os conceitos descritos são postos em prática de uma forma ágil e produtiva. Oseventos permitem, também, a minimização da necessidade de reuniões não contempladas no Scrum. Os eventos possuem um tempo pré-definido com uma duração máxima estipulada denominada de timebox, o que garante uma quantidade apropriada de tempo no planejamento. Vejamos os eventos Scrum.
-
-- **SPRINT**
-
- O **Sprint** corresponde a uma unidade de iteração em Scrum, tendo uma duração (timebox) em torno de um mês, ao final do qual é gerado um incremento de produto em condições de uso pelos usuários finais. Ele possui duração consistente durante todo o desenvolvimento. Cada Sprint inclui as atividades típicas de um processo de desenvolvimento de software, tais como, levantamento de requisitos, análise, projeto etc.
-
-- **REUNIÃO DE PLANEJAMENTO DO SPRINT**
-
- A **Reunião de planejamento do Sprint** permite planejar o trabalho a ser realizado em dado Sprint, sendo esse plano resultado de trabalho colaborativo da equipe scrum. A reunião é limitada a 8h para um Sprint de um mês, dividida em duas partes que, respectivamente, buscam respostas às seguintes perguntas: O que será entregue no incremento resultante do Sprint planejado? Como será alcançado o trabalho necessário para entregar o incremento?
-
-- **REUNIÃO DIÁRIA DO SPRINT (DAILY SCRUM)**
-
- A **Reunião diária do Sprint (Daily Scrum)**, como diz o próprio nome, é um evento diário limitado a 15 minutos, no qual a equipe scrum ajusta as atividades e cria um plano para as próximas 24 horas. Isso é feito inspecionando o trabalho desde a última daily scrum e pela previsão do trabalho a ser feito antes da próxima reunião diária.
-
-- **REVISÃO DO SPRINT**
-
- A **Revisão do Sprint** é realizada no final do sprint para inspecionar o incremento e adaptar, se necessário, o product backlog. Essa é uma reunião informal, e a apresentação do incremento destina-se a obter feedback e a fomentar a colaboração na equipe, não devendo ultrapassar quatro horas para sprints de um mês.
-
-- **RETROSPECTIVA DO SPRINT**
-
- A **Retrospectiva do Sprint** é uma oportunidade formal para a equipe scrum inspecionar ecriar um plano de melhorias a ser seguido durante o próximo Sprint, sendo uma reunião limitada a 3h para sprints de um mês. Os objetivos dessa retrospectiva incluem verificar como correu o último sprint no que diz respeito às pessoas, relações, processos e ferramentas; identificar e ordenar os itens que correram de forma satisfatória e potenciais ajustes; e criar um plano para implementar melhorias no modo como a equipe scrum faz o seu trabalho.
-
-
-## FLUXO DE PROCESSO DO SCRUM
-
-![Fonte : [Lakeworks](https://commons.wikimedia.org/w/index.php?title=User:Lakeworks&action=edit&redlink=1) - Wikimedia Commons](https://upload.wikimedia.org/wikipedia/commons/5/58/Scrum_process.svg)
-
-Fonte : [Lakeworks](https://commons.wikimedia.org/w/index.php?title=User:Lakeworks&action=edit&redlink=1) - Wikimedia Commons
-
-O fluxo de processo Scrum, ilustrado na Figura. Os requisitos que definem as funcionalidades a serem entregues são agrupadas pelo product owner no product backlog.
-
-- **REUNIÃO DE PLANEJAMENTO DE SPRINT**
-
- No início de cada sprint, é realizada a reunião de planejamento de sprint, com a participação do product owner, scrum master e scrum teams, a fim de que sejam priorizados e selecionados os requisitos do product backlog que serão implementados no sprint em planejamento. Esses requisitos são decompostos em tarefas, para cada tarefa é alocado um responsável que realiza a sua estimativa. Ao final da reunião, essas tarefas passam a compor o sprint backlog.
-
-- **DESENVOLVIMENTO DO SPRINT**
-
- Na sequência, a scrum team inicia o desenvolvimento do sprint de acordo com o planejado. No início de cada dia do sprint, a daily scrum permite o compartilhamento, entre os membros da equipe, do que foi concluído no dia anterior e quais as prioridades do dia atual. O scrum master conduz essa reunião.
-
-- **REUNIÃO DE REVISÃO DE SPRINT**
-
- Ao final do sprint, ocorre a reunião de revisão de sprint que permite a geração de um product backlog revisto, sendo definidas as prováveis exigências para o próximo sprint; os requisitos podem ser ajustados em função de sua volatilidade ou de novas tecnologias. Participam dessa reunião o project owner, o scrum master e a scrum team.
-
-- **REUNIÃO DE RETROSPECTIVA DO SPRINT**
-
- A última atividade da iteração sprint é a reunião de retrospectiva do sprint com a finalidade de levantar as lições aprendidas nessa iteração, incluindo os pontos positivos e o que precisa ser aprimorado nas próximas reuniões.
-
-
-## PROCESSO UNIFICADO ÁGIL - AUP
-
-O Processo Unificado Ágil, ou [Agile Unified Process](https://en.wikipedia.org/wiki/Agile_unified_process) (AUP), é uma versão simplificada do [Rational Unified Process](https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process) (RUP). O AUP baseia-se nos seguintes princípios:
-
-- A equipe sabe o que está fazendo. O AUP disponibiliza links de acesso à documentação com muitos detalhes, isso para os que estiverem interessados.
-- Simplicidade. Tudo é descrito de forma concisa maximizando a simplicidade.
-- Agilidade. O AUP está em conformidade com os valores e princípios da metodologia ágil de desenvolvimento de software.
-- Concentre-se em atividades de alto valor. O foco está nas atividades que realmente agregam valor ao cliente.
-- Independência de ferramenta. A recomendação é utilizar as ferramentas mais adequadas, que muitas vezes são ferramentas simples.
-- Customização. O produto AUP é facilmente customizável às necessidades dos seus usuários.
-
-O AUP adota uma natureza serial para o que é amplo, e iterativo para o que é particular. Vejamos a natureza serial do AUP que inclui as mesmas quatro fases adotadas pelo RUP:
-
-- **CONCEPÇÃO**
-
- Tem como objetivos a identificação do escopo do projeto, de uma arquitetura em potencial para o sistema e a viabilidade do projeto.
-
-- **ELABORAÇÃO**
-
- Tem foco na comprovação da arquitetura do sistema.
-
-- **CONSTRUÇÃO**
-
- Visa a construir um software funcional de forma iterativa e incremental que atenda às necessidades das partes interessadas do projeto.
-
-- **TRANSIÇÃO**
-
- Tem como objetivo validar e implantar o sistema em ambiente de produção.
-
-
-Vejamos o processo iterativo do AUP. As atividades que são realizadas de forma iterativa pelos membros da equipe de desenvolvimento para construir, validar e entregar software operacional são as seguintes:
-
-- **MODELAGEM**
-
- Inclui o entendimento do negócio em questão e do problema a ser resolvido pelo software, identificando uma solução; representações UML para os modelos são utilizadas, entretanto, devem ser suficientemente boas e adequadas, ou seja, o mínimo de formalismo.
-
-- **IMPLEMENTAÇÃO**
-
- Transformação dos modelos em código executável, realizando os respectivos testes básicos, tais como testes unitários.
-
-- **TESTES**
-
- Realização de uma avaliação objetiva a fim de garantir a qualidade, incluindo a detecção de defeitos, a validação funcional e a verificação de que os requisitos são cumpridos.
-
-- **IMPLANTAÇÃO**
-
- Planejar e executar a entrega do software operacional aos usuários finais e na obtenção de feedback dos usuários.
-
-- **GERENCIAMENTO DE CONFIGURAÇÃO**
-
- Garantir o acesso aos artefatos do projeto, incluindo o rastreamento das diversas versões,bem como o controle e gerenciamento de suas alterações.
-
-- **GESTÃO DE PROJETOS**
-
- Planejar, monitorar e controlar as atividades do projeto a fim de que ele seja entregue no prazo, dentro do orçamento e atendendo as expectativas dos usuários.
-
-- **AMBIENTE**
-
- Atua em apoio às demais atividades, garantindo a infraestrutura do processo que inclui padrões, ferramentas e outras tecnologias de suporte disponíveis à equipe. Importante destacar que a adoção do AUP requer a aceitação prévia dos conceitos, valores e princípios relacionados com o desenvolvimento ágil.
-
-
-## RESUMINDO
-
-Destacamos os processos de desenvolvimento ágil Scrum e Processo Unificado Ágil (AUP). O Scrum é uma metodologia que possui uma destacada aplicação em projetos de software. Existe a possibilidade de aplicarmos a metodologia Scrum no gerenciamento de projeto ágil de software ou como processo ágil de desenvolvimento de software. Como todo processo ágil, aplica o fluxo de processo iterativo, sendo cada iteração denominada de sprint e, ao final de cada um destes, é gerada uma entrega, isto é, um software operacional. O método AUP tem suas origens no Processo Unificado (RUP), podendo ser considerado uma versão simplificada em função de sua adesão aos valores e princípios das metodologias ágeis. As fases do projeto permanecem as mesmas do RUP, tais como, concepção, elaboração, construção e transição. As mudanças significativas estão nas atividades iterativas compostas de modelagem, implementação, testes, implantação, gerenciamento de configurações, gestão de projetos e ambiente.
-
-Para saber mais sobre os assuntos tratados neste tema, leia:
-
-- [Engenharia de Software, Sommerville](https://www.facom.ufu.br/~william/Disciplinas%202018-2/BSI-GSI030-EngenhariaSoftware/Livro/engenhariaSoftwareSommerville.pdf).
-- [Princípios de Análise e Projeto de Sistemas com UML](https://www.tecgraf.puc-rio.br/ftp_pub/lfm/EduardoBezerra-PrincipiosAnaliseProjetoSistemasComUML-2aEd.pdf)
-- [Engenharia de Software Moderna](https://engsoftmoderna.info/)
-
-Cursos gratuitos:
-
-[Princípios de Desenvolvimento Ágil de Software](https://www.coursera.org/learn/principios-de-desenvolvimento-agil-de-software)
-
-[Desenvolvimento Ágil com Padrões de Projeto](https://www.coursera.org/learn/desenvolvimento-agil-com-padroes-de-projeto)
-
-[Desenvolvimento Ágil com Java Avançado](https://www.coursera.org/learn/desenvolvimento-agil-com-java-avancado)
-
-[Software Engineering: Introduction](https://www.edx.org/learn/software-engineering/university-of-british-columbia-software-engineering-introduction)
\ No newline at end of file