Ambiente de Requisitos de Software e Testes de Aceitação para Softwares Web Terceirizados
|
|
- Cármen Martini Ramires
- 8 Há anos
- Visualizações:
Transcrição
1 Ambiente de Requisitos de Software e Testes de Aceitação para Softwares Web Terceirizados Rodison dos Santos Ferreira, Anita Maria da Rocha Fernandes Pós-Graduação em Qualidade e Engenharia de Software Universidade do Vale do Itajaí (Univali) Florianópolis SC Brasil rodison@gmail.com, anita.fernandes@univali.br Abstract. Writing requisites and software acceptance tests in a clean way, with rastreability and warranties of a documentation always updated is a big challenge. This paper shows the definition and deployment of a method for requirements specification and acceptance tests to outsourced web systems based on agile methods using tools like FitNesse, Selenium and Prologa to achieve this objective. Resumo. Escrever requisitos e testes de aceitação de software de forma clara, com rastreabilidade e com garantias de que a documentação não fique desatualizada é um grande desafio. Este artigo mostra a definição e implantação de um método de documentação de requisitos e testes de aceitação para sistemas web terceirizados baseado em métodos ágeis com o uso das ferramentas FitNesse, Selenium e Prologa para atingir este objetivo. 1. Introdução Requisitos e testes de aceitação de software são partes importantes do desenvolvimento de sistemas. O desenvolvimento de software começa com a especificação de requisitos. Não adianta nada você ter a melhor equipe de desenvolvedores do mundo se a especificação que eles recebem é incompleta, superficial ou burocrática demais [Helm e Wildt 2014]. Se a especificação de requisitos não for boa, o resultado será a criação de um software que não atende às necessidades do usuário. Segundo Martin et al (2015), um grande problema que muitos projetos acabam enfrentando é o problema de Projeto Morto por Requisitos (Project Death by Requirements). Segundo este conceito, o desenvolvimento inicia com uma boa especificação e com bons desenvolvedores normalmente. Mais tarde, perto do fim do projeto, a equipe descobre que o que os clientes desejavam não é exatamente o que foi implementado e que as partes do sistema não podem ser integradas uma a outra porque suas interfaces são incompatíveis. Isto ocorre devido a vários fatores: porque os requisitos geralmente são escritos na forma de linguagem natural; porque o sistema só consegue ser integrado por completo ao final do projeto; e porque as mudanças que são feitas no sistema se mostram complexas e testá-las se torna muito difícil. Ainda segundo Martin et al (2015), o problema dos requisitos escritos em linguagem natural é que eles são necessários mas não são o suficiente. Isto porque é normal haver má interpretação das descrições de requisitos em linguagem natural. O problema do sistema só ser integrado por completo ao final do projeto é quando não são feitos testes de integração e de aceitação do sistema e, com isso, não se antecipa os problemas de integração que possam vir a existir entre os componentes do sistema ou entre a integração do sistema com outros sistemas externos. E o problema dos testes complexos e difíceis após mudanças, é que testes manuais funcionais baseado nas telas
2 do sistema demoram muito para serem executados, o que implica em um custo muito alto. E como os testes são manuais, é normal para estes testes não considerarem algumas partes do sistema, perdendo a cobertura de testes necessária, o que implica em feedback de testes pobres, tanto que não é raro um sistema ser testado durante dias e mesmo assim ocorrerem vários bugs quando o mesmo entra em produção. Estes problemas de integração se acentuam ainda mais quando não se está desenvolvendo um software, mas sim um módulo de um software terceirizado, onde a equipe não possui acesso ao código-fonte do sistema, pois sem os códigos-fontes fazer testes de integração e aceitação se torna uma tarefa muito mais difícil. Devido a este cenário, o intuito deste artigo é apresentar a proposta de um método de documentação de requisitos e elaboração de testes de aceitação para ferramentas web de terceiros através de um exemplo que foi implantado na equipe do autor na empresa na qual ele trabalha utilizando conceitos de metodologias ágeis e as ferramentas FitNesse, Selenium e Prologa. A seguir, para melhor compreensão do trabalho, serão apresentados o referencial teórico, as ferramentas para especificação de requisitos e testes de aceitação, a criação e implantação do método de especificações de requisitos e testes de aceitação e a conclusão do trabalho. 2. Referencial Teórico Segundo Bourque e Fairley (2014), especificação de requisitos de software estabelece a base para um acordo entre a empresa de desenvolvimento de software e o cliente estipulando o que o produto deve fazer e o que não é esperado que ele faça. Ela permite que uma rigorosa avaliação dos requisitos seja feita antes que se comece a codificação do sistema, reduzindo o redesign. Ela também provê uma base realística para estimativas de prazo, custo e risco do projeto. Geralmente estes requisitos são escritos na forma de linguagem natural, mas eles também podem ser escritos de maneira formal ou semi-formal. Os métodos tradicionais de desenvolvimento de software propõem várias formas de se especificar os requisitos de software. Com o advento dos Métodos Ágeis de desenvolvimento de software, novas formas de se especificar os requisitos surgiram. Métodos Ágeis [Prikladnicki, Willi e Milani 2014] são conjuntos de novos métodos de desenvolvimento de software que começaram a ser criados a partir de meados dos anos 90 em resposta aos antigos processos de desenvolvimento de software considerados excessivamente regrados, lentos, burocráticos e inadequados à natureza da atividade. Estes métodos ágeis são baseados em desenvolvimento iterativo, no qual requisitos e soluções evoluem pela colaboração entre equipes auto-organizadas e multifuncionais, encorajam frequentemente inspeção e adaptação, uma filosofia de liderança, alinhamento entre o desenvolvimento e os objetivos das empresas ou dos clientes e um conjunto de boas práticas de engenharia que permita entregas rápidas e de alta qualidade. Os Métodos Ágeis introduziram vários novos conceitos. Um deles foi o Test Driven Development (Desenvolvimento Orientado a Testes - TDD). Segundo Prikladnicki, Willi e Milani (2014), TDD é um conjunto de técnicas que consistem em conduzir o desenvolvimento a partir de testes criando o código em iterações muito curtas. Estas iterações são compostas pelas seguintes etapas: primeiro se escreve um teste automatizado antes de escrever qualquer código de produção; depois se escreve um
3 código de produção da forma mais rápida e minimalista possível o suficiente para fazer o teste passar com sucesso; então, deve ser feita a refatoração do código, ou seja, devese melhorar o design do código já funcional; e, por último, se roda novamente os testes para garantir que o código continua com seu comportamento externo. Este ciclo deve ser feito com trechos muito pequenos de código, de forma se que possa executar este ciclo em questões de segundos ou minutos. Testes automatizados executados facilmente e com frequência cultivam a confiança na equipe quanto à qualidade do sistema, assim como promovem a coragem e a segurança para modificar o design, já que qualquer passo em falso será detectado imediatamente. Com o advento do TDD, outras variações surgiram, como o Acceptance Test- Driven Development (Desenvolvimento Orientado a Testes de Aceitação - ATDD). Um dos trabalhos mais difíceis em desenvolvimento de software é comunicar claramente o que o sistema deve fazer e o ATDD ajuda muito neste ponto. O ATDD prega que antes de se implementar cada funcionalidade, o time de desenvolvimento deve criar exemplos de uso das funcionalidades. Então estes exemplos devem ser traduzidos para testes de aceitação automatizados. Estes exemplos e testes definem um vocabulário do sistema padronizado, se tornam parte do conhecimento compartilhado do time e definem uma descrição precisa de pronto para cada funcionalidade [Gärtner 2013]. Outra variação do TDD que surgiu foi o Behaviour-Driven Development (Desenvolvimento Orientado a Comportamento - BDD). Segundo North (2015), BDD é uma série de práticas e designs que eliminam algumas das ambiguidades e falta de comunicação que ocorrem entre pessoas técnicas e pessoas de negócio. O BDD utiliza os conceitos oriundos do TDD, porém aplicados a especificação de requisitos. BDD define uma linguagem ubíqua para escrever histórias de usuário usando o padrão: Sendo [X] para definir quem é o ator da história; Posso [Y] para definir a funcionalidade que será feita; Para que [Z] para definir o benefício ou valor da funcionalidade. E para os cenários das histórias, o BDD utiliza o padrão Given-When- Then composto da seguinte forma: Dado que [A] para definir o contexto inicial; Quando [B] para definir quando um evento ocorre; Então [C] para definir quais serão as saídas. Escrevendo as histórias de usuário e cenários usando estes padrões, deve-se então codificar os testes sendo que os nomes dos métodos devem ser as mesmas sentenças destes padrões citados acima. Desta forma, se faz um link entre o código de teste e a especificação escrita desta maneira. Utilizando-se uma ferramenta de BDD, como o JBehave (que será citado mais a frente), é possível executar os testes a partir da especificação. 3. Ferramentas para especificação de requisitos e testes de aceitação Existem várias ferramentas que podem ser utilizadas como ferramentas de especificação de requisitos: Microsoft Word: para se fazer uma especificação de requisitos, um simples editor de texto é uma alternativa, principalmente se a especificação for apenas em linguagem natural. Enterprise Architect (EA) [Sparx Systems 2014]: é uma ferramenta muito completa destinada a especificação de requisitos. Ela possui vários recursos como: elementos para se documentar necessidades do usuário, regras de negócio, casos de uso e até mesmo diagrama de classes de software. Esta ferramenta permite criar cada um
4 dos itens acima como elementos e permite que se criem dependências entre eles, o que permite que seja feito todo o controle de rastreabilidade entre os elementos. A ferramenta possui, inclusive, um mapa de rastreabilidade, que mostra na forma de uma tabela quais elementos estão relacionados entre si. JBehave [JBehave.org 2015]: é uma ferramenta destinada à utilização do BDD. Ele permite descrever os requisitos de software utilizando uma linguagem Given- When-Then, muito parecida com linguagem natural, de forma que tanto desenvolvedores quanto clientes conseguem ler as regras escritas neste formato e entendê-las. Esta ferramenta possui integrações com o código-fonte e com ferramentas de desenvolvimento. Por exemplo, para a linguagem Java, é possível adicionar Annotations nas classes Java para associar os métodos das classes à escrita dos requisitos. Dessa forma, se tem uma ligação direta do código fonte com os requisitos. FitNesse: é um servidor web, uma wiki e uma ferramenta de teste automatizado para software [Martin et al 2015]. É baseado no Framework for Integrated Test (Framework para Teste Integrados - FIT). O FitNesse permite escrever tanto testes unitários quanto testes de aceitação. A grande diferença desta ferramenta em relação às outras, é que os testes são escritos em uma linguagem natural na wiki através de tabelas chamadas Tabelas Fit (também chamadas de Tabelas de Decisão ou Tabelas Verdade), de forma que tanto técnicos quanto não técnicos possam entender e acompanhar os testes e regras que estão sendo utilizadas. Estas tabelas são usadas ao invés de texto puro ou linguagens de programação porque as linhas e colunas da tabela fornecem uma estrutura clara e simples, principalmente porque muitas pessoas já estão acostumadas a usarem tabelas em planilhas, páginas Web e outros documentos. O FitNesse possui dois Sistemas de Teste: o FIT e o Slim (Simple List Invocation Method). O FIT é mais antigo, maior e mais lento e utiliza parse de HTML para executar os testes. O Slim é mais novo, leve, mais rápido e fácil de portar. Estes dois Sistemas de Teste interpretam as tabelas de decisão. As tabelas de decisão usadas pelo FitNesse possuem entradas e saídas. A primeira linha da tabela é o nome da tabela, que representa o nome da classe que rodará o teste. A segunda linha da tabela contém as colunas de cabeçalhos. As primeiras colunas representam as entradas de dados e as últimas colunas representam as ações que serão executadas de acordo com a entrada dos dados. As demais linhas são os dados das entradas e das ações. Cada uma destas outras linhas se tornará um caso de teste. Com todas as combinações possíveis entre as entradas dos dados, se tem a cobertura total do teste para estas condições. O FitNesse ainda permite que os testes sejam executados automaticamente simplesmente clicando em um botão disponível na própria página wiki. Os resultados dos testes aparecem na própria tabela mostrando cores diferentes em caso de sucesso ou falha de forma muito intuitiva. Para que se possa testar sistemas web acessando o sistema como se fosse o usuário final através de navegadores de Internet, se utiliza o Selenium. O Selenium é uma ferramenta de automação de testes voltado principalmente para testes de sistemas web [Selenium Project 2015]. Ele provê uma ferramenta de gravação de testes (chamada SeleniumIDE) que permite exportar os testes gravados para várias linguagens de programação, como o Java, por exemplo, e possui também API s (Application Programming Interface) que permitem que os testes possam ser programados em várias linguagens de programação. Estes testes interagem diretamente com o navegador de internet fazendo ações como cliques de botão, acionamento de opções em combo boxes, seleção de valores da tela, abertura e fechamento de janelas, etc. Uma vez gravados ou
5 programados estes testes, o Selenium permite que eles sejam executados automaticamente em vários navegadores de internet modernos, como o Internet Explorer, Chrome, Firefox, etc., o que permite que os testes verifiquem se o sistema web funciona independentemente do navegador utilizado. 4. Criação e Implantação do Método de Especificações de Requisitos e Testes de Aceitação Como citado anteriormente, foi criado um método de especificação de requisitos e testes de aceitação na equipe da empresa do autor. Esta equipe era responsável por fazer customizações em um sistema web de terceiros. Ela enfrentava problemas principalmente na questão relativa a testes. A equipe não possuía um setor de testes e nem pessoas destinadas cem por cento do tempo à área de testes. No caso, eram os analistas de negócio que faziam os testes das aplicações. Eram testes manuais, alguns baseados em algum templates de testes já existentes e outros baseados em roteiros de testes elaborados pelos mesmos. Neste cenário, estas eram as principais dificuldades encontradas pela equipe: sistemas muito complexos com customizações igualmente complexas; e testes manuais difíceis de serem executados e com execução muito demorada. Como os testes demoravam muito para serem executados manualmente, quando algum erro era encontrado, era necessário corrigir o erro e retestar o sistema todo novamente, o que fazia com que a etapa de testes demorasse muito mais do que o esperado. No fim, a equipe trabalhava em um ciclo de duas semanas de desenvolvimento mas que levava mais de duas semanas de teste. Desta forma se perdia a característica ágil que a equipe buscava alcançar. Outro problema enfrentado pela equipe era a constante mudança de requisitos. Os requisitos anteriormente eram armazenados em arquivos.doc. Tantos eram os requisitos que quando um requisito era alterado, a equipe não conseguia determinar qual era o impacto que uma mudança iria causar. A equipe não possuía uma rastreabilidade dos requisitos com o código e nem mesmo uma rastreabilidade entre os próprios requisitos, de forma que não se sabia quais os códigos seriam afetados pelas mudanças e nem quais os outros requisitos que também seriam afetados. Para resolver este problema de rastreabilidade, a equipe começou a utilizar o software Enterprise Architect (EA). Com ele, a equipe criava elementos que representavam as necessidades do cliente, as regras de negócio e utilizava casos de uso para documentar os requisitos. No entanto não havia uma rastreabilidade direta com o código. Se o código fonte do sistema fosse alterado, a documentação não era alterada automaticamente. O resultado disso eram documentações desatualizadas que perdiam a sua utilidade prática e muitos bugs causados em partes não previstas do código, mesmo depois de passar pela etapa de testes do ciclo de desenvolvimento. Isto em grande parte porque os colaboradores que executavam os testes davam mais ênfase aos testes das funcionalidades que haviam sido alteradas, dando menos ênfase às outras funcionalidades que em teoria não haviam sido impactados. Com a aquisição de um novo sistema destinado a substituir a antiga solução existente na empresa do autor, a equipe viu a oportunidade para que estes problemas não viessem a se repetir no novo software.
6 Pesquisando entre várias soluções disponíveis no mercado e conversando com consultores existentes na própria empresa, a equipe decidiu por utilizar um conjunto de ferramentas que possibilitasse gerenciar melhor os requisitos escritos, mantendo uma rastreabilidade entre os requisitos e entre os requisitos e o código. Bem como fazer com que os requisitos não se tornem desatualizados e que eles possam ser testáveis de forma automática, de forma que os testes dos requisitos não se tornem um gargalo de tempo para as entregas da equipe. Considerando-se as ferramentas analisadas acima, o Word e o EA foram desconsiderados devido à falta de sincronização automática entre o código e a documentação de requisitos. Então pesquisou-se o JBehave e o FitNesse. No fim, apesar das duas ferramentas serem muito parecidas e atenderem as questões citadas acima, o FitNesse foi o escolhido pois um problema que também era enfrentado pela equipe era como disponibilizar a documentação de forma que ficasse fácil para o cliente visualizar os requisitos e que o próprio cliente pudesse alterar estes requisitos e os testes já serem executados informando o impacto da alteração. Como no FitNesse todas as documentações e testes ficam na wiki, o ponto citado acima é atendido pelo FitNesse mas não pelo JBehave. O método utilizado pela equipe do autor do presente artigo, optou por utilizar o ATDD para testar sistemas web terceirizados utilizando o FitNesse para isto. O sistema testado pela equipe foi o IBM SmartCloud Control Desk O Control Desk é uma ferramenta web que permite gerenciar solicitações de serviço para uma empresa. Ele gerencia a criação de solicitações de serviço e todo o seu ciclo de vida desde manter o controle de quem irá atender à solicitação de serviço, o que será feito para atendê-la, gestão de documentos envolvidos na sua resolução, gestão de interações entre a empresa e o cliente que criou a solicitação de serviço e gestão de cumprimento de prazos. O Control Desk está sendo utilizado pela empresa do autor para fazer a gestão das solicitações de serviço de seus clientes. O Control Desk é uma ferramenta altamente adaptável, baseado em fluxos de trabalho que são desenhados dentro da própria ferramenta. Desta forma, pode-se criar fluxos de trabalho extremamente complexos e que precisam ser muito bem testados para garantir a correta utilização do produto. A equipe definiu que três fluxos de trabalho precisariam ser criados dentro do Control Desk: um fluxo de suporte, um fluxo de correções e um fluxo de evoluções. O fluxo de suporte é destinado a atender solicitações de serviço de orientações dos clientes. Quando o cliente possui alguma dúvida ou deseja algum esclarecimento, o fluxo de suporte é executado. O fluxo de correções é executado quando o cliente identifica algum bug em algum dos sistemas desenvolvidos pela empresa do autor e solicita a sua correção. O fluxo de evoluções é executado quando o cliente solicita alguma alteração ou nova funcionalidade nos sistemas. Inicialmente o FitNesse foi utilizado para fazer a especificação e cobertura de testes do fluxo de suporte, que é o primeiro fluxo que foi implantado nesta nova ferramenta. Para isso, o primeiro passo da equipe foi instalar o FitNesse e configurá-lo para começar a funcionar. O próximo passo foi desenhar o processo de suporte que seria criado na ferramenta. Com o processo desenhado, a equipe passou então a escrever todas as funcionalidades que o Control Desk permitiria executar dentro deste fluxo. Para isso foi criada uma página wiki no FitNesse onde foi colocada uma lista simples das funcionalidades. Foram levantadas 19 funcionalidades. Foram nomeados identificadores únicos para estas funcionalidades: de F1 a F19.
7 Para a primeira funcionalidade - funcionalidade de cadastro de solicitação - foram levantadas quais seriam as condições para que ela pudesse ser executada. Foram levantadas 6 condições: o cliente deve ter acesso ao cadastro de solicitação e o cliente deve preencher os campos detalhes, produto, módulo, local e serviço. Criando uma tabela de decisão levando em conta todas as combinações possíveis entre estas 6 condições, temos 64 casos de testes no total para esta funcionalidade. Para ter uma cobertura de testes de 100% das regras desta funcionalidade, deveríamos implementar os 64 casos de teste. No entanto, é preciso avaliar o custo de se implementar estes testes com os resultados práticos que se terão com eles. Às vezes é melhor desenvolver menos testes que tenham uma cobertura mais significante do que implementar todos estes testes. Esta afirmação é feita baseando-se no Princípio de Pareto [Koch 2000] (também conhecido como Princípio 80-20, que diz que 80% das consequências advêm de 20% das causas). Tendo-se isso em conta, se fizermos cerca que 20% dos casos de testes, poderemos prevenir 80% dos problemas. No caso de testes, estes não são valores fixos, mas são apenas exemplos de que se deve fazer a cobertura dos casos mais importantes, se não for possível cobrir todos os casos. Para não ter que desenvolver os 64 casos de teste e encontrar os casos de teste mais significativos, a equipe utilizou um software chamado Prologa [Vanthienen 2015]. Ele é um gerenciador de tabelas de decisão. Entrou-se com as condições para se montar a tabela de decisão neste aplicativo. Ele automaticamente gerou as 64 combinações que se tornariam os 64 casos de teste. Este aplicativo também possui uma funcionalidade de otimizar a tabela de decisão. Com isso, podemos dizer para o aplicativo ignorar a ordem das condições, eliminando desta forma casos de teste que produzem as mesmas ações, o que resultou em bem menos casos de teste que teoricamente cobrem a mesma quantidade problemas. Desta forma, acionando a funcionalidade de simplificação da tabela de decisão, a quantidade de casos de teste foi reduzida para 7 casos de teste. Com a quantidade de casos de testes definidos para esta funcionalidade, então o próximo passo foi exportar a tabela gerada pelo Prologa para o FitNesse. Ao exportar a tabela de decisão para a ferramenta, foi necessário fazer algumas alterações. Primeiro, foi preciso adicionar uma linha na tabela de decisão. Esta tinha que ser a primeira linha da tabela e deveria conter o pacote e nome da classe que iria executar os testes. A outra alteração feita foi alterar as ações para sempre terminar com um ponto de interrogação, é a forma do FitNesse fazer a distinção do que é uma condição e o que é uma ação. Uma vez exportada a tabela para a ferramenta, a tabela foi salva no FitNesse e os testes foram executados no próprio FitNesse. Ao executar os testes se pôde observar que todos os testes falharam pois não havia sido adicionada a classe Java responsável por executar os testes na ferramenta Control Desk. Desta forma, o próximo passo foi criar esta classe Java. Para isso, criou-se um projeto Java e o FitNesse foi configurado para apontar para o diretório onde se localizavam os códigos fontes desse projeto. Então, criou-se a classe Java para a execução dos testes. No caso, a equipe utilizou o padrão F1CadastrarSolicitacaoFixture como nome da classe responsável por executar os testes da funcionalidade F1 - Cadastrar Solicitação. Para os testes da funcionalidade 2 foi criada a classe F2AvaliarSolicitacaoFixture e assim por diante. Nesta classe, criou-se um método set para cada condição da tabela de decisão e criou-se um método para cada ação da tabela. Os métodos set devem ter o nome das condições escritas na tabela de decisão. Por exemplo, se existe uma entrada de dados
8 "Usuário tem acesso à tela", deve ter um método "setusuariotemacessoatela". Os métodos de ação devem ter o mesmo nome das ações da tabela de decisão. Se existe uma ação "Cadastrar Solicitação?", deve existir um método "cadastrarsolicitacao". Os métodos set devem receber por parâmetro os valores das condições da tabela de decisão. Já os métodos das ações devem ser programados para executar os testes no sistema alvo usando os valores das condições que foram atribuídos nos métodos set. Após a execução do teste, os métodos das ações devem retornar o valor que foi definido na tabela de decisão, mesmo que seja um valor boleano dizendo se a ação foi executada com sucesso ou não. Neste caso, os métodos de ações devem executar testes no Control Desk. Para os testes das funcionalidades, foram gravados os testes no SeleniumIDE para cada um dos 7 casos de testes da funcionalidade 1 e exportados para a linguagem Java para que eles pudessem ser chamados pela classe F1CadastrarSolicitacaoFixture. Uma vez alterada a classe F1CadastrarSolicitacaoFixture para executar os testes do Selenium, ao mandar executar o teste direto no FitNesse, o FitNesse passou a mostrar as linhas da tabela de decisão em verde quando o teste foi executado corretamente ou em vermelho se algum teste falhou. Desde que este método começou a ser implantado, já foram encontrados cerca de 30 bugs que não haviam sido previstos inicialmente e que foram descobertos ao se executar os testes do FitNesse. Também já foram realizadas 2 alterações nas configurações do Control Desk onde foi identificado que seria necessário alterar 5 funcionalidades configuradas no Control Desk após alterar as tabelas de decisão para refletir as alterações solicitadas e executar os testes do FitNesse. 5. Conclusão Com este método é possível então listar todas as funcionalidades de um sistema web terceirizado, definir as suas regras de negócio através de tabelas de decisão, definir qual será a cobertura de teste que será implementado em cima de todas as combinações possíveis das tabelas de decisão e garantir que o software atende às regras de negócio. Foram encontrados benefícios que foram além das benfeitorias relatadas na literatura de cada conceito e ferramentas. Alguns exemplos serão listados abaixo: organização da documentação do sistema, versionamento da documentação e das regras do sistema, rastreabilidade indireta entre funcionalidades e requisitos, documentação executável e sempre atualizada, aumento da confiança da equipe para desenvolver novas funcionalidades ou realizar alterações no sistema, aumento do acerto das estimativas para se fazer uma nova funcionalidade ou alteração e realizar alterações no sistema e maior garantia ao se fazer atualizações do sistema. Organização da documentação do sistema: como o FitNesse também é um servidor wiki, todas as informações do projeto foram documentadas no FitNesse, centralizando toda a documentação do sistema em um único ponto. Antes as documentações ficavam espalhadas em vários pontos: no Enterprise Architect (ferramenta que era utilizada para se documentar das regras de negócio), em arquivos do Microsoft Word, no sistema de versionamento da empresa (foi utilizado o Microsoft Team Foundation Server, o TFS), na wiki corporativa da empresa, no antigo sistema de gerenciamento de solicitações da empresa, em s, etc. Outro ponto positivo é que além da documentação ter ficado centralizada em um único ponto, o próprio cliente
9 pôde acessar a documentação do sistema pois além de ficar disponível para ele, a documentação das funcionalidades e regras de negócio ficou escrita de uma forma prática e facilmente compreensível pois não existem detalhes técnicos nas regras de negócio escritas. Versionamento da documentação e das regras do sistema: todas as páginas wiki do FitNesse são armazenadas no formato simples de texto. Dessa forma, foi possível adicioná-las no sistema de versionamento da empresa. No caso do autor, as páginas do FitNesse foram adicionadas ao TFS. Desta forma, sempre que se aplicava um rótulo de nova versão no TFS, toda a documentação também recebia o rótulo da nova versão. Desta forma, ao se recuperar alguma versão antiga das configurações do Control Desk também se obtém quais eram as regras de negócio válidas naquele momento. Rastreabilidade indireta entre Funcionalidades e Requisitos: como já citado acima, os testes permitiram saber quais funcionalidades e requisitos estão relacionados de forma indireta. É de forma indireta pois é necessário algum teste quebrar para que se veja quais funcionalidades e requisitos estão relacionados. Documentação Executável e sempre atualizada: com o FitNesse é possível aplicar o conceito de Documentação Executável [Shore 2008]. Isto porque se a documentação for atualizada e as configurações do Control Desk não, os testes irão quebrar. E da mesma forma, se algum desenvolvedor resolver alterar as configurações do Control Desk sem atualizar a documentação, os testes também irão quebrar. Desta forma, todos os desenvolvedores se obrigam sempre a manter a documentação atualizada. Aumento da confiança da equipe para desenvolver novas funcionalidades ou realizar alterações no sistema: ao realizar alterações no sistema ou desenvolver novas funcionalidades, era só executar os testes do FitNesse para ver quais funcionalidades tinham deixado de funcionar. Os testes dão esta garantia de que alterações não se tornarão sinônimo de bugs em produção. Aumento do acerto das estimativas para se fazer uma nova funcionalidade ou alteração: quando se é necessário fazer uma alteração, é só, inicialmente, alterar o código da configuração da funcionalidade que se deseja alterar que os testes já mostrarão quais funcionalidades e regras de negócio terão que ser alteradas. Com esta informação é mais fácil fazer uma estimativa mais realista sobre o esforço necessário para fazer a alteração. Maior garantia ao se fazer atualizações do sistema: uma grande preocupação sempre é aplicar grandes atualizações de sistemas terceirizados como o Control Desk. Afinal, sempre que se aplica uma grande atualização, muitas configurações e adaptações realizadas deixam de funcionar. Embora o autor ainda não tenha passado por uma situação destas, espera-se que com os testes do FitNesse se possa identificar mais facilmente funcionalidades que deixem de funcionar devido a alguma atualização do sistema. Porém, alguns pontos negativos também foram identificados com o uso deste método: tempo gasto com a documentação e testes automatizados, falta de uma rastreabilidade direta entre Funcionalidades e Requisitos, falta de uma rastreabilidade com o código, necessidade de se gerar novamente toda a tabela de decisão quando a alteração é muito grande e demora na execução dos testes de Selenium.
10 Tempo gasto com a documentação e testes automatizados: aumentou o tempo gasto com documentação. Já que a atualização da documentação se tornou obrigatória, agora é necessário sempre gastar mais tempo com a documentação. E uma vez que se trabalha com tabelas de decisão, são descobertos mais casos de teste que devem ser implementados do que da forma antiga que a equipe trabalhava. Antes os casos de teste e sua quantidade eram determinados pela experiência do analista de negócio. Porém muitos casos de teste não eram feitos pois não se achava necessário. Porém, com a tabela de decisão se descobrem muito mais casos de teste. E um ponto ruim em se precisar de mais tempo para documentação e teste é ter que convencer os gestores de que este tempo é realmente necessário até que se tenha os dados que demonstrem que um esforço maior em documentação e testes reduzem a quantidade de bugs que vão para a produção. Falta de uma rastreabilidade direta entre Funcionalidades e Requisitos: como já citado, a rastreabilidade existente com a metodologia é a rastreabilidade indireta entre as funcionalidades e requisitos. A rastreabilidade é indireta pois é necessário quebrar os testes para se identificar quais funcionalidades e requisitos estão relacionados um com o outro. O ideal seria que o FitNesse ou alguma outra ferramenta gerasse uma matriz de rastreabilidade automaticamente entre as funcionalidades e requisitos. Falta de uma rastreabilidade com o código: na verdade este não chega a ser um problema do FitNesse, uma vez que ele permite que sejam executados testes caixa branca como testes unitários e testes de integração. O problema mesmo é devido à natureza do sistema testado. Como o Control Desk é um sistema terceirizado a equipe não possui acesso ao código-fonte. Por isso não é possível fazer uma rastreabilidade com o código. Necessidade de se gerar novamente toda a tabela de decisão quando a alteração é muito grande: quando a alteração de uma funcionalidade é muito grande, às vezes compensa mais gerar uma nova tabela de decisão do zero no Prologa e então adicioná-la e configurá-la novamente no FitNesse do que alterar a tabela de decisão já existente devido à grande quantidade de casos de teste identificados em uma funcionalidade. Talvez se houvesse alguma integração entre o Prologa e o FitNesse, estas alterações poderiam ser facilitadas. Demora na execução dos testes de Selenium: testes de Selenium demoram muito para ser executados. Embora a cada versão o Selenium esteja ficando mais rápido, ele ainda é muito lento se comparado a testes unitários, por exemplo. Isto porque ele precisa abrir o Firefox para executar os testes, carregá-lo, executar os testes e então fechar o Firefox. Principalmente o tempo de processamento e memória gastos para abrir o navegador é muito grande. Rodar todos os testes do FitNesse do projeto pode demorar algumas horas. E um dos princípios das metodologias ágeis é a Construção em 10 Minutos (Ten Minute Build). Segundo Shore (2008), um desenvolvedor deve ser capaz de construir, testar e instalar o sistema inteiro a qualquer momento ao clicar de um botão. Isto porque todo desenvolvedor deve ser capaz de saber a qualquer momento se é possível atualizar o sistema em produção neste momento e se o software está funcionando. Não ser capaz de responder estas questões frustra o desenvolvedor. Fazer uma construção automatizada e rápida é a forma mais fácil de aumentar a moral da equipe e aumentar a sua produtividade. Outro ponto é que nenhum desenvolvedor deve quebrar a construção do código. Se a construção for quebrada, o desenvolvedor deve
11 desfazer suas alterações no repositório do sistema e então corrigir o código na sua máquina. Se cada vez que a construção rodar ela demorar horas, são horas que o desenvolvedor terá que esperar até ter certeza que tudo está funcionando corretamente. Ou, pior ainda, se o desenvolvedor começar a trabalhar em uma nova funcionalidade enquanto a construção é executada e, depois de horas, a construção finalizar e informar que o desenvolvedor quebrou a construção, daí o desenvolvedor terá que parar a nova funcionalidade que estava fazendo, perdendo assim o seu foco, e corrigir o código que quebrou a construção. Com isso, conclui-se que esta metodologia vale a pena ser utilizada devido a todos os pontos positivos encontrados durante a execução da mesma. Como melhorias futuras, pode-se expandir esta metodologia para se utilizar em softwares desenvolvidos pela própria empresa. Dessa forma, tendo acesso ao código fonte do sistema, é possível usar o FitNesse também para execução de testes caixa branca como testes unitários e testes de integração, o que proporcionaria criar uma rastreabilidade indireta das funcionalidades e regras de negócio até o nível do código-fonte. Uma outra melhoria futura é utilizar o Selenium Grid2, que possibilita escalar a execução dos testes do Selenium em várias máquinas distribuídas, o que dessa forma permitiria que os testes rodassem de forma mais rápida. Referências Bourque, P. e Fairley, R. E. (2014) SWEBOK V3.0: Guide to the Software Engineering Body of Knowledge, IEEE Computer Society. Gärtner, M. (2013) ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, Addison-Wesley. Helm, R. e Wildt, D. (2014), Histórias de Usuário: Porque e Como Escrever Requisitos de Forma Ágil?, Historiasdeusuario.com.br, 2ª edição. JBehave.org (2015), What is JBehave?, fevereiro. Koch, R (2000) O Princípio 80/20: O segredo de se fazer mais com menos, Rocco. Martin, R. C. et al. (2015), FitNesse User Guide, fevereiro. Mugridge, R. e Cunningham, W. (2005), Fit for Developing Software: Framework for Integrated Tests, Prentice Hall Press. North, D. (2015) Introducing BDD, fevereiro. Prikladnicki, R., Willi, R. e Milani, F. (2014) Métodos ágeis Para Desenvolvimento De Software, Bookman. Selenium Project. (2015), SeleniumHQ: Browser Automation, fevereiro. Shore, J. e Warden, S. (2008), The Art of Agile Development, O Reilly. Sparx Systems. (2014), Requirements Management with Enterprise Architect, Sparx Systems. Vanthienen, J. e Dries, E. (2015), Tabular Decision Modeling and Prologa, fevereiro.
4 O Workflow e a Máquina de Regras
4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu
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 maisPlano de Gerenciamento do Projeto
Projeto para Soluções Contábeis 2015 Plano de Gerenciamento do Projeto Baseado na 5ª edição do Guia PMBOK Brendon Genssinger o e Elcimar Silva Higor Muniz Juliermes Henrique 23/11/2015 1 Histórico de alterações
Leia mais02 - Usando o SiteMaster - Informações importantes
01 - Apresentação do SiteMaster - News Edition O SiteMaster foi desenvolvido para ser um sistema simples de gerenciamento de notícias, instalado em seu próprio computador e com configuração simplificada,
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 maisManual do Visualizador NF e KEY BEST
Manual do Visualizador NF e KEY BEST Versão 1.0 Maio/2011 INDICE SOBRE O VISUALIZADOR...................................................... 02 RISCOS POSSÍVEIS PARA O EMITENTE DA NOTA FISCAL ELETRÔNICA.................
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 maisManual de Utilização
Manual de Utilização Versão 1.0 18/01/2013 Sempre consulte por atualizações deste manual em nossa página. O Cotação Web está em constante desenvolvimento, podendo ter novas funcionalidades adicionadas
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 maisGerenciamento de Projetos
Gerenciamento de Projetos O objetivo do módulo de Gerenciamento de Projetos é ajudar a empresa a gerenciar com mais eficiência os seus projetos. Controle dos prazos, das tarefas, dos eventos, da quantidade
Leia maisOI CONTA EMPRESA MANUAL DO USUÁRIO
OI CONTA EMPRESA MANUAL DO USUÁRIO 1 Bem-vindo ao Oi Conta Empresa! A Oi tem o orgulho de lançar mais um produto para nossos clientes corporativos, o Oi Conta Empresa. Nele, nossos clientes poderão acessar
Leia maisManual de configuração do sistema
Manual de configuração do sistema (v.1.5.x Beta) Rua México, 119 Sala 2004 Centro Rio de Janeiro, RJ www.doctors-solution.com.br www.simdoctor.com.br contato@simdoctor.com.br Sumário 1. Fazendo seu primeiro
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 maisExportação e Importação de Orçamentos
Exportação e Importação de Orçamentos Copyright 2013 By Softplan. Rod. José Carlos Daux, km 1, Nº 10 Centro de Tecnologia Ilhasoft - ParqTec Alfa João Paulo Florianópolis SC CEP 88030-000 Telefone: (48)
Leia maisMANUAL DE UTILIZAÇÃO
MANUAL DE UTILIZAÇÃO Módulo de operação Ativo Bem vindo à Vorage CRM! Nas próximas paginas apresentaremos o funcionamento da plataforma e ensinaremos como iniciar uma operação básica através do nosso sistema,
Leia maisXP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br
XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso
Leia maisDesenvolvendo Websites com PHP
Desenvolvendo Websites com PHP Aprenda a criar Websites dinâmicos e interativos com PHP e bancos de dados Juliano Niederauer 19 Capítulo 1 O que é o PHP? O PHP é uma das linguagens mais utilizadas na Web.
Leia maisEntendendo como funciona o NAT
Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços
Leia maisManual Geral do OASIS
Manual Geral do OASIS SISTEMA DE GESTÃO DE DEMANDA, PROJETO E SERVIÇO DE TECNOLOGIA DA INFORMAÇÃO OASIS Introdução Esse manual tem como objetivo auxiliar aos usuários nos procedimentos de execução do sistema
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 maisTópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.
Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico
Leia maisGUIA INTEGRA SERVICES E STATUS MONITOR
GUIA INTEGRA SERVICES E STATUS MONITOR 1 - Integra Services Atenção: o Integra Services está disponível a partir da versão 2.0 do software Urano Integra. O Integra Services é um aplicativo que faz parte
Leia maisUNIDADE 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 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 maisa) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema
Simulado CTFL- BSTQB Tempo de duração: 60 minutos 1. Considerando as seguintes afirmações: I. 100% de cobertura de sentença (comando) garante 100% de cobertura de desvio II. 100% de cobertura de desvio
Leia maisDesenvolvimento Ágil de Software
Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento
Leia maisBarra de ferramentas padrão. Barra de formatação. Barra de desenho Painel de Tarefas
Microsoft Power Point 2003 No Microsoft PowerPoint 2003, você cria sua apresentação usando apenas um arquivo, ele contém tudo o que você precisa uma estrutura para sua apresentação, os slides, o material
Leia maisDicas para usar melhor o Word 2007
Dicas para usar melhor o Word 2007 Quem está acostumado (ou não) a trabalhar com o Word, não costuma ter todo o tempo do mundo disponível para descobrir as funcionalidades de versões recentemente lançadas.
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 maisIntegração Contínua com Rational Team Concert, Jenkins e SonarQube
Integração Contínua com Rational Team Concert, Jenkins e SonarQube Agenda 1. Introdução à Integração Contínua 2. Ferramentas 3. Solução de Integração Contínua em Furnas 4. Demonstração O que é a Integração
Leia maisOI CONTA EMPRESA MANUAL DO USUÁRIO (exceto Administradores de Conta)
OI CONTA EMPRESA MANUAL DO USUÁRIO (exceto Administradores de Conta) 1 Bem-vindo ao Oi Conta Empresa! A Oi tem o orgulho de lançar mais um produto para nossos clientes corporativos, o Oi Conta Empresa.
Leia maisReferências internas são os artefatos usados para ajudar na elaboração do PT tais como:
Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código
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 maisGuia Site Empresarial
Guia Site Empresarial Índice 1 - Fazer Fatura... 2 1.1 - Fazer uma nova fatura por valores de crédito... 2 1.2 - Fazer fatura alterando limites dos cartões... 6 1.3 - Fazer fatura repetindo última solicitaçã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 maisChannel. Visão Geral e Navegação. Tutorial. Atualizado com a versão 3.9
Channel Visão Geral e Navegação Tutorial Atualizado com a versão 3.9 Copyright 2009 por JExperts Tecnologia Ltda. todos direitos reservados. É proibida a reprodução deste manual sem autorização prévia
Leia maisJonas de Souza H2W SYSTEMS
Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição
Leia maisEngenharia de Requisitos Estudo de Caso
Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este
Leia maisSumário INTRODUÇÃO... 3. 1. Acesso ao Ambiente do Aluno... 4. 2. Ferramentas e Configurações... 5. 2.1 Ver Perfil... 5. 2.2 Modificar Perfil...
Sumário INTRODUÇÃO... 3 1. Acesso ao Ambiente do Aluno... 4 2. Ferramentas e Configurações... 5 2.1 Ver Perfil... 5 2.2 Modificar Perfil... 6 2.3 Alterar Senha... 11 2.4 Mensagens... 11 2.4.1 Mandando
Leia maisCálculo utilizando variáveis do tipo DATA
Cálculo utilizando variáveis do tipo DATA Pré requisitos: Elaboração de questionário Análise de resultados Visões: relatórios multimídia Publicação de questionário na internet O uso de variáveis do tipo
Leia maisDistribuidor de Mobilidade GUIA OUTSOURCING
Distribuidor de Mobilidade GUIA OUTSOURCING 1 ÍNDICE 03 04 06 07 09 Introdução Menos custos e mais controle Operação customizada à necessidade da empresa Atendimento: o grande diferencial Conclusão Quando
Leia maisGoogle Drive. Passos. Configurando o Google Drive
Google Drive um sistema de armazenagem de arquivos ligado à sua conta Google e acessível via Internet, desta forma você pode acessar seus arquivos a partir de qualquer dispositivo que tenha acesso à Internet.
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 maisACOMPANHAMENTO GERENCIAL SANKHYA
MANUAL DE VISITA DE ACOMPANHAMENTO GERENCIAL SANKHYA Material exclusivo para uso interno. O QUE LEVA UMA EMPRESA OU GERENTE A INVESTIR EM UM ERP? Implantar um ERP exige tempo, dinheiro e envolve diversos
Leia maisAPOSTILA DE EXEMPLO. (Esta é só uma reprodução parcial do conteúdo)
APOSTILA DE EXEMPLO (Esta é só uma reprodução parcial do conteúdo) 1 Índice Aula 1 - Área de trabalho e personalizando o sistema... 3 A área de trabalho... 3 Partes da área de trabalho.... 4 O Menu Iniciar:...
Leia maisDespachante Express - Software para o despachante documentalista veicular DESPACHANTE EXPRESS MANUAL DO USUÁRIO VERSÃO 1.1
DESPACHANTE EXPRESS MANUAL DO USUÁRIO VERSÃO 1.1 1 Sumário 1 - Instalação Normal do Despachante Express... 3 2 - Instalação do Despachante Express em Rede... 5 3 - Registrando o Despachante Express...
Leia maisRegistro e Acompanhamento de Chamados
Registro e Acompanhamento de Chamados Contatos da Central de Serviços de TI do TJPE Por telefone: (81) 2123-9500 Pela intranet: no link Central de Serviços de TI Web (www.tjpe.jus.br/intranet) APRESENTAÇÃO
Leia maisAdapti - Technology Solutions www.adapti.net Leonor cardoso nº 331 Fone : (041) 8844-7805 81240-380 Curitiba - PR MANUAL DO USUÁRIO
MANUAL DO USUÁRIO 1 Índice Administração de Documentos...2 Lista de documentos criados...3 Criando um novo documento...3 Barra de ferramentas do editor...4 Editando um documento...7 Administrando suas
Leia maisGuia de boas práticas para realização de Backup
Objetivo Quando o assunto é backup de dados, uma proposição de atividades e procedimentos como sendo a melhor prática pode ser bastante controversa. O que permanece verdadeiro, porém, é que seguir algumas
Leia maisMicrosoft Access XP Módulo Um
Microsoft Access XP Módulo Um Neste primeiro módulo de aula do curso completo de Access XP vamos nos dedicar ao estudo de alguns termos relacionados com banco de dados e as principais novidades do novo
Leia maisManual do Sistema "Coelho - Sistema de Analise Loterica" Editorial Brazil Informatica
Manual do Sistema "Coelho - Sistema de Analise Loterica" Editorial Brazil Informatica I Coelho - Sistema de Analise Loterica Conteudo Part I Introdução 2 1 Coelho- Sistema... de Analise Loterica 2 Part
Leia maisApresentação. Nossa sugestão é que você experimente e não tenha medo de clicar!!!
Apresentação Este manual é uma orientação para os participantes de cursos no ambiente Moodle do INSTITUTO PRISMA. Tem como objetivo orientar sobre as ações básicas de acesso e utilização do ambiente virtual
Leia maisApostilas OBJETIVA Escrevente Técnico Judiciário TJ Tribunal de Justiça do Estado de São Paulo - Concurso Público 2015. Caderno 1.
Caderno 1 Índice MS-Windows 7: conceito de pastas, diretórios, arquivos e atalhos, área de trabalho, área de transferência, manipulação de arquivos e pastas, uso dos menus, programas e aplicativos, interação
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 maisO papel do CRM no sucesso comercial
O papel do CRM no sucesso comercial Escrito por Gustavo Paulillo Você sabia que o relacionamento com clientes pode ajudar sua empresa a ter mais sucesso nas vendas? Ter uma equipe de vendas eficaz é o
Leia maisGUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas
PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas
Leia maisSistema de Digitalização e Gerenciamento de Arquivos On-Line
Sistema de Digitalização e Gerenciamento de Arquivos On-Line O aplicativo Aplicativo com quase 3 anos de mercado, onde gerencia atualmente mais de 500.000 arquivos sendo eles entre digitalizados ou anexados
Leia maisSISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO
SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO AGOSTO DE 2013 SUMÁRIO STI/UFF - Sistema de Gerenciamento de Projetos do PDI SUMÁRIO... 2 1 Introdução... 3 1.1 O que é e qual a finalidade
Leia maisAula 01 - Formatações prontas e condicionais. Aula 01 - Formatações prontas e condicionais. Sumário. Formatar como Tabela
Aula 01 - Formatações prontas e Sumário Formatar como Tabela Formatar como Tabela (cont.) Alterando as formatações aplicadas e adicionando novos itens Removendo a formatação de tabela aplicada Formatação
Leia maisPMAT. Sistema de Análise e Acompanhamento de Operações. Manual. Desenvolvido pelo BNDES AS/DEGEP
PMAT Sistema de Análise e Acompanhamento de Operações Manual 1 Índice 1. O que é o Sistema de Análise e Acompanhamento de Operações PMAT... 3 2. Acessando o sistema pela primeira vez Download... 3 3. Fluxogramas
Leia maisVVS Sistemas (21)3405-9500
Índice Assunto Página Apresentação... 2 Funcionamento do Módulo... 3 Instalação do Módulo... 4 Configurações no C-Plus NF-e... 9 Acessando os arquivos... 11 Apresentação Apresentamos o módulo C-Plus NF-e
Leia maisGUIA BÁSICO DA SALA VIRTUAL
Ambiente Virtual de Aprendizagem - MOODLE GUIA BÁSICO DA SALA VIRTUAL http://salavirtual.faculdadesaoluiz.edu.br SUMÁRIO 1. Acessando Turmas 4 2. Inserindo Material 4 3. Enviando Mensagem aos Alunos 6
Leia maisTarefas em Moodle (1.6.5+)
(1.6.5+) Ficha Técnica Título Tarefas em Moodle Autor Athail Rangel Pulino Filho Copyright Creative Commons Edição Agosto 2007 Athail Rangel Pulino 2 Índice Tarefas 4 Criando uma tarefa 4 Configuração
Leia maisMelhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson
QUALIDADE Simpósio Brasileiro de Qualidade de Software - SBQS Instituto Nokia de Tecnologia Unit Test Sucess Bug INdT Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua
Leia maisCOMO FAZER A TRANSIÇÃO
ISO 9001:2015 COMO FAZER A TRANSIÇÃO Um guia para empresas certificadas Antes de começar A ISO 9001 mudou! A versão brasileira da norma foi publicada no dia 30/09/2015 e a partir desse dia, as empresas
Leia maisFollow-Up Acompanhamento Eletrônico de Processos (versão 3.0) Manual do Sistema. 1. Como acessar o sistema Requisitos mínimos e compatibilidade
do Sistema Índice Página 1. Como acessar o sistema 1.1 Requisitos mínimos e compatibilidade 03 2. Como configurar o Sistema 2.1 Painel de Controle 2.2 Informando o nome da Comissária 2.3 Escolhendo a Cor
Leia maisDesenvolvimento de Interfaces Prototipação
Autarquia Educacional do Vale do São Francisco AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Centro de Engenharia e Ciências Tecnológicas CECT Curso de Ciência da Computação Desenvolvimento
Leia maisInventario de produtos
Inventario de produtos Parar o TAC. Gerar o inventario. Informações de erros na importação de produtos. Produtos sem código tributário associado. A posse de produtos no Thotau. Como corrigir as posses
Leia maisTutorial Folha Express. Como otimizar a confecção da folha de pagamento.
Tutorial Folha Express Como otimizar a confecção da folha de pagamento. Índice Apresentação Pág. 2 Passo 1 Pág. 3 Disponibilização da Folha de Pagamento Passo 2 Pág. 5 Exportação de clientes e Folha de
Leia maisTreinamento GVcollege Módulo Acadêmico - Pedagógico
Treinamento GVcollege Módulo Acadêmico - Pedagógico 2015 GVDASA Sistemas Pedagógico 2 AVISO O conteúdo deste documento é de propriedade intelectual exclusiva da GVDASA Sistemas e está sujeito a alterações
Leia maisBanco de Dados. Microsoft Access
Banco de Dados Microsoft Access PARTE 01 edição 2007 Índice 01-) Conceito... 2 02) Sistema Gerenciador de Banco de Dados Relacional (SGBDR)... 3 03) Access... 3 04) Etapas para elaboração de um Banco de
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 maisMúltiplos Estágios processo com três estágios Inquérito de Satisfação Fase II
O seguinte exercício contempla um processo com três estágios. Baseia-se no Inquérito de Satisfação Fase II, sendo, por isso, essencial compreender primeiro o problema antes de começar o tutorial. 1 1.
Leia maisMANUAL DE UTILIZAÇÃO SISTEMA DE CADASTRO INTRANET
MANUAL DE UTILIZAÇÃO SISTEMA DE CADASTRO INTRANET I Sumário 1. Objetivo do Documento... 1 2. Início... 1 3. Cadastro de Pessoa Física... 3 3.1. Preenchimentos Obrigatórios.... 4 3.2. Acesso aos Campos
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 mais15. OLHA QUEM ESTÁ NA WEB!
7 a e 8 a SÉRIES / ENSINO MÉDIO 15. OLHA QUEM ESTÁ NA WEB! Sua home page para publicar na Internet SOFTWARES NECESSÁRIOS: MICROSOFT WORD 2000 MICROSOFT PUBLISHER 2000 SOFTWARE OPCIONAL: INTERNET EXPLORER
Leia maisManual do Google agenda. criação e compartilhamento de agendas
Manual do Google agenda criação e compartilhamento de agendas 1 O que é o Google Agenda? Google Agenda é um serviço de agenda on line gratuito do Google, onde você pode anotar compromissos e tarefas, organizando
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 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 maisMANUAL DE UTILIZAÇÃO DO SISTEMA GLPI
MANUAL DE UTILIZAÇÃO DO SISTEMA GLPI PERFIL TÉCNICO Versão 2.0 DEPARTAMENTO DE INFORMÁTICA E TELECOMUNICAÇÕES PREFEITURA DE GUARULHOS SP 1 Objetivo: Esse manual tem como objetivo principal instruir os
Leia maisAmbientação JAVA. Versão 0.1 MICHEL CORDEIRO ANALISTA DE NEGÓCIO (NTI 2014) 1 UNIVERSIDADE CEUMA 08/01/2014
UNIVERSIDADE CEUMA Ambientação JAVA Versão 0.1 08/01/2014 Este é um modelo de configuração para desenvolvimento no ambiente Java. MICHEL CORDEIRO ANALISTA DE NEGÓCIO (NTI 2014) 1 Sumário Sumário... 2 1
Leia maisManual Portal Ambipar
Manual Portal Ambipar Acesso Para acessar o Portal Ambipar, visite http://ambipar.educaquiz.com.br. Login Para efetuar o login no Portal será necessário o e-mail do Colaborador e a senha padrão, caso a
Leia maisPlano 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 maisManual do Ambiente Moodle para Professores
UNIVERSIDADE FEDERAL DA FRONTEIRA SUL Manual do Ambiente Moodle para Professores Tarefas Versão 1.0b Setembro/2011 Direitos Autorais: Essa apostila está licenciada sob uma Licença Creative Commons 3.0
Leia maisINSTRUMENTO NORMATIVO 004 IN004
1. Objetivo Definir um conjunto de critérios e procedimentos para o uso do Portal Eletrônico de Turismo da Região disponibilizado pela Mauatur na Internet. Aplica-se a todos os associados, empregados,
Leia maisGestão de Relacionamento com o Cliente CRM
Gestão de Relacionamento com o Cliente CRM Fábio Pires 1, Wyllian Fressatti 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil pires_fabin@hotmail.com wyllian@unipar.br RESUMO. O projeto destaca-se
Leia maisAssociação Educacional Dom Bosco Curso de Engenharia 1º ano
Formatação condicional utilizando o valor da célula O que é? Algumas vezes é preciso destacar os valores, ou seja, como colocar em vermelho ou entre parênteses, os negativos, e de outra cor os positivos,
Leia maisCOMO EXPLORAR OS BENEFÍCIOS DOS INDICADORES DE DESEMPENHO NA GESTÃO DE UM CSC. Lara Pessanha e Vanessa Saavedra
COMO EXPLORAR OS BENEFÍCIOS DOS INDICADORES DE DESEMPENHO NA GESTÃO DE UM CSC Lara Pessanha e Vanessa Saavedra A utilização de indicadores de desempenho é uma prática benéfica para todo e qualquer tipo
Leia maisCom metodologias de desenvolvimento
Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente
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 maisEDITORES DE TEXTO Capítulo 1: Avaliação técnica e econômica dos principais editores de texto do mercado.
Nome: Nº Série: EDITORES DE TEXTO Capítulo 1: Avaliação técnica e econômica dos principais editores de texto do mercado. Habilidades: Pesquisar novas ferramentas e aplicativos de informática para a área
Leia maisPRINCÍPIOS DE INFORMÁTICA PRÁTICA 08 1. OBJETIVO 2. BASE TEÓRICA. 2.1 Criando Mapas no Excel. 2.2 Utilizando o Mapa
PRINCÍPIOS DE INFORMÁTICA PRÁTICA 08 1. OBJETIVO Aprender a utilizar mapas, colocar filtros em tabelas e a criar tabelas e gráficos dinâmicos no MS-Excel. Esse roteiro foi escrito inicialmente para o Excel
Leia maisManual de Operação do Sistema de Tickets Support Suite
Manual de Operação do Sistema de Tickets Support Suite Sumário Acessando a página do HelpDesk helpdesk.virtuem.com.br... 3 Criando um Ticket... 6 Visualizando Tickets Existentes... 9 Respondendo um Ticket...
Leia maisMANUAL DE SUPORTE. Controle de Suporte. Este manual descreve as funcionalidades do controle de suporte.
MANUAL DE SUPORTE Controle de Suporte Este manual descreve as funcionalidades do controle de suporte. SUMÁRIO Considerações Iniciais... 3 Acesso... 4 Controle de Suporte... 5 1. Solicitação de Atendimento...
Leia maisAjuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental
Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma
Leia maisProf. Me. Marcos Echevarria
Prof. Me. Marcos Echevarria Introdução a engenharia de software; Conceito de análise orientada a objetos; UserStories; Requisitos de software; Técnicas de levantamento de requisitos; Modelo de casos de
Leia maisMicrosoft Office PowerPoint 2007
INTRODUÇÃO AO MICROSOFT POWERPOINT 2007 O Microsoft Office PowerPoint 2007 é um programa destinado à criação de apresentação através de Slides. A apresentação é um conjunto de Sides que são exibidos em
Leia maisSistema Banco de Preços Manual do Usuário OBSERVATÓRIO
Sistema Banco de Preços Manual do Usuário OBSERVATÓRIO da Despesa Pública 1 Sumário O Banco de Preços... 3 Acessando o Banco de Preços... 4 Funções do Banco de Preços... 5 Gerar Preço de Referência...
Leia mais