ESTRATEGIAS de DESENVOLVIMENTO de APLICAÇÕES

Tamanho: px
Começar a partir da página:

Download "ESTRATEGIAS de DESENVOLVIMENTO de APLICAÇÕES"

Transcrição

1 ESTRATEGIAS de DESENVOLVIMENTO de APLICAÇÕES Arquitetura Tecnológica A arquitetura tecnológica da informação descreve um plano estrutural de longo prazo, abrangendo toda a organização, que define investimentos e trata da organização da tecnologia da informação. A arquitetura para uma firma de publicidade de 30 empregados, por exemplo, pode envolver PCs interligados em rede, cada um carregado com software de processamento de texto, apresentação e correio eletrônico,etc. A arquitetura de uma organização determina os tipos de equipamentos que ela deve adquirir, os tipos de software que deve usar e a tecnologia de telecomunicações que ela deve comprar. As decisões sobre a arquitetura envolvem, também, decisões sobre padronizações e desempenho global. A arquitetura pode especificar o estado atual e futuro da infra-estrutura, assim como um plano de transição para alcançar o estado desejado.. Nem todas as organizações desenvolvem uma arquitetura de tecnologia da informação. Muitas empresas, ao contrário, tomam as decisões de investimento projeto a projeto. Embora uma arquitetura aumente a probabilidade de que a organização tome decisões coordenadas que expressem sua estratégia de longo prazo, o desenvolvimento de uma arquitetura custa tempo, esforço e dinheiro. A arquitetura pode reduzir a flexibilidade da organização para responder às mudanças tecnológicas. Depois que a organização implementa planos de arquitetura e adquire a tecnologia que a arquitetura prescreve, Arquitetura de Aplicações A arquitetura de aplicações de uma organização trata de seu portfólio de software. A arquitetura de aplicações identifica os sistemas existentes, suas forças, fraquezas e interdependências. Ela especifica a política corporativa sobre o desenvolvimento de aplicações deve ser centralizado, descentralizado ou terceirizado. Ela pode especificar as metodologias a serem usadas no desenvolvimento de novas aplicações. Ela deve, também, abordar como as decisões são tomadas a respeito de qual software rodar internamente e qual terceirizar. A arquitetura de aplicações deve identificar as prioridades para o desenvolvimento de novas aplicações. Sistema de Informação Centralizado Um sistema de informação centralizado (SIC) é aquele executado em uma coleção de máquinas, que se utiliza de seus recursos individuais e possui uma máquina servidora que centraliza todas as informações. São sistemas que possuem pouco poder de processamento sequencial (tempo compartilhado) e necessitam de um mainframe para que possa funcionar com qualidade. Porém, por maior que seja a velocidade de processamento de um mainframe, ele jamais conseguirá alcançar o poder de processamento de vários microcomputadores interligados, como se fosse um único sistema. Existem três modelos de sistemas centralizados: Monousuário, Cliente-servidor (duas camadas) e Multicamadas. Como características do cliente servidor, geralmente, são utilizadas as máquinas clientes com pouca capacidade e um servidor robusto. Uma outra forma de especificar essa característica é utilizando a expressão servidor gordo e cliente magro. As regras de negócio ficam armazenadas no próprio banco de dados por views e storage procedures. No cliente, fica somente a interação do sistema com o usuário, as chamadas interfaces, como as telas e os relatórios. Já o sistema Multicamadas é uma melhoria do cliente servidor (duas camadas), em que são separadas as regras de negócio, a interface e o banco de dados.

2 A segurança é um ponto fundamental em qualquer sistema de informação e uma das vantagens dos sistemas centralizados é que eles possuem um único host que fornece alto grau de segurança, concorrência e controle de cópias de segurança e recuperação. Ao contrário dos sistemas distribuídos que é mais fácil acessar os dados, o que dificulta garantir a segurança dos dados existentes e a privacidade dos dados secretos. Além disto, em um sistema centralizado não há necessidade de um diretório distribuído, já que todos os dados estão localizados em um único host. Porém todos os acessos aos dados realizados por outro que não seja o host, onde o banco de dados está, gera alto custo de comunicação. O host em que o banco de dados está localizado pode ainda criar um gargalo (diz-se que um elemento é o gargalo quando limita o desempenho do sistema), dependendo da quantidade de acessos simultâneos. Podem acontecer também problemas de disponibilidade dos dados, se o host, onde os dados estão armazenados, sair do ar. Sistema de Informação Distribuído Os sistemas de informação distribuídos ficaram mais populares depois da explosão da Internet em 1993 e, desde então, estes sistemas não param de crescer, tanto no meio acadêmico como no meio comercial. A principal motivação na construção de um sistema distribuído é o compartilhamento de recursos tais como: impressoras, arquivos, páginas web, acesso a banco de dados distribuídos, etc., porém, é muito mais do que isto; um SID é um conjunto de processos concorrentes acessando recursos distribuídos, os quais podem ser compartilhados ou replicados, através de troca de mensagens em um ambiente de rede. Durante décadas, pesquisadores e profissionais enfatizaram a importância destes sistemas, muito utilizados atualmente, principalmente em ambientes que necessitam ter escalabilidade, alto desempenho, tolerância a falhas e heterogeneidade. A segurança das informações em qualquer sistema é extremamente importante, pois é ela que garante que o sistema conseguirá fazer aquilo pelo qual foi projeto, de maneira correta e para os usuários corretos. Muitas informações mantidas ou que trafegam em sistemas distribuídos são sensíveis e sigilosas, portanto sua segurança é fundamental e consiste em três aspectos: confiabilidade, integridade e disponibilidade. Uma característica marcante dos sistemas de informação distribuídos, que são construídos a partir de uma variedade de redes, sistemas operacionais, hardwares e linguagens de programação variadas, é a transparência, cujo objetivo é tornar certos aspectos da

3 distribuição e da funcionalidade do sistema invisíveis ao usuário, parecendo não existir, quando na verdade existem. A transparência é o atributo que esconde de usuários/aplicativos detalhes de funcionamento do sistema distribuído, de tal forma que exista a impressão de se tratar de um sistema centralizado. Os SIDs possuem grande tolerância a falhas, ou seja, grande capacidade do sistema sobreviver a falhas em algum dos seus elementos. Uma falha em algum tipo de componente poderá ocorrer o isolamento do mesmo e dos computadores dependentes, mas não impede que o resto do sistema continue funcionando normalmente. Além de todas estas características dos sistemas de informação distribuídos, podemos destacar a economia que este sistema oferece. Isto porque, um sistema de informação centralizado de grande porte, necessita de um mainframe para que possa funcionar perfeitamente. Quando se utiliza um sistema distribuído em substituição a um sistema centralizado, pode-se substituir o mainframe por vários microcomputadores, onde é acrescentado um poder computacional de processamento de baixo custo, sendo mais viável economicamente. Isto porque o custo de um mainframe é bem mais alto que o custo de processamento por servidores distribuídos.

4 As Ferramentas CASE A tradicional expressão "em casa de ferreiro espeto de pau" pode aplicar-se com alguma propriedade aos desenvolvedores de aplicações: tal como o ferreiro não utilizava utensílios para facilitar o seu trabalho, uma parte significativa da atividade de desenvolvimento de software foi sempre realizada com apoio reduzido de ferramentas. Nos últimos anos tem-se procurado corrigir esta situação, e um bom exemplo disso é a utilização de ambientes de desenvolvimento integrados. No entanto, a maioria destes ambientes concentram a sua atenção na fase de implementação do software, proporcionando um reduzido suporte à sua fase de concepção. Introdução O acrônimo CASE tem tido, ao longo do tempo, diversas interpretações, se bem que a mais utilizada e referida na literatura é a de Computer Aided Software Engineering, o que, numa tradução literal, significa "Engenharia de Software Auxiliada por Computador". Se relativamente ao significado das letras iniciais C e E existe algum consenso, o mesmo não acontece com as outras duas letras, cujos diferentes significados podem ser observados Figura Antes de apresentamos a nossa definição do conceito CASE, vale a pena constatarmos as opiniões que outros "pensadores" sobre o assunto emitiram anteriormente: B. Terry [Terry90]: "CASE designa um conjunto de ferramentas que auxiliam um programador ou um gestor de projetos durante uma ou mais fases do processo de desenvolvimento de software, incluindo a manutenção". Carma McClure [McClure89]: "Uma combinação de ferramentas de software e de metodologias de desenvolvimento estruturadas". Esta definição reflecte claramente o momento histórico em que foi elaborada, uma vez que utiliza a expressão "metodologias estruturadas" para definir CASE, pois à data em que a definição foi elaborada, não existiam outras metodologias com expressão. Software Engineering Institute (www.sei.cmu.edu): "CASE é a utilização de meios de suporte baseados em computador no processo de desenvolvimento de software". Definimos CASE como um conjunto de técnicas e ferramentas informáticas que auxiliam o engenheiro de software no desenvolvimento de aplicações, com o objetivo de diminuir o respectivo esforço e complexidade, de melhorar o controle do projeto, de aplicar sistematicamente um processo uniformizado e de automatizar algumas atividades, nomeadamente a verificação da consistência e qualidade do produto final e a geração de artefatos. Uma ferramenta CASE não é mais do que um produto informático destinado a suportar uma ou mais atividades de engenharia de software, relacionadas com uma (ou mais) metodologia(s) de desenvolvimento. Um dos principais objetivos que há muito tempo se procura alcançar com estas ferramentas é a implementação de um ambiente integrado que permita a aplicação de uma abordagem concept to code (isto é, "desde a concepção até à implementação") para o desenvolvimento de sistemas de informação. No entanto, este objetivo foi freqüentemente comprometido por diversas razões. Uma das mais relevantes tem a ver com a incapacidade de suportar, de forma integrada, todas as atividades das várias fases do processo, e, sobretudo de automatizar várias delas (nomeadamente a geração automática de código).

5 As alterações significativas ao nível da tecnologia, dos métodos de análise e desenho, e a crescente preocupação com a modelação do negócio ao mais alto nível, são algumas das razões que vieram trazer preocupações acrescidas e reforçar a necessidade da implementação do conceito concept to code. Os estudos existentes no mercado não são consistentes sobre as vantagens da utilização deste tipo de aplicações. Se alguns ([Banker91], [Finlay94], [Iivari96]) apontam para aumentos de produtividade com a introdução de produtos CASE, outros ([Orlikowski93], [Vessey92]) chegam à conclusão de que estes benefícios são difíceis de atingir e quantificar. Apenas no início da década de 80 é que surgem no mercado as primeiras ferramentas que se consideram atualmente como integrando o universo CASE. O Excelerator, uma das primeiras ferramentas CASE considerada como tal, surgiu em A crescente importância que foram tendo no processo de desenvolvimento está diretamente relacionada com um conjunto de fatores decisivos que contribuíram para o crescente sentimento da necessidade deste tipo de ferramentas: A mudança do ênfase das atividades de programação para atividades de análise e desenho de software, de modo a possibilitar a ultrapassagem dos diversos problemas que se reconheciam aos métodos de trabalho ad-hoc. Utilização de computadores pessoais e de interfaces de trabalho gráficas. O aparecimento de diversas técnicas de modelação de sistemas, que implicavam o desenho de diagramas gráficos (tais como os fluxogramas ou diagramas de fluxos de dados), em que a representação destas notações em papel, ou em ambientes orientados ao caráter, se tornava impraticável à medida que a respectiva complexidade aumentava (quaisquer correções que fossem necessárias implicavam sempre refazer tudo de novo). O aumento da complexidade e do tamanho do software, associado às maiores capacidades do hardware. As ferramentas desta fase tiveram essencialmente três grandes preocupações: ajudar na elaboração da documentação, na produção de diagramas e no suporte das atividades de análise e desenho. Data também desta altura o aparecimento de outras ferramentas e que nós consideramos integradas no universo das ferramentas CASE, tais como ferramentas para gestão de projetos, elaboração de estimativas ou suporte à realização de testes. Figura : Evolução das ferramentas de apoio ao desenvolvimento de software. No início dos anos 90, muita das ferramentas CASE passaram a ser designadas por ferramentas RAD (Rapid Application Development), o que traduzia a preocupação de aumentar o ritmo do desenvolvimento de aplicações.

6 Exemplos destas ferramentas foram (e algumas ainda são) o Visual Basic, SQL Windows, Dephi, Powerbuilder, Oracle Designer e Oracle Developer, que estão freqüentemente orientadas para auxiliar o desenvolvimento de software para ambientes cliente-servidor. A partir de meados dos anos 90, com a crescente importância das abordagens orientadas por objetos e o desenvolvimento de componentes, a terminologia utilizada por alguns autores passou a ser ferramentas de modelação visual. No entanto, a expressão CASE permanece, no nosso entender, como a mais abrangente de todas. Mais recentemente, a introdução dos conceitos da orientação por objetos veio de alguma forma revolucionar o mercado, quer porque uma parte significativa das ferramentas tradicionais teve que se "reinventar", e incorporar novas técnicas de modelação integradas (ou não) com as abordagens estruturadas já existentes; quer porque surgiram no mercado novas ferramentas que suportam exclusivamente este paradigma (é o caso da ferramenta Rose da Rational). Neste contexto, assume particular destaque o UML, que vem assumindo um papel crescente ao nível das notações de modelação. Hoje em dia, praticamente todas as ferramentas que detêm uma quota de mercado mais significativa incorporam algum suporte para o UML. Esta é uma das "áreas quentes" das ferramentas CASE que se concentram na modelação de software: a dúvida sobre a preponderância de determinadas notações e conseqüente implementação pelas ferramentas. Algumas correntes de pensamento acham que as metodologias e notações orientadas por objetos, e em particular o UML, acabarão por se tornar preponderantes no futuro, ao nível da especificação de software. A arquitetura típica das ferramentas CASE (ou pelo menos uma que se considera mais adequada para este tipo de aplicações) é constituída por um conjunto de aplicações / componentes, suportados por um repositório integrado, como se representa na Figura Arquitetura genérica das ferramentas CASE. Repositório O termo repositório designa o componente da arquitectura das ferramentas CASE que é utilizado como meio de armazenamento, gestão e partilha de objectos, modelos, documentos, ou quaisquer outros artefactos, produzidos por algum dos restantes componentes que completam a arquitectura. Na prática, o papel do repositório pode ser concretizado através de uma base de dados, como é o caso típico dos fornecedores que possuem simultaneamente produtos CASE e bases de

7 dados (casos da Oracle e da Sybase), mas muitos produtos utilizam um simples sistema de gestão de ficheiros, alguns com formatos proprietários. O repositório de uma ferramenta CASE é particularmente relevante, uma vez que facilita a gestão de modelos elaborados, e a respectiva reutilização, disponibilizando para isso mecanismos potentes de pesquisa. Tipicamente, o seu conteúdo incluirá: Templates de âmbito variado, nomeadamente de diagramas e de documentos, que facilitam a elaboração de artefatos concretos a partir de modelos genéricos. Templates e frameworks aplicações, a partir dos quais podem ser construídos "esqueletos" de aplicações em função de um conjunto de parâmetros. Bibliotecas de objetos, classes e componentes, que para além de eventuais componentes que possam vir inicialmente com as ferramentas, permitem a integração de outros desenvolvidos ao longo do tempo. Diagramas diversos que resultam da modelação do sistema. Código fonte, programas executáveis e aplicações empacotadas prontas para distribuir aos utilizadores finais. 404 Arquivos de dados para testes e scripts de execução dos mesmos. O repositório apresenta as funcionalidades típicas de um sistema de gestão de bases de dados, nomeadamente no que diz respeito a: Garantia de integridade de dados. Partilha de informação. Suporte ao trabalho concorrente de vários utilizadores. Facilidades de realização de operações de pesquisa. O repositório é um componente crítico ao providenciar mecanismos e estruturas de dados para a integração entre as ferramentas, constituindo-se como o meio de armazenamento comum, para todos os artefatos. No entanto, e de modo a garantir o sucesso do repositório, enquanto facilitador da partilha de informação, é necessário que sejam definidos adicionalmente os seguintes aspectos: Um formato comum para troca de informação descritiva dos artefatos. Uma interface comum para aceder e utilizar os artefatos. Vantagens e Problemas das Ferramentas CASE A introdução de ferramentas CASE numa organização pressupõe uma predisposição para a aplicação de regras e princípios a todo o processo de desenvolvimento, sendo esta précondição já de si um aspecto positivo no processo de melhoria do desenvolvimento de software numa organização. Podemos identificar algumas das principais vantagens que resultam da aplicação deste tipo de ferramentas: Uniformização do processo de desenvolvimento, das atividades realizadas, e dos artefatos produzidos.

8 Reutilização de vários artefatos ao longo do mesmo projeto, e entre projetos, promovendo o consequente aumento da produtividade. Automatização de atividades, com particular destaque ao nível da geração de código e de documentação. Diminuição do tempo de desenvolvimento, recorrendo à geração automática de diversos artefatos do projeto, ou à reutilização de outros previamente existentes. Integração de artefatos produzidos em diferentes fases do ciclo de desenvolvimento de software, em que os outputs de uma ferramenta são utilizados como inputs de outra. Um bom exemplo é a possibilidade de um diagrama de classes originar o esquema relacional de uma base de dados. Demonstração da consistência entre os diversos modelos e possibilidade de verificar a correção do software. Qualidade do produto final superior, pois a utilização de ferramentas impõe um rigor que obriga a uma abordagem mais estruturada no processo de desenvolvimento.

9 Manutenção Durante a vida útil de qualquer sistema de software são detectados problemas que não são devidamente verificados durante a fase de implementação (designados por bugs). Surgem também inúmeras solicitações internas e externas relativamente a pedidos de alteração de requisitos que não foram contemplados originalmente na fase de concepção, e que exigem a elaboração de novas versões/atualizações do software. Durante o tempo de vida útil do software são ainda detectados problemas que apenas podem ser identificados nesta fase; estão normalmente relacionados com questões de desempenho do sistema e apenas se tornam perceptíveis com a sua crescente utilização. Figura 2.8: Percentagem relativa das intervenções que ocorrem durante a manutenção do software. A Figura 2.8 mostra a proporção em que estas diversas situações ocorrem. O objetivo da tarefa de manutenção de software é garantir que a ocorrência de alguma destas situações sejam convenientemente tratadas. Atualmente, muitos autores não vêem a manutenção como uma tarefa com atividades próprias, mas sim como o período que se inicia imediatamente após a entrada em produção do sistema, e que dura enquanto o software se mantiver em operação. Isto porque as atividades a executar sobre o sistema fazem de fato parte de outras tarefas já descritas (análise, desenvolvimento, testes, etc). Por isso, é mais correto considerar que a manutenção desencadeia uma nova iteração de todo o processo de desenvolvimento de software. Complementarmente à manutenção são realizadas outras atividades que garantem o bom funcionamento do sistema segundo diverso critérios, e que têm uma intervenção, sobretudo a nível tecnológico. Estamos nos referindo ao conjunto de atividades que pode ser genericamente designado por operação do sistema, e que inclui, entre outras, a realização de cópias de segurança do sistema, a verificação dos parâmetros de desempenho, a definição de novos utilizadores, etc.

10 ENTENDENDO A MANUTENÇÃO (Aula de 16/05/2011) Qual a origem maior do trabalho de manutenção? Quais são as maiores dificuldades na realização da manutenção? Definição de manutenção Qualquer trabalho no software feito depois que ele se torna operacional ou passa para a produção Parikh Correção de erros; Revisão dos requisitos originais; Aumento de função e desempenho. A manutenção do software envolve toda e qualquer modificação feita no software após estar pronto, assim qualquer correção de erro ou nova funcionalidade adicionada é considerada uma atividade de manutenção. Portanto, esta fase não tem um fim definido, enquanto o software estiver sendo utilizado, alguma atividade de manutenção de software poderá ser necessária. Como o gasto de manutenção é eterno, é normal uma empresa de software gastar mais com a manutenção de sistemas existentes do que com o desenvolvimento de novos sistemas. Pesquisas recentes estimam que 20% do esforço das empresas é gasto em desenvolvimento e 80% em manutenção. Tipos de manutenção Existem basicamente quatro tipos de manutenção de software, conforme abaixo: Manutenção corretiva; consiste em corrigir erros de programas, que geralmente são descobertos pelos usuários software. Quando o erro é pequeno, pode ser corrigido com simples alterações, mas quando o erro exige um tempo maior, pode se fazer algum reparo temporário, sendo o erro corrigido completa e adequadamente apenas em uma nova versão do software. Correção Adaptativa; Este tipo de manutenção é necessária, porque o ambiente onde o software é executado muda constantemente ou para adaptar o software a uma nova legislação, por exemplo novos regulamentação para o RH, Fiscal, Contabilidade,etc. Frequentemente surgem novas gerações de processadores, memórias, sistemas operacionais, etc. Os softwares, portanto, precisam se adaptar, tanto para

11 conseguirem ser executados no novo ambiente ou simplesmente para aproveitar novos recursos e potencialidades oferecidas. Manutenção Aperfeiçoadora; Trata de modificações no sentido de melhorar o software. O software funciona adequadamente, mas talvez podemos adicionar novas funcionalidades ou um desempenho melhor. Também envolve em melhorar a documentação do software, modificar o código para melhorar a legibilidade, etc. Manutenção Preventiva; Consiste em modificar o software para melhorar a confiabilidade ou a manutenabilidade futura. Por exemplo; o desenvolvedor do software pode descobrir algum aspecto que pode levar a uma falha no futuro e corrigi-lo antes que o problema ocorra. Exemplo: Bug do milênio. Quando o processo de desenvolvimento do software foi feito de forma estruturada, seguindo os métodos e técnicas definidos pela engenharia de software, a manutenção é facilitada e consiste dos seguintes passos: Avaliação da documentação do projeto; Análise da arquitetura do programa; Avaliação do impacto das modificações; Modificação do projeto original; Implementação das mudanças; Testes de regressão (refazer os mesmos testes feitos anteriormente, verificando se os mesmos resultados são obtidos) PROBLEMAS DE MANUTENÇÃO Grande parte dos problemas de manutenção referem-se a falta de planejamento no desenvolvimento do software. Outra parte refere-se as dificuldades operacionais, por exemplo, para fazer um upgrade de um sistema. Talvez seja necessário torná-lo indisponível por algum tempo. Podem-se agrupar os problemas de manutenção nas seguintes categorias: Problemas com pessoal; Problemas técnicos; Compromisso com o cliente; Custos de manutenção.

12 Problemas com pessoal Entendimento limitado, normalmente é difícil entender o software produzido por outra pessoa. Perde-se muito tempo tentando entender o software, principalmente se a documentação for ineficiente. Problemas técnicos As vezes a lógica adotada por um programa não permite sua modificação imediata, requerendo mudanças em todo o código. Exemplo; o bug do milênio, onde foi adotado guardar apenas dois dígitos para o ano. Compromisso com o cliente É a impossibilidade de prever quando as falhas vão ocorrer. Não há como prever quando é um cliente vai ligar reportando um erro. É difícil conseguir recursos e pessoal de imediato para resolver o problema. Em geral é preciso deslocar pessoas envolvidas com outras atividades para resolver o problema. Custos de manutenção O custo é sempre alto, pois enquanto as outras fases de processo têm começo e fim, a fase de manutenção dura enquanto o software estiver sendo usado. REGISTROS de MANUTENÇÃO Registrar toda e qualquer modificação no software, pois deve ser documentada. EFEITOS COLATERAIS das MANUTENÇÕES As vezes, uma mudança em uma única linha de código pode provocar diversos erros e até fazer com que o programa deixe de funcionar corretamente. Portanto, não importa a simplicidade da modificação feita, você TEM que testar o software inteiro novamente.

13 PREMISSAS DA REENGENHARIA DE SOFTWARE Sistemas existentes são uma vantagem valiosa da qual a corporação depende e portanto deveriam ser apropriadamente gerenciados; A manutenção de software poderá ser mais efetiva e eficientemente realizada com ajuda de ferramentas poderosas; É uma manutenção automatizada; Envolve a melhoria dos processos de manutenção de software e melhoria dos sistemas atuais pela aplicação de novas tecnologias e ferramentas para a manutenção de software; Sugere um estratégia de manutenção a longo prazo ao invés de simplesmente procurar por uma imediata mudança na manutenção de Software; Oferece uma maneira de organizar o software e mantê-lo organizado. CONCEITO de REENGENHARIA Reengenharia é o processo de examinar software existente e/ou modificá-lo com ajuda de ferramentas automatizadas para: Melhorar sua futura manutenção; Atualizar sua tecnologia; Estender sua expectativa de vida; Aumentar a produtividade da manutenção. OUTROS CONCEITOS É o estudo e alteração de um determinado sistema para reconstruí-lo numa nova forma e subseqüente implementação dessa nova forma ; Modificação em código e estrutura de dados existentes usando os princípios de engenharia de software atuais para aumentar a capacidade de manutenção e capacidade de adaptação do sistema. Combinação de técnicas e ferramentas que facilitam a análise, melhoria, redesenho e reutilização de sistemas existentes para suportar as necessidades de informação ; Meio para melhorar sistemas existentes sem causar impactos na sua funcionalidade atual, plataforma ou arquitetura técnica ; Conjunto de técnicas e ferramentas orientadas à avaliação, reposicionamento e transformação de sistemas existentes, com o objetivo de estender-lhes a vida útil e ao mesmo tempo, proporcionar-lhes uma melhor qualidade técnica e funcionalidade (Furlan);

14 OBJETIVOS DA REENGENHARIA DE SOFTWARE Criar um inventário dos sistemas existentes; Fornecer assistência automatizada para a manutenção; Reduzir custos e erros de manutenção; Tornar o sistema mais fácil de compreender, modificar e testar. Facilitar a conversão e migração do sistema; Reforçar a aderência a padrões; Melhorar a resposta às solicitações de manutenção; Melhorar o ânimo do pessoal de manutenção; Proteger e estender a vida do sistema; Utilizar CASE para suportar sistemas atuais; Reutilizar componentes de sistemas existentes. RAZÕES PARA O USO DA REENGENHARIA DE SOFTWARE Freqüentes falhas de produção; Problemas de desempenho; Tecnologia obsoleta; Problemas de integração de sistemas; Qualidade técnica ruim; Dificuldades para testar e caro para manter; Problemas crescentes no sistema. RAZÕES PARA REFAZER O SISTEMA Não confiável; Algoritmos ruins ou incorretos; Não atende as necessidades dos usuários.

15 SISTEMAS CANDIDATOS A REENGENHARIA DE SOFTWARE São de importância crítica da empresa; São alvo de manutenção freqüente e requerem um grande percentual de recursos de manutenção; São compreensíveis e podem seguramente ser modificados por poucos membros da equipe de software; Contém erros que ninguém pode encontrar; Requerem uma melhoria considerável. AREAS DE ATUAÇÃO DA REENGENHARIA DE SOFTWARE Análise; Reestruturação; Engenharia Reversa; Migração; Reutilização. ANALISE É o processo de examinar os sistemas atuais a fim de compreender os componentes do sistema e como seus programas funcionam. O propósito principal é identificar programas prioritários para Reengenharia e medir sua qualidade. REESTRUTURAÇÃO É o processo de alterar a forma do software (Ex: definição e nomes de dados e código do programa) sem alterar sua funcionalidade. O propósito principal é tornar o programa mais fácil de ser compreendido. ENGENHARIA REVERSA É o processo de analisar o software para reconstruir uma descrição de seus componentes e seus relacionamentos. Uma descrição de alto nível do programa é obtida a partir do programa físico. O propósito é redocumentar o sistema e descobrir informações do projeto com o auxílio na melhoria da compreensão do programa. MIGRAÇÃO É o processo de converter um software de uma linguagem para outra, mover de um ambiente operacional para outro ou atualizar sua tecnologia. O propósito principal é amenizar o impacto de adoção de novos ambientes e tecnologias.

16 REUTILIZAÇÃO É o processo de sistematicamente reaproveitar os diversos elementos criados durante o desenvolvimento de software (código, projeto, especificações, documentação). O propósito principal é acelerar o desenvolvimento de novos sistemas e melhorar sua qualidade. ENGENHARIA REVERSA A Engenharia Reversa é tida como um processo inverso à Engenharia de Sistemas tradicional, e tem como um dos objetivos principais a recuperação de informações em um nível mais alto de abstração. Essas informações podem ser obtidas por meio de uma aplicação transformacional. Uma das áreas da Engenharia de Software que vem se destacando é a Reengenharia de código fonte legado. A dificuldade em atualizar os sistemas para atenderem a novos requisitos e serem executados em novas plataformas de hardware e software, tem motivado os pesquisadores a investigar novas soluções para diminuir os custos e facilitar a manutenção [Prado e Novais,2000] [Costa, 1997]. OBJETIVOS DA ENGENHARIA REVERSA O objetivo da reengenharia de software é manter o conhecimento adquirido com os sistemas legados e utilizar estes conhecimentos como base para a evolução contínua e estruturada do software. O código-fonte legado possui uma lógica de programação, decisões de projeto,requisitos do usuário e regras de negócio que podem ser recuperadas e reconstruídas em um modelo sem a perda da semântica. O modelo resultante pode ser utilizado para reconstruir o sistema, procurando melhorar sua qualidade e reduzir custos com manutenção. Por outro lado, a tarefa de recuperação de informações sobre um sistema já implementado, não é trivial, pois muitas vezes a documentação disponível é escassa e desatualizada.. A atividade de manutenção de software consiste de três etapas: entendimento, modificação e revalidação do sistema [Schneidewind, 1987]. As etapas de entendimento e modificações estão muito relacionadas com a disponibilidade da documentação do software, ou seja, existência, consistência, completeza e atualizações corretas dos documentos que a compõem. Estas mudanças podem ser alterações de funcionalidade ou de técnica de implementação e que são seguidas da engenharia avante. Ou seja, reengenharia é o processo de criar uma descrição abstrata do sistema, elaborar mudanças em alto nível de abstração e então implementá-las no sistema. O processo de engenharia reversa é bastante dependente da solução do problema da escolha da forma de representação do conhecimento extraído de um sistema. Tendo em vista que as

17 informações recuperadas, em um processo de engenharia reversa de um projeto orientado a objeto, poderão (quase sempre) se apresentar de maneira não linear; utilizamos uma linguagem de marcação para disponibilizar essas informações. A linguagem de marcação escolhida foi a XMI (extensible Metadata Interchange) definida pela OMG2 (Object Management Group) [OMG, 2000]

18 Software Produzido Analise O quê o sistema deve fazer. o Documento de especificação Projeto Utiliza o documento de especificação e define como o comportamento especificado será obtido. o Documento de Arquitetura Implementação Utilização uma linguagem de programação. o Código Mas nem sempre funciona assim. Sistemas sem documentação; Dificuldade de manutenção; Erros gerando outros erros; Código duplicado.

19 ENGENHARIA REVERSA O termo Engenharia Reversa tem sua origem na análise de hardware, pois é comum a prática de decifrar projetos de produtos finalizados com intuito de duplicá-los. O conceito de Engenharia Reversa de Software é similar. Porém, tradicionalmente o objetivo da Engenharia Reversa é obter apenas um entendimento do sistema. Definição de ER: Processo de exame e compreensão do software existente, para recapturar ou recriar o projeto e decifrar os requisitos atualmente implementados pelos sistema, apresentado-os em um nível ou grau mais alto de abstração. Por meio da engenharia reversa um software pode ser visualizado em diferentes níveis de abstração. Cada visualização características próprias da fase do ciclo de vida correspondente à abstração. Quais os documentos utilizados para realizar a engenharia reversa (er)? Código fonte Informações de usuários e/ou analista Documentação existente (manual do usuário, manual do sistema, DFDs, Fluxogramas, etc.) Como começa a engenharia reversa? Obtendo as informações necessárias para o completo entendimento do sistema. O que fazer com essas informações? o Só para manutenção o Mesmo paradigma e mudança da linguagem o Mudança de paradigma (só modelo lógico) o Mudança de paradigma e de linguagem Finalidades: Manutenção de Sistema Reunir todas as informações de modo que sejam expressas através de alguma ferramenta disponível. Pseudocódigos; DFDs (se a abordagem for procedimental) Outros métodos de análise existentes

20 Propósito da Engenharia Reversa As atividades de manutenção fornecem a motivação para muitas ferramentas de engenharia reversa. Essa motivação é proveniente da elevada proporção de tempo e custos despendida no entendimento e exame do software a ser mantido. É estimado que mantenedores gastam entre 42 a 67% de seu tempo tentando entender o software. Nas manutenções adaptativas (adequar software a novo ambiente) e evolutivas (adicionar novas funcionalidades ao software), as técnicas de engenharia reversa são usadas indiretamente, através do fornecimento de visões do software, para localizar os componente onde serão realizadas as mudanças e adições, e para auxiliar no controle da estrutura global do sistema modificado, através da produção de documentação. Nas manutenções corretivas (correção de erros), as técnicas de engenharia reversa não servem para detectar, remover ou corrigir erros, porém auxiliam indiretamente o programador na localização do componente defeituoso, através de melhorias da compreensibilidade do software. Para mudanças preventivas ( redução de esforços em futuras mudanças), ferramentas de engenharia reversa podem fornecer um discernimento de onde e como realizar mudanças apropriadas, através da produção de visões do software. Os maiores benefícios da engenharia reversa serão mais reconhecidos quando manutenções futuras tiverem como apoio a documentação produzida numa manutenção anterior. ER x REUSO Reuso é uma atividade que se destina a identificar software reutilizável. Envol vê também a correta importação, reconfiguração e adaptação deste software para uma nova aplicação em um sistema de computação. O processo de reuso é descrito por meio de atividades: Reconhecimento, Decomposição, Classificação (para povoar as bibliotecas de reuso), Seleção, Adaptação e Composição. Técnicas de ER disputam o papel principal no apoio a esses passos, contudo, o foco principal é nos três primeiros passos. Componentes candidatos a reuso podem ser mais facilmente reconhecidos, se forem convertidos para uma notação ou forma padrão. Mesmo que as técnicas de engenharia reversa não sejam focalizadas na identificação e composição de componentes a partir de partes reutilizáveis, elas podem ser proveitosa em completar a documentação dos novos sistemas compostos. Questões Econômicas de Engenharia Reversa O Beneficio fundamental da tecnologia de ER é o aumento do entendimento de um sistema o que facilita a atividade de manutenção O processo de Engenharia Reversa (ER) pode auxiliar na recuperação de dados, por exemplo: Softwares antigos nos quais os desenvolvedores originais não mais trabalham podem ter seus códigos-fonte recuperados com a finalidade de realizar ajustes em partes do programa. Alguns exemplos de tal pratica são jogos antigos (Como os de Atari, Mega Drive,Super Nintendo etc.).

