[Música] o olá eu sou professor marcelo campeonato essa é a aula número 5 da disciplina de gestão da informação nós vamos começar agora um ciclo de de algumas aulas que vão tratar do mesmo assunto esse assunto é nestas duas metodologias de desenvolvimento de sistemas de informação nas aulas anteriores em vários momentos é eu estar aqui pra vocês a importância dos sistemas de informação dentro da gestão da informação são os sistemas de informação que dão um apoio computacional ao gerenciamento das informações e por consequência a tomada de decisões e inclusive sistemas de informação projetado e desenvolvido
especificamente para a tomada de decisão a gente chama isso de sistemas de tomada de decisão o sistema de apoio à tomada de decisão bom essa área de sistemas de informação ela tem uma sobreposição bastante grande com a gestão da informação é importante que a do ponto de vista de desenvolvimento a equipe que vai desenvolver um sistema de informação sabe exatamente quais são os requisitos de a da gestão da informação e por outro lado quem trabalha diretamente com a gestão da informação precisa saber das características do desenvolvimento de um sistema de informação porque em geral eles
são os clientes da equipe que desenvolve sistemas de informação nós temos diferentes tipos de sistemas de informação diferentes naturezas focado em questões que em que a tomada de decisão ela aparece de uma forma implícita quase todo o sistema de informação ele por definição envolve tomadas de decisão porque o sistema de informação por definição ele envolve as próprias pessoas que vão usar o sistema e essas pessoas precisam tomar decisões diariamente a a usar esse sistema agora alguns sistemas de informação eles são estritamente designados para apoiar a tomada de decisão nós estamos aqui preocupados um pouco mais
com esse tipo de sistema do que os outros sistemas de propósito geral mesmo que eles cubram a tomada de decisão de alguma forma então nessa aula nós vamos começar com o assunto metodologia e desenvolvimento de sistemas de informação pensando ah o objetivo de apresentar uma visão geral né o que são metodologias de desenvolvimento de sistemas de informação então aqui apenas recapitulando o que eu já adiantei existem diferentes tipos de sistema um desses sistemas é são sistemas de informação e aí e esse tem totalmente uma relação com a gestão da informação nós vamos trabalhar agora bom
como é que se desenvolve sistemas de informação sistemas de informação ele é basicamente um software é mais do que software porque ele vai rodar no hardware ele vai ter usuários como parte dele que vão esses usuários seguem alguns procedimentos mas o principal é o software que existe dentro desse conjunto de componentes formando um sistema de informação para desenvolver o software existe uma grande área dentro da computação chamada engenharia de software da mesma forma que a engenharia da produção de uma forma maior ela se preocupa com a uma série de atividades relacionadas à produção de uma
organização e para isso e isso deve ser feito de uma forma bastante sistemática por isso que nós chamamos de engenharia e e o que está sendo produzido é especificamente um software um sistema nós também temos que ter um conjunto de conjunto de atividades sistemáticas para desenvolver o tema aí nós damos o nome de engenharia de software então vocês engenheiro futuro engenheiro de produção podem olhar à engenharia de software de dois aspectos diferentes um deles é é um produto desenvolvido você aplica engenharia de software para a produção de algo assim como você tem engenharia da produção
de uma forma mais genérica engenharia de software seria uma produção mais específica agora nessa disciplina especialmente nós estamos preocupados na engenharia de software engenharia de software que ela que é usada para desenvolver sistemas de informação que vão possibilitar a gestão da informação bom e o que é a engenharia de software adiantei já né é um conjunto de conceito técnicas métodos processos ferramentas ou seja uma série de coisas que fiz tematicamente podem ajudar a desenvolver um sistema de informação ea gente costuma juntar todos esses conceitos dentro do que nós chamamos modelo ou metodologias de desenvolvimento que
é justamente o nome dessa aula metodologias de desenvolvimento de sistemas de informação existem diferentes modelo que a gente pode por exemplo o chamado modelo de ciclo de vida que dá um direcionamento de como desenvolver um sistema de informação nessa aula como a gente está tratando uma visão geral dessas metodologias eu apresentar para vocês alguns desses modelos primeiramente o modelo em cascata o modelo em cascata representado por essa imagem aqui é também chamado de ciclo de vida clássico ele organiza as diferentes atividades dentro da engenharia de software sendo que uma é executada depois da outra e
você não volta por isso é chamado de modelo em cascata porque é como se você estivesse descendo uma cascata uma cachoeira ea cada passo dessa cascata que você está descendo você tem diferentes atividades da engenharia de software sendo desenvolvidas esse modelo dificilmente ele é usado hoje em dia na prática porque dificilmente você passa por uma para uma próxima etapa sem voltar para lá o anterior aqui nós estamos só para deixar mais claro não estamos falando de engenharia de requisitos então a primeira coisa é você define os requisitos depois há a desculpa que a engenharia de
sistema que é você pensar no sistema como um todo e depois da engenharia de de requisitos do software então lembra o software é um dos principais componentes do sistema de informação mas também pode ter hardware também pode ter pessoas procedimentos então num primeiro momento você pensa nos requisitos do sistema e depois nos requisitos do software uma vez que você sabe quais são os requisitos do software então você vai fazer o projeto do software chamado aqui de design você vai projetar como software tem que ter a mesma forma que um alguém vai construir um edifício você
tem o projeto projeto arquitetônico projeto hidráulico projeto elétrico você tem que que vai dizer como aquele espírito tem que ser construído nós também temos o projeto do software que diz como aquele software tem que ser construído depois nós construímos um software propriamente dito que é o que ele chama de programação do software ou modificação elas têm os programadores e testa a esse teste pode ser primeiro aqui relacionado à atividade mais direta de programação e depois de um teste maior que é o teste do sistema como um todo por sim uma vez que você testou você
implanta sistema o sistema está bom e aí você entra em operação e aí você tenha manutenção do software em execução do sistema na verdade em execução porque esse modelo em geral hoje ele não é usado porque pensa se durante a hotel de sistema eu pego um problema o que acontece você precisa voltar na programação para poder corrigir o problema ou o problema talvez nem foi de programação foi de projeto então você precisa voltar no projeto ou de repente você ainda nem está acertando atestando ainda mais durante a própria programação você pegou um problema de projeto
você precisa voltar para reprojetar às vezes o problema não é do projeto o requisito é que estava mal definido então diferentes pontos você pode precisar voltar para a engenharia de requisitos que o problema pode ser ainda mais alto pode ser a engenharia do sistema na prática na prática esse modelo que existiu ele só foi uma forma teórica de você representar esse fico aqui desde as primeiras vezes quando esse modelo foi apresentado na prática sempre deveria ser possível conseguir voltar pro etapa anterior depois nós temos um outro modelo que é bastante usado hoje em dia que
é a um modelo que a gente chama de incremental e interativo n tem um conceito geral genérico né incremental significa você fazendo software aos poucos e interativo significa que você e dizem que um conjunto de atividades várias vezes para chegar no software final então a o incrementar o interativo estão altamente relacionados existem diferentes propostas de modelos de ciclo de vida incrementais e interativos o mais famoso é o rup cup é de resto na univag prótese é uma empresa que atualmente foi comprado é que atualmente pertence a ibm então na verdade é o ibm hope esse
processo ele define uma série de interações está representado aqui ou seja são interações onde você em que você executa a mesma coisa várias vezes por exemplo cuidado requisitos cuidade análise e projeto cuidar da implementação do teste então em cada interação você faz requisitos análise implementação o teste aí você começa de novo requisitos análise implementação o teste de novo equipe de análise de novo e assim vai e assim por diante então em cada interação você faz tudo em cada final de interação você desenvolveu um pedacinho do software dependendo se você está nas primeiras interações aqui no
meio ou no fim você pode fazer tudo mas como ênfase diferente então por exemplo logo no início as primeiras alterações vão ter uma em fase bastante grande nos requisitos um pouco depois os requisitos caem ea ênfase maior em projeto aqui na frente à entrada do maior é na implementação propriamente dita teste você vai fazendo desde o início está pequeno aí lá no fim onde você tem a maior contribuição do ponto de vista de teste então embora seja várias interações de uma forma a você fazer tudo em cada interação fazer um pouco de cada coisa na
prática olha você faz isso aqui na prática você está fazendo requisitos do projeto implementando testando implantando mas na verdade em cada interação você faz um pouco de cada a questão ea ênfase em bonn esse é um modelo bastante usado ele é um considerado modelo um pouco pesado porque você tem uma certa burocracia a trabalhar nele bom plano na unidade mas vou pra casa depois da volta vou aproveitar que esse que a gente chama de modelo ágil é justamente a esses modelos que eu chamo de pesados porque ele tem pouca burocracia a idéia é que você
tenha equipes pequenas desenvolvendo softwares de uma forma mais ágil sem muita burocracia então o próprio modelo do processo do ciclo de vida ele é feito de uma forma mais simples basicamente você tem um conjunto de requisitos a partir desse requisito você definir atividades a serem feitas você executa essas atividades de duas a quatro semanas sempre tentando fechar cada 24 horas gerando alguma coisa e ao final você tem um software pronto mas a cada duas a quatro semanas você escolheu alguma coisa para desenvolver ele também é incremental e ele também é interativo porém com uma burocracia
menor isso geralmente funciona para a equipe pequenos softwares não tão complexo agora se você tem um software altamente complexo sendo desenvolvido uma equipe de 100 200 pessoas dificilmente a metodologia ágil vai essa é a melhor opção ela pode ser uma opção mas pode não ser a melhor opção porque você tem muitas pessoas envolvidas o sistema é formado por vários módulos vários componentes você precisa de ter um modelo um ciclo de vida mais estruturado e que por consequência é mais burocrático é uma forma de v mas cada caso acaba sendo um caso você precisa porque é
bom você conhecer diferentes metodologias para você saber quando usá la é uma outra forma de você vê os processos incrementais interativos é através do que a gente chama de modelo em espiral porquê porque ele forma essa espiral aqui da mesma forma em quatro grandes áreas então determinar objetivos tem a ver com os requisitos identificar e resolver riscos têm um foco grande esse modelo no gerenciamento do projeto você tem que identificar e resolver o risco daquele projeto desenvolver e testar propriamente dito e planejar a próxima e ter ação então você começa a uma espiral no início
você faz um pouquinho de riscos um pouquinho de desenvolvimento e teste planeja próximo e comércio próximo definir o que você quer fazer é definir tem riscos trata e vir desenvolve testa propriamente dito planejar o próximo em cada uma dessas espirais você está tratando você está aumentando o tamanho do software que você está desenvolvendo ele é mais detalhado aqui a parte do desenvolvimento e tem a sua própria mente dito onde aquelas atividades elas começam a aparecer de forma mais clara por exemplo requisitos modificação integração teste enquanto mais longe do centro da espiral você está mais atividades
de engenharia de software propriamente dito você faz planejar a próxima geração e identificar e resolver risco atividades - técnicas são atividades de gestão e de determinados objetivos também é um pouco mais de gestão a parte técnica mesmo é como se tudo aquilo que a gente viu nessa primeira segura aqui esse conjunto de atividades que são esse conjunto primeiro aqui olha essa parte aqui ela também é de gestão do projecto e esta parte a parte técnica e aqui então a parte técnica está concentrada ac e as outras três partes da da espiral é a parte gerencial
e último modelo é o que se chama de modelo em ver porque ele forma e se vê aqui é uma forma de representar não só os outros já não façam isso mas aqui esse modelo deixa claro que você tem várias atividades de construção e depois várias atividades de testes em diferentes níveis do sistema de integração e testes de unidade nós vamos ver um pouquinho melhor as próximas aulas então significa que você define projeta projeto mais detalhado implementa uma vez você implementou você testa cada unidade baseada no projeto detalhado depois você tem essa casa integração baseada
no projeto de alto nível e depois você tem o sistema como um todo e então cada nível de teste ele está relacionado a diferentes tarefas de desenvolvimento até chegar na implementação propriamente dito por isso a gente chama de modelo em ver aqui a gente pensa que ele está querendo construir o software e aqui no teste nós queremos destruir o software é o objetivo do teste é tentar destruir se não conseguir destruir é porque o software foi bem desenvolvido bom com isso nós temos então um resumo de diferentes metodologias de desenvolvimento de sistemas de informação novamente
muito úteis no contexto de gestão da informação porque vocês passam a perceber de uma forma mais clara como os sistemas que vão automatizar apoiará a a tomada de decisão e gestão da informação eles devem ser desenvolvidos por exemplo é muito claro o enfoque na engenharia de requisitos porque porque é importante saber o que os clientes querem no caso os gestores de informação e os tomadores de decisão [Música] ronan [Música] [Música] [Música]