VALIDAÇÃO DE UMA TÉCNICA PARA GERAÇÃO AUTOMÁTICA DE TESTES COM OBJETOS MOCK
|
|
- Ruth Ventura Caminha
- 8 Há anos
- Visualizações:
Transcrição
1 UNIVERSIDADE FEDERAL DE CAMPINA GRANDE CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA UNIDADE ACADÊMICA DE SISTEMAS E COMPUTAÇÃO RELATÓRIO DE ESTÁGIO VALIDAÇÃO DE UMA TÉCNICA PARA GERAÇÃO AUTOMÁTICA DE TESTES COM OBJETOS MOCK RENATO MICELI COSTA RIBEIRO Estagiário DALTON DARIO SEREY GUERRERO Orientador Acadêmico SABRINA DE FIGUEIRÊDO SOUTO Supervisora Técnica Campina Grande PB Dezembro de 2009
2 VALIDAÇÃO DE UMA TÉCNICA PARA GERAÇÃO AUTOMÁTICA DE TESTES COM OBJETOS MOCK APROVADO EM BANCA EXAMINADORA Dalton Dario Serey Guerrero, Prof. DSc. ORIENTADOR ACADÊMICO Joseana Macêdo Fechine, Prof. DSc. MEMBRO DA BANCA Sabrina de Figueirêdo Souto, BSc. MEMBRO DA BANCA
3 AGRADECIMENTOS Agradeço inicialmente a Sabrina Souto, por ter me convidado a auxiliá-la em seu mestrado, me oferecendo a oportunidade de participar desse estágio; agradeço a Dalton Serey, pelas discussões frutíferas, mesmo em face das dificuldades em encontrá-lo; agradeço também a Alexandro Soares, a Pryscilla Dóra e a Cícero Alan Cruz, pelas boas sugestões quanto a conduzir este trabalho; e, finalmente, agradeço a Joseana Fechine, pelos votos de sucesso ao acreditar no êxito deste trabalho.
4 APRESENTAÇÃO Como parte das exigências do curso de Ciência da Computação, da Universidade Federal de Campina Grande, para cumprimento da disciplina de Estágio Integrado, apresenta-se o relatório de estágio, que expõe as atividades desenvolvidas por Renato Miceli Costa Ribeiro, ao curso do período , sob a orientação acadêmica de Dalton Dario Serey Guerrero e supervisão técnica de Sabrina de Figueirêdo Souto. Esse estágio integrado objetivou validar a técnica Automock de geração automática de testes com Objetos Mock. O estágio foi realizado no Laboratório de Sistemas Distribuídos (LSD), localizado na Universidade Federal de Campina Grande (UFCG), bloco CO. Esse ambiente foi bastante propício para a realização do estágio, visto que dispunha de todo o aparato necessário para o desenvolvimento das atividades. O conteúdo do relatório está distribuído conforme a seguinte descrição. Seção 1 Introdução. Seção 2 Ambiente de Estágio. Seção 3 Fundamentação Teórica e Tecnologias Utilizadas. Seção 4 Atividades do Estágio. Seção 5 Considerações Finais. Referências Bibliográficas. Apêndices. Anexos. 4
5 5
6 RESUMO Testar softwares é uma atividade muito importante. É através dela que os testadores descobrem faltas no software, que poderiam causar falhas de execução. Uma boa prática de testes sobre sistemas orientados a objeto consiste em isolar as várias unidades de código do restante do sistema de modo a diminuir a influência entre elas durante a execução dos testes. Para isso, uma solução bastante empregada são os Objetos Mock; entretanto, desenvolver testes com Objetos Mock é uma tarefa tediosa e complexa, além de requerer que os testadores possuam profundo conhecimento do sistema e de suas interações. Em seu mestrado, Sabrina Souto propôs uma técnica chamada Automock, para geração automática de código Mock a partir de testes pré-existentes. Este relatório apresenta as atividades desenvolvidas por Renato Miceli ao longo de seu estágio, que objetivaram avaliar a técnica Automock. Para isso, foram utilizados experimentos e questionários, além de análises quantitativas. Este é um trabalho em andamento e deverá ser concluído por Sabrina Souto ao final de seu mestrado. 6
7 ABSTRACT Testing softwares is an important task. It is by means of it that testers find out faults on softwares, which could lead to execution failures. A recommended testing practice over object-oriented systems consists in isolating the many units of code from the rest of the system, so to decrease the influence between them during the tests' execution. A commonly employed solution for that are the Mock Objects; developing tests with Mock Objects, however, is a tedious and complex task, besides requiring testers to posess deep knowledge about the system and its interactions. On her Masters Course, Sabrina Souto proposed a technique called Automock, for the automatic generation of Mock code out of previously existing tests. This report presents the activities developed by Renato Miceli during his internship, which aimed help evaluating the technique Automock. In order to do that, there have been used experiments and surveys, as well as quantitative analysis. This is an on-going work and should be finished by Sabrina Souto by the end of her Masters Course. 7
8 8
9 SUMÁRIO Lista de Siglas e Abreviaturas Lista de Quadros Lista de Tabelas Introdução Ambiente de Estágio Orientador Acadêmico Supervisora Técnica Fundamentação Teórica Linguagem de Programação Java Ambiente de Desenvolvimento Eclipse Testes de Software Automatizados Arcabouço JUnit Classes Stub Objetos Mock Arcabouço EasyMock Atividades Realizadas Revisão Bibliográfica Escrita de Artigo Proposta de Plano de Estágio Documentação das Atividades Seleção de Casos de Teste Participar do LADC' Geração de Testes com Colaboradores Stub Execução de Experimentos Avaliação Preliminar de Tempo de Execução Montagem de Questionário Avaliação Preliminar do Número de Linhas de Código Considerações Finais Referências Bibliográficas APÊNDICE A APÊNDICE B
10 APÊNDICE C APÊNDICE D APÊNDICE E ANEXO A ANEXO B ANEXO C
11 LISTA DE SIGLAS E ABREVIATURAS BD Banco de Dados CD-ROM Compact Disc, Read-Only Memory CUT Class Under Test (Classe Sob Teste) DSC Departamento de Sistemas e Computação HP Hewlett-Packard IDE Integrated Development Environment IEEE Institute of Electrical and Electronics Engineers LA-WASP Latin American Workshop on Aspect-Oriented Software Development LCD Liquid Crystal Display (Visor de Cristal Líquido) LSD Laboratório de Sistemas Distribuídos LSI Laboratório de Sistemas de Informação SAST Workshop Brasileiro de Teste de Software Sistemático e Automatizado SBSE Simpósio Brasileiro de Engenharia de Software TDD Test-Driven Development (Desenvolvimento Orientado a Testes) UFCG Universidade Federal de Campina Grande 11
12 LISTA DE QUADROS Quadro 1 Classes de Teste e seus respectivos Sistemas
13 LISTA DE TABELAS Tabela 1: Tempos gastos por participante na execução dos experimentos Tabela 2: Tempos gastos pela ferramenta Automock para gerar código mock Tabela 3: Ganho em tempo por participante frente à geração automática de código mock Tabela 4: Média de ganhos em tempo para intervalos de confiança de 95% Tabela 5: Número de linhas de código dos testes gerados em experimento Tabela 6: Média do total de linhas de código e erros para intervalos de confiança de 95%
14 SEÇÃO I INTRODUÇÃO 14
15 1. INTRODUÇÃO A atividade de construção do conhecimento não está desassociada da prática do saber. Quando ambas caminham unidas, fortalecem-se os conceitos, adquire-se experiência, obtém-se proeficiência e autossuficiência. Participar de um estágio integrado, pois, é ser presenteado com um diferencial. Essa oportunidade única na vida escolar do jovem aprendiz visa apresentar uma visão prática das teorias já conhecidas. É através dela que se vivencia o dia-a-dia de quem corriqueiramente usa pra fins reais os conceitos meramente teóricos de outrora. Para a formação de um profissional, ter sido estagiário lhe dá uma bagagem de conhecimento teórico e prático, firmemente fixados, e que devem lhe acompanhar durante toda a vida. Seguindo essa filosofia, Renato Miceli participou durante o segundo semestre de 2009 de um estágio integrado. Ele foi realizado no Laboratório de Sistemas Distribuídos (LSD), bloco CO do Campus I da Universidade Federal de Campina Grande (UFCG), durante o período escolar , sob orientação acadêmica de Dalton Dario Serey Guerrero e supervisão técnica de Sabrina de Figueirêdo Souto. Este relatório visa apresentar de forma sucinta as atividades desenvolvidas por Renato Miceli ao longo de seu estágio integrado. O estágio integrado desenvolvido teve por objetivo validar a técnica Automock para geração de testes com Objetos Mock (SOUTO, 2009). O foco do estágio foi entender o trabalho proposto, pesquisar soluções de avaliação para problemas similares, e empregar a solução mais adequada para avaliar o Automock sobre o Automock. Objetivo Geral: Validar a técnica e o protótipo de ferramenta Automock de geração de testes com Objetos Mock. 15
16 Objetivos Específicos: Entender o trabalho desenvolvido e proposto por Sabrina Souto, a partir de leitura de documentação por ela produzida, palestras e discussões interpessoais. Pesquisar soluções similares, a fim de identificar melhores abordagens para proceder com a avaliação do trabalho proposto. Conduzir o trabalho de avaliação usando a abordagem mais adequada, oriunda do trabalho de pesquisa, visando identificar a viabilidade, os benefícios e limitações da técnica Automock. O restante do relatório abordará com mais detalhes o ocorrido no decorrer do estágio integrado, focando as causas que resultaram em mudanças no andamento das atividades, embasadas por argumentos que justificam as decisões tomadas. 16
17 SEÇÃO II AMBIENTE DE ESTÁGIO 17
18 2. AMBIENTE DE ESTÁGIO Como citado na seção 1, o estágio integrado foi conduzido no Laboratório de Sistemas Distribuídos (LSD). Este é um laboratório pertencente à Universidade Federal de Campina Grande (UFCG), no âmbito do Departamento de Sistemas e Computação (DSC), localizado no bloco CO. O grupo de pesquisa em sistemas distribuídos já vem de longas datas: fundado em 1996, já passou por diversas mudanças em infraestrutura básica. Sua localidade atual, inaugurada em 2004, dedica toda uma construção própria ao laboratório. Desde sua fundação, os esforços do grupo de pesquisa estão direcionados para a área de sistemas distribuídos, com foco claro nas sub-áreas de computação em grade, sistemas entre-pares, gerenciamento de Ti orientado a negócios, sistemas de arquivo distribuídos e computação nas nuvens. No LSD foram desenvolvidas soluções conhecidas para ambientes distribuídos. Dentre elas, pode-se citar o OurGrid, para compartilhamento de recursos computacionais ociosos; o Commune, para comunicação segura e confiável entre pares através de uma rede; e o BeeFS, um sistema de arquivos distribuído sobre máquinas desktop, que utiliza da capacidade de armazenamento disponível nelas para criar um grande diretório de arquivos. Muitas outras soluções já foram ou estão em desenvolvimento no laboratório, que conta com o suporte financeiro da gigante da informática Hewlett-Packard (HP), especialmente por meio dos projetos OurGrid e Hybrid Clouds, este do qual o estagiário é pesquisador e desenvolvedor atualmente. Mais informações acerca do ambiente de estágio podem ser obtidas na seção Ambiente de Estágio no Apêndice A. O LSD possui infraestrutura própria e dispõe de salas climatizadas e máquinas de última geração. São computadores de uso pessoal com mouse, teclado e monitor LCD, rodando sistemas Unix/Linux e Windows e serviços básicos associados. Toda essa infraestrutura de informática é apoiada por uma equipe de suporte, disponível em horário comercial para quaisquer problemas 18
19 que haja. Assim, o laboratório satisfaz todos os requisitos necessários para ser posto de trabalho permanente no decorrer do estágio integrado. Acima de tudo, foi no LSD que se iniciou o desenvolvimento da técnica Automock, no contexto do projeto AutoTest, coordenado por Dalton Serey. Apesar do fim desse projeto, o laboratório ainda conserva as infraestrutura de serviços montada para suportá-lo; assim sendo, esse é o local mais que propício para a condução do estágio integrado. Dalton Serey e Sabrina Souto são, respectivamente, o orientador acadêmico e a supervisora técnica desse estágio integrado. Suas informações pessoais e profissionais são descritas em sequência ORIENTADOR ACADÊMICO Nome: Dalton Dario Serey Guerrero Função: Professor Adjunto e Coordenador de Curso Endereço Profissional: Universidade Federal de Campina Grande (UFCG) Centro de Engenharia Elétrica e Informática (CEEI) Coordenação do Curso de Ciência da Computação (CCC) Rua Aprígio Veloso, s/n, Bodocongó CEP Campina Grande - PB, Brasil. Telefone: +55 (83) Endereço de Pessoal: daltonserey@gmail.com Endereço de Profissional: dalton@dsc.ufcg.edu.br 2.2. SUPERVISORA TÉCNICA Nome: Sabrina de Figueiredo Souto Função: Mestranda 19
20 Endereço Profissional: Universidade Federal de Campina Grande (UFCG) Departamento de Sistemas e Computação (DSC) Laboratório de Sistemas Distribuídos (LSD) Rua Aprígio Veloso, Bloco CO Bodocongó CEP Campina Grande - PB, Brasil. Telefone: +55 (83) Fax: +55 (83) Endereço de Pessoal: sabrinadfs@gmail.com Endereço de Profissional: sabrina@lsd.ufcg.edu.br 20
21 SEÇÃO III FUNDAMENTAÇÃO TEÓRICA 21
22 3. FUNDAMENTAÇÃO TEÓRICA 3.1. LINGUAGEM DE PROGRAMAÇÃO JAVA A linguagem de programação Java (JAVA, 2009) é uma linguagem de programação desenvolvida pela Sun Microsystems, Inc. em 1995 que mescla conceitos dos paradigmas imperativo e orientado a objeto. Sua sintaxe deriva majoritariamente das linguagens de programação C e C++, embora tenha um modelo de objetos bem mais simples e menos facilidades de baixo nível. Foi feita para rodar sobre a Máquina Virtual Java, por meio da interpretação de bytecodes, gerados pela compilação de código-fonte. Para a condução do estágio, foi necessário conhecimento aprofundado sobre o paradigma de programação orientado a objeto e suas boas práticas de projeto, bem como proeficiência na linguagem de programação Java. Essa foi a linguagem utilizada durante todo o trabalho já desenvolvido até o momento, inclusive sendo a linguagem usada para desenvolver o protótipo de ferramenta Automock, os cenários de estudo do protótipo e os sistemas para experimentação. Apesar de ser geral, a técnica Automock só foi implementada em ambientes Java (SOUTO, 2009), tornando esse um requisito fundamental para a atividade de estágio AMBIENTE DE DESENVOLVIMENTO ECLIPSE Um dos mais usados ambientes de desenvolvimento de softwares para a linguagem de programação Java, compreende uma IDE e um sistema de gerenciamento de plug-ins (ECLIPSE, 2009). É o sistema de facto utilizado na UFCG para desenvolvimento de aplicações Java. No contexto do trabalho, essa ferramenta foi de suma importância, pois foi através dela que o protótipo Automock e os casos de teste simples para 22
23 validação foram desenvolvidos (SOUTO, 2009). Esta ferramenta foi usada durante todo o decorrer do estágio para realizar alterações sobre código Java, além de ser tecnologia assistencial obrigatória para os estudos de caso e execução dos experimentos TESTES DE SOFTWARE AUTOMATIZADOS Dentre os maiores princípios da Engenharia de Software estão as recomendadas boas práticas de teste. Testar software é uma técnica eficaz para identificar defeitos em um software que podem ocasionar em falhas de execução. É fato que um maior tempo empregado com atividades de verificação e validação diminui consideravelmente o tempo demandado em atividades de depuração, refatoramento e evolução do software. Para facilitar as atividades de teste de software, inúmeras ferramentas surgiram. Elas se propõem a automatizar o passo-a-passo executado para estimular o software em busca de falhas. Ter se tornado uma tarefa bem menos custosa em termos de tempo contribuiu para tornar o teste de software cada vez mais popular na academia e no mercado ARCABOUÇO JUNIT Dos maiores arcabouços para desenvolvimento de testes de unidade automáticos em sistemas Java é o JUnit (JUNIT, 2009). Na sua atual versão 4.x, é o arcabouço dominante na academia e no mercado para compor testes automatizados sobre softwares Java. Foi com uso do JUnit que o protótipo Automock foi validado. Além disso, os testes que devem ser fornecidos ao protótipo são testes escritos usando o arcabouço JUnit. Assim, todos os testes estudados, alterados e construídos durante o estágio integrado estavam ou foram escritos usando JUnit. 23
24 3.5. CLASSES STUB O conceito de Classes Stub está intimamente ligado às bases do paradigma de programação orientado a objeto. Classes Stub são classes que simulam o comportamento de outras classes do sistema. Para isso, elas devem respeitar o mesmo contrato e retornar respostas predefinidas para certos estímulos fornecidos ao software. O comportamento esperado é definido estaticamente no código da classe Stub. Classes Stub são um dos meios para prover isolamento da CUT em testes de unidade. No entanto, podem se multiplicar ao longo do ciclo de vida do software, por não serem reutilizáveis OBJETOS MOCK Como o conceito de Classes Stub, o conceito de Objetos Mock também está intimamente ligado ao paradigma de programação orientado a objeto. Objetos Mock servem ao mesmo propósito de classes Stub. Diferenciam-se dessas por terem seu comportamento definido dinamicamente em código, no corpo dos métodos de teste. No mais, Objetos Mock têm a capacidade de auxiliar na decisão sobre a falha ou aceitação de um teste, checando a sequência de expectativas que deveriam ter sido satisfeitas quanto a chamadas sobre si. Objetos Mock, bem como Classes Stub, podem tornar a execução do teste mais rápida, por não executarem algoritmos complexos, além de isolar a CUT do restante do ambiente de teste. Por outro lado, código mock é bem custoso de se escrever, requer conhecimento profundo do testador sobre o sistema em estudo, além de ser bastante suscetível a mudanças sutis no código do sistema (pequenas alterações no código podem levar a descartar o código mock). O trabalho proposto visa solucionar esse problema, através de da técnica Automock (SOUTO, 2009). 24
25 Para construir Objetos Mock eficientemente, existe uma variedade de arcabouços disponíveis para a linguagem Java, dentre os quais destaca-se o EasyMock ARCABOUÇO EASYMOCK O EasyMock (EASYMOCK, 2009) é um dos arcabouços de desenvolvimento de código mock mais utilizados dentre os disponíveis para a linguagem de programação Java. Ele provê a construção de Objetos Mock para interfaces e classes Java, registra listas de expectativas e omite completamente a existência de um objeto falso por debaixo do tipo provido pelo objeto. É bastante recomendado para TDD, visto que seu modo único de registro de expectativas o torna imune à maioria dos refatoramentos feitos a códigos Java. Esse arcabouço foi de suma importância para o trabalho de estágio, visto que é com uso dele que o protótipo Automock gera código mock para testes JUnit. Por isso, toda e qualquer atividade que envolvesse Objetos Mock no decorrer desse trabalho necessariamente utilizou o arcabouço EasyMock, para fins de comparação de resultados. 25
26 SEÇÃO IV ATIVIDADES REALIZADAS 26
27 4. Atividades Realizadas Nessa seção são apresentadas as atividades realizadas no decorrer do estágio. Note-se que a sequência de atividades está ordenada cronologicamente, por questões de organização Revisão Bibliográfica Antes de se proceder com o trabalho de avaliação do Automock, foi necessária uma pesquisa bibliográfica inicial do estado-da-arte. O objetivo dessa atividade foi de agregar conhecimento acerca de outras técnicas utilizadas para realizar a avaliação proposta. Foi necessário entender primeiramente o contexto em que se inseria o problema sob estudo, as abordagens que já haviam sido empregadas para resolver tal problema, além de novas abordagens que potencialmente poderiam ser empregadas, para enfim propor uma metodologia adequada para encarar o problema. Assim, essa atividade foi de suma importância para a condução do trabalho de avaliação do Automock. A revisão bibliográfica apresentou Tim Mackinnon como o criador do conceito de Objetos Mock (MACKINNON, 2001). Seu intuito primário era de auxiliar os desenvolvedores a escrever testes para objetos isolados, enquanto seguiam o método Extreme Programming (BECK, 2000). Também foi mostrado que outra abordagem isolar esses objetos são os Stubs, que, mesmo que tenham os mesmos objetivos dos Objetos Mock, não são o mesmo (FOWLER, 2007). De acordo com Meszaros, Stubs proveem respostas predefinidas para as chamadas feitas durante um teste; se usados fora do programado para o teste, é possível que responsam incorretamente (MESZAROS, 2007). Por outro lado, Objetos Mock são dinamicamente préprogramados com expectativas; se usados fora do programado para o teste, eles podem indicar explicitamente uma falha. Há ainda outras características que os diferenciam: por exemplo, Objetos Mock geralmente contam o número 27
28 de vezes que cada operação é invocada, além de verificar os argumentos fornecidos às operações e terem seus valores de retorno pré-estabelecidos. Através dessa atividade pôde-se conhecer uma gama de arcabouços dedicados a auxiliar testadores na construção de testes com Objetos Mock. Dentre eles, pode-se listar o EasyMock (EASYMOCK, 2009) e o GoogleMock (GOOGLEMOCK, 2009). A revisão bibliográfica também revelou alguns trabalhos diretamente relacionados ao Automock. O GenUTest, por exemplo, é uma ferramenta que captura e registra interações entre os objetos durante a execução de programas Java para gerar testes JUnit (PASTERNAK, 2009). Apesar de aparentar ser bastante similar à técnica proposta, GenUTest depende de uma versão funcional do software para executar, e gera testes de unidade para todos as classes do sistema; o Automock, por outro lado, espera que o testador indique um objeto-alvo e provenha algum teste que exercite esse objeto (SOUTO, 2009). Ainda, pelo que consta, o GenUTest, até o presente momento, parece não ter sido levado a público, dificultando o estudo dessa ferramenta que tanto se assemelha ao Automock. Outros trabalhos bem relacionados foram um protótipo de ferramenta para geração de Objetos Mock usando uma combinação de execuções concreta e simbólica de código.net (TILLMANN, 2006), e uma proposta de ferramenta para conversão automática de testes de sistema em uma coleção de testes de unidade, a fim de apoiar a fatoração de testes (SAFF, 2005). Esse último trabalho utiliza a técnica de instrumentação do código binário do sistema, inclusive de todas as suas dependências (por exemplo, as bibliotecas que usa), exceto da CUT. Apesar da similaridade à técnica Automock, nenhum desses trabalhos parece abordar o problema da maneira proposta (SOUTO, 2009), o que aumenta seu trabalho em relevância e originalidade. A partir dessa atividade foram geradas as seções 2 e 1 dos artigos para o SAST'09 e o LA-WASP'09, respectivamente, que podem ser encontrados nos apêndices C e D. 28
29 4.2. Escrita de Artigo Dada a relevância e originalidade do trabalho de geração automática de testes com Objetos Mock, o próximo passo foi documentar seu estágio atual no formato de artigo científico. Embora tenha sido útil para treinar a prática da escrita de documentos formais, o maior objetivo dessa atividade era de apresentar à comunidade científica a abordagem a ser seguida para solucionar o problema da escrita de testes com Objetos Mock. O primeiro fruto dessa atividade foi o artigo escrito para o SAST'09 (vide apêndice C). Por questões de imaturidade do trabalho, esse artigo acabou não sendo submetido para a conferência a tempo. Entretanto, a partir dele foi escrito o artigo para o LA-WASP'09 (vide apêndice D). Esse último trabalho foi submetido ao evento e notificado como aceito. Ele foi defendido por Sabrina Souto durante o evento, ocorrido em outubro de 2009 em Fortaleza. Foi publicado em CD-ROM pela IEEE Computer Society, juntamente com os anais do SBSE' Defesa de Plano de Estágio A ideia do estágio era de realizar a avaliação da técnica Automock por meio de estudos de caso. Para isso, deveria-se averiguar o ganho promovido pela técnica automatizada frente à construção manual de testes com Objetos Mock. Assim, seriam selecionados testes já desenvolvidos para os sistemas sob estudo, que seriam convertidos manualmente e automaticamente (com uso do protótipo de ferramenta) em testes com Objetos Mock. Sobre esses testes com e sem o uso de Objetos Mock seriam aplicadas métricas preestabelecidas: tempo para geração, total de linhas de código, cobertura da execução, número de detecções de erro, equivalência em semântica. O resultado dessas métricas, por uso de diferença simples, geraria o ganho proporcionado pela técnica sobre a construção manual de testes com Objetos Mock. Os sistemas para estudo foram selecionados pela proximidade da equipe de desenvolvimento. Esses sistemas eram o OurBackup, o Hidrogis e o OurGrid. Desenvolvido no LSD nos anos de 2007 e 2008 sob orientação de 29
30 Dalton Serey, o OurBackup (OLIVEIRA, 2008) é voltado para o compartilhamento de arquivos entre amigos, visando o becape cruzado; o Hidrogis foi desenvolvido no Laboratório de Sistemas de Informação (LSI), na UFCG; e o OurGrid (CIRNE, 2006), também desenvolvido no LSD, foca no compartilhamento de poder computacional entre várias grades de máquinas oportunistas. Todos os três sistemas possuem desenvolvedores próximos, o que facilitaria o trabalho de avaliação do Automock. O Plano de Estágio, que pode ser obtido no Apêndice A, foi defendido por meio de uma apresentação, disponível no Apêndice B. Após apreciação do trabalho frente à professora e à turma da disciplina de Estágio Integrado, foi aprovado com a pontuação máxima Documentação das Atividades Foi acordado com a supervisora técnica que todas as atividades relevantes desenvolvidas durante o estágio seriam registradas. Para tanto, foi criado um espaço em wiki no serviço Redmine (REDMINE, 2009), hospedado nos servidores do LSD. As atividades passíveis de documentação são primariamente as reuniões, sejam formais ou informais; o andamento das atividades, sejam de cumprimento obrigatório da disciplina, sejam decorrentes da condução do estágio integrado; quaisquer ideias que forem surgindo, que possam de alguma forma contribuir para melhorar o trabalho. Assim, durante todo o decorrer do estágio, foram postadas anotações que documentam adequadamente as atividades desenvolvidas no âmbito do estágio integrado. Além de tudo, também foram documentados os cronogramas de trabalho, horários de presença no estágio e as atividades desenvolvidas atualmente no âmbito do estágio, tanto do estagiário quanto de seu supervisor técnico. Portanto, o wiki do Redmine tornou-se serviço primordial na boa condução do estágio integrado; obteve status de serviço de centralização das informações concernentes ao estágio, bem como serviço de comunicação confiável público entre o estagiário e seu supervisor técnico. 30
31 4.5. Seleção de Casos de Teste Para dar início à avaliação da técnica Automock, foi necessário selecionar um sistema como ponto de partida para estudá-lo, entendê-lo e, por fim, poder extrair uma suíte de testes que comporia o estudo de caso. O primeiro sistema escolhido foi o OurBackup (OLIVEIRA, 2008). Esse sistema se apresenta em duas versões: a Home, voltada para usuários doméstico, e a Enterprise, direcionada a usuários corporativos. Visto que o estagiário havia participado do desenvolvido da versão Enterprise do OurBackup e isso implicaria em uma curva de aprendizado menos custosa, essa foi a escolha inicial de sistema para estudo. Após alguns estudos sobre o estado atual do sistema, constatou-se que o OurBackup Enterprise não possuia testes adequados para compor a suíte do estudo de caso. Apenas dois testes envolviam uma CUT e seus colaboradores; entretanto, esses testes já possuíam respectivos com uso de mocks. Os demais testes do sistema se encaixam em cinco categorias: ou são testes de unidade, cuja CUT é testada na inexistência de colaboradores; ou são testes de aceitação sobre um módulo servidor, cujo módulo cliente recebe os estímulos de entrada e fornece as respostas de saída; ou são testes de unidade com CUT e colaboradores, cujos colaboradores já são objetos mock; ou são testes de unidade cuja CUT não está bem modularizada, lidando diretamente com o ambiente (seja agregando responsabilidade ou usando instâncias locais de seus colaboradores em seus métodos), quando isso deveria ser feito por meio de colaboradores globais; ou são testes nãodeterminísticos (isto é, nem toda execução admitirá o mesmo comportamento resultante), que envolvem a realização de operações não necessariamente sequenciais (paralelas ou concorrentes) para atingir condições probabilísticas sobre o estado do sistema. (como é a maioria dos sistema distribuídos, senão todos). Além disso, testes adequados para a técnica Automock (chamados testes mockáveis ) não devem ser dependentes do tempo de execução, como ocorre com alguns testes não-determinísticos, uma vez que a substituição de colaboradores reais por Objetos Mock pode alterar o tempo de execução do sistema sensivelmente (imagine colaboradores para acesso a BD ou conexões 31
32 remotas). Dado o uso inviável dos testes do OurBackup Enterprise, não houve outra opção senão descartar o sistema. O próximo sistema sob estudo foi o OurBackup Home. Após diversas análises do sistema e de seus testes, constatou-se que ele apresentava as mesmas deficiências do sistema OurBackup Enterprise. No entanto, sua suíte de testes com Objetos Mock era bem maior. Foi identificado que em ambos os softwares os testes de unidade cuja CUT interage com diversos colaboradores (isto é, os testes focados pelo Automock) já fazem uso de Objetos Mock. Considera-se, pois, sua suíte de testes como de boa qualidade para os padrões atuais de teste de software. Uma alternativa em todo caso seria construir testes para os sistemas sob estudo. Isso requere conhecimento profundo sobre esses sistemas e os relacionamentos estabelecidos entre os objetos em tempo de execução. O tempo de aprendizado seria grande. Portanto, essa foi uma alternativa descartada. Outra alternativa consistia em converter os testes com código mock em testes com colaboradores reais, para então proceder de maneira inversa. No entanto, isso implicaria em realizar manualmente ou dispor de uma ferramenta para tal; ambas as abordagens podem apresentar imperfeições e não garantir equivalência semântica entre os testes original e alterado (vale salientar que avaliar a validade de uma técnica de conversão de testes com código mock em testes com colaboradores reais é da mesma ordem de complexidade de avaliar a técnica Automock). Também requere conhecimento aprofundado do sistema para saber que colaborador real faz o papel exato do Objeto Mock presente em um teste, para questões de substituição. Ainda é um requisito conhecimento acerca da gerência de configuração do sistema, que pode ser bastante complexa, dada a complexidade dos sistemas sob estudo. Por fim, uma limitação dessa abordagem foi de que nem sempre há colaboradores reais no software que se comportem de maneira exata ao modo prescrito pelos Objetos Mock; esse código mock pode realizar o comportamento errôneo (casos de erro ou de alteração do software original), ou ainda servir pra injetar falhas propositais no sistema, desviando do comportamento esperado para um colaborador. Ainda, mesmo que haja colaboradores que se comportem à 32
UNIVERSIDADE FEDERAL DE CAMPINA GRANDE - UFCG CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA - CEEI DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO - DSC
UNIVERSIDADE FEDERAL DE CAMPINA GRANDE - UFCG CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA - CEEI DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO - DSC PLANO DE ESTÁGIO Suporte ao DDGfs Experimentos e ambientação
Leia maisManual SAGe Versão 1.2 (a partir da versão 12.08.01)
Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação
Leia maisGARANTIA DA QUALIDADE DE SOFTWARE
GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características
Leia maisProcessos de Desenvolvimento de Software
Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e
Leia maisUNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ALEXANDRE PRADO BARBOSA RELATÓRIO DE ESTÁGIO Ponta Grossa 2012 ALEXANDRE PRADO BARBOSA Relatório
Leia maisISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
Leia maisPROCESSO 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 maisProjeto Você pede, eu registro.
Projeto Você pede, eu registro. 1) IDENTIFICAÇÃO 1.1) Título do Projeto: Você pede eu registro. 1.2) Equipe responsável pela coordenação do projeto: Pedro Paulo Braga Bolzani Subsecretario de TI Antonio
Leia mais18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB
18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB Autor(es) HARLEI MIGUEL DE ARRUDA LEITE Orientador(es) PLÍNIO ROBERTO SOUZA VILELA Apoio Financeiro PIBIC/CNPQ
Leia maisExtração de Requisitos
Extração de Requisitos Extração de requisitos é o processo de transformação das idéias que estão na mente dos usuários (a entrada) em um documento formal (saída). Pode se entender também como o processo
Leia maisPós-Graduação em Gerenciamento de Projetos práticas do PMI
Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL
Leia maisO CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE
O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo
Leia maisREFORÇO DE PROGRAMAÇÃO ESTRUTURADA EM LINGUAGEM C PARA GRADUAÇÃO EM ENGENHARIA ELÉTRICA
REFORÇO DE PROGRAMAÇÃO ESTRUTURADA EM LINGUAGEM C PARA GRADUAÇÃO EM ENGENHARIA ELÉTRICA Andréa Willa Rodrigues Villarim (Voluntário) Marcelo Pereira Rufino (Bolsista) Larissa Aguiar (Bolsista) Nady Rocha
Leia maisFACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>
FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido
Leia mais3 Qualidade de Software
3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo
Leia maisFACULDADE DE TECNOLOGIA RUBENS LARA Análise e Desenvolvimento de Sistemas
FACULDADE DE TECNOLOGIA RUBENS LARA Análise e Desenvolvimento de Sistemas Trabalho de Conclusão de Curso Regulamento (2013/01) Professor Responsável: Ms. Gerson Prando Santos, 17 de março de 2013. Versão
Leia maisFeature-Driven Development
FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por
Leia maisNa 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 maisRequisitos de Software. Teresa Maciel DEINFO/UFRPE
Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito
Leia maisMBA MARKETING DE SERVIÇOS. Turma 19. Curso em Ambiente Virtual
MBA MARKETING DE SERVIÇOS Turma 19 Curso em Ambiente Virtual São Paulo, 1 de Setembro de 2011 1. Apresentação O MBA em Marketing de Serviços, coordenado pelos Professores Marcos Cortez Campomar e Geraldo
Leia mais1.1. Organização de um Sistema Computacional
1. INTRODUÇÃO 1.1. Organização de um Sistema Computacional Desde a antiguidade, o homem vem desenvolvendo dispositivos elétricoeletrônicos (hardware) que funciona com base em instruções e que são capazes
Leia maisARCO - 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 maisImplantação de ERP com sucesso
Implantação de ERP com sucesso Implantação de ERP com sucesso, atualmente ainda é como um jogo de xadrez, você pode estar pensando que está ganhando na implantação, mas de repente: Check Mate. Algumas
Leia maisMÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que
Leia maisMídias sociais como apoio aos negócios B2C
Mídias sociais como apoio aos negócios B2C A tecnologia e a informação caminham paralelas à globalização. No mercado atual é simples interagir, aproximar pessoas, expandir e aperfeiçoar os negócios dentro
Leia maisRegulamento Complementar do Trabalho de Conclusão de Curso do Curso de Engenharia de Computação UTFPR, campus Pato Branco
Ministério da Educação Universidade Tecnológica Federal do Paraná Campus Pato Branco Engenharia de Computação Regulamento Complementar do Trabalho de Conclusão de Curso do Curso de Engenharia de Computação
Leia maisIntrodução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3
Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3 A LEGO Education tem o prazer de trazer até você a edição para tablet do Software LEGO MINDSTORMS Education EV3 - um jeito divertido
Leia maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisPRIMAVERA RISK ANALYSIS
PRIMAVERA RISK ANALYSIS PRINCIPAIS RECURSOS Guia de análise de risco Verificação de programação Risco rápido em modelo Assistente de registro de riscos Registro de riscos Análise de riscos PRINCIPAIS BENEFÍCIOS
Leia maisPlanejando o aplicativo
Um aplicativo do Visual FoxPro geralmente inclui um ou mais bancos de dados, um programa principal que configura o ambiente de sistema do aplicativo, além de uma interface com os usuários composta por
Leia maisSistema de Controle de Solicitação de Desenvolvimento
Sistema de Controle de Solicitação de Desenvolvimento Introdução O presente documento descreverá de forma objetiva as principais operações para abertura e consulta de uma solicitação ao Setor de Desenvolvimento
Leia maisApós a confirmação de pagamento de sua inscrição para o congresso, você estará apto a entrar no sistema de submissão de trabalho.
Para submissão de trabalhos é necessário que você esteja inscrito no evento. Você deve realizar seu cadastro acessando a opção Cadastrar, quando disponível. É imprescindível que você guarde suas informações
Leia maisGerenciamento de Incidentes
Gerenciamento de Incidentes Os usuários do negócio ou os usuários finais solicitam os serviços de Tecnologia da Informação para melhorar a eficiência dos seus próprios processos de negócio, de forma que
Leia mais1 http://www.google.com
1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou
Leia maisFá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 maisSistema Gerenciador de Conteúdo OpenCms: um caso de sucesso no CEFET-MG
Sistema Gerenciador de Conteúdo OpenCms: um caso de sucesso no CEFET-MG Marco T. A. Rodrigues*, Paulo E. M. de Almeida* *Departamento de Recursos em Informática Centro Federal de Educação Tecnológica de
Leia maisGlossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.
Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis
Leia maisEngenharia 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 maisFATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios
FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Cruzeiro SP 2008 FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Projeto de trabalho de formatura como requisito
Leia maisPONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1132 Processo e qualidade de software II Prof. Me. Elias Ferreira Sala: 402 E Quarta-Feira:
Leia maisAUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0
AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação
SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar
Leia maisSISTEMAS DISTRIBUÍDOS
SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias
Leia maisSistemas Distribuídos
Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor
Leia maisAula 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 maisTó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 maisComo melhorar a Qualidade de Software através s de testes e nua. Cláudio Antônio de Araújo 22/11/2008
Como melhorar a Qualidade de Software através s de testes e integração contínua. nua. Cláudio Antônio de Araújo 22/11/2008 Objetivos Fornecer uma visão geral da área de testes de software, com ênfase em
Leia maisDIRETRIZES DE ORIENTAÇÃO DAS ATIVIDADES DO TRABALHO DE CURSO
Manual de Orientação das Atividades do Trabalho de Conclusão de Curso INSTITUTO DE ENSINO SUPERIOR DE RIO VERDE - IESRIVER CURSO DE ADMINISTRAÇÃO DIRETRIZES DE ORIENTAÇÃO DAS ATIVIDADES DO TRABALHO DE
Leia maisPorque estudar Gestão de Projetos?
Versão 2000 - Última Revisão 07/08/2006 Porque estudar Gestão de Projetos? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para projetos
Leia mais)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR
6LPXODomR GH6LVWHPDV )HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR #5,6. Simulador voltado para análise de risco financeiro 3RQWRV IRUWHV Fácil de usar. Funciona integrado a ferramentas já bastante conhecidas,
Leia maisAPOO Análise e Projeto Orientado a Objetos. Requisitos
+ APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas
Leia maisMetodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi
Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia
Leia maisSistemas de Informação I
+ Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,
Leia maisV Semana de Ciência e Tecnologia IFMG - campus Bambuí V Jornada Científica 19 a 24 de novembro de 2012
LEARN IN SQL FERRAMENTA DE AUXÍLIO NO ENSINO-APRENDIZAGEM DE SQL/BANCO DE DADOS Junio MOREIRA 1 ; Silas ANTÔNIO CEREDA DA SILVA 2 ; Marcos VINÍCIUS DE CASTRO SILVA 4 ; Samuel DE OLIVEIRA PERFISTER 5 ;
Leia mais1. Introdução. Avaliação de Usabilidade Página 1
1. Introdução Avaliação de Usabilidade Página 1 Os procedimentos da Avaliação Heurística correspondem às quatro fases abaixo e no final é apresentado como resultado, uma lista de problemas de usabilidade,
Leia maisATIVIDADES PRÁTICAS SUPERVISIONADAS
ATIVIDADES PRÁTICAS SUPERVISIONADAS 4ª Série Informática Industrial CST em Mecatrônica Industrial A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem desenvolvido por meio de um
Leia maisCENTRO DE ENSINO SUPERIOR FABRA GUIA DE APRESENTAÇÃO DA MATÉRIA ESTÁGIO SUPERVISIONADO DO CURSO SISTEMAS DE INFORMAÇÃO
CENTRO DE ENSINO SUPERIOR FABRA GUIA DE APRESENTAÇÃO DA MATÉRIA ESTÁGIO SUPERVISIONADO DO CURSO SISTEMAS DE INFORMAÇÃO Serra 2013 SUMÁRIO INTRODUÇÃO... 3 OBJETIVOS DO ESTÁGIO SUPERVISIONADO.... 4 ACOMPANHAMENTO
Leia maisSUMÁRIO Acesso ao sistema... 2 Atendente... 3
SUMÁRIO Acesso ao sistema... 2 1. Login no sistema... 2 Atendente... 3 1. Abrindo uma nova Solicitação... 3 1. Consultando Solicitações... 5 2. Fazendo uma Consulta Avançada... 6 3. Alterando dados da
Leia maisROTEIRO PARA ELABORAÇÃO DE PROJETOS
APRESENTAÇÃO ROTEIRO PARA ELABORAÇÃO DE PROJETOS Breve histórico da instituição seguido de diagnóstico e indicadores sobre a temática abrangida pelo projeto, especialmente dados que permitam análise da
Leia maisMRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior
MRP II Introdução A lógica de cálculo das necessidades é conhecida há muito tempo Porém só pode ser utilizada na prática em situações mais complexas a partir dos anos 60 A partir de meados da década de
Leia maisProcessos Técnicos - Aulas 4 e 5
Processos Técnicos - Aulas 4 e 5 Trabalho / PEM Tema: Frameworks Públicos Grupo: equipe do TCC Entrega: versão digital, 1ª semana de Abril (de 31/03 a 04/04), no e-mail do professor (rodrigues.yuri@yahoo.com.br)
Leia maisNome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO A4 DATA 23/04/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA
Leia maisPEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0
PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisArpPrintServer. Sistema de Gerenciamento de Impressão By Netsource www.netsource.com.br Rev: 02
ArpPrintServer Sistema de Gerenciamento de Impressão By Netsource www.netsource.com.br Rev: 02 1 Sumário INTRODUÇÃO... 3 CARACTERÍSTICAS PRINCIPAIS DO SISTEMA... 3 REQUISITOS DE SISTEMA... 4 INSTALAÇÃO
Leia maisENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisPodemos encontrar uma figura interessante no PMBOK (Capítulo 7) sobre a necessidade de organizarmos o fluxo de caixa em um projeto.
Discussão sobre Nivelamento Baseado em Fluxo de Caixa. Item aberto na lista E-Plan Podemos encontrar uma figura interessante no PMBOK (Capítulo 7) sobre a necessidade de organizarmos o fluxo de caixa em
Leia maisModelo Cascata ou Clássico
Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação
Leia maisMODELO CMM MATURIDADE DE SOFTWARE
MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo
Leia mais6 Construção de Cenários
6 Construção de Cenários Neste capítulo será mostrada a metodologia utilizada para mensuração dos parâmetros estocásticos (ou incertos) e construção dos cenários com respectivas probabilidades de ocorrência.
Leia maisITIL v3 - Operação de Serviço - Parte 1
ITIL v3 - Operação de Serviço - Parte 1 É na Operação de Serviço que se coordena e realiza as atividades e processos necessários para fornecer e gerenciar serviços em níveis acordados com o usuário e clientes
Leia maisProf. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br
Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Ementa Introdução a Banco de Dados (Conceito, propriedades), Arquivos de dados x Bancos de dados, Profissionais de Banco de dados,
Leia maisDadas a base e a altura de um triangulo, determinar sua área.
Disciplina Lógica de Programação Visual Ana Rita Dutra dos Santos Especialista em Novas Tecnologias aplicadas a Educação Mestranda em Informática aplicada a Educação ana.santos@qi.edu.br Conceitos Preliminares
Leia maisCONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES
CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás
Leia maisAPLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2
APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 Renan J. Borges 1, Késsia R. C. Marchi 1 1 Universidade Paranaense (UNIPAR) Paranavaí, PR Brasil renanjborges@gmail.com, kessia@unipar.br
Leia maisUniversidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares
Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares O Project Management Institute é uma entidade sem fins lucrativos voltada ao Gerenciamento de Projetos.
Leia maisSIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português
1 de 7 28/10/2012 16:47 SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português RESULTADO DO SIMULADO Total de questões: 40 Pontos: 0 Score: 0 % Tempo restante: 55:07 min Resultado: Você precisa
Leia maisProgramação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza
Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões Prof. MSc. Hugo Souza Se você precisar manter informações sobre seus usuários enquanto eles navegam pelo seu site, ou até quando eles saem
Leia mais3 SCS: Sistema de Componentes de Software
3 SCS: Sistema de Componentes de Software O mecanismo para acompanhamento das chamadas remotas se baseia em informações coletadas durante a execução da aplicação. Para a coleta dessas informações é necessário
Leia maisSacix Linux Casa Brasil/Região Norte
Sacix Linux Casa Brasil/Região Norte Bruno de Carvalho de Christo 1 Bruno Lopes Dalmazo 1 Francisco Tiago Avelar 1 1 Acadêmico do Curso de Ciência da Computação Universidade Federal de Santa Maria (UFSM)
Leia maisProduto de Gerenciamento: Business Case
{lang: 'pt-br'} Preliminar Introdução Produto de Gerenciamento: Business Case Esse artigo é parte da nova série de artigos proposta pela Management Plaza e se relaciona aos chamados Produtos de Gerenciamento
Leia maisObjetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.
Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos
Leia mais5 Considerações finais 5.1. Reflexões sobre os resultados
5 Considerações finais 5.1. Reflexões sobre os resultados Ao longo da história o boca a boca sempre se mostrou como um meio eficaz de promoção de produtos e serviços, como advento da Internet esse poder
Leia maisLógica de Programação
Lógica de Programação Softblue Logic IDE Guia de Instalação www.softblue.com.br Sumário 1 O Ensino da Lógica de Programação... 1 2 A Ferramenta... 1 3 Funcionalidades... 2 4 Instalação... 3 4.1 Windows...
Leia maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia mais10 DICAS DE TECNOLOGIA PARA AUMENTAR SUA PRODUTIVIDADE NO TRABALHO
10 DICAS DE TECNOLOGIA PARA AUMENTAR SUA PRODUTIVIDADE NO TRABALHO UMA DAS GRANDES FUNÇÕES DA TECNOLOGIA É A DE FACILITAR A VIDA DO HOMEM, SEJA NA VIDA PESSOAL OU CORPORATIVA. ATRAVÉS DELA, ELE CONSEGUE
Leia maisCHECK - LIST - ISO 9001:2000
REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da
Leia maisAvanços na transparência
Avanços na transparência A Capes está avançando não apenas na questão dos indicadores, como vimos nas semanas anteriores, mas também na transparência do sistema. Este assunto será explicado aqui, com ênfase
Leia maisOrientação a Objetos
1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou
Leia maisDESENVOLVIMENTO DE UM SOFTWARE NA LINGUAGEM R PARA CÁLCULO DE TAMANHOS DE AMOSTRAS NA ÁREA DE SAÚDE
DESENVOLVIMENTO DE UM SOFTWARE NA LINGUAGEM R PARA CÁLCULO DE TAMANHOS DE AMOSTRAS NA ÁREA DE SAÚDE Mariane Alves Gomes da Silva Eliana Zandonade 1. INTRODUÇÃO Um aspecto fundamental de um levantamento
Leia maisBRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:
BRAlarmExpert Software para Gerenciamento de Alarmes A TriSolutions conta com um produto diferenciado para gerenciamento de alarmes que é totalmente flexível e amigável. O software BRAlarmExpert é uma
Leia mais