[Música] lomba olá eu sou professor marcelo fantinato é ter disciplina de engenharia de software do curso de engenharia da computação da univesp aula número 2 processo unificado no final da aula número 1 eu comentei com vocês que a gente ia falar ainda do método método lages vai tratar um pouco uma visão geral dos métodos vagas mas ainda não é nessa aula nesta aula a gente vai tratar do processo unificado que é seguindo aquela evolução histórica dos modelos de processos de software que é pra gente poder tratar como as coisas foram evoluindo para dar enfim nós
chegarmos na ideia dos métodos haja um processo unificado é muito importante nessa evolução o processo unificado ele tem uma uma ligação muito forte com a linguagem o ml que é uma linguagem que vocês já devem ter ouvido falar em alguma outra disciplina é provavelmente até mesmo antes do curso em que você está fazendo agora engenharia da computação caso vocês já tenham trabalhado com computação com software antes do primeiro contato que vocês estão tendo com softwares talvez em outras disciplinas vocês já tenham trabalhado com isso mas enfim pra gente tratar então do processo unificado que é
um mais um modelo de processo de software vamos então tratar a primeira coisa com a questão de mudanças lidando com mudanças que não adianta vocês é um uma das da um dos focos do método vargem nós vamos mas enfim mudança é inevitável em grandes projetos significa mudanças nós estávamos falando de o clima o que o cliente que é cliente quer um determinado conjunto de coisas com software farsa e o que acontece é que com o passar do tempo ele muda de opinião às vezes ele simplesmente muda de opinião às vezes ele nem sabia o que
queria exatamente quando ele percebe que o que ele queria era diferente ele muda então é isso que eu queria da outra coisa então essas mudanças elas vão ocorrendo além disso há algum tipo de pressão externa pode surgir no negócio então o cliente sabia que ele queria pediu aquilo mas em algum momento mudou o negócio mudou o ambiente mudou o mercado então ele muda mesmo de opinião não é que ele não sabe ele sabia mas mudou a então às vezes não sabia pediu errado mas ele sabia mas mudou a a prioridade que ele tinha pode mudar
ele pediu uma série de 50 requisitos e aquilo que ele pediu a bola e se fosse só faz de tempo de repente aquilo passou a ser a maior prioridade por algum motivo alguma tecnologia nova surgiu não era possível fazer uma determinada coisa passou a ser possível então mudou alguma coisa no projeto como um todo novos projetos surgiram então aquele projeto que você estava colocando muito esforço passa a não ser a sua prioridade enfim muitas mudanças podem acontecer uma empresa que está desenvolvendo software num outro alguma mudança em termos de lei pode acontecer um regulamento uma
legislação dependendo do sistema que está sendo desenvolvido um sistema bancário por exemplo uma nova legislação surge e aí algum tipo de requisito tem que mudar ou seja essas mudanças que acontece elas vão acontecer necessariamente elas vão salvar algum tipo de custos essas mudanças acontecem cedo no processo de desenvolvimento que bom você faz um assunto segue as jantes suína e o prédio já foi construído chega lá na frente de uma sacada do apartamento bom neste momento pensando no prédio é uma coisa física provavelmente não vai ter como alterar mas o software é algo é não consegue
alterar você consegue fazer uma funcionalidade adicional só que vai custar caro porque você já tá com uma série de coisas feitas no software para você adicionar uma funcionalidade para você alterar embora seja possível você tem que mexer em muita coisa que você soubesse desde o início que aquela funcionalidade era necessário sairia bem mais barato bom isso para tentar evitar que as coisas sejam caras você pode por exemplo fazer protótipos para que serve um protótipo você faz um protótipo mostra o cliente é isso mesmo que você quer então você já consegue evitar um tipo de custo
o cliente olha só não não é bem isso não é isso que se sentiu não é isso então vai ter uma série certo conflito ali mas em algum momento vocês vão chegar a uma conclusão ok então o que você quer realmente é isso é tá bom então vamos adiante mas teve um certo custo o custo foi pequeno você também pode ter entrega incrementais não só não não o protótipo mas realmente uma entrega oficial e aí com essa entrega oficial que você vai ter nem fazendo aos poucos você também vai perceber o problema de uma forma
que você não deixe para pegar os problemas só lá na frente então você pode ter um modelo um outro exemplo de um modelo de processo de software que é baseado e desenvolvimento de protótipo então você vai desenvolver um protótipo o próprio nome protótipo ele é muito característico da idéia do que ele significa você faz o protótipo para mostrar ao cliente a palavra proposta significa isso você estabelece objetivos do protótipo você define que funcionalidade protótipo tem você desenvolve e você avalia e aí esse protótipo vai servir então para você melhorar os requisitos e você evitar que
lá na frente face descubra que evitam problemas você também tem a entrega e incrementar você pode ter a entrega incremental significa que você vai ter um fim começa aqui continua chega aqui você pode começar novamente você pode ficar fazendo isso aqui ter lá o que for que não todo 90 ali até que em algum momento você termina então de pagar aqui pra gente mas olha você tem uma etapa anterior é a fazer o planejamento básico e aí você começa a desenvolver os incrementos em algum momento você pergunta já finalizei vou fazer novos incrementos novos incrementos
novos incrementos em algum momento é matar completa está então acabou então você vai desenvolvendo esse incremento percebam que isso eu não tenho um ano aqui quando esse modelo foi proposto mas basicamente já adiantando isso é muito parecido com o que nós temos métodos usados que surgiu a partir do ano 2000 mas antes do ano 2000 nós já tínhamos a idéia de você desenvolver baseado incremento a diferença é que com os métodos da gente e isso passou a ter um foco maior em conjunto com outras idéias outras idéias da filosofia do método lazio ainda pensando na
idéia de protótipo junto com outras coisas nós temos um modelo ainda mais complexo em termos de desenho mas a filosofia é pra juntar tudo isso que é você ter os implementos terá de ter ações em que você vai exibir tentando evitar que os problemas sejam pedro fala na frente então você tem que a gente chama de modelo espiral de 90 a 88 a 88 em que você vai tendo os objetivos alternativa de restrições definir quais são o objetivos alternativa de restrições você avalia isso que você definiu você desenvolve propriamente dito avalia e planeja a próxima
fase então você começa aqui por exemplo analisa risco faz um protótipo verifica a operação e planeja próxima de novo sempre aqui nesse ciclo você sempre analisar riscos faz um protótipo analisa ir para outro protótipo analisa que escutar outro protótipo e aqui nesse conjunto é onde você desenvolve propriamente dito cada vez que você passa você vai desenvolver melhor até que no final você já está fazendo detalhado codificando testando um novo teste mais um teste mais detalhado e colocar em operação enfim é um modelo em que em cada quanto mais você está evoluindo você está fazendo atividades
mais complexas não vou entrar no detalhe de todas as etapas aqui mas está bastante explicado na bibliografia que vocês têm a festa bom e aí nós chegamos então no processo unificado propriamente dito esse processo unificado ele é de uma empresa chamada rancho não na verdade ele é da empresa e bm a ibm comprou ashton então para ser mais correto de ibm ok mas ele é chamado de ruppy ele começou na verdade ele foi chamado e foi proposto como n pró séries como empresa comprou esse processo e depois a ibm comprou a empresa histórico esse modelo
também com mais cuidado na bibliografia ele é um modelo híbrido basicamente ele foi proposto em 2003 e ele foi muito de tudo que era visto como bom dos modelos anteriores ok por exemplo prototipação incremental e interativo e aí ele junta três perspectivas diferentes ele tem uma perspectiva dinâmica que nós chamamos de fase uma perspectiva estático que são as disciplinas ou atividades e uma perspectiva prática que são boas práticas ele é resumido nessa figura ok então as disciplinas são basicamente as disciplinas as fases que nós já temos falado nas anteriores basicamente requisitos análise e projeto ou
design é uma palavra também traduzir que é o design porque o projeto em português significa outra coisa além de design a implementação o teste implantação tem uma anterior ao requisito que costuma ser opcional que a modelagem de negócios e 3 ac de gerenciamento gerenciamento de mudança e configuração gerenciamento de projetos gerenciamento de ambiente mas enfim com o modelo do rup ele tem com uma duas três quatro em 67 899 atividade e existem as aves a fase de iniciação iniciando seu projeto de elaboração com quatro podem ter várias interações normalmente há uma interação só na transição
é uma interação só na elaboração costuma ter duas ou três gerações de duas três quatro interações e aí vocês percebam pela segura parte colorida e dependendo da interação que você tá tem um foco maior ou menor em diferentes atividades então por exemplo no início você tem um foco maior na iniciação e requisitos e praticamente nada em implementação no final no meio você tem bastante implementação mas praticamente mais nada de modelagem de negócios em só um pedacinho de requisitos que você só está ajustando aqueles que tenham em mudar no final enfim eu asseguro a vocês percebam
que é mais ou menos assim o foco no iene no início mais as primeiras atividades e no final mas as últimas atividades bom então aqui nós temos a perspectiva dinâmica que são as fases a estática que são as disciplinas e nós ainda temos a prática que são as boas práticas antes disso nós temos para cada uma dessas disciplinas por exemplo o evento de requisitos do golpe dar um fluxo de trabalho por exemplo requisitos que é essa aqui olha aqui é o fluxo então você tem um detalhe como tratar requisitos a você vê ele começa por
aqui você verifica é um novo sistema ou é um sistema existente há como o novo sistema analisa o problema depois você compreende as necessidades dos envolvidos depois você pergunta o problema está incompleto que tiver começa de novo senão você vem definir o sistema aí você gerencie ficou enfim fluxograma que ele te dá a ideia do que você pode fazer você não é obrigado a farinha você não é obrigado passa vez esse é um dos problemas chave você não é obrigado não é obrigado porque uma das grandes críticas do que a gente está hoje em engenharia
de software tradicional é que quando as pessoas olham isso olham ifo ver que cada um desses para cada uma dessas atividades o modelo você não é obrigado a isso é um exemplo é um modelo você olha aquilo a qual parte disso é bom para minha empresa parte disso é bom para o meu caso existe um exemplo de glossário template quero isso pra mim eu preciso de um evento de um plano é importante se eu quero eu quero aquele exemplo de algo mais simples ao mais complexo modelo o único trabalho que você deve ter em algum
momento para avaliar aquilo e ver o que você precisa é que você não precisa e eventualmente fazer os ajustes necessários isso agora o trabalho a ciência se você acha que avaliar o modelo dá muito trabalho e você não quer e então tá bom então física fala não vou ter esse trabalho agora não é pra você olhar para aquele falar é muita coisa para minha empresa fazer imagina cada software foi desenvolver eu tenho que passar por todas as etapas e não precisa ninguém falou pra você em nenhum livro está escrito que você tem que fazer tudo
aquilo a mais o processo é enorme tem um monte de atividade muito dinheiro de de artefatos para elaborar um monte de documento eu vou ficar três anos só elaborando o documento nunca desenvolveu o software ninguém você tem que fazer isso então esse é uma é uma das grandes alavancas que vitima engenharia de software tradicional e deixa um livro deste tamanho o livro sommerville a pessoa abre e fala assim é festa mas não vou fazer tudo isso me mandou fazer tudo isso são as idéias pra você olhar e ver o que você acha que é interessante
para sua organização eu não vou falar mais nisso durante o resto da disciplina também vai acabar falando mas não tem essa intenção mas o hulk é bastante completo temática idéias pra montar o seu processo de software de uma forma incremental cada incremento para interação desenvolve um pedacinho do software e segue adiante a bom e aí você tem para cada uma dessas tarefas o saque para cada um de construir para cada pessoa que vai fazer algo no sistema para cada é a atividade mais específica você pode ter uma boa prática alguma ideia algum tipo de técnica
por exemplo algumas boas práticas para a qual foi escolhida que só para fazer ir pra essa pressa que olha para a atividade compreendendo a pagar essa atividade a compreender as necessidades dos envolvidos aí o hulk em algum momento fala assim olha eventos de coisas que você pode fazer para compreender as atividades desenvolvidas você pode também em entrevistas você pode fazer é o workshop de requisitos você pode fazer um brainstorm de filtro de idéias você pode fazer workshop caso de uso você pode fazer encenação você pode fazer a interpretação de papéis você pode fazer análise dos
requisitos existentes e ele não só dá o nome ele não é um texto de eventos ltda idéias ferramenta para você vai ver essas coisas você lê você fala nós é legal a vou fazer vou tentar acho que não funciona é só uma idéia são exemplos de boas práticas bom enfim é essa é a idéia do rup e foi criado em 2003 ele foi adaptado por muitas organizações existem vários casos de sucesso existem organizações que já publicaram as suas adaptações que podem ser um caminho mais rápido para as outras organizações usarem como exemplo seria uma forma
de caminho das pedras é mas dificilmente vai servir é tal e qual para outras organizações que cada organização é diferente da outra então o ideal mesmo é que cada uma a vale e tome a sua própria decisão agora sim eu acho que a gente está no momento pra se aproximar mais do método da ásia obrigado [Música] [Música] [Música] [Música] ana