21 A ER é freqüentemente associada a questões de segurança também, pois por meio de suas técnicas pode explorar o código dos programas afim de averiguar se há códigos maléficos, arveriguar se o código original de um software não sofreu alteração ou injeção de rotinas ocultas (tal como vírus de computador fazem). No que diz respeito a recuperação de dados ainda pode-se muito explorar através da ER. Um sistema de arquivos criptografado pode ser entendido e ter seus recursos utilizados para recuperação de importantes dados perdidos. Em alguns países a prática de ER é considerada ilegal e alguns praticantes interessam-se em obter acesso não autorizado a recursos de software não oferecidos gratuitamente pelos fabricantes que vendem o produto. Tal prática é denominada Cracking. Por outro lado, a ER tem sido utilizada como ferramenta de proteção contra a própria ER praticada de forma ilegal. A partir de técnicas aplicadas nesta área é possível modelar melhores proteções para o software como anti-descompiladores, códigos mutantes e armadilhas A Engenharia reversa, foi amplamente utilizada durante a criação dos drivers para todo tipo de hardware, pelos desenvolvedores do Sistema Operacional GNU/Linux, mais especificamente o kernel Linux, devido ao fato dos fabricantes de hardware, a principio, não reconhecerem o Linux como um sistema operacional onde valesse a pena investir tempo e dinheiro no desenvolvimento de drivers. REENGENHARIA de SOFTWARE, é qualquer atividades que: 1) Melhore o entendimento do software 2) Prepare ou melhore o software em si, aumentando sua manutenção, seu reuso e sua extensão. Chikofsky e Cross definem reengenharia: o exame e a alteração de um sistema para reconstruí-lo de uma nova forma, seguida pela sua implementação. Sinônimos de Reengenharia: Melhoramento, renovação, modernização, engenharia de redesenvolvimento, engenharia de reuso. Passos para se realizar a reengenharia de software. Engenharia reversa Estudo das possibilidades existentes Reengenharia o Sem mudanças de funcionalidades, o Mudança parcial de funcionalidades,

22 o Mudança total de funcionalidades

23

Engenharia Reversa e Reengenharia

Engenharia Reversa e Reengenharia Engenharia Reversa e Reengenharia SCE 186 Engenharia de Software Profa Rosana T. Vaccare Braga (material adaptado a partir do concedido pela Profa.: Rosângela Penteado, DC - UFSCar) Fases Genéricas do

Leia mais

EVOLUÇÃO DE SOFTWARE

EVOLUÇÃO DE SOFTWARE EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1 Mudança de Software 2 Manutenção de software Mudança de software é inevitável

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 27 http://www.ic.uff.br/~bianca/engsoft2/ Aula 27-26/07/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software

Leia mais

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

Figura 1 - Arquitetura multi-camadas do SIE

Figura 1 - Arquitetura multi-camadas do SIE Um estudo sobre os aspectos de desenvolvimento e distribuição do SIE Fernando Pires Barbosa¹, Equipe Técnica do SIE¹ ¹Centro de Processamento de Dados, Universidade Federal de Santa Maria fernando.barbosa@cpd.ufsm.br

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Segurança Internet. Fernando Albuquerque. fernando@cic.unb.br www.cic.unb.br/docentes/fernando (061) 273-3589

Segurança Internet. Fernando Albuquerque. fernando@cic.unb.br www.cic.unb.br/docentes/fernando (061) 273-3589 Segurança Internet Fernando Albuquerque fernando@cic.unb.br www.cic.unb.br/docentes/fernando (061) 273-3589 Tópicos Introdução Autenticação Controle da configuração Registro dos acessos Firewalls Backups

Leia mais

MÓDULO 11 ELEMENTOS QUE FAZEM PARTE DO PROJETO DO SISTEMA

MÓDULO 11 ELEMENTOS QUE FAZEM PARTE DO PROJETO DO SISTEMA MÓDULO 11 ELEMENTOS QUE FAZEM PARTE DO PROJETO DO SISTEMA Através dos elementos que fazem parte do projeto do sistema é que podemos determinar quais as partes do sistema que serão atribuídas às quais tipos

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

Leia mais

UNIVASF - Universidade Federal do Vale do São Francisco Manutenção de Software

UNIVASF - Universidade Federal do Vale do São Francisco Manutenção de Software UNIVASF - Universidade Federal do Vale do São Francisco Manutenção de Software Prof. Ricardo A. Ramos Ciclo de Vida de Software 2 Manutenção de Software Alterações efetuadas no software depois de sua liberação.

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

Garantia de Processo Leis de Lehman Manutenção de Softwares

Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Acidentes são eventos raros em sistemas críticos e pode ser impossível simulá-los durante testes de um sistema. Requisitos

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Plano de Gerência de Configuração

Plano de Gerência de Configuração Plano de Gerência de Configuração Objetivo do Documento Introdução A aplicação deste plano garante a integridade de códigos-fonte e demais produtos dos sistemas do, permitindo o acompanhamento destes itens

Leia mais

Apostila de Gerenciamento e Administração de Redes

Apostila de Gerenciamento e Administração de Redes Apostila de Gerenciamento e Administração de Redes 1. Necessidades de Gerenciamento Por menor e mais simples que seja uma rede de computadores, precisa ser gerenciada, a fim de garantir, aos seus usuários,

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4.

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4. Guia de Atualização PROJURIS WEB 4.5 Por: Fabio Pozzebon Soares Página 1 de 11 Sistema ProJuris é um conjunto de componentes 100% Web, nativamente integrados, e que possuem interface com vários idiomas,

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios?

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? RESUMO DA SOLUÇÃO CA ERwin Modeling Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? O CA ERwin Modeling fornece uma visão centralizada das principais definições de

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

15 Computador, projeto e manufatura

15 Computador, projeto e manufatura A U A UL LA Computador, projeto e manufatura Um problema Depois de pronto o desenho de uma peça ou objeto, de que maneira ele é utilizado na fabricação? Parte da resposta está na Aula 2, que aborda as

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO Competências Analista 1. Administração de recursos de infra-estrutura de tecnologia da informação 2.

Leia mais

Introdução à Computação

Introdução à Computação Aspectos Importantes - Desenvolvimento de Software Motivação A economia de todos países dependem do uso de software. Cada vez mais, o controle dos processos tem sido feito por software. Atualmente, os

Leia mais

Manutenção e Ferramentas CASE. Marcos L. Chaim Segundo Bimestre 2003 Mestrado Profissional IC/Unicamp

Manutenção e Ferramentas CASE. Marcos L. Chaim Segundo Bimestre 2003 Mestrado Profissional IC/Unicamp Manutenção e Ferramentas CASE Marcos L. Chaim Segundo Bimestre 2003 Mestrado Profissional IC/Unicamp O que é manutenção de software? mudanças que devem ser feitas nos programas de computadores depois de

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 1 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Apresenta a diferença entre dado e informação e a importância

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Disciplina: Curso de Tecnologia em Redes de Computadores Auditoria e Análise de Segurança da Informação - 4º período Professor: José Maurício S. Pinheiro AULA

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Modernização e Evolução do Acervo de Software Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Tópicos 1. Estudo Amplo sobre Modernização 2. Visão IBM Enterprise Modernization 3. Discussão - Aplicação

Leia mais

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de SCE186-ENGENHARIA DE SOFTWARE Módulo 1 Atividades da Engenharia de GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br 2003 DEFINIÇÃO CONSTRUÇÃO SOFTWARE PRODUTO MANUTENÇÃO

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Manutenção desoftware. SCE 186- Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestrede2002

Manutenção desoftware. SCE 186- Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestrede2002 Manutenção desoftware SCE 186- Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestrede2002 CiclodeVidadeSoftware 2 ManutençãodeSoftware n Alterações efetuadas no software

Leia mais

INTERNET HOST CONNECTOR

INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR IHC: INTEGRAÇÃO TOTAL COM PRESERVAÇÃO DE INVESTIMENTOS Ao longo das últimas décadas, as organizações investiram milhões de reais em sistemas e aplicativos

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

Soluções Inteligentes para regulamentações e negócios em aplicações SAP

Soluções Inteligentes para regulamentações e negócios em aplicações SAP Soluções Inteligentes para regulamentações e negócios em aplicações SAP Uma nova visão no Gerenciamento da Aplicação INDICE 1. A Union IT... 3 2. A importância de gerenciar dinamicamente infra-estrutura,

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Introdução. Hardware X Software. Corpo Humano Parte Física. Capacidade de utilizar o corpo em atividades especificas explorando seus componentes

Introdução. Hardware X Software. Corpo Humano Parte Física. Capacidade de utilizar o corpo em atividades especificas explorando seus componentes Introdução Hardware X Software Corpo Humano Parte Física Componentes 18 Capacidade de utilizar o corpo em atividades especificas explorando seus componentes Hardware Introdução Parte física: placas, periféricos,

Leia mais

2 Engenharia de Software

2 Engenharia de Software 20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Perguntas para avaliar a efetividade do processo de segurança

Perguntas para avaliar a efetividade do processo de segurança Perguntas para avaliar a efetividade do processo de segurança Questionário básico de Segurança da Informação com o objetivo de ser um primeiro instrumento para você avaliar, em nível gerencial, a efetividade

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software Análise e Projeto de Sistemas Análise e Projeto de Sistemas Contextualização ENGENHARIA DE SOFTWARE ANÁLISE E PROJETO DE SISTEMAS ENGENHARIA DA INFORMAÇÃO Perspectiva Histórica Engenharia de Software 1940:

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas

Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.ufma.br

Leia mais

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Alexandro Deschamps (Ápice) alexandro@apicesoft.com Everaldo Artur Grahl (FURB/DSC) egrahl@furb.br Resumo. Uma das grandes

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE Modelo de Otimização de SAM Controle, otimize, cresça Em um mercado internacional em constante mudança, as empresas buscam oportunidades de ganhar vantagem competitiva

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 8 http://www.ic.uff.br/~bianca/engsoft2/ Aula 8-17/05/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software (Caps. 13 e 14 do

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS Quando falamos em arquitetura, normalmente utilizamos esse termo para referenciar a forma como os aplicativos computacionais são estruturados e os hardwares

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO

2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO 2.3. ORGANIZAÇÕES E GESTÃO DOS SISTEMAS DE INFORMAÇÃO As Empresas e os Sistemas Problemas locais - impacto no sistema total. Empresas como subsistemas de um sistema maior. Uma empresa excede a soma de

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Introdução BD desempenha papel crítico em todas as áreas em que computadores são utilizados: Banco: Depositar ou retirar

Leia mais

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED UML 01 Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Referências BARBIERI, Carlos. Análise e Programação

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA

SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA SERVIÇO DE ANÁLISE DE REDES DE TELECOMUNICAÇÕES APLICABILIDADE PARA CALL-CENTERS VISÃO DA EMPRESA Muitas organizações terceirizam o transporte das chamadas em seus call-centers, dependendo inteiramente

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

Definir o espaço das informações das organizações; Realizar o detalhamento das análises dos fluxos de dados;

Definir o espaço das informações das organizações; Realizar o detalhamento das análises dos fluxos de dados; MODELAGEM DE SISTEMAS DE INFORMAÇÃO EAD Módulo 1 Arquitetura dos sistemas de informação A unificação das perspectivas desenvolvidas pelo modelo de negócio e dos sistemas de informação formam a arquitetura

Leia mais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais 1º Estudo Dirigido Capítulo 1 Introdução aos Sistemas Operacionais 1. Defina um sistema operacional de uma forma conceitual correta, através de suas palavras. R: Sistemas Operacionais são programas de

Leia mais

Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1

Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1 Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1 Aula 3 Disponibilidade em Data Center O Data Center é atualmente o centro nervoso

Leia mais

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE Prof. Msc. Hélio Esperidião O QUE É UM ALGORITMO? É qualquer procedimento computacional bem definido que informa algum valor ou conjunto de valores como entrada

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais