SIPTEST System Intelligent Process Testing.

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

Download "SIPTEST System Intelligent Process Testing."

Transcrição

1 SIPTEST System Intelligent Process Testing. Sistema de incentivos à investigação e desenvolvimento tecnológico (SI I&DT) Relatório técnico-científico final do projeto nº (Janeiro de 2012 Dezembro de 2013) Elaborado por: Link Consulting

2 Índice 1 A Equipa de Projeto Principais competências e atividades desenvolvidas Impacto do seu envolvimento no projeto Alterações estruturais na equipa Novas contratações Criação de departamento de I&D O Projeto Os objetivos e a estrutura Calendarização das atividades do projeto Identificação e justificação das principais alterações ao quadro dos investimentos previstos do projeto Identificar a carga horária despendida por cada técnico e por atividade ao longo do projeto Identificar os custos indiretos e respetivo método de imputação, bem como o cálculo da percentagem dos custos indiretos pedir relatórios ao IDT Trabalho Desenvolvido Atividades e tarefas desenvolvidas A Estudos preliminares B Especificações técnicas C Aquisição e desenvolvimento de novos conhecimentos D Desenvolvimento E Construções de protótipos para testes e documentação da solução implementada F Testes e Ensaios G Promoção e divulgação de resultados Milestones Resultados alcançados Eliminar limitações à execução de testes funcionais Gestão eficaz de defeitos Estender o QA à governação dos serviços QA para além da entrada em produção Envolver gestores de negócio nas iniciativas de QA Resultados Valorização dos resultados de I&D decorrentes do projeto System Intelligent Process Testing Link Consulting,SA Pág. 1 de 62

3 4.2 Impacto do projeto para as entidades participantes Principais/Potenciais clientes, Principais Concorrentes, Análise Comparativa Quantificar o potencial valor de mercado dos resultados obtidos Avaliação Ex-Post Notas Finais Participação em Conferências e Publicações Sítio do projeto Outros meios Grafismo Monofolhas de divulgação Vídeo de divulgação Referências Anexos (opcionais) Fecho do documento Índice de Figuras Figura 1 Exemplo dos resultados na deteção de SQL Injection Figura 2 Interface do SoapUI Figura 2 Processo de criação e execução de testes de desempenho Figura 4 Níveis de maturidade TMMI e áreas de processo Figura 5 Integração das ferramentas do SIPTESTE Figura 6 Exemplo da estrutura do ficheiro XML consumido pelo EAMS Figura 7 Arquitetura SIPTEST Figura 8 Meta modelo da solução Figura 9 Modelo V Figura 10 Abstract conferência testes portugal Figura 11 Evento Testing Portugal Figura 14 Evento TOC Figura 12 Site projeto SIPTEST Figura 13 Site parceria ORACLE System Intelligent Process Testing Link Consulting,SA Pág. 2 de 62

4 Índice de Tabelas Tabela 1 Excerto da tabela de comparação de ferramenta de testes funcionais Tabela 2 Excerto da tabela de comparação de ferramenta de testes de segurança Tabela 3 Algumas das ferramentas de análise estática analisadas Tabela 4 Excerto da tabela de comparação de ferramenta de testes de carga e desempenho Tabela 5 Excerto da tabela de comparação de ferramenta de testes de capture/replay Tabela 5 Excerto da tabela de comparação de frameworks de automação System Intelligent Process Testing Link Consulting,SA Pág. 3 de 62

5 1 A Equipa de Projeto 1.1 Principais competências e atividades desenvolvidas A tabela seguinte apresenta de forma resumida a equipa de técnicos da Link, bem como dos recursos contratados à FEUP e à StongStep, que desempenharam actividades no projeto SIPTEST, sintetizando as principais tarefas que cada um dos perfis desempenhou no âmbito do projeto. Perfil Nome Descrição das principais tarefas desempenhadas P1 Especialista em Arquiteturas Empresariais Complexas P2 - Especialista em Ferramentas de Testes e de Gestão de Testes Armando A - Estudos Preliminares Vieira o Estado da arte da evolução da prática de testes, tendo como referência o CMMI B Especificações Técnicas o Definição da arquitetura de integração das ferramentas selecionadas C Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento o Definição do Meta Modelo da Base de Conhecimento o Estado da Arte das técnicas de Arquitetura Empresarial para suporte ao processo de testes Desenvolvimento o Instalação dos ambientes e ferramentas o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste o Desenvolvimento da ferramenta de gestão de testes o Desenvolvimento do modelo final da ferramenta de gestão de testes Jorge Leandro A - Estudos Preliminares o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de segurança o Estudo comparativo de ferramentas de testes de carga e desempenho o Estudo comparativo de ferramentas de automação de testes B Especificações Técnicas o Revisão e definição das metodologias e práticas melhoradas de testes de segurança o Revisão e definição da metodologia de testes de carga e desempenho o Revisão e definição da metodologia de automação de testes. o Revisão e definição da metodologia de testes funcionais o Definição da arquitetura de integração das ferramentas selecionadas System Intelligent Process Testing Link Consulting,SA Pág. 4 de 62

6 Perfil Nome Descrição das principais tarefas desempenhadas P3 - Especialista em Desenho e Tecnologia de Testes o Definição de SLAs a aplicar na frente de testes funcionais o Definição de SLAs a aplicar na frente de testes de segurança o Definição de SLAs a aplicar na frente de testes de carga e desempenho o Definição de SLAs a aplicar na frente de automação de testes o Especificação de uma ferramenta de gestão de serviço integrada. C Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento Específicas o Estado da Arte das técnicas de Teste para Arquitecturas de SW específicas G Promoção e Divulgação de Resultados o Produção e publicação de documentos científicos o Divulgação em fóruns Industriais e Científicos das lições aprendidas e resultados alcançados no SIPTEST José Marques A - Estudos Preliminares o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de segurança o Estudo comparativo de ferramentas de testes de carga e desempenho o Estudo comparativo de ferramentas de automação de testes o Estado da arte da evolução da prática de testes, tendo como referência o CMMI B Especificações Técnicas o Revisão e definição das metodologias e práticas melhoradas de testes de segurança o Revisão e definição da metodologia de testes de carga e desempenho o Revisão e definição da metodologia de automação de testes. o Revisão e definição da metodologia de testes funcionais o Definição da arquitetura de integração das ferramentas selecionadas o Definição de SLAs a aplicar na frente de testes funcionais o Definição de SLAs a aplicar na frente de testes de segurança o Definição de SLAs a aplicar na frente de testes de carga e desempenho o Definição de SLAs a aplicar na frente de automação de testes o Especificação de uma ferramenta de gestão de serviço integrada. C Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento o Definição do Meta Modelo da Base de Conhecimento System Intelligent Process Testing Link Consulting,SA Pág. 5 de 62

7 Perfil Nome Descrição das principais tarefas desempenhadas P4 Especialistas em Engenharia de Software e Automação de Processos Diogo Henriques Daniel Gonçalves Luis Gonçalves José Rodrigues o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Arquitetura Empresarial para suporte ao processo de testes o Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento Específicas o Estado da Arte das técnicas de Teste para Arquitecturas de SW específicas D Desenvolvimento o Instalação dos ambientes e ferramentas o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste o Desenvolvimento da ferramenta de gestão de testes o Desenvolvimento do modelo final da ferramenta de gestão de testes E Construção de Protótipos o Revisão da documentação e normalização dos processos definidos o Construção de Protótipos para Testes e Documentação da solução implementada F Testes e Ensaios o Testes Unitários e de Integração o Set up da frente dos vários serviços de testes funcionais, segurança, carga, e automação de testes G Promoção e Divulgação de Resultados o Produção e publicação de documentos científicos o Criação de um microsite da oferta o Divulgação em fóruns Industriais e Científicos das lições aprendidas e resultados alcançados no SIPTEST o Evento de fecho do projeto C Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento o Definição do Meta Modelo da Base de Conhecimento D Desenvolvimento o Instalação dos ambientes e ferramentas o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste o Desenvolvimento da ferramenta de gestão de testes o Desenvolvimento do modelo final da ferramenta de gestão de testes E Construção de Protótipos o Construção de Protótipos para Testes e Documentação da solução implementada F Testes e Ensaios o Testes Unitários e de Integração System Intelligent Process Testing Link Consulting,SA Pág. 6 de 62

8 Perfil Nome Descrição das principais tarefas desempenhadas P5 Especialistas em Engenharia de Sistemas P6 Especialista de Engenharia de Sistemas (novas contratações) Nuno Camacho Silva Daniel Rodrigues G Promoção e Divulgação de Resultados o Criação de um microsite da oferta o Evento de fecho do projeto A - Estudos Preliminares o Estado da arte da evolução da prática de testes, tendo como referência o CMMI B Especificações Técnicas o Revisão e definição das metodologias e práticas melhoradas de testes de segurança o Revisão e definição da metodologia de testes de carga e desempenho o Revisão e definição da metodologia de automação de testes. o Revisão e definição da metodologia de testes funcionais o Definição da arquitetura de integração das ferramentas selecionadas C Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento Específicas o Estado da Arte das técnicas de Teste para Arquiteturas de SW específicas D Desenvolvimento o Instalação dos ambientes e ferramentas o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste o Desenvolvimento da ferramenta de gestão de testes o Desenvolvimento do modelo final da ferramenta de gestão de testes D Desenvolvimento o Instalação dos ambientes e ferramentas o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste o Desenvolvimento da ferramenta de gestão de testes o Desenvolvimento do modelo final da ferramenta de gestão de testes E Construção de Protótipos o Construção de Protótipos para Testes e Documentação da solução implementada F Testes e Ensaios o Testes Unitários e de Integração System Intelligent Process Testing Link Consulting,SA Pág. 7 de 62

9 Perfil Nome Descrição das principais tarefas desempenhadas P7 Especialista em Automação de Testes para Softwares P8 - Especialistas em Enquadramento de Testes em boas práticas CMMI João Faria (FEUP) Ana Paiva (FEUP) João Batista (FEUP) Tiago Marques (FEUP) José Cruz (FEUP) Pedro Henriques (StrongStep) Bruno Martins (StrongStep) A - Estudos Preliminares o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de carga e desempenho o Estudo comparativo de ferramentas de automação de testes o Estado da arte da evolução da prática de testes, tendo como referência o CMMI B Especificações Técnicas o Revisão e definição das metodologias e boas práticas de teste o Revisão e definição da metodologia de testes funcionais o Levantamento de referências sobre metodologias e boas práticas de testes funcionais, incluindo critérios de automação o Revisão e definição da metodologia de testes funcionais o Definição de SLAs típicos aplicáveis a testes funcionais o Definição de SLAs aplicáveis a testes de segurança o Levantamento de SLAs típicos aplicáveis a testes de carga e desempenho o Definição de SLAs típicos aplicáveis a testes manuais e automáticos o Levantamento de referências sobre frameworks de gestão de serviços de testes G Promoção e Divulgação de Resultados o Produção e publicação de documentos científicos o Divulgação em fóruns Industriais e Científicos das lições aprendidas e resultados alcançados no SIPTEST o Evento de fecho do projeto o Definição de SLAs a aplicar na frente de testes funcionais o Def. de SLAs a aplicar na frente de testes de segurança o Def. de SLAs a aplicar na frente de testes de carga e desempenho o Def. de SLAs a aplicar na frente de automação de testes o Revisão da documentação e normalização dos processos definidos o Set Up da frente dos vários serviços de testes funcionais, segurança, carga e automação de testes 1.2 Impacto do seu envolvimento no projeto É de salientar a multiplicidade de competências desta equipa que se complementaram entre si para o atingimento dos objetivos do projeto. Do ponto de vista específico da área de testes e qualidade, a equipa reúne os perfis com conhecimento técnico e funcional necessário. Desta forma foi possível enquadrar a solução desenvolvida no âmbito deste projeto na evolução dos serviços e soluções da área de SQA que se destina a responder a necessidades reais de grandes organizações que são o maior consumidor deste tipo de soluções e serviços. System Intelligent Process Testing Link Consulting,SA Pág. 8 de 62

10 Do ponto de vista técnico, os recursos que deram corpo aos perfis técnicos na área dos testes, arquiteturas SOA, arquitetura empresarial, são recursos com larga experiência no desenvolvimento de soluções em diferentes geografias e clientes reais enquadradas em diferentes contextos tecnológicos. Do ponto de vista de conceção e desenho foram envolvidos recursos com larga experiência no desenvolvimento de soluções e sistemas de informação complexos, em ambientes próximos daquele que era pretendido neste projeto. É de salientar ainda a colaboração determinante estabelecida com os parceiros do meio científico e tecnológico FEUP e StrongStep. Esta colaboração foi determinante para o sucesso do projeto, garantindo a segurança necessária para avançar para novas áreas algumas das quais transcendiam a experiência e conhecimento da equipa link. Para além da colaboração específica neste projeto e no contributo direto nos resultados do projeto esta colaboração contribuiu para a alimentação direta da equipa link com conhecimento técnico e cientifico inovador na área das metodologias de testes, automação de testes, e práticas CMMI, com capacidade de utilização na atividade de negócio da link que vai muito para além da oferta SQA. Em sentido inverso, esta parceria com as SCT foi determinante para a instanciação do conhecimento genérico destas entidades numa solução específica e concreta de negócio. É prova disso a partição conjunta no maior certame nacional na área dos testes e qualidade, e o artigo admitido numa publicação científica da especialidade. 1.3 Alterações estruturais na equipa No que respeita a alterações à equipa de projeto há apenas a registar a saída dos seguintes colaboradores: o Manuel Soares Morais, em Fevereiro de 2012, o Daniel Gonçalves, em Julho de Novas contratações Foi efetuada uma nova contratação para participar no projeto SIPTEST, que não fazia parte do quadro de pessoal da empresa, com o seguinte perfil: Daniel Rodrigues: Especialista em Engenharia de Sistemas O técnico Daniel Rodrigues continuará a integrar a equipa da oferta resultante do SIPTEST, dando suporte à solução desenvolvida e às novas funcionalidades que se pretende continuar a criar para a mesma. 1.5 Criação de departamento de I&D A link Consulting possui um Departamento de I&D, que coordena todas as atividades de investigação industrial e desenvolvimento experimental da empresa, estando o seu SG IDI certificado segundo a NP4457:2007 desde System Intelligent Process Testing Link Consulting,SA Pág. 9 de 62

11 2 O Projeto 2.1 Os objetivos e a estrutura O objetivo estruturante desta candidatura foi dotar a Link Consulting, mais concretamente a linha de oferta SQA, de uma solução de gestão de testes inovadora com o objetivo de oferecer aos seus clientes serviços integrados de testes funcionais e não funcionais (Ex: Carga e performance), reforçando ao mesmo tempo o seu potencial de internacionalização. Tal objetivo implicou o desenvolvimento de uma solução que implementa um novo conceito de gestão e automação de testes, explorando três domínios de melhoria e inovação nas práticas de testes: Arquiteturas empresariais, arquiteturas SOA e processos de negócio. De forma a atingir este objetivo genérico foi necessário percorrer várias etapas até a implementação da solução final. A primeira dessas etapas consistiu na pesquisa e estudo comparativo de várias ferramentas de testes funcionais, não funcionais (segurança, carga e desempenho) e de automação. O objetivo destes estudos foi o de conhecer o estado da arte no que respeita às ferramentas de testes disponíveis no mercado, tendo em consideração, entre outros aspetos: A maturidade das ferramentas, A curva de aprendizagem das ferramentas Capacidades de integração das ferramentas com outras ferramentas e ambientes de desenvolvimento Capacidades de análise gráfica do status de execução dos testes e dos defeitos detetados. Desta pesquisa resultou a seleção do conjunto de ferramentas que viriam a ser integradas na solução SIPTEST. A etapa seguinte consistiu na análise de várias metodologias de testes funcionais, não funcionais e de automação de testes, bem como a sistematização de diversos níveis de serviço (SLAs). O objetivo desta etapa foi o de alinhar a solução a desenvolver com as melhores práticas e metodologias, tendo sempre em consideração as especificidades das arquiteturas SOA, assim como as recomendações do CMMI. Por fim procedeu-se à definição da arquitetura de integração das ferramentas selecionadas, e ao desenvolvimento da solução. A solução concebida pela Link resultou da integração de diversos tipos de ferramentas frequentemente utilizadas, tanto na área do Quality Assurance (QA) como na área das arquiteturas SOA. Isoladamente, cada uma destas ferramentas apenas está vocacionada para garantir parte do processo de QA, ou apenas permite um acompanhamento parcial das iniciativas SOA de uma organização (sem abranger o QA). Com a integração de vários tipos de ferramentas numa única plataforma, a Link procurou complementar as valências de cada uma delas de forma a contribuírem para um processo de QA unificado e consistente. A plataforma integrada para testes em arquiteturas orientadas a serviços resultou da integração dos seguintes tipos de ferramentas: Ferramenta de gestão de testes (test management): Uma ferramenta de gestão de testes permite que testadores funcionais ou key users registem as suas baterias de testes funcionais, bem como os resultados da sua execução. Este tipo de ferramentas permite especificar, para cada teste que se pretenda executar System Intelligent Process Testing Link Consulting,SA Pág. 10 de 62

12 especificar, os seus passos, os respetivos resultados esperados e, após a execução, registar o respetivo resultado. Trata-se portanto de um tipo de ferramenta essencial para os testadores funcionais e key users, onde é efetuado todo o planeamento das ações de QA e onde é registado a sua execução e progresso. Ferramenta de gestão de defeitos (bug tracking): Uma ferramenta de gestão de defeitos possibilita aos testadores reportar às equipas de desenvolvimento os defeitos detetados durante a execução dos testes. De forma genérica, este tipo de ferramentas permite gerir todo o ciclo de vida de um defeito, desde que é detetado (aberto) até à sua correção e validação (fecho), bem como classificar os defeitos reportados quanto à sua severidade e prioridade na correção. É portanto um tipo de ferramenta crucial em qualquer processo de QA, que agiliza a comunicação entre testadores e desenvolvimento no que respeita à deteção de defeitos e respetiva correção. Ferramenta de automação de testes funcionais a serviços (API functional testing): Uma ferramenta de automação de testes a serviços permite que testadores com um perfil técnico, ou mesmo membros das equipas de desenvolvimento, codifiquem e automatizem a execução de testes a serviços ou orquestrações de serviços. Este tipo de ferramentas requer tanto um conhecimento das API s dos serviços testados como domínio da linguagem da ferramenta de automação utilizada. É pois um tipo de ferramenta vocacionada para perfis mais técnicos, onde os testes que são registados estão desprovidos de enquadramento funcional. Ferramenta de automação de testes de carga a serviços (API load testing): De forma similar ao tipo de ferramenta anterior, esta ferramenta permite a testadores com um perfil técnico codificar e automatizar a execução de testes de carga aos serviços. Tal como no caso anterior, este tipo de ferramenta está vocacionado para perfis mais técnicos, portanto menos focados nos aspetos funcionais e de negócio. Ferramenta de governação SOA (SOA governance): Uma ferramenta de governação SOA possibilita aos arquitetos SOA monitorizar de ponta a ponta o ciclo de vida das iniciativas de governação SOA. De forma genérica, um arquiteto poderá registar neste tipo de ferramenta todas as características relevantes de um serviço bem como as suas relações com outros serviços ou entidades da arquitetura (serviços dependentes, aplicações onde é utilizado, etc..). De forma geral é omissa neste tipo de ferramentas informação relativa ao QA dos serviços (nº de casos de testes previstos, testes passados, testes falhados, defeitos abertos, etc ), devido a não existir uma forma expedita de atualizar este tipo de informação na ferramenta. Ferramenta de arquitetura empresarial (Enterprise Architecture): Uma ferramenta de arquitetura empresarial permite representar diversos domínios de uma organização como processos de negócio, sistemas de informação, serviços, orquestrações, infraestrutura, bem como as relações entre eles e a forma como estas evoluem ao longo do tempo, permitindo aos gestores de negócio fazer análises preditivas e tomar decisões. Tal como no caso anterior, também não é registado neste tipo de ferramentas informação sobre as iniciativas de QA em curso devido à inexistência de uma forma expedita de atualizar este tipo de informação. Como mencionado anteriormente, se considerados de forma isolada, os tipos de ferramentas acima descritos não suportam um processo de QA de ponta a ponta, transversal aos diversos perfis comprometidos com a qualidade de System Intelligent Process Testing Link Consulting,SA Pág. 11 de 62

13 uma arquitetura SOA. Através da integração de todos estes tipos de ferramentas complementares numa única plataforma a link conseguiu garantir que a informação relevante sobre os processos de QA flui entre os vários tipos de ferramentas, promovendo assim a transparência e visibilidade para os vários tipos de perfis que as utilizam. Face aos resultados palpáveis obtidos com o projeto consideramos que todos os objetivos foram cabalmente atingidos e conseguimos com isto desenvolver e evoluir os processos e metodologias dos serviços fornecidos pela oferta SQA. 2.2 Calendarização das atividades do projeto No essencial o calendário de execução das atividades do SIPTEST esteve sempre muito próximo do plano estabelecido inicialmente. Apenas foi necessário realizar reajustamentos ao plano de execução de algumas atividades, sem que tal tenha tido impacto no plano global do projeto. Atividades Previsto Realizado Início Fim Início Fim A Estudos Preliminares 02/01/ /03/ /01/ /03/2012 B Especificações Técnicas 01/04/ /09/ /04/ /09/2012 C Aquisição e Desenvolvimento de Novos Conhecimentos 02/01/ /07/ /01/ /12/2012 D Desenvolvimento 01/08/ /12/ /09/ /09/2013 E Construção de Protótipos 01/04/ /08/ /01/ /12/2013 F Testes e Ensaios 01/07/ /11/ /07/ /12/2013 G Promoção e Divulgação de Resultados 01/10/ /12/ /10/ /12/ Identificação e justificação das principais alterações ao quadro dos investimentos previstos do projeto No que respeita aos investimentos previstos no SIPTEST não ocorreram alterações significativas, uma vez que todos foram realizados. Apenas há a mencionar o facto de nos serviços prestados pelo ROC se terem conseguido obter prestações de serviços por valores mais baixos que o previsto à data da candidatura. System Intelligent Process Testing Link Consulting,SA Pág. 12 de 62

14 2.4 Identificar a carga horária despendida por cada técnico e por atividade ao longo do projeto P1 - Armando Vieira P2 - Jorge Leandro P3 - José Marques P4 - Manuel Morais P4 - Daniel Gonçalves P4 - Emanuel Teixeira P4 - Diogo Henriques P4 - José Rodrigues P5 - Nuno Silva P6 - Daniel Rodrigues A B C D E F G Jan-Dez Out-Dez Jan-Mar 2012 Abr-Set 2012 Jan-Dez 2012 Set-Dez 2012 Jan-Set 2013 Jul-Dez 2013 Jan-Dez Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizad o Previsto Realizado Previsto Realizado 113, , , , , , ,6 240, , , ,0 201, ,4 144, , ,2 2168,2 699, 1771, ,07 371, , , , , ,7 274

15 2.5 Identificar os custos indiretos e respetivo método de imputação, bem como o cálculo da percentagem dos custos indiretos pedir relatórios ao IDT Dada a natureza da actividade e dos projetos de IDT da Link Consulting o custo com o pessoal técnico operacional é a sua componente de custos directos maioritária. Consequentemente, todas as despesas necessárias à actividade da empresa, salvo quando sejam directamente relacionadas com outro projeto ou actividade específica, têm a natureza de Custos Indirectos ou despesas de suporte, necessárias para assegurar aos colaboradores operacionais as condições essenciais para desenvolverem a sua actividade. Com o objectivo de optimizar o custo da actividades de suporte, quer em termos de pessoal, quer em termos de outros custos, a Link Consulting tem, desde sempre, optado por fazer uma distribuição destes custos indirectos proporcional, apenas, à dimensão do projeto, dimensão essa medida em função dos custos de pessoal directo (operacional) envolvidos no mesmo. Como consequência deste critério, nos custos indirectos imputados a um dado projeto podem estar contemplados custos de rubricas que podem não ter uma relevância e correspondência directas com esse projeto. Todavia, como pela sua natureza indirecta esses custos não são facilmente associáveis aos diferentes projetos que suportam, parece-nos que esta prática representa uma boa aproximação para, de uma forma justa e equitativa, distribuir tais custos. Exemplificando: para um dado projeto de ID que represente 2% da actividade da empresa, os custos de gestão administrativa, de reporting e de apoio jurídico, apesar de provavelmente poderem ser superiores a esses 2%, só são imputados nessa proporção. Em contrapartida, outros custos mais relacionados com a actividade corrente da Link, tais como o Marketing ou o Recrutamento, que numa primeira análise podem não estar relacionados com o referido projeto de ID, são também lançados nessa mesma proporção de 2%. Face ao exposto, o Método de Cálculo dos Custos Indirectos a imputar ao SIPTEST corresponde ao peso, em temos de custo directo dos colaboradores envolvidos no projeto, versus o custo directo total de todos os colaboradores operacionais. Ou seja, o Cálculo dos Custos Indirectos (CI) a imputar ao projeto num determinado ano será igual a: CI = Peso do projeto no ano x x Total dos Custos Indirectos da empresa no ano x. Sendo que o Peso do projeto (PP) num determinado ano é calculado do seguinte modo: PP = Custos directos do pessoal operacional (Custo MO) afecto ao projeto no ano x / Total dos custos directos de todos os colaboradores operacionais no ano x. Cálculo da % dos Custos Indirectos a afectar ao projeto SIPTEST em 2012: Custo MO do projeto = Custo de MO total dos operacionais da Link = ,61 Percentagem de CI a imputar ao projeto em 2012 = 4,81% Cálculo da % dos Custos Indirectos a afectar ao projeto SIPTEST em 2013: Custo MO do projeto = ,66 Custo de MO total dos operacionais da Link = Percentagem de CI a imputar ao projeto = 4,45%

16 3 Trabalho Desenvolvido 3.1 Atividades e tarefas desenvolvidas O projeto SIPTEST foi estruturado com base no desenvolvimento de um conjunto de sete atividades diferenciadas, que se complementam entre si, e foram essenciais à realização do mesmo. A consistência do projeto assentou na adequação das atividades aos objetivos da investigação e na conceção de tarefas necessárias para a concretização de cada atividade, sendo o sucesso da respetiva execução controlado por milestones que conferiram, por sua vez, sustentabilidade aos resultados obtidos e permitem aferir a concretização dos objetivos. De seguida é apresentada a descrição e fundamentação de cada uma das sete atividades contempladas no projeto, assim como apresentado um quadro resumo das tarefas associadas a cada atividade A Estudos preliminares A primeira atividade do projeto A. Estudos preliminares foi concluída na sua totalidade e teve como missão o estudo comparativo de várias ferramentas de testes e a análise do estado da arte na prática de testes, tendo como referência o CMMI. No decorrer desta atividade foi possível analisar e comparar vários tipos de ferramentas de testes funcionais, de testes carga e desempenho, de teste de segurança, e de automação de testes. As ferramentas foram avaliadas e comparadas segundo vários parâmetros, sendo de destacar (genericamente): A maturidade das ferramentas, A curva de aprendizagem das ferramentas Capacidades de integração das ferramentas com outras ferramentas e ambientes de desenvolvimento Capacidades de análise gráfica do status de execução dos testes e dos defeitos detetados. Estes estudos foram realizados em parceria com a FEUP e a StrongStep, e basearam-se tanto na documentação disponível sobres as ferramentas, como na instalação e utilização exploratória de algumas delas. Tarefas Data de Conclusão A.1 - Estudo comparativo de ferramentas de gestão de testes funcionais A.2 - Estudo comparativo de ferramentas de testes de segurança A.3 - Estudo comparativo de ferramentas de testes de carga e desempenho A.4 - Estudo comparativo de ferramentas de automação de testes A.5 - Estado da arte da evolução da prática de testes, tendo como referência o CMMI A1 Estudo comparativo de ferramentas de gestão de testes funcionais Para melhor direcionar os estudos efetuados e basear as comparações efetuadas às ferramentas de gestão de testes funcionais foram analisados alguns casos de estudo e artigos que permitiram identificar melhor as caraterísticas System Intelligent Process Testing Link Consulting,SA Pág. 15 de 62

17 essenciais de uma ferramenta de gestão de testes. Abaixo alguns dos artigos e estudos analisados e um sumário do seu conteúdo: Martin R. Woodward, Michael A. Hennell Strategic benefits of software test management: a case study : Neste artigo, é apresentado um caso de estudo que enfatiza o facto de que, embora testes funcionais e testes estruturais pareçam técnicas opostas, podem realmente complementar-se e produzir uma estratégia de teste de software mais poderosa do que qualquer uma das duas separadas. Isto é conseguido através de um caso de estudo que comprova que partes do software ficam por testar se for usada apenas uma das duas técnicas. Michael W. Evans Productive Software Test Management : Livro que explora como testadores devem abordar a criação de testes e boas práticas para evitar a falta de cobertura dos testes. O livro também aborda números princípios que testadores devem ter em consideração e explica algumas técnicas de organização de testes. Johnson et al. Method and system for test management : Patente registada no âmbito de teste de software, com via a simplificar a importação e migração de configurações de testes. Iris Pinkster et al. Successful Test Management: An Integral Approach : Este livro demostra quais as grandes componentes do teste de software, ensinando conceitos por trás dos diferentes tipos de testes, boas práticas, erros comuns na elaboração de testes e gestão de testes no geral. Eickelmann, N.S. An evaluation of software test environment architectures : Artigo que verça sobre a otimização de ambientes de teste de software (STE) com base numa reestruturação da arquitetura desse mesmo ambiente. Particularmente, os autores propõem um arquitetura mais generalizada e comprovam o seu valor acrescentado e o ganho em eficácia por comparação a tradicionais ambientes de teste. Jonathan Bach - Session-Based Test Management : Neste artigo são analisadas e discutidas sessões de teste de software. São explicados os tipos de suporte que uma ferramenta de teste deve dar, métricas de testes e alguns conselhos do autor na resolução de problemas. Griselda Giraudo, Paolo Tonella - Designing and Conducting an Empirical Study on Test Management Automation : Este artigo visa passar ao leitor a experiência do autor na gestão de testes automatizados. Mais concretamente, é analisada a metodologia de testes adotada durante o projeto ITALO e é feita uma projeção dos resultados esperados. Finalmente, a nova metodologia é usada e os seus resultados são discutidos. Rudolf Ramler, Stefan Biffl, Paul Grünbacher - Value-Based Management of Software Testing : Artigo focado na maximização do retorno do investimento em testes de software. O trabalho em si descreve a motivação por detrás de value-based testing, descrevendo boas práticas que podem ser adotadas e descrever e demonstrar uma framework para a gestão deste tipo de testes. Hefner, R.H. - Collaborative test management : Este artigo apresenta os problemas mais comuns em testes formais de sistemas de larga escala e detalha uma abordagem à gestão colaborativa de testes de software. Para tal, como exemplo, apresenta uma tecnologia de informação baseada na Web, já aplicada em vários sistemas de teste da agência NASA. Após a análise destes documentos foi reunida informação sobre algumas das mais conotadas ferramentas de gestão de testes de software, tendo em consideração as funcionalidades mais significativas deste tipo de ferramentas, de maneira a poderem ser comparadas e escolhida(s) a(s) mais apropriada(s), dependendo da utilização pretendida. Abaixo são listadas algumas das funcionalidades observadas: Pago/Livre Se a aplicação é proprietária e paga ou se é livre (freeware); System Intelligent Process Testing Link Consulting,SA Pág. 16 de 62

18 Gestão de Requisitos capacidade da aplicação em fazer a gestão relacionada com requisitos funcionais e/ou não funcionais do sistema, considerando a interdependência entre requisitos; Planos de teste capacidade da aplicação de suportar a geração ou exportar planos de teste; Relatórios capacidade da aplicação de gerar relatórios com o resultado da execução dos testes ou planos de teste; Bug-Tracking indica se a aplicação contém um sistema integrado para rastreabilidade de erros aquando da execução dos testes; Testes Unitários capacidade da aplicação de executar testes unitários de forma automática; Testes a Pedido capacidade da aplicação de executar testes não automatizados, i.e. com input do utilizador para o início ou para os testes em si; Interface de Gestão e Análise existência de uma interface da aplicação capaz de gerir, guardar, analisar e mostrar os resultados. Toda esta informação foi agregada numa tabela similar à que se pode ver na figura abaixo: Nome do Produto XStudio [10] HP Quality Center [11] QADirector [12] QMetry [13] Rational TestManag er [14] Empresa Tipo de Licença Gestão de Requisitos Planos de Teste Relatórios Bug- Tracking Testes Unitários Testes a Pedido Interface de Gestão e Análise XQual Proprietária + GNU Sim Sim Sim Sim Sim Sim Sim HP (antiga Proprietária Sim Sim Sim Sim Sim Sim Mercury) Micro Proprietária Sim Sim Sim Focus QMetry Proprietária Sim Sim Sim Sim Sim Sim Sim IBM (antiga Rational) Proprietária Sim Sim Sim Sim Sim Tabela 1 Excerto da tabela de comparação de ferramenta de testes funcionais Como corolário desta tarefa a equipa de projeto elegeu ainda a ferramenta TestLink como a ferramenta de gestão de testes funcionais a integrar na solução a desenvolver. A principais razões para esta seleção foram o facto de se tratar de uma ferramenta amplamente disseminada e popular na comunidade de testadores funcionais, e cuja funcionalidades atendem as principais necessidade destes tipo de utilizadores e por outro lado se tratar de uma ferramenta free, que não requer qualquer tipo de licenciamento A2 - Estudo comparativo de ferramentas de testes de segurança Foram analisadas dois tipos de ferramentas de testes de segurança: Ferramentas dinâmicas: Que encontram vulnerabilidades tentando explorá-las. System Intelligent Process Testing Link Consulting,SA Pág. 17 de 62

19 Ferramentas estáticas: Que apenas examinam fragmentos de código e inferem sobre a existência ou não de vulnerabilidades no sistema. No que respeita às ferramentas dinâmicas, foi analisado um estudo exaustivo realizado por Shay Chen a 60 ferramentas (open-source e comerciais) onde foram sintetizados alguns dos recursos mais críticos e capacidades de cada ferramenta, tais como: Características e capacidades Benchmark de exatidão Cross-site scripting & taxa de falsos positivos SQL Injection & taxa de falsos positivos Tabela 2 Excerto da tabela de comparação de ferramenta de testes de segurança Figura 1 Exemplo dos resultados na deteção de SQL Injection A análise deste estudo permitiu identificar quais as ferramentas mais completas no mercado, direcionando a equipa na seleção das ferramentas que instalou para investigação e utilização exploratória. System Intelligent Process Testing Link Consulting,SA Pág. 18 de 62

20 Conforme mencionado anteriormente, foram também analisadas ferramentas de análise estática, que permitiu concluir as limitações existentes neste tipo de ferramentas, nomeadamente na deteção das falhas ao nível da arquitetura do software, e da integração entre vários componentes de uma aplicação. Tabela 3 Algumas das ferramentas de análise estática analisadas A3 - Estudo comparativo de ferramentas de testes de carga e desempenho O primeiro passo desta atividade consistiu em reunir alguns exemplos e linhas orientadoras sobre como selecionar uma ferramenta de testes de carga e desempenho. Abaixo alguns dos artigos consultados: A Comparison of Open Source Load Testing Tools (http://www.jds.net.au/techtips/load-testing-toolcomparison/) Real-World Load Testing Tips to Avoid Bottlenecks When Your Web App Goes Live (http://msdn.microsoft.com/en-us/magazine/cc aspx) The French Social Security Administration Switches To Web Performance Load TesterTM From Open Source (http://www.webperformance.com/library/whitepapers/cnav/load-testing-cnav.html) Choosing an Appropriate Performance Testing Tool (http://fyi.oreilly.com/2009/01/choosing-anappropriate-perfor.html) Load Testing Metrics (http://loadstorm.com/load-testing-metrics) Software testing tool finder (http://www.vcaa.com/tools/) Tendo como base os estudos realizados acima, foram analisadas várias ferramentas, e a comparação das mesmas sistematizadas numa tabela atendendo aos seguintes fatores comparativos: Pago/Livre Se a aplicação é proprietária e paga ou se é livre (freeware); Linguagem dos testes Fator importante para determinar a compatibilidade com outras aplicações, linguagem e compatibilidade dos testes, plugins e sistemas operativos; System Intelligent Process Testing Link Consulting,SA Pág. 19 de 62

21 Aplicação ativa indica se a aplicação se encontra em desenvolvimento ativo ou não; Tipos de teste tipos de testes de desempenho suportados (stress e carga); Sistema Operativo indica o sistema operativo em que a aplicação pode ser executada; Alvo indica o tipo de software que aplicação pode testar Tabela 4 Excerto da tabela de comparação de ferramenta de testes de carga e desempenho Como corolário desta tarefa a equipa de projeto elegeu ainda a ferramenta LoadUI como a ferramenta de testes carga a integrar na solução a desenvolver. As principais razões para esta seleção foram o facto de se tratar de uma ferramenta amplamente disseminada no seio das equipas de desenvolvimento em arquiteturas orientadas a serviços e por outro lado se tratar de uma ferramenta opensource, o que facilita a sua integração A4 - Estudo comparativo de ferramentas de automação de testes O estudo comparativo de ferramentas de automação incidiu sobre dois tipos de ferramentas. As ferramentas de Capture/Replay e as frameworks de automação. As ferramentas de Capture/Replay permitem executar várias vezes scripts de teste criados para garantir que os requisitos implementados são cumpridos ao longo da evolução da aplicação a testar. Os critérios escolhidos para a diferenciação das ferramentas de testes Capture/Replay foram os seguintes: Livre/Pago indica se a aplicação é proprietária e paga ou se é livre (freeware); Aplicação activa indica se a aplicação se encontra em desenvolvimento ativo ou não; Testes de Interface Interface Desktop (GUI) ou interfaces WEB; Sistema Operativo sistema operativo em que a aplicação pode ser executada; System Intelligent Process Testing Link Consulting,SA Pág. 20 de 62

22 Tabela 5 Excerto da tabela de comparação de ferramenta de testes de capture/replay Para além das ferramentas de Capture/Replay, foram também estudadas e comparadas frameworks de automação através dos quais é possível simular as ações dos utilizadores sobre uma interface gráfica. Tabela 6 Excerto da tabela de comparação de frameworks de automação Com base nas comparações acima, foram selecionadas seis ferramentas sobre as quais se realizaram estudos mais aprofundados. Três ferramentas de testes de serviços Web e três de testes a aplicações Desktop. Mais concretamente, as ferramentas foram o Badboy, o BlueDuck SDA e o SoapUI (para testes Web), o Expect, o Marathon e o Maveryx (para testes a aplicações Desktop). Os estudos referidos acima focaram-se em algumas características essenciais para este tipo de ferramentas: Captura: a captura dos movimentos de cada teste é um fator a ter em conta aquando da comparação deste tipo de ferramentas; System Intelligent Process Testing Link Consulting,SA Pág. 21 de 62

23 Dados de imput: O facto de uma aplicação ser capaz de gerar dados de input, seguir regras para os mesmos (expressões regulares, por exemplo) ou mesmo importar os dados de um ficheiro ou base de dados externos é um fator importante na diferenciação das ferramentas. Ambiente de execução: O agendamento de testes, opções de debug e suporte para múltiplos ambientes de desenvolvimento são aspetos cruciais na escolha de uma ferramenta de testes Resultados, e relatórios produzidos. A conclusão desta etapa permitiu sobretudo revelar as potencialidades da ferramenta SoapUI (ferramenta que viria a ser integrada na solução desenvolvida). Esta ferramenta é desenvolvida pela SmartBear Software e suporta testes funcionais, de carga, regressão e aceitação a serviços. Suporta a maior parte dos protocolos e é capaz de modificar parâmetros intrínsecos dos mesmos, como por exemplo, timeouts ou tamanho dos requests. Para além disso esta ferramenta pode ser usada como ferramenta final ou como framework por ser adaptável e open-source. Figura 2 Interface do SoapUI A4 Estado da arte da evolução da prática de testes, tendo como referência o CMMI Antes de iniciar um projeto de melhoria é necessário conhecer qual o nível de maturidade dos processos de teste existentes na organização. Portanto, a atual situação da organização tem que ser inicialmente avaliada. A avaliação torna claro que informação e que procedimentos estão em curso, e especialmente o que precisa ser melhorado Este estudo teve como foco as práticas genéricas do modelo TMMi e que derivam do modelo CMMI. System Intelligent Process Testing Link Consulting,SA Pág. 22 de 62

24 O TMMi é um guia e uma referência para melhorar o processo de teste de qualquer organização. O modelo pode também ser considerado como o modelo, uma descrição generalizada de como uma atividade, neste caso de teste, deve ser feita. O TMMi pode ser usado para complementar o CMMI (uma abordagem para melhoria de processos), ou de forma independente. Aplicando o TMMi para avaliar e melhorar um processo de teste de uma organização, a produtividade desta deverá aumentar e por consequentemente a qualidade do produto final. Foram ainda analisadas as duas ações (Verificação & Validação) que podem melhorar a qualidade do software desenvolvido segundo o CMMI. O modelo CMMI contempla dois processos de controlo e análise para avaliação do software desenvolvido: Verificação e Validação (V & V). A Verificação e Validação inicia-se com a revisão dos requisitos e continua através das revisões de design e inspeções de código. O objetivo principal do processo V & V é estabelecer confiança de que o sistema de software é adequado à finalidade : Verification: Are we building the product right? Validation: Are we building the right product? A Verificação inclui verificação do produto, bem como todos os intermediários relacionados com os requisitos, incluindo clientes, requisitos dos produtos, etc. A Verificação é inerente a um processo incremental, pois ocorre durante todo o desenvolvimento do produto, começando com a verificação dos requisitos, progredindo através da verificação do produto em evolução, e culminando com a verificação do produto terminado. A atividade de Validação pode ser aplicada a qualquer aspeto do produto em qualquer ambiente de execução, tais como, operação, treino, produção, manutenção e suporte. A Validação demonstra que o produto irá cumprir o seu propósito, por outras palavras, a validação assegura que se desenvolveu o correto produto. As atividades de validação utilizam abordagens semelhantes à verificação (exemplo, teste, análise, inspeção, demonstração, simulação). Regularmente os utilizadores finais e outros stakeholders relevantes estão também envolvidos em atividades de validação B Especificações técnicas Esta etapa do projeto B - Especificações Técnicas foi concluída na sua totalidade e tinha como missão: A revisão e definição de metodologias de testes para as diversas frentes (segurança, carga e desempenho, automação, funcionais). Definição da arquitetura de integração das ferramentas selecionadas A definição dos níveis de serviço a aplicar nas diversas frentes de testes (segurança, carga e desempenho, automação, funcionais) Especificação de uma ferramenta de gestão de serviço integrada Em termos das tarefas nas quais se consubstancia a atividade B temos: Tarefas Data de Conclusão B.1 - Revisão e definição das metodologias e práticas melhoradas de testes de segurança 04/05/2012 B.2 - Revisão e definição da metodologia de testes de carga e desempenho 18/05/2012 B.3 - Revisão e definição da metodologia de automação de testes. 21/06/2012 System Intelligent Process Testing Link Consulting,SA Pág. 23 de 62

25 B.4 - Revisão e definição da metodologia de testes funcionais 20/06/2012 B.5 - Definição da arquitetura de integração das ferramentas selecionadas 25/07/2012 B.6 - Definição de SLAs a aplicar na frente de testes funcionais 31/07/2012 B.7 - Definição de SLAs a aplicar na frente de testes de segurança 24/08/2012 B.8 - Definição de SLAs a aplicar na frente de testes de carga e desempenho 19/09/2012 B.9 - Definição de SLAs a aplicar na frente de automação de testes 27/09/2012 B.10 - Especificação de uma ferramenta de gestão de serviço integrada 27/09/ B1 Revisão e definição das metodologias e práticas melhoradas de testes de segurança Nesta atividade foram analisadas várias metodologias e boas práticas para desenvolvi- mento de software mais seguro, tais como: SAFECode BSIMM, OSSTMM, 10 Práticas para Codificação Segura CERT, Padrões de Codificação Segura. SAFECode é baseado num abordagem perspetiva que enfatiza o uso de práticas de segurança e técnicas que provaram ser eficazes em cada membro da organização SAFECode. Não faz juízos de valor deliberados sobre práticas de segurança e prioriza aquelas que foram reconhecidas, por especialistas (membros do SAFECode), como tendo o maior impacto - independentemente do tamanho da organização, recursos ou plataforma de computação. O BSIMM emprega uma abordagem descritiva para o desenvolvimento seguro de software e não procura medir a eficácia dos processos de segurança. Por outras palavras, o BSIMM é útil para comparar as atividades de segurança para software observadas numa determinada organização, com as outras 42 organizações referidas no estudo. O Manual Open-Source de uma Metodologia para Testes de Segurança (Open Source Security Testing Methodology Manual - OSSTMM) é uma metodologia de peer-reviewed para testes de segurança e métricas de desempenho, com vários anos de experiência. Os casos de teste do OSSTMM são divididos em cinco canais (secções), tais como, Recursos Humanos, Físico, Wireless, Telecomunicações e Redes de Dados. Coletivamente esses canais testam: informação e controlo de dados, níveis de segurança pessoais, fraudes e níveis de controlo de engenharia social, redes de computadores e telecomunicações, dispositivos wireless, dispositivos móveis, controlos de acesso físico e localizações físicas tais como edifícios, bases militares, etc. O OSSTMM incide nos detalhes técnicos sobre quais os itens que precisam ser testados, o que fazer antes, durante e após um teste de segurança, e como medir os resultados. Testes individuais, por si só, não são particularmente revolucionários, mas a metodologia como um todo representa o ponto de referência para a profissão de testes de segurança. Novos testes para as melhores práticas internacionais, regulamentos e preocupações éticas são adicionados regularmente ao manual. O CERT, um centro de estudos para resposta e tratamento de incidentes em computadores, elaborou uma lista com 10 boas práticas para codificação segura para os programadores seguirem, quando estão a desenvolver o seu código e inclui sugestões para manter o código simples, validar os dados de entrada, etc. System Intelligent Process Testing Link Consulting,SA Pág. 24 de 62

26 1. Validar os dados de entrada. Uma apropriada validação pode eliminar uma vasta maioria das vulnerabilidades do software. O programador deve sempre desconfiar de onde os dados de entrada provêm incluindo linhas de comando, interfaces de rede, variáveis de ambiente, etc. 2. Avisos do compilador. O programador deve compilar o seu código utilizando o nível mais alto de alertas disponível no seu compilador e eliminar os avisos [CMSC00-A 1, C++ MSC00-A 2 ]. Podem ainda ser utilizadas ferramentas de análise dinâmica para detetar e tentar eliminar falhas de segurança. 3. Arquitetura e Design para políticas de segurança. Criar um arquitetura e um design para o software que implemente e force o cumprimento de políticas de segurança. 4. Manter o código simples. Manter o código tão simples e pequeno quanto possível. Sistemas complexos aumentam a probabilidade de existirem erros na sua implementação/configuração. 5. Negação por padrão. Basear as decisões de acesso em permissões ao contrário de exclusões. Isto significa, que por norma, o acesso é negado e as permissões de acesso identificam condições sobre as quais o acesso é permitido. 6. Respeitar o princípio do menor privilégio. Cada processo deve ser executado com o mínimo conjunto de privilégios necessário para realizar a sua tarefa. Esta abordagem reduz a oportunidade de uma pessoa malintencionada executar código arbitrário com elevados privilégios. 7. Alterar os dados a enviar para outros sistemas. Alterar todos os dados enviado para subsistemas complexos [C STR02-A 3 ], tais como, bases de dados relacionais, etc. Isto porque pessoas mal-intencionadas podem ser capazes de invocar funcionalidades não utilizadas nesse componente através do uso de injeção SQL. 8. Práticas de defesa. Gerir os riscos com múltiplas estratégias defensivas, por forma a que se uma camada de defesa for invadida, a camada imediatamente a seguir pode evitar que uma falha de segurança se torne uma vulnerabilidade explorável e/ou limitar as consequências de uma exposição bem sucedida. 9. Utilizar técnicas eficazes que garantam qualidade. Técnicas que garantam qualidade, podem ser eficazes para identificar e eliminar vulnerabilidades. Devem ser incorporadas audições ao código fonte como parte de um programa de garantia de qualidade, bem como testes Fuzz, testes penetração, etc. Revisões independentes ao código fonte, podem também garantir mais segurança. 10. Adotar padrões de codificação segura. Desenvolver e/ou aplicar padrões de codificação segura para a sua linguagem e plataforma de desenvolvimento. O CERT é parte do Carnegie Mellon University s Software Engineering Institute e desenvolve padrões de codificação seguro para as linguagens de programação mais utilizadas, tais como, C/C++ e Java, através de um esforço de toda a comunidade, que inclui membros de desenvolvimento de software e comunidades de segurança para software. O CERT inclui também, orientações para evitar erros de codificação e implementação, bem como, erros de baixo nível no design de software. 1 MSC00-C. Compile cleanly at high warning levels, https://www.securecoding.cert.org/confluence/display/seccode/msc00- C.+Compile+cleanly+at+high+warning+levels, C++ MSC00-A, https://www.securecoding.cert.org/confluence/display/cplusplus/void+compile+cleanly+at+high+warning+levels, Sanitize data passed to complex subsystems, https://www.securecoding.cert.org/confluence/display/seccode/str02- C.+Sanitize+data+passed+to+complex+subsystems, System Intelligent Process Testing Link Consulting,SA Pág. 25 de 62

27 Normas de codificação bem documentadas e exequíveis são essenciais para um desenvolvimento seguro de software. Padrões de codificação incentivam os programadores a seguir um conjunto de regras e guias, determinados pelos requisitos de um projeto e pela organização e não pela familiaridade dos programadores ou suas preferências. Uma vez estabelecidos esses padrões, podem ser utilizados como métrica para avaliar o código fonte (utilizando processos manuais ou automáticos) para o cumprimento da norma. Padrões de Codificação para Java do CERT Os Padrões de Codificação para Java do CERT incluem regras e práticas recomendadas para programação segura em Java Platform Standard Edition 6 e Java SE 7. A versão 1 desta norma já está concluída e pronta para revisão. Padrões de Codificação Segura para C/C++ do CERT Os Padrões de Codificação Segura para C/C++ do CERT fornecem regras e recomendações para codificação segura na linguagem de programação C. O objetivo principal destas regras é recomendar e eliminar práticas inseguras e comportamentos indefinidos que se podem tornar vulnerabilidades exploráveis. A aplicação deste padrão de codificação segura irá conduzir a um sistema mais robusto e mais resistente a ataques, logo com maior qualidade B2 Revisão e definição das metodologias e práticas melhoradas de testes de carga e desempenho Nesta atividade foram utilizadas analisadas várias metodologias de teste de carga e desempenho. Testes de carga são, por definição, testes que tentam sobrecarregar um sistema, dentro dos requisitos para os quais este foi desenvolvido, avaliando as respostas do mesmo. Para tal, estes testes usam o aumento de carga em um ou vários componentes, de uma maneira linear ou mais dinâmica. Por oposição aos testes de carga, os testes de stress tentam sobrecarregar um sistema acima dos requisitos para os quais o sistema foi desenvolvido, avaliando as respostas do mesmo. Estes tipos de teste têm como objetivo o teste da estabilidade do sistema. Testes de carga são capazes de detetar bugs que não são detetados em ambientes normais de execução. Testes de carga são também capazes de detetar problemas relacionados com bufferoverflow, memory leaks e má gestão de memória, além de determinar os limites dos recursos dos componentes de uma aplicação de software, por exemplo, bases de dados, hardware e redes, etc.,de forma a poder gerir e estimar a carga futura do sistema de software. Por sua vez, os testes de stress são normalmente usados de maneira a detetar os pontos (carga necessária) em que um componente ou um sistema falha, chamados de breaking points. A utilidade deste tipo de testes está também no facto de que as falhas de um sistema sobrecarregado podem revelar erros na implementação do componente ou sistema. Existem diferentes abordagens aos testes de carga, por exemplo: Testes de carga simples execução de testes que impõe carga máxima em todos os componentes; Testes de carga crescente execução de carga crescente em todos os componentes de maneira a detetar qual o limite de cada um; Testes de carga variável por componente testes de carga crescente e variável efetuados a cada componente de maneira a detetar dependências não previstas entre os componentes. System Intelligent Process Testing Link Consulting,SA Pág. 26 de 62

28 Os tipos de teste de stress que existem são em parte similares à abordagem tomada nos testes de carga, mas com algumas modificações em termos do propósito. Desta maneira, os diferentes testes de stress existentes são: Testes de sensibilidade testes realizados com o propósito de descobrir o impacto da sobrecarga de diferentes componentes de forma a perceber as dependências existentes; Testes por cenário testes baseados em casos reais que exigiriam uma sobrecarga no sistema. No decorrer desta atividade focou-se também no processo de testes associados aos testes de desempenho (ver figura abaixo), assim como nas boas práticas. Figura 3 Processo de criação e execução de testes de desempenho No que respeita às boas práticas na construção e execução de testes de desempenho, são: Um projeto que implemente testes de desempenho deve ter um documento que contenha uma linha de base para o desempenho esperado do sistema, para que durante a execução de testes possa ser feita uma comparação da expectativa vs condição atual do produto; O ambiente de execução de testes deve replicar com a maior precisão possível o ambiente de produção no qual o sistema vai ser instalado; O ambiente de desenvolvimento de testes de desempenho, tal como de outros testes, não deve ser agrupado com o ambiente de desenvolvimento do produto em si; Este tipo de testes deve ser executado e monitorizado com frequência de maneira a controlar o incremento em desempenho que cada parte ou componente desenvolvida tem. System Intelligent Process Testing Link Consulting,SA Pág. 27 de 62

29 B3 Revisão e definição da metodologia de automação de testes Esta atividade focou-se essencialmente nos critérios de automação em que deverá assentar uma metodologia de testes. Existem algumas circunstâncias que podem levar a preferência por criar ou executar testes automaticamente. Cabe aos testadores perceberem para cada teste ou conjunto de testes que pretendem correr se estes devem ser gerados ou executados automaticamente. No caso da criação de testes, testadores devem ter em conta os seguintes critérios de modo a determinar que testes podem e/ou devem ser gerados automaticamente: Reutilização de tipos de testes Dinamismo do output produzido Previsibilidade do output Concretamente, se for possível generalizar o teste ou conjunto de testes que se pretende desenvolver e os seus inputs (i.e., geração de classes de equivalência e valores fronteira automaticamente), então pode ser preferível automatiza-los. Da mesma maneira, se os outputs forem considerados dinâmicos na sua natureza ou difíceis de prever, será difícil julgar a sua validade; os testes devem portanto, nestes casos, não serem automatizados. No caso da execução de testes, e tomando como certo que os dois últimos pontos dos critérios de automação da criação de testes também são válidos para a execução de testes, o critério de automação mais relevante para a execução de testes de software pode ser centrado na seguinte pergunta Quantas vezes terão um teste ou um conjunto de testes de ser executado e com que frequência?. De uma maneira lógica, quanto mais vezes executado e quanto maior for a frequência de execução de um teste ou conjunto de testes, maior estes serão candidatos à automação da sua execução B4 Revisão e definição da metodologia de testes funcionais Esta atividade aprofundou a metodologia de testes TMMI. O TMMi foi desenvolvido por uma comunidade de especialistas na área de testes designada TMMi Foundation 4, para tentar corrigir a lacuna do CMMI e de outros modelos de teste, posicionando-se assim, como um modelo complementar ao CMMI. A framework TMMi foi implementada na já existente frameworktmm (inicialmente desenvolvida pelo Illinois Institute of Technology em 1996) como ponto de partida e guiada através das boas práticas da framewok CMMI. O TMMi é uma compilação de todos os modelos de teste de software que suportem testes que não são cobertos ou estão em falta em vários modelos como TPI ou TMM. O TMMi segue um modelo de representação que utiliza conjuntos predefinidos de áreas de processos, para definir melhorias na área de teste que pode estar integrada ou é independente do desenvolvimento de software da organização. Tal como o CMMI, o TMMi também utiliza o conceito de níveis de maturidade para avaliação e melhoramento de processos. Além do mais, as áreas de processo, objetivos e práticas chave são também identificadas. Aplicando os critérios de maturidade do TMMi qualquer organização poderá melhorar o processo de teste e por isso terá um impacto positivo no ciclo de desenvolvimento, e consequentemente uma melhoria na qualidade do produto final. O TMMi foi desenvolvido para apoiar as organizações de software na avaliação e melhoria dos seus processos de teste. 4 TMMi Foundation Homepage System Intelligent Process Testing Link Consulting,SA Pág. 28 de 62

30 As experiências realizadas com a utilização do TMMi, são positivas e mostram que este estabelece um processo de teste mais eficaz e eficiente. Níveis de Maturidade do TMMi O TMMi é composto por vários níveis, através dos quais uma organização evolui de processos de teste ad hoc para processos geridos, definidos, medidos e otimizados. O cumprimento de cada nível garante à organização a passagem para o próximo nível de melhoramento. Os cinco níveis do TMMi (ver figura) descrevem uma hierarquia que permite melhorar o processo de teste. Nível 1 - Inicial O TMMi reconhece a tarefa de teste como sendo um processo indefinido e muitas vezes, na organização, considerado como uma tarefa de debugging. As organizações avaliadas com apenas o nível de maturidade 1, são caraterizadas por abandono de processos em tempos de crise e uma incapacidade de repetir sucessos. Não existem processos-chave envolvidos neste nível e é altamente recomendável o avanço para um nível superior. Figura 4 Níveis de maturidade TMMI e áreas de processo System Intelligent Process Testing Link Consulting,SA Pág. 29 de 62

31 Nível 2 - Gerir Testar é um processo que se destaca completamente do debugging e ajuda a garantir que as práticas existentes são mantidas durante períodos de stress. O principal objetivo de testar é verificar que os produtos satisfazem os seus requisitos. Contudo, testar é ainda reconhecida como sendo apenas uma fase do projeto, que se segue logo após a programação. Neste nível os testes são reconhecidos como sendo transversais a múltiplos níveis, abrangendo desde testes unitários a testes de aceitação. Para cada nível de teste identificado, existem objetivos específicos definidos na estratégia de teste da organização. As áreas de processo do nível 2 são: 1. Políticas e Estratégias de Teste; 2. Planeamento de Testes; 3. Monitorização e Controlo de Testes; 4. Design e Execução de Testes; 5. Ambiente de Teste. Nível 3 - Definir Neste nível a organização entende a importância das revisões no controlo de qualidade e implementa um programa de revisão formal ligado ao processo de teste dinâmico. A fase de testes é perfeitamente integrada no ciclo de desenvolvimento e são associadas metas para os testes. Este processo de melhoria ao nível dos testes está totalmente integrado como parte importante nas práticas aceites pelas organizações. As áreas de processo do nível 3 são: 1. Organização de Testes; 2. Programa de Treino para Testes; 3. Ciclo de Integração e Testes; 4. Testes Não-Funcionais; 5. Revisões. Nível 4 - Medir Neste nível testar torna-se um processo de medição das áreas de processo dos níveis 2 e 3, por forma a encorajar um crescimento e a realização de testes pela organização. Os testes são entendidos como uma avaliação que consiste, em todas as atividades do ciclo de vida do software relacionadas com a validação e verificação. Em relação à qualidade do produto a presença de um programa de medição, permite à organização implementar um processo de avaliação de qualidade, através da definição de necessidades de qualidade, atributos de qualidade e métricas de qualidade. Os produtos são avaliados utilizando critérios quantitativos através de atributos qualitativos como confidencialidade, usabilidade e manutenção. O nível 4 estabelece também uma abordagem de teste coordenada entre revisões de testes estáticos e testes dinâmicos, o uso dos resultados das revisões e os dados para otimizar a abordagem de testes, com o principal objetivo de realizar testes mais eficazes e eficientes. As revisões estão System Intelligent Process Testing Link Consulting,SA Pág. 30 de 62

32 integradas diretamente com processos de teste dinâmicos e é parte da estratégia e da abordagem dos testes. As áreas de processo do nível 4 são: Medição dos Testes; Avaliação da Qualidade do Produto; Revisões Avançadas. Nível 5 - Otimizar No nível 5 cada organização (individualmente) é capaz de melhorar continuamente os seus processos baseando-se numa interpretação quantitativa dos processos controlados estatisticamente. As melhorarias no desempenho do processo de teste são realizadas através de um processo incremental e inovador. Os métodos de teste e técnicas são otimizados e existe um foco contínuo na melhoria do processo. O processo de prevenção de falhas é estabelecido para identificar e analisar causas comuns ao longo do ciclo de desenvolvimento e definir ações para prevenir que falhas semelhantes não voltam a ocorrer no futuro. O processo de otimização do processo de teste define mecanismos para afinar e melhorar continuamente os testes. As áreas de processo do nível 5 são: 1. Prevenção de Falhas; 2. Controlo de Qualidade; 3. Otimização do Processo de Teste. Para finalizar, as áreas de processo do TMMi fornecem suporte e especificações mais detalhadas, sobre o que é necessário estabelecer para definir um processo de verificação e validação. A framework TMMi enquadra todos os níves de teste (incluindo testes estáticos e dinâmicos) de testes estruturados (ciclo de vida do teste, infraestruturas e organização dos testes). O TMMi fornece uma excelente referência para auxiliar a melhoria do processo de teste de qualquer organização que desenvolva software B5 Definição da arquitetura de integração das ferramentas selecionadas Nesta etapa procedeu-se à especificação da arquitetura de integração das ferramentas de testes selecionadas para o projeto SIPTEST (ver figura abaixo). System Intelligent Process Testing Link Consulting,SA Pág. 31 de 62

33 Figura 5 Integração das ferramentas do SIPTESTE Procedeu-se também à definição dos mecanismos de importação e exportação entre as diversas ferramentas, como serviços SOA ou ficheiros XML: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <Rep> <DT Uid="1" Nm="Service Types"> <DTP> <P MTdt="" MT="Text" Nm="Id"/> <P MTdt="" MT="Text" Nm="Name"/> <P MTdt="" MT="Text" Nm="Default Value"/> </DTP> <DIs> <DI Uid="145" Nm="Mediator Service"> <P MTUid="" MTsv="50438" Nm="Id"/> <P MTUid="" MTsv="Mediator Service" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="146" Nm="Split-Join Service"> <P MTUid="" MTsv="50439" Nm="Id"/> <P MTUid="" MTsv="Split-Join Service" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="147" Nm="EJB Service"> <P MTUid="" MTsv="50436" Nm="Id"/> <P MTUid="" MTsv="EJB Service" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="148" Nm="FileAdapter"> <P MTUid="" MTsv="50437" Figura Nm="Id"/> 6 Exemplo da estrutura do ficheiro XML consumido pelo EAMS <P MTUid="" MTsv="FileAdapter" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="149" Nm="Application Interface"> <P MTUid="" MTsv="50434" Nm="Id"/> <P MTUid="" MTsv="Application Interface" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="150" System Nm="BPEL"> Intelligent Process Testing Link Consulting,SA Pág. 32 de 62 <P MTUid="" MTsv="50435" Nm="Id"/> <P MTUid="" MTsv="BPEL" Nm="Name"/> <P MTUid="" MTsv="false" Nm="Default Value"/> </DI> <DI Uid="151" Nm="Abap Proxy"> <P MTUid="" MTsv="50432" Nm="Id"/> <P MTUid="" MTsv="Abap Proxy" Nm="Name"/>

34 B6 Definição de SLAs a aplicar na frente de testes funcionais Nesta tarefa procurou-se deferir os níveis de serviço (SLAs) a aplicar numa frente de testes funcionais. Os testes funcionais verificam que o sistema já integrado executa as funções tal como especificado nos requisitos. Um SLA típicos aplicável a testes funcionais pode ser definido segundo as métricas dos vários métodos que caraterizam os testes funcionais: EquivalenceClass Partitioning, Boundary-Value Analysis, Random Testing, State Transition Testing e Static Testing. Equivalence Class Partitioning Neste método, o domínio de dados de entrada é dividido em diferentes classes de dados de equivalência. É tipicamente utilizado para reduzir o número total de casos de teste para um conjunto finito, mantendo a cobertura máxima dos requisitos. Algumas das caraterísticas que podem ser incluídas num SLA são: preferência pelos casos de teste que incluem combinações dos valores de limite; garantir que todos os valores representativos de uma classe de equivalência ocorrem pelo menos uma vez num caso de teste; pode também ser utilizada a medição de quantos dos casos de teste com base em classes de equivalência foram cobertos pelos casos de teste (para determinar a abrangência dos testes). O valor de equivalence class partitioning depende da determinação das classes de equivalência. Equivalence Class (EC) = (número de combinações EC testadas/ número total de combinações EC) * 100 Boundary-Value Analysis É amplamente reconhecido que os valores de entrada nos extremos do domínio de entrada, causam mais erros no sistema. A técnica de teste Boundary-Value Analysis é utilizada para identificar erros utilizando valores de entrada de fronteira do domínio e não, encontrar erros com valores intermédios do domínio de entrada. Análise do valor fronteira deve ser feita em conjunto com o equivalence partitioning. No acordo entre o cliente e o prestador do serviço podem ser incluídas as seguintes regras: definição de valores fronteira para todos os casos de teste; tal como a equivalence partitioning, os valores de teste gerados a partir de cada análise de limite devem ser combinados para gerar os casos de teste; semelhante ao equivalence partitioning o boundary-value pode ser medido. Boundary-Value (BV) = (número de combinações BV testadas/ número total de combinações BV)*100 Random Testing É um tipo de teste funcional que é útil quando o tempo necessário para escrever e executar testes é muito longo (ou a complexidade do problema torna impossível testar cada combinação). Em relação a Random Testing, o SLA pode descrever, por exemplo, a exigência deque não poderá haver falhas aleatórias durante 2 semanas antes do lançamento do sistema. State Transition Testing System Intelligent Process Testing Link Consulting,SA Pág. 33 de 62

35 State Transition Testing é utilizado quando algum componente do sistema pode ser descrito como uma máquina de estados finito. Isto significa, que o sistema pode estar num número (finito) de diferentes estados, e as transições de um estado para outro é determinada pelas regras da máquina de estados. Alguns dos pontos que podem ser abordados no SLA relativos a State Transition Testing são: cada estado deve ser coberto pelo menos uma vez; cada transição deve ser executada pelo menos uma vez; cada transição que viole a especificação deve ser verificada. Uma tabela de estados pode ser utilizada para verificar o número total de combinações de estados e transições (válidas e inválidas). Para software crítico o SLA pode também incluir as seguintes regras: todas as combinações de transições têm que ser verificadas; todas as transições em qualquer ordem, com todos os estados possíveis, têm que ser verificadas. Static Testing É uma forma de testar o sistema que não envolve a execução da aplicação a ser testada. Static Testing envolve analisar o código da aplicação para verificar principalmente a conformidade com os requisitos funcionais, com o design, as funcionalidades em falta e possíveis erros no código. Static Tests são em geral, eficazes na deteção de erros de lógica e de codificação. Uma possível métrica (passível de ser definida no SLA) para determinar se um programa (flow graph do programa) é mais ou menos complexo, é a cyclomatic complexity. Quanto mais complexo for o flow graph do programa, maior será o valor de cyclomatic complexity. Cyclomatic Complexity = L-N +2*P Onde L é o número de ligações entre os vários nós do flow graph, N é o número de nós que constituem o flow graph e P é o número de componentes independentes (número de partes desconetadas do flow graph) B7 Definição de SLAs a aplicar na frente de testes de segurança Nesta tarefa procurou-se definir um modelo de SLAs para segurança. Um modelo SLA para segurança é difícil de projetar, isto porque a segurança é difícil de medir, não é um produto, ou um fluxo, ou um processo. No entanto, pode ser generalizado para níveis de controlo/checkpoints necessários para garantir que não existem desvios do ponto de vista da segurança de uma organização. Por exemplo, o tempo necessário para abrir/fechar tickets, tempo para configuração das mudanças nas políticas, disponibilidade dos serviços de monitorização, tempo para corrigir vulnerabilidades, atualização de arquivos com as definições de vírus e vários outros parâmetros que podem ser utilizados. Uma possível métrica é a medição do Risco. A gestão de riscos define Segurança da Informação em termos que possa ser aplicada a projetos de segurança, aplicando apropriados controlos de segurança, até que esse valor esteja dentro dos parâmetros da organização. Além disso, devem ser realizadas autoavaliações para servir como barómetro, e audições internas/externas como ferramenta para validar o progresso. System Intelligent Process Testing Link Consulting,SA Pág. 34 de 62

36 Por exemplo, a Neteller 5 tenta alinhar os SLAs de segurança com outras métricas, como por exemplo, a disponibilidade do sistema. Disponibilidade é a probabilidade de um sistema está a funcionar com sucesso de acordo com a sua especificação, num determinado ponto no tempo, assumindo que os recursos externos estão também disponíveis. Relativamente à disponibilidade, um SLA tipicamente descreve consequências associadas com o tempo médio de falhas dos serviços (medido em tempos de relógio e não em tempos de execução). Outros parâmetros que podem também ser especificados são: a resposta do sistema quando ocorre uma falha; o tempo que demora a reconhecer uma falha; quando tempo demorará a recuperar de uma falha; o tempo que o sistema está em baixo para a realização de uma atualização (deverá ser zero); a percentagem de tempo que o sistema estará disponível e em pleno funcionamento. O SLA disponibilizado pela Hosted Test 6 aos seus clientes, fornece metas de segurança, serviço, suporte, tempo que o sistema está em funcionamento (uptime) e desempenho. A Hosted Test assegura no SLA a privacidade dos dados utilizando as melhores práticas para segurança como, proteção com a utilização de passwords, encriptação de dados e redes seguras. Assegura também a proteção dos dados executando regularmente cópias de segurança para recuperação em caso de algum ataque/falha do sistema. A Education Shared Information Security Service (ESISS) 7 oferece um portfólio completo de serviços (Automated Penetration Testing Service, Network HealthCheck, Reputation Dashboard ) destinados a minimizar o risco de violações de segurança e reduzir os custos associados a atividades de prevenção, gestão, reabilitação e auditoria. Um SLA típico da ESISS descreve os seguintes pontos: a resposta do sistema quando ocorre uma falha; o serviço; os vários níveis do serviço; as responsabilidades da ESISS e do cliente; taxas e pagamentos; como os problemas com o serviço serão resolvidos. Não existe uma padrão ou fórmula para desenvolver um SLA para testes de segurança, também pelo facto da segurança ser uma jornada que nunca termina. No entanto, a organização IT Governance 8 disponibiliza documentação que poderá ser útil tanto às organizações que fornecem o serviço como aos cliente, dividida em duas secções: (1) Service Level Agreements, onde se podem encontrar livros e ferramentas que ajudam à criação de SLAs, (2) Service Level Management, que facilitam a identificação contínua, a monitorização e análise dos níveis de serviço, conforme estabelecido no SLA. 5 Neteller, Hosted Test, Education Shared Information Security Service, https://www.esiss.ac.uk/, IT Governance, System Intelligent Process Testing Link Consulting,SA Pág. 35 de 62

37 B8 Definição de SLAs a aplicar na frente de testes de carga e desempenho Esta tarefa incidiu na definição de SLA a aplicar na frente de testes de carga e desempenho. Os SLAs deverão estar alinhados com expectativas criadas nos utilizadores finais e a sua correta criação implicará uma gestão correta das expectativas que se pretende criar em utilizadores finais. De uma maneira similar, a ligação estrita entre testes de carga/desempenho e SLAs implica que estes sejam definidos tendo também em mente testes exequíveis. Por estas razões, SLAs devem ser definidos em fases iniciais do desenvolvimento de um produto ou serviço. Adicionalmente, SLAs devem seguir uma metodologia centrada no utilizador e de acordo com produtos concorrentes, dependendo do objetivo do produto. Finalmente, a definição das métricas usadas em SLAs leva em consideração os fatores mais relevantes para o sucesso desses SLAs. Desta maneira, Hayes define 5 princípios que devem ser considerados na elaboração de métricas: Escolher medidas que motivam o comportamento correto do produto Certificar que as métricas refletem fatores controláveis pelo fornecedor do serviço Escolher medidas que possam ser compiladas facilmente Minimizar a quantidade de métricas usadas mantendo a sua significância e interdependência Definir uma linha de base adequada. Concretamente, os SLAs devem adotar a seguinte informação e estrutura: 1. Background; 2. Pessoas e organizações envolventes; 3. Serviços a ser disponibilizados pelo fornecedor e a sua duração/período de tempo; 4. Procedimentos de encomenda e entrega; 5. Desempenho acordado e standard do serviço (QoS); 6. Responsabilidades do consumidor; 7. Avaliações de desempenho e de arbitragem; 8. Procedimento para alteração do SLA; 9. Pontos de contacto para manutenção do SLA. Depois de definir uma estrutura adequada e de descrever como criar e fazer manutenção de SLAs, apresentam-se abaixo alguns exemplos de SLAs implementados em serviços existentes que foram analisados. Exemplo de SLA entre um serviço de IT (o serviço fornecido) e um serviço de treino e desenvolvimento de uma empresa (o cliente); Exemplo de SLA entre uma equipa de IT e os utilizadores de uma escola; SLA genérico fornecido pela Microsoft; System Intelligent Process Testing Link Consulting,SA Pág. 36 de 62

38 Exemplar de um SLA do Woodgrove Bank para um serviço para desktops; SLA usado para vtools.webinabox ; Template de um SLA para projetos PPP do Governo da Arábia Saudita. No entanto, a criação de SLAs e da sua aplicação no desenvolvimento de um produto ou serviço não é suficiente para garantir a qualidade do mesmo (QoS Quality of Service). SLAs podem, e devem, ser também usados na manutenção dos produtos a fim de testar o QoS, quer em termos de disponibilidade, quer em tempo de resposta. Esta manutenção deve ter em conta componentes internos, bem como, componentes externos do produto. Desta maneira, os testes de carga e desempenho devem ser efetuados do ponto de vista do consumidor, ou seja, testando um sistema por completo e não apenas os seus módulos. Os serviços externos ao produto descrito no SLA terá também de ser contabilizado já que a sua disponibilidade e tempo de resposta influenciam diretamente o QoS do serviço a fornecer. Testes dos SLAs devem, por norma, ser associados a iterações do desenvolvimento de um serviço, de forma que, se numa iteração estes forem violados, possa ser feito rollback para uma versão estável que cumpra os SLAs pretendidos ou mesmo identificar o bottleneck que causa o incumprimento dos SLAs B9 Definição de SLAs a aplicar na frente de automação de testes Os SLA típicos aplicáveis a testes de automação são essencialmente os mesmo que os SLA aplicáveis em frente de testes funcionais e que podem ser definidos segundo as métricas dos vários métodos que caraterizam os testes funcionais: EquivalenceClass Partitioning, Boundary-Value Analysis, Random Testing, State Transition Testing e Static Testing, (ver secção sobre SLAs aplicáveis em frentes de testes funcionais). No entanto para uma frente de testes funcionais para além dos SLA à que ter também em linha de conta o retorno que o investimento em automação irá proporcionar. Atualmente, as empresas contam com infra-estruturas de computação muito complexas. Uma organização típica pode depender de várias aplicações que foram desenvolvidas para trabalhar em sistemas operativos diferentes, que utilizam diferentes front-end com clientes, envolvem numerosos processos de negócio, e interagem com muitos conjuntos de dados separados. Testar todas as permutações possíveis desses componentes cria uma situação altamente complexa, com centenas ou milhares de cenários de testes. Quando o software falha, a despesa para tentar controlar a falha e resolve-la, pode ser extremamente alta. E quanto mais tarde essas falhas forem descobertas no ciclo de desenvolvimento, mais caras elas serão. Uma falha identificada quando o software está já em produção pode ser 100 vezes mais cara do que a reparar a mesma falha, mas identificada anteriormente na fase de conceção. A automação pode ser a chave para melhorar a velocidade e a flexibilidade do processo de teste de software, permitindo que a organização possa encontrar e corrigir as falhas mais cedo. Em geral, faz sentido concentrar os esforços de automação em processos críticos do negócio e aplicações complexas. Mas se a organização tiver uma equipa de testadores independente que passam muitas horas a testar o software, e mesmo assim a organização ainda tem problemas de qualidade, a organização deve definitivamente mudar para testes automatizados. A decisão se se deve ou não automatizar o processo de teste deve ser System Intelligent Process Testing Link Consulting,SA Pág. 37 de 62

39 considerada através do cálculo do valor do Return On Investment (ROI). O valor do ROI para qualquer investimento pode ser simplesmente calculado como: ROI = Valor líquido do investimento/custo inicial Tradicionalmente, para automação o ROI funciona quando qualquer caso de teste tem que ser executado mais de 13 vezes. Após este número, a automação começa a ser mais barata do que o teste manual. Em geral, haverá um retorno positivo se a aplicação requerer testes de regressão, requerer multiplas compilações/correções, precisar de ser testado com hardware diversificado, com numerosas configurações de software, e se precisa de suporte a vários utilizadores em simultâneo. Além disso, se as tarefas repetitivas, como o carregamento de dados e a configuração do sistema estiverem envolvidas, a automação certamente será mais económica. Ahmed descreve como exemplo: suponha que para qualquer caso de teste o esforço total para escrever o teste é de 15 minutos e a sua execução manual igualmente 15 minutos. Serão necessárias 6 horas e 30 minutos para executar o caso de teste 13 vezes. Supondo, também, que a automação do mesmo caso de teste demora à volta de 6 horas. O script para a execução do caso de teste demora (em média) 3 minutos a executar. Portanto, o tempo necessário para escrever o caso de teste, automatizá-lo e executá-lo 13 vezes é à volta de 6 horas e 54 minutos. Testes de performance, testes de regressão, e outros tipos de testes semelhantes são os melhores candidatos à automação. Isto porque, quando um sistema é desenvolvido, novas funcionalidades serão adicionadas à nova versão. Portanto, a regressão das funcionalidades já existentes será testada em todas as novas versões seguintes. E sempre que essas funcionalidades sejam invocadas pelas novas funcionalidades nas novas versões, essas devem também ser re-testadas. De facto, o número de testes de regressão aumenta ao longo do tempo, com o aparecimento de novas versões. Mas os recursos para testar são sempre limitados e não aumentam ao longo do tempo. Então, a equipa de desenvolvimento que assegura a qualidade do produto, acaba tendo menos recursos para executar os inúmeros testes de regressão. É por isso que faz sentido automatizá-los, para que as necessidades de recursos possam ser reduzidas significativamente. A automação é a execução repetida de casos de teste, que são na maioria casos de verificações do sistema (no caso do sistema em produção) ou para regressão (no caso de novas versões). Em testes manuais, os especialistas usam a sua experiência para testar o fluxo do programa, pontos de contato na integração com outros módulos, e outros aspetos funcionais do sistema para verificar se este falha. Testes de regressão automáticos (ou outros semelhantes) não são apropriados para tipos de testes que apenas os seres humanos podem fazer e exigem muito do pensamento intuitivo. Desta forma, podemos concluir que cabe a cada organização avaliar os prós e os contras da automatização ou não das várias fases (tipos) de teste funcionais B10 Especificação de uma ferramenta de serviço integrada. Nesta tarefa procedeu-se à especificação da plataforma integrada de testes a serviços. System Intelligent Process Testing Link Consulting,SA Pág. 38 de 62

40 T e st e r T e st e r Fe rrame ntas de Gove rnaç ã o E nt e rpri se Re posi t ory Domai n Control le r DSSIPTEST ( ) DB Te st E ngi nce Control le r T es t E ngi ne Control le r T es t Li nk Se rve r DB Te st L i nk Se rve r Figura 7 Arquitetura SIPTEST Como mencionado acima o objetivo desta solução foi o de agregar diferentes sistemas, de modo que a informação referente ao quality assurance dos serviços testados possa ser espalhada / partilhada entre eles. Procedeu-se então à especificação de uma plataforma de integração que a partir de uma ferramenta de gestão de testes permita, executar autonomamente testes automatizados a serviços, e que o resultado dessa execução seja registado nessa ferramenta de gestão de testes. Como já referido anteriormente esta solução integrada permite a um testador funcional registar os casos de teste numa ferramenta de gestão de testes (TestLink) e, após o registo dos casos de testes, que um testador (com um perfil mais técnico), aceda a uma ferramenta de automação de testes (SoapUI) e automatize esse mesmos casos de teste. Visto que a ferramenta de gestão de testes TestLink não tem qualquer add-in para execução automática de testes, foi necessário especificar um novo módulo ao qual se deu no nome de TestEngine, e que se trata de um WebService que permite executar autonomamente a partir do TestLink os testes automatizados no SoapUI, e após execução, reporta os resultados da execução no TestLink. Para além de reportar os resultados dos testes no TestLink, o TestEngine foi também especificado de modo registar o resultado da execução numa ferramenta de governação SOA, o OER. Por fim e de modo a completar o ciclo, foi também especificada a integração entre a ferramenta de governação SOA e uma ferramenta de arquitetura empresarial (o EAMS desenvolvida pela Link), que permite que todos os conceitos relacionados com quality assurance associados aos serviços sejam visualizados de uma simples ao nível desta ferramenta. System Intelligent Process Testing Link Consulting,SA Pág. 39 de 62

41 3.1.3 C Aquisição e desenvolvimento de novos conhecimentos Esta etapa do projeto C. Aquisição e desenvolvimento de novos conhecimentos foi concluída na totalidade e tinha como missão: Definição do meta modelo da base de conhecimento Comparação com as melhores práticas de gestão de testes tendo por referência o CMM Investigação do estado da arte das técnicas de Arquitetura Empresarial para suporte aos testes Investigação do estado da arte das técnicas de teste para metodologias de desenvolvimento e arquiteturas específicas Tarefas Data de Conclusão C.1 - Definição do Meta Modelo da Base de Conhecimento 14/08/2012 C.2 - Comparação com as melhores práticas de gestão de testes 16/10/2012 C.3 - Estado da Arte das técnicas de Arquitetura Empresarial para suporte ao processo de 07/11/2012 testes C.4 - Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento 20/12/2012 Específicas C.5 - Estado da Arte das técnicas de Teste para Arquiteturas de SW específicas 28/12/ C1 Definição do meta modelo da base de conhecimento. Nesta tarefa definiu-se o meta modelo para a base de conhecimento. Um Meta Modelo permite consolidar os principais conceitos que dentro de uma organização deverão ser alvo de análise, bem como as relações entre esses conceitos. Foi definida uma abordagem que possibilitou consolidar quais os principais conceitos de uma arquitetura, estabelecendo assim uma linguagem arquitetural única, suportada por critérios bem definidos que permitam eliminar interpretações ambíguas dos termos utilizados. Para que tal aconteça a descrição de cada conceito foi complementada com os seguintes aspetos: Propriedades: Características inerentes a cada conceito Relações: Clarificação dos conceitos que estão diretamente relacionados com determinado tipo de conceito. O Meta Modelo explicita os conceitos que foram definidos na arquitetura bem como as suas relações conceptuais. Este modelo pretendeu ser fundamentalmente um instrumento na clarificação de conceitos, abstraindo-se das questões de implementação associadas aos modelos de dados. System Intelligent Process Testing Link Consulting,SA Pág. 40 de 62

42 Contains Tests of Contains Tests Test Composed by Business Process Composes Subscribes / Subscribed by Service Contains Interface Service Interface Defined by Artifact: WSDL Interface Of Defines Tested by Functional Test Case Performance Test Case UAT User Acceptance Test Contained in Test Suite Figura 8 Meta modelo da solução C2 Comparação com as melhores práticas de gestão de testes. Esta tarefa debruçou-se sobre a comparação das melhores práticas na gestão de serviços de testes De maneira a otimizar a comunicação e disponibilizar os meios de teste e reporting essenciais, podem ser usadas frameworks de gestão destas soluções. Estas frameworks podem servir como interfaces de comunicação estandardizada, evitando meios de comunicação menos eficientes para este tipo de tarefas rotineiras e recursivas como, por exemplo, s. Exemplos de linhas orientadoras para este tipo de ferramentas são: Acesso e alojamento seguro de informação de maneira a não disponibilizar informação sensível a pessoas não autorizadas; Implementação de um sistema de cargos para de maneira a facilitar a validação dos objetivos de trabalho; Rápida comunicação entre membros da empresa fornecedora e requerente do serviço de gestão; Elaboração, representação e gestão ágeis de processos e os seus agentes; Geração de relatórios deve ser acessível de maneira transparente e ser validado pela empresa requerente do serviço; System Intelligent Process Testing Link Consulting,SA Pág. 41 de 62

43 Finalmente, deve também conter geração automática de relatórios, quando possível Neste sentido, foram analisadas algumas frameworkss de gestão de serviços: Service Management Framework (SMF); Integrated Service Management (ISM); Information Technology Infrastructure Library (ITIL) C3 Estado da arte das técnicas de Arquitetura Empresarial para suporte aos testes. Esta tarefa centrou-se no estudo de modelo e frameworks de arquitetura empresarial no suporte aos testes, nomeadamente o TOGAF. O core do TOGAF é a Architecture Development Method (ADM), que é uma aproximação passo a passo para gerir o ciclo de vida de uma arquitetura empresarial. O desenvolvimento de uma arquitetura é um processo cíclico e contínuo. Ao executar o ADM repetidamente os arquitetos adicionam conteúdo gradualmente ao repositório de arquitetura de uma organização. Embora o principal foco do ADM seja o desenvolvimento específico da arquitetura empresarial, num contexto mais alargado o ADM pode ser visto como um processo de popular o repositório de arquitetura empresarial de uma empresa com componentes reutilizáveis relevantes. Entre estes componentes poderão estar conceitos que gravitam em torno do tema dos testes e do quality assurance, necessários à representação da problemática de testes em sistemas integrados no IT complexo de uma organização. Nomeadamente: Processos de Negócio, Use cases, Casos de Testes, Funcionalidades, Sistemas, Serviços, Interfaces, Componentes Aplicacionais e outros C4 Estado da arte das técnicas de teste para metodologias de desenvolvimento específicas. Nesta tarefa foi aprofundado o estado da arte no que diz respeito a técnicas de testes para metodologias de desenvolvimento específicas. Forma estudadas as seguintes metodologias de desenvolvimento: Modelo cascata Modelo espiral Modelo V Modelo ágil No que diz respeito ao modelo de cascata, é um tipo de modelo, em que não é dada a possibilidade de um testador saltar passos ou refazer passos anteriores isoladamente. Também não é contemplada a possibilidade da execução de várias destas tarefas em paralelo. Desta maneira, este modelo garante que cada tarefa é executada tendo como premissa a tarefa anterior, o que pode permitir desenvolver testes mais rapidamente. Por outro lado, se alguma das tarefas for mal executada, este modelo requer que o testador refaça todas as tarefas dependentes. De acordo com esta metodologia, o processo de testes é normalmente executado no final do ciclo de vida do desenvolvimento, i.e., depois do design e implementação de todos os requisitos da aplicação. Como consequência, os erros são mais complicados de detetar e custam, em média, mais recursos a reparar. Desta maneira, é possível afirmar que este modelo é indicado para uma equipa de testes com conhecimentos avançados, menos inclinada a cometer erros. System Intelligent Process Testing Link Consulting,SA Pág. 42 de 62

44 Relativamente ao modelo de espiral, é baseado em múltiplas iterações ( espiral ) sobre todos os passos descritos no modelo Cascata de maneira a que estes sejam todos executados, por ordem, múltiplas vezes. Este modelo é ideal para aplicações cujas funcionalidades não estão todas disponíveis no início do desenvolvimento. Desta maneira, cada espiral tem como objetivo desenvolver e testar apenas parte das funcionalidades da aplicação (as disponíveis, ou as selecionadas). Isto é verificado também para o desenvolvimento de testes neste modelo. Cada espiral deste modelo contempla portanto os passos descritos acima para o desenvolvimento de testes do modelo cascata. No entanto, através da segmentação no desenvolvimento de funcionalidades, o modelo Espiral garante que algumas das desvantagens do desenvolvimento de testes do modelo cascata (no qual se baseia) são eliminadas. No modelo em espiral, por exemplo, os erros são encontrados com mais facilidade e corrigidos em média com menor gasto de recursos. Relativamente ao modelo V, o processo pelo qual este modelo se rege pode ser descrito como desenvolvimento topdown e testes botom-up. O benefício em usar este modelo está na interligação e paralelismo das atividades de desenvolvimento e testes. Figura 9 Modelo V A metodologia específica para desenvolvimento dos testes no modelo em V assenta, portanto, numa subdivisão lógica na qual se partem de testes mais pequenos e independentes, para testes mais abrangentes em que todos os módulos são envolvidos. Concretamente, os testes deverão ser corridos de maneira a testar primeiro os componentes e o seu funcionamento (testes unitários), seguidos dos testes de integração entre os componentes, testes ao sistema como um todo e finalizando com testes de aceitação de maneira a validar os requisitos do produto. A metodologia de testes Ágil consiste num equilíbrio entre uma abordagem iterativa e uma sequencial. Em termos de desenvolvimento, este modelo incita o desenvolvimento rápido e incremental de funcionalidades. Em termos de testes, esta característica tem como repercussão a obtenção de iterações rápidas, práticas e que podem ser usados para testes finais com o utilizador (tendo em conta que parte das funcionalidades da aplicação poderão ser mock objects ou estar mesmo em falta). System Intelligent Process Testing Link Consulting,SA Pág. 43 de 62

45 Neste modelo estão incorporadas várias técnicas para desenvolvimento de testes (tais como: Test-driven development; Rapid aplication development; Scrum) que assentam no mesmo princípio de desenvolvimento ágil, enunciado acima C5 Estado da arte das técnicas de teste para arquiteturas de SW específicas. Para além das metodologias de desenvolvimento de testes descritas acima, existem também metodologias para desenvolvimento de testes que se diferenciam consoante a arquitetura do produto a desenvolver. Neste sentido, foram estudadas algumas arquiteturas de software mais comuns (tais como: 3-tier, SOAs, Cloud compu ting, peer-to-peer e aplicações monolíticas) e as metodologias de desenvolvimento de testes que mais se adequam. Ao nível da arquitetura 3-tie, cuja aplicação está dividida em módulos, os testes devem seguir uma estrutura que garanta o bom funcionamento inter e intra-módulos. Desta maneira, a fase de testes deve ser estruturada de uma maneira semelhante ao Modelo em V. Ao dividir os testes em testes unitários, testes de integração, testes de sistema e testes de aceitação, estamos a garantir que os vários módulos e as suas interações estão a ser testados. Adicionalmente, deve ser assegurado que os testes são desenvolvidos e mantidos aquando do desenvolvimento de cada módulo. No que respeita às arquiteturas orientadas a serviços, a metodologia de testes a seguir seria o Modelo em V, no qual são feitos: testes unitários, testes de integração, testes de sistema e testes de aceitação. É também comum neste tipo de arquiteturas o recurso a simuladores de módulos aquando da execução de testes unitários e de integração (como por exemplo, mock objects). Pode-se afirmar que as arquiteturas cloud computing é uma evolução das arquiteturas Service-oriented descritas anteriormente. A diferença nestas estruturas está por vezes na definição/estabilidade da interface de comunicação e/ou no facto de cada serviço poder ser disponibilizado a mais do que um tipo de aplicação. Dada esta semelhança entre arquiteturas Cloud-Computing e arquiteturas Service-oriented, é possível afirmar que os seus testes também partilham metodologias semelhantes. Uma das características do Cloud-computing é a ênfase na abstração de serviços. Neste contexto, é possível afirmar que o desenvolvimento e execução de testes à comunicação entre os serviços adquire maior relevo. Portanto, neste tipo de arquiteturas, são especialmente fundamentais os testes de integração dado o desenvolvimento potencialmente díspar entre cada serviço, do qual uma aplicação depende. De uma maneira semelhante às SOAs e às arquiteturas Cloud-Computing, as arquitecturas pear-to-pear (P2P) depende de serviços remotos para operar corretamente e os testes podem, portanto, seguir metodologias semelhantes. No entanto, este tipo de arquitetura em específico é normalmente capaz de sobreviver ao mau funcionamento de um serviço (um peer) já que tipicamente cada peer é especializado num tipo de tarefa. Contudo, todos eles conseguem executá-la. Em termos de arquiteturas P2P sem host, se uma das linhas de comunicação estiver a falhar, não significa que o nó está inacessível, o que indica que o desenvolvimento de testes deve focar-se principalmente na falha de comunicação entre peers e nas suas potenciais consequências, como pedidos duplicados. Por outro lado, em termos de arquiteturas P2P com recurso a um host, estes tipos de falhas são menos frequentes por haver um controlo centralizado de pedidos. No entanto, o desenvolvimento de testes deve focar-se em problemas de comunicações com o servidor host, cujas falhas podem ter como consequência a indisponibilização de toda a aplicação distribuída. System Intelligent Process Testing Link Consulting,SA Pág. 44 de 62

46 Ao contrário de todos tipos de arquitetura vistos neste documento, arquiteturas monolíticas são arquiteturas de apenas uma camada. Isto quer dizer que, por oposição a, por exemplo, arquiteturas 3-tier, o código dos vários módulos (interface de utilizador, lógica de negócio e base de dados) estão interligados. Este tipo de arquitetura tem a vantagem de ser independente de outras aplicações e serviços e de reduzir o número de erros provenientes de aplicações ou serviços externos (por ter nenhuma ou quase nenhuma dependência). Quanto à metodologia de testes a seguir neste tipo de arquiteturas, existem várias hipóteses possíveis dependendo do tipo de produto a ser desenvolvido e da maneira como ele é desenvolvido. No caso desta arquitetura, o mais indicado parece ser seguir a metodologia de desenvolvimento do produto e interligá-la com uma metodologia de desenvolvimento e execução de testes D Desenvolvimento Esta etapa do projeto foi concluída na sua totalidade. Na tarefa D.1 - Instalação dos ambientes e ferramentas procedeu-se à instalação dos ambientes de desenvolvimento, incluindo os ambientes de programação, das ferramentas escolhidas e para integrar a plataforma integrada de testes SOA. A tarefa D.2 - Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste, consistiu de 3 etapas: parametrização do meta-modelo na ferramenta de arquitetura Empresarial (OER); implementação dos serviços de importação da informação para dentro da ferramenta de arquitetura empresarial, parametrização de cada uma das ferramentas para importação e exportação da informação necessária. Na tarefa D.3 - Desenvolvimento da ferramenta de gestão de testes procedeu-se ao desenvolvimento da primeira versão da plataforma integrada para testes SOA. Na tarefa D.4 Desenvolvimento do modelo final da ferramenta de gestão de testes procedeu-se ao desenvolvimento da versão final da plataforma integrada para testes SOA. Durante esta atividade foram realizadas as seguintes tarefas: Tarefas Data de Conclusão D.1 - Instalação dos ambientes e ferramentas 18/09/2012 D.2 - Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste 14/08/2013 D.3 - Desenvolvimento da ferramenta de gestão de testes 19/09/2013 D.4 Desenvolvimento do modelo final da ferramenta de gestão de testes 27/09/ E Construções de protótipos para testes e documentação da solução implementada Na atividade E. Construção de protótipos para testes e documentação da solução implementa, e com base nos resultados da fase de desenvolvimento, todas as componentes foram integradas para construção, instalação e configuração de protótipos, o que permitiu validar posteriormente a adequação dos módulos desenvolvidos. Esta atividade teve, ainda, por objetivo global obter uma configuração da solução, muito próxima daquela que se está a divulgar e pretende-se comercializar. System Intelligent Process Testing Link Consulting,SA Pág. 45 de 62

47 Por fim procedeu-se à compilação da documentação de todo o sistema desenvolvido e de todas as interfaces produzidas. Durante esta atividade foram realizadas as seguintes tarefas: Tarefas Data de Conclusão E.1 - Revisão da documentação e normalização dos processos definidos E.2 - Construção de Protótipos para Testes e Documentação da solução implementada F Testes e Ensaios A validade dos protótipos foi testada na atividade F. Testes e Ensaios, a qual teve por objetivo validar os resultados através de utilizadores-teste. Esta atividade permitiu detetar ineficiências e promover a respetiva correção ou ajustamento necessários a um desempenho ótimo por parte da solução face aos objetivos ambicionados. Durante esta atividade foram realizadas as seguintes tarefas: Tarefas Data de Conclusão F.1 - Testes Unitários e de Integração 20/12/2013 F.2 - Set up da frente dos vários serviços de testes funcionais, segurança, carga, e automação 26/12/2013 de testes G Promoção e divulgação de resultados A atividade G. Promoção e divulgação de resultados está concluída, tendo sido terminada com o evento de fecho Test Our Cofee realizado a 11 de Dezembro de A sua execução foi determinante na disseminação dos resultados alcançados neste projeto e na criação de consciência sobre o potencial de vantagens e benefícios conseguidos, bem como a rentabilidade da solução desenvolvida. Esta atividade decorreu ao longo de todo o projeto e foi no seu âmbito que que se criou o site do SIPTEST, tendo sido publicados os resultados do mesmo para divulgação nacional e internacional, se criou material promocional, e se participou em eventos para divulgação pública dos resultados obtidos. Esta atividade subdividiu-se nas seguintes tarefas: Tarefas Data de Conclusão G.1 - Produção e publicação de documentos científicos 31/12/2013 G.2 - Criação de um microsite da oferta 31/12/2013 G.3 - Divulgação em fóruns Industriais e Científicos das lições aprendidas e resultados 27/12/2013 alcançados no SIPTEST G.4 Evento de fecho do projeto 27/12/ Milestones No decorrer das atividades realizadas no período do projeto atingiram-se os seguintes milestones. System Intelligent Process Testing Link Consulting,SA Pág. 46 de 62

48 Tarefa Milestone Data A1 M1 Relatório do estudo comparativo entre ferramentas de testes analisadas, com as "best" práticas de teste e com o estado da arte de utilização de técnicas de Arquitetura Empresarial na problemática de teste. A2 M2 Documento com a análise do estado da arte das ferramentas de testes de segurança e a identificação das mais evoluídas e respetivas características. A3 M3 Documento com a análise do estado da arte das ferramentas de teste de carga e desempenho e a identificação das mais evoluídas e respetivas características. A4 M4 Documento com a análise do estado da arte das ferramentas de automação de testes e a identificação das mais evoluídas e respetivas características. A5 M5 Documento com a análise do estado da arte na prática de testes tendo como referência o CMMI. B1 M6 Relatório sobre as medidas corretivas e objetivos de segurança que a nova solução deverá atingir face ao que existe no mercado. B2 M7 Documento: Objetivos metodológicos para o novo modelo de testes de carga e desempenho. B3 M8 Objetivos metodológicos para o novo modelo de automação de testes B4 M9 Documento: Objetivos metodológicos para o novo modelo de testes funcionais B5 M10 Documento: Arquitetura de integração das ferramentas selecionadas B6 M11 Relatório: SLAs a aplicar na frente de testes funcionais B7 M12 Relatório: SLAs a aplicar na frente de testes de segurança B8 M13 Relatório: SLAs a aplicar na frente de testes de carga e desempenho B9 M14 Relatório: SLAs a aplicar na frente de automação de testes B10 M15 Documento: Análise do historial dos projetos de testes estudados e especificações de possíveis SLA para cada uma das frentes de testes do modelo de serviço, segmentadas por tipo de sistema. Ferramenta de gestão de serviço operacional C1 M16 Documento: Meta Modelo da Base de Conhecimento C2 M17 Relatório: Comparação com as melhores práticas de gestão de testes, tendo por referência o CMMI C3 M18 Documento: Estado da Arte das técnicas de Arquitetura Empresarial para suporte ao processo de testes C4 M19 Documento: Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento Específicas C5 M20 Documento: Estado da Arte das técnicas de Teste para Arquiteturas de SW específicas D1 M21 Relatório: Ambientes e ferramentas de desenvolvimento instalados D2 M22 Relatório: Parametrização das ferramentas de testes a desenvolver D3 M23 Relatório: Primeira versão do modelo de gestão de testes SIPTEST e respetivas ferramentas D4 M24 Relatório: Versão final do modelo de gestão de testes SIPTEST e respetivas System Intelligent Process Testing Link Consulting,SA Pág. 47 de 62

49 ferramentas E1 M25 Documento: Características e metodologias em que deverá assentar o modelo de gestão de testes e as respetivas ferramentas. E2 M26 Construção do Protótipo F1 M27 Relatório dos testes unitários e de integração efetuados e análise das conclusões. F2 M28 Relatório dos testes funcionais, de segurança e de carga efetuados, bem como da respetiva automação e análise dos respetivos resultados. G1 M29 Documento síntese das publicações e documentos científicos publicados G2 M30 Construção de um site para divulgação dos resultados do projeto à medida que o mesmo se vá desenvolvendo com constante atualização em função dos resultados obtidos. G3 M31 relatório de resumo da divulgação do SIPTEST em fóruns industriais e científicos. G4 M32 Relatório do evento e respetivos resultados Resultados alcançados Na secção abaixo descrevem-se os principais resultados alcançado no âmbito deste projeto, com a plataforma integrada para testes a serviços SOA Eliminar limitações à execução de testes funcionais Um dos principais óbices nos testes a serviços e orquestrações é a dificuldade com que os testadores funcionais (que dominam as particularidade do negócio que os serviços sustentam) se deparam na execução dos seus testes. Para a executar testes a um serviço é necessário recorrer a uma ferramenta de automação de testes a serviços, o que requer um domínio técnico da linguagem utilizada pela ferramenta, bem como um conhecimento das API s dos serviços que irão ser testados. De uma forma geral os testadores funcionais e Key users não possuem este conhecimento, o que se torna uma restrição à execução de testes funcionais, que acabam muitas vezes por não ser executados com a profundidade necessária. De forma a contornar este problema procedeu-se, no seio desta plataforma, à integração entre uma ferramenta de automação de teste funcionais a serviços e uma ferramenta de gestão de testes, habitualmente utilizada pelos key user e testadores funcionais para planear e registar a execução dos seus testes. A ferramenta de gestão de testes foi estendida por forma a permitir que um testador, uma vez concluída a tarefa de especificação de testes, alerte através do envio de um as equipas de desenvolvimento (ou testadores com um perfil mais técnico) que os testes se encontram especificados e estão prontos para serem automatizados. Por sua vez a ferramenta de automação de testes funcionais a serviços foi também estendida com um mecanismo que permite que as equipas de desenvolvimento (uma vez terminada a automação dos testes) possam associar os testes codificados aos testes especificados na ferramenta de gestão de testes. O resultado desta associação permitirá aos testadores funcionais despoletar a execução dos testes diretamente da ferramenta de gestão de testes, bem como receber e registar os resultados da execução. System Intelligent Process Testing Link Consulting,SA Pág. 48 de 62

50 A plataforma passou assim a permitir: a) A existência de um mecanismo de comunicação entre a comunidade de testadores funcionais e key users e as equipas de desenvolvimento ou testadores técnicos. b) Aos testadores funcionais a possibilidade de planearem, especificarem e executarem autonomamente os seus testes funcionais sem terem de abandonar a ferramenta de trabalho com a qual estão mais familiarizados, e sem terem de dominar a complexidade técnica das API e da ferramenta de automação de teste funcionais a serviços Gestão eficaz de defeitos Uma gestão eficaz dos defeitos reportados é mandatória em qualquer processo de QA bem estruturado. Como tal, esta plataforma foi complementada com a integração de uma ferramenta de gestão de defeitos que permite aos testadores funcionais, aquando da ocorrência de um defeito na execução de um teste, proceder ao registo e atribuição dos mesmos às equipas de desenvolvimento diretamente a partir da ferramenta de gestão de testes. Desta forma todo o processo de reporte de um defeito poderá ser iniciado diretamente a partir da ferramenta de gestão de testes, ficando o defeito aberto automaticamente associado ao teste onde foi detetado (principio da rastreabilidade). Por seu lado as equipas de desenvolvimento serão automaticamente notificadas por da abertura de um defeito na ferramenta de gestão de defeitos onde poderão consultar toda a informação a respeito do defeito bem com eventuais evidências recolhidas. A partir da ferramenta de gestão de testes os testadores funcionais poderão também fazer todo o acompanhamento dos defeitos associados a um teste, desde a sua abertura até ao seu fecho e assim saber quando poderão reexecutar um teste (após a correção dos defeitos). Através desta integração conseguiu-se assim agregar a esta plataforma uma gestão eficaz do ciclo de vida dos defeitos, assegurando a rastreabilidade entre os testes e os correspondentes defeitos reportados, disponibilizando uma comunicação fluida entre os testadores funcionais e as equipas de desenvolvimento, e permitindo mais uma vez à comunidade de testadores funcionais a possibilidade de o fazer a partir da ferramenta de gestão de testes com a qual estão mais familiarizados Estender o QA à governação dos serviços A visibilidade sobre o andamento das iniciativas de QA, para além das equipas de testadores ou das próprias equipas de desenvolvimento, é algo de pouco frequente e que motiva que arquitetos SOA, equipas de desenvolvimento e testadores tenham muitas vezes visões diferenciadas sobre o progresso do desenvolvimento de novos serviços ou orquestrações. Para obviar este problema, esta plataforma foi enriquecida com uma integração entre a ferramenta de automação de testes funcionais aos serviços (onde os testes são efetivamente executados) e uma ferramenta de governação de serviços. Esta integração permite que os resultados da execução dos testes (resultados, erros, nº de execuções, etc ) sejam propagados à ferramenta de governação ficando associados aos respetivos serviços e orquestrações. System Intelligent Process Testing Link Consulting,SA Pág. 49 de 62

51 Desta forma, quando um arquiteto SOA aceder à ferramenta de governação SOA poderá encontrar para além de toda a informação habitual referente à governação dos serviços (Ex: dependências, endpoints, interfaces, WSDL), informação complementar sobre o progresso das atividades relacionadas com o processo de QA (plano de testes, testes executados, resultado dos testes etc..). No sentido inverso esta integração permite também, sempre que for detetado um erro na execução de testes a um serviço, informar a ferramenta de automação de testes funcionais, sobre quais os serviços dependentes do serviço testado. Esta informação é por sua vez agregada ao resultado da execução dos testes e propagada até à ferramenta de gestão de testes onde surgirá como um alerta aos testadores funcionais. Com esta integração, conseguiu-se por um lado enriquecer a visão que a comunidade de arquitetos SOA pode ter sobre o progresso dos serviços e orquestrações em desenvolvimento, e por outro lado alertar testadores funcionais sobre as dependências entre serviços onde foram detetados problemas na execução de testes QA para além da entrada em produção Para além dos serviços que estão em desenvolvimento ou prestes a entrarem em produção, outro aspeto com o qual a governação SOA se preocupa é o desempenho dos serviços em produção. Mais uma vez, e também nesta matéria, não é comum uma visão consistente e partilhada entre gestores de operações e os arquitetos SOA. A pensar nesta problemática foi adicionada a esta plataforma uma integração entre uma ferramenta de automação de teste de carga a serviços e a ferramenta de governação. Esta integração permite (da mesma forma que para os testes funcionais) que após a execução dos testes de carga os resultados sejam exportados para a ferramenta de governação e fiquem associados aos respetivos serviços. Desta forma os arquitetos SOA passam a dispor em tempo real na sua ferramenta de governação uma visão sobre o progresso dos testes de performance aos serviços de forma geral, e em particular sobre os testes de desempenho aos serviços já em produção, podendo atuar de imediato Envolver gestores de negócio nas iniciativas de QA Uma ferramenta de arquitetura empresarial permite visualizar de forma fácil as relações entre diversos domínios (processos de negócio, aplicações, projetos, serviços, orquestrações) de uma organização e a forma como essas relações se alteram ao logo do tempo. No seio desta plataforma foi também assegurada uma integração entre a ferramenta de governação SOA e uma ferramenta de arquitetura empresarial, com o intuito de adicionar a esta ferramenta a possibilidade de visualizar as relações de conceitos associados ao QA (Ex: casos de testes, bateria de testes) e os restantes conceitos nela habitualmente mapeados (Ex: serviços, orquestrações, aplicações, etc ). Desta forma, será possível aos gestores de negócio visualizarem sob a forma de mapas os testes planeados para um dado serviço e a data prevista de execução, e ao longo do tempo analisar a evolução do estado de execução dos testes de um serviço num determinado período, ou ainda visualizar dashboards sobre o estado de maturidade de uma orquestração indicando o número de serviços testados com sucesso ou percentagem de casos testes passados. System Intelligent Process Testing Link Consulting,SA Pág. 50 de 62

52 4 Resultados 4.1 Valorização dos resultados de I&D decorrentes do projeto O objetivo estruturante desta candidatura foi dotar a Link Consulting de competências na área dos Testes e Quality Assurance, com o intuito de fazer evoluir a linha de serviços e produtos SQA, que constituem a oferta Link para o mercado dos testes e qualidade. Esta evolução teve como objectivos centrais: Definir e sistematizar metodologias de testes alinhadas (e que vão para além de) com o estado da arte em diversas frentes de testes; Criar uma ferramenta inovadora para gestão de testes. Consistentemente, os resultados do SIptest encontram-se perfeitamente alinhados com esses objetivos. Foram estudadas e comparadas várias metodologias de testes analisando-as, quer pelo prisma da arquitetura do SW, quer pela metodologia de desenvolvimento e foi desenvolvida uma plataforma inovadora de gestão de testes vocacionada para as arquiteturas SOA. Esta evolução, para além de constituir uma abordagem tecnologicamente inovadora, permitirá à link endereçar novos mercados em frentes de testes até agora difíceis de abranger. A nível da ferramenta, a plataforma desenvolvida adicionou ao portefólio da SQA uma solução que endereça vários problemas evidenciados nos testes a arquiteturas SOA, complementando valências de várias ferramentas utilizadas, quer na área dos testes, quer na governação SOA, como seja a ferramenta de arquitetura empresarial. Em termos genéricos esta evolução da oferta permite alargar o posicionamento da Link como fornecedor de soluções e serviços de testes em situações que anteriormente não seriam possíveis. Significa por isso um avanço importante em termos da capacidade de promoção destes produtos e serviços num universo mais abrangente de clientes, e por isso com um maior potencial de negócio. 4.2 Impacto do projeto para as entidades participantes Para os parceiros do meio científico e tecnológico este projeto permitiu a colaboração numa nova área de investigação e desenvolvimento, onde tipicamente não é feito qualquer tipo de investimento, e onde foram obtidos casos práticos e necessidades de negócio reais para testar as abordagens teóricas. Desta forma foi possível construir uma ponte efetiva de partilha com estas entidades, abordando as necessidades e dificuldades de casos reais de negócio, ao mesmo tempo que foi possível efetuar a transferência direta de conhecimento para o meio empresarial. Em linhas gerais, o impacto desta parceira com as entidades SCT, nomeadamente a FEUP, foi demonstrado pela adesão e interesse dos docentes e dos alunos que participaram no evento TOC (Test Our Coffee) realizado nas próprias instalações da FEUP (descrito com maior detalhe no ponto 6 deste relatório). System Intelligent Process Testing Link Consulting,SA Pág. 51 de 62

53 4.3 Principais/Potenciais clientes, Principais Concorrentes, Análise Comparativa Os novos desenvolvimentos na oferta SQA permitem ao promotor do Siptest abordar os clientes com as suas necessidades centradas na área da qualidade genericamente e especificamente na qualidade no desenvolvimento e operação de sistemas baseados em arquiteturas SOA. Estão neste grupo todas as grandes organizações na área financeira, das telecomunicações, do retalho e das utilities. A oferta link concorre no que respeita ao mercado de serviço de testes essencialmente com empresas que fornecem outsourcing de recursos que executam testes nas instalações do cliente. A investigação realizada pela Link permitiu-lhe sistematizar uma oferta de serviços de testes, assente em SLAs e em metodologias próprias bem como num modelo de negócio onde o risco é totalmente partilhado com o cliente. A oferta agora implementada dá-nos por isso um horizonte de clientes potenciais acrescido nos mercados onde operamos. Permite também avançar para novas geografias onde poderemos prestar serviços de testes em regime offsite, nos quais os recursos de testes estão fora das instalações do cliente (situados nas nossas instalações). Isto só é possível através de um modelo de prestação de serviços totalmente transparente para o cliente final, e onde o risco seja de facto partilhado entre as organizações. No que respeita à solução desenvolvida, ela é totalmente inovadora não existindo no nosso conhecimento oferta similar no mercado. A plataforma desenvolvida vai permitir à link, efetuar a gestão de testes em arquiteturas SOA de forma mais eficaz, integrando quer ferramentas utilizadas tipicamente na área do quality assurance, quer ferramentas de governação SOA. A solução desenvolvida assenta também essencialmente em ferramentas free, o que a torna mais competitiva face às soluções tradicionais dos fornecedores tipicamente bastante onerosas. 4.4 Quantificar o potencial valor de mercado dos resultados obtidos Tal como referido no ponto anterior, os desenvolvimentos agora efetuados permitem á Link abordar novos mercado onde até agora não tem conseguido grande penetração, com uma abordagem totalmente inovadora: Mercado nacional: Empresas da área do retalho, telecomunicações, banca, seguros e utilities; Mercado Europeu: Essencialmente empresas da área das telecomunicações e utilities e SW houses; PALOPS: Mercado mais restrito, Essencialmente empresas da área das telecomunicações Face a esta análise, conclui-se que existe um grande mercado potencial, especialmente fora de Portugal. A limitação aqui será apenas a capacidade comercial da Link para abranger estes mercados. System Intelligent Process Testing Link Consulting,SA Pág. 52 de 62

54 5 Avaliação Ex-Post Na avaliação que fizemos do projeto SIPTEST consideramos que o seu objetivo principal foi em grande medida alcançado. O projeto permitiu à empresa Link Consulting criar e evoluir a sua linha de oferta SQA (System Quality Assurance), no sentido de ganhar competência na área dos testes e de inovar através da criação de uma nova plataforma integrada de testes para sistemas baseados em SOA, o que vai permitir dar respostas às necessidades emergentes dos nossos clientes. Os conceitos explorados no projeto rompem com o modelo tradicional em que os serviços de outsourcing de testes assentam e permitem endereçar os problemas dos teste e da qualidade de uma maneira flexível e com custos de implementação mais reduzidos. Em termos gerais consideramos que o projeto permitiu alcançar os seguintes objetivos: Implementar linhas de serviços de testes assentes: o Em SLA. o Num processo transparente para o cliente (em termos do que é testado vs custos). o Num modelos de negócio fixed price e cotação prévia dos pedidos realizados (risco transferido para o fornecedor do serviço). Implementar uma plataforma integrada de gestão de testes para arquiteturas SOA que possibilita: o Mitigar a necessidade de conhecimentos técnicos detalhados requeridos para a execução de testes aos perfis mais funcionais, concedendo-lhes autonomia para planearem, especificarem e executarem os seus testes. o Implantar mecanismos de comunicação eficazes entre a comunidade de testadores funcionais, key users e as equipas de desenvolvimento ou testadores técnicos. o Que os diferentes perfis comprometidos no desenvolvimento e governação de uma arquitectura SOA (arquitectos, gestores de negócio, testadores funcionais, gestores de operações, key users), partilhem uma visão unificada e consistente do progresso das iniciativas de QA. o Suportar processos de QA que abranjam, tanto a fase prévia à entrada em produção dos serviços. como o acompanhamento após a entrada em produção Como foi já referido, os desenvolvimentos resultantes do SIPTEST permitem posicionar a Link Consulting como uma empresa inovadora e com soluções diferenciadoras na área dos testes e da qualidade, em particular nos mercados internacionais, onde a diferenciação pela inovação é particularmente relevante para as empresas portuguesas. Acrescenta ainda credibilidade à sua capacidade de fazer diferente e de gerir projetos de I&D com entidades do SCT. Assim, em termos qualitativos, este projeto contribuiu para: Uma maior diferenciação na proposta de valor das soluções SQA; Uma credibilização da empresa e da oferta ao apresentar uma imagem inovadora; A absorção de conhecimento especializado em áreas onde ele não existia; Suportar um discurso internacional mais consistente e sustentável; Reforçar as relações com a FEUP e a StrongStep, as entidades do SCT que participaram no projeto. A estratégia de valorização e desenvolvimento de negócio que a Link Consulting vai adotar para introduzir a solução desenvolvida no mercado passará pelas seguintes fases: 1. Divulgação dos protótipos desenvolvidos através da realização de road shows. System Intelligent Process Testing Link Consulting,SA Pág. 53 de 62

55 2. Criação de provas de conceito junto de clientes existentes e, a partir dessas experiências, publicar casos de estudo/referências. Este processo pressupõe que, caso haja adesão do mercado, se continue a desenvolver a oferta, nomeadamente acrescentando suporte a novos serviços e funcionalidades à plataforma desenvolvida, que por razões de restrição orçamental ficaram fora do âmbito deste projecto. System Intelligent Process Testing Link Consulting,SA Pág. 54 de 62

56 6 Notas Finais 6.1 Participação em Conferências e Publicações Foram levadas a cabo várias iniciativas para divulgação do SIPTEST, tendo como objetivo promover e divulgar os resultados da investigação do projeto e, simultaneamente, ir aferindo a recetividade por parte dos potenciais clientes às inovações introduzidas pelo mesmo. Artigo intitulado Plataforma integrada para testes em arquitecturas orientadas a serviços Especificamente, no âmbito da tarefa Produção e publicação de artigos e documentos científicos (G1), e em conjunto com a FEUP, foi escrito, submetido e aceite um artigo para a revista da qualidade intitulado: Plataforma integrada para testes em arquitecturas orientadas a serviços. Este artigo (uma cópia do artigo está também disponível no sitio do projeto) descreve detalhadamente o funcionamento da plataforma desenvolvida no âmbito do SIPTEST, focando os problemas que esta ajuda a resolver. Conferencia Testing Portugal 2013 A Link participou, enquanto speaker, na conferencia Testing Portugal 2013, promovida pela PSTQB - Associação Portuguesa de Testes de Software, que decorreu nos dias 25 e 26 de Novembro de 2013, em Lisboa. A notoriedade deste evento esteve na base da sua escolha como evento de apresentação dos resultados do projeto Siptest e da plataforma daí resultante, na medida em que o Testing Portugal é o maior certame nacional na área dos Testes e da Qualidade (de salientar que esta 4.ªedição teve carácter internacional). Pretende, pois, ser uma montra anual do que de melhor se está a fazer em termos de testes de software e qualidade, quer no mercado nacional, quer numa perspetiva internacional (contando com a participação dos mais conceituados gurus da área), e é um evento direcionado para todos os Profissionais de Testes, Test Managers, e decisores na área da Garantia da Qualidade de Software (incluindo CEO e CIO). A apresentação realizada no dia 26 de Novembro, por José Granate Marques, System Quality Assurance (SQA) Services Manager da Link Consulting, intitulou-se Plataforma Integrada para Testes em Arquitecturas orientadas a Serviços, como se pode verificar no excerto da agenda do evento: Figura 10 Abstract conferência testes portugal System Intelligent Process Testing Link Consulting,SA Pág. 55 de 62

SIPTEST System Intelligent Process Testing. Estudo Comparativo de Ferramentas de Teste.

SIPTEST System Intelligent Process Testing. Estudo Comparativo de Ferramentas de Teste. SIPTEST System Intelligent Process Testing. Estudo Comparativo de Ferramentas de Teste. SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 7 Índice 1 Introdução... 2 1.1 Objectivo do documento...

Leia mais

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 10 Índice 1 Introdução...

Leia mais

System Quality Assurance

System Quality Assurance System Quality Assurance Visão Reduzir os custos inerentes à existência de defeitos em produção, em sistemas de alta complexidade funcional e de elevada heterogeneidade tecnológica, através de um conjunto

Leia mais

SIPTEST System Intelligent Process Testing. Estudo Ferramentas de Automação

SIPTEST System Intelligent Process Testing. Estudo Ferramentas de Automação SIPTEST System Intelligent Process Testing. Estudo Ferramentas de Automação SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 14 Índice 1 Introdução... 2 1.1 Objectivo do documento... 2

Leia mais

SIPTEST System Intelligent Process Testing. Arquitetura de integração das ferramentas selecionadas

SIPTEST System Intelligent Process Testing. Arquitetura de integração das ferramentas selecionadas SIPTEST System Intelligent Process Testing. Arquitetura de integração das ferramentas selecionadas SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 14 Índice 1 Introdução... 2 2 Ferramentas

Leia mais

Procifisc Engenharia e Consultadoria, Lda.

Procifisc Engenharia e Consultadoria, Lda. 01. APRESENTAÇÃO DA EMPRESA 2 01. Apresentação da empresa, com sede em Castelo Branco, é uma empresa criada em 2007 que atua nos domínios da engenharia civil e da arquitetura. Atualmente, é uma empresa

Leia mais

Sobre a Prime Control

Sobre a Prime Control Sobre a Prime Control A Prime Control é um Centro de Excelência em Qualidade de Software. Nossa missão é desenvolver, aperfeiçoar e realizar serviços de testes de software inovadores que agregam valor

Leia mais

Projeto 6.18 Automação de Testes Sistêmicos Funcionais

Projeto 6.18 Automação de Testes Sistêmicos Funcionais Projeto 6.18 Automação de Testes Sistêmicos Funcionais Paula Luciana F. Cunha, Rosanne M. R. Carneiro, Carlo Giovano S. Pires, Liane R. P. Bandeira, Paula M. Donegan, Camila Maia, Ana Cristina Matos 1.

Leia mais

SIPTEST System Intelligent Process Testing. SLAs a aplicar em frentes de testes funcionais

SIPTEST System Intelligent Process Testing. SLAs a aplicar em frentes de testes funcionais SIPTEST System Intelligent Process Testing. SLAs a aplicar em frentes de testes funcionais SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 8 Índice 1 Introdução... 2 2 SLAs a aplicar

Leia mais

PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 10/SI/2015

PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 10/SI/2015 PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 10/SI/2015 PROJETOS DEMONSTRADORES INDIVIDUAIS Título do projeto /

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

BPM Social: Novas formas de se trabalhar

BPM Social: Novas formas de se trabalhar BPM Social: Novas formas de se trabalhar BPM Global Trends Brasília, Novembro 2013 Sandy Kemsley www.column2.com @skemsley Agenda A Organização Social Tecnologias para BPM Social: BPM Social Gerenciamento

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais

Liderança Empresarial A crise como alavanca de oportunidades. AEP Março.2012

Liderança Empresarial A crise como alavanca de oportunidades. AEP Março.2012 Liderança Empresarial A crise como alavanca de oportunidades AEP Março.2012 1/ Perfil Em busca da Excelência Missão Inovar com qualidade 1/ Perfil Trabalhamos diariamente no desenvolvimento de soluções

Leia mais

CobiT 4.1 Plan and Organize Manage Projects PO10

CobiT 4.1 Plan and Organize Manage Projects PO10 CobiT 4.1 Plan and Organize Manage Projects PO10 Planejar e Organizar Gerenciar Projetos Pedro Rocha http://rochapedro.wordpress.com RESUMO Este documento trás a tradução do objetivo de controle PO10 (Gerenciamento

Leia mais

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste)

Melhoria de Conhecimentos em Garantia de Qualidade no Software. (Tipos de Teste) Melhoria de Conhecimentos em Garantia de Qualidade no Software (Tipos de Teste) Av. Conde de Valbom, nº 30 8º 1050-068 Lisboa Telf: +351 213 510 540 Fax: +351 213 510 549 Controlo do Documento Elaborado

Leia mais

SIPTEST System Intelligent Process Testing. Frameworks de Gestão de Serviços de Testes

SIPTEST System Intelligent Process Testing. Frameworks de Gestão de Serviços de Testes SIPTEST System Intelligent Process Testing. Frameworks de Gestão de Serviços de Testes SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 9 Índice 1 Introdução... 2 1.1 Objetivo do documento...

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

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

Leia mais

ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting

ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting ANA obtém certificação em quatro áreas críticas com apoio da VP Consulting Contactos: Isabel Fonseca Marketing VP Consulting Telefone: +351 22 605 37 10 Fax: +351 22 600 07 13 Email: info@vpconsulting.pt

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

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

Leia mais

Documento de apresentação Software de Gestão e Avaliação da Formação

Documento de apresentação Software de Gestão e Avaliação da Formação Documento de apresentação Software de Gestão e Avaliação da Janeiro-2010 Para a boa gestão de pessoas, as empresas devem elevar o RH à posição de poder e primazia na organização e garantir que o pessoal

Leia mais

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

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

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) Universidade Federal de Santa Catarina Departamento de Informática e Estatística INE Curso: Sistemas de Informação Disciplina: Projetos I Professor: Renato Cislaghi Aluno: Fausto Vetter Orientadora: Maria

Leia mais

SIPTEST System Intelligent Process Testing. Meta Modelo da Base de Conhecimento

SIPTEST System Intelligent Process Testing. Meta Modelo da Base de Conhecimento SIPTEST System Intelligent Process Testing. Meta Modelo da Base de Conhecimento SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 8 Índice 1 Introdução... 2 2 Meta modelo... 3 2.1 SQA -

Leia mais

Quality Assurance & Test Center. Experiência, Metodologia e Ferramentas

Quality Assurance & Test Center. Experiência, Metodologia e Ferramentas Experiência, Metodologia e Ferramentas Março de 2008 Índice 1. Enquadramento 3 2. Experiência e referências 3 2.1 Evolução e principais projectos 3 2.2 Certificações 4 3. Metodologia de testes Link 4 3.1

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO DO PARCEIRO Soluções de garantia do serviço da CA Technologies você está ajudando seus clientes a desenvolver soluções de gerenciamento da TI para garantir a qualidade do serviço e a

Leia mais

12 EXCEL MACROS E APLICAÇÕES

12 EXCEL MACROS E APLICAÇÕES INTRODUÇÃO O principal objetivo deste livro é auxiliar o leitor na sua aprendizagem sobre os recursos avançados do Excel em especial na interligação com o Visual Basic for Applications (VBA). Pretende-se

Leia mais

ILM e as Arquitecturas Empresariais por Pedro Sousa

ILM e as Arquitecturas Empresariais por Pedro Sousa ILM e as Arquitecturas Empresariais por Pedro Sousa Neste artigo clarifica-se os objectivos do ILM (Information Life Cycle Management) e mostra-se como estes estão dependentes da realização e manutenção

Leia mais

Linha Silk: a maneira leve para testar, desenvolver e gerenciar

Linha Silk: a maneira leve para testar, desenvolver e gerenciar Linha : a maneira leve para testar, desenvolver e gerenciar Leve Criado apenas com a funcionalidade que você precisa Barato Do uso gratuito ao licenciamento flexível Eficiente Software fácil de usar e

Leia mais

Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas

Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas Luciano Gomes Helvinger, Rodrigo Prestes Machado Curso de Análise e Desenvolvimento de Sistemas Faculdade

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

Sistema de Incentivos à Inovação e I&DT (Sector Automóvel) Quadro de Referência Estratégico Nacional [QREN]

Sistema de Incentivos à Inovação e I&DT (Sector Automóvel) Quadro de Referência Estratégico Nacional [QREN] Sistema de Incentivos à Inovação e I&DT (Sector Automóvel) Quadro de Referência Estratégico Nacional [QREN] Frederico Mendes & Associados Sociedade de Consultores Lda. Frederico Mendes & Associados é uma

Leia mais

Teste de Software Apresentação

Teste de Software Apresentação Teste de Software Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Agenda Teste de Software VV&T e Defeitos de Software Inspeção de Software Teste

Leia mais

COBIT FOUNDATION - APOSTILA DE RESUMO

COBIT FOUNDATION - APOSTILA DE RESUMO COBIT FOUNDATION - APOSTILA DE RESUMO GOVERNANÇA DE TI O QUE É GOVERNANÇA DE TI É um conjunto de estruturas e processos que visa garantir que a TI suporte e maximize adequadamente os objetivos e estratégias

Leia mais

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem:

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem: Descrição de Serviços Serviços de Planeamento e Empresarial Os Serviços de Planeamento e Empresarial fornecem serviços de consultoria e prototipagem para facilitar a agenda do Licenciado relativa à inovação

Leia mais

OMNIBEES SOFTWARE CHALLENGE APRESENTAÇÃO

OMNIBEES SOFTWARE CHALLENGE APRESENTAÇÃO OMNIBEES SOFTWARE CHALLENGE APRESENTAÇÃO A Visualforma S.A. e a Faculdade de Ciências e Tecnologia da Universidade do Algarve, desenvolveram em conjunto o concurso OMNIBEES SOFTWARE CHALLENGE, destinado

Leia mais

A CHAVE PARA A EFICIÊNCIA ENERGÉTICA

A CHAVE PARA A EFICIÊNCIA ENERGÉTICA A CHAVE PARA A EFICIÊNCIA ENERGÉTICA Agenda Enquadramento dos consumos Energéticos nos Edifícios e no ramo Hoteleiro Enerbiz Conceito Geral e explicação funcional Conclusões e Aspetos Gerais Índice Enquadramento

Leia mais

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

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

Leia mais

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa Atila Belloquim Gnosis IT Knowledge Solutions TI e Negócio 10 entre 10 CIOs hoje estão preocupados com: Alinhar TI ao Negócio;

Leia mais

PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 07/SI/2015

PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 07/SI/2015 PROPOSTA DE CANDIDATURA PARTE B (ANEXO TÉCNICO) SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) AVISO Nº 07/SI/2015 REGIME CONTRATUAL DE INVESTIMENTO (RCI) PROJETOS DE INTERESSE

Leia mais

Rumo à Integração de Segurança. IDC FutureScape IT Security Products and Services 2015 Predictions

Rumo à Integração de Segurança. IDC FutureScape IT Security Products and Services 2015 Predictions Rumo à Integração de IDC FutureScape IT Security Products and Services 0 Predictions ª Plataforma Processo de Decisão Evolução da ª Plataforma focalizada no risco do acesso a servidores centralizados e

Leia mais

Relatório Técnico Final Projecto nº 22838

Relatório Técnico Final Projecto nº 22838 SISTEMA DE INCENTIVOS À INVESTIGAÇÃO E DESENVOLVIMENTO TECNOLÓGICO (SI I&DT) Leadership Business Consulting Relatório Técnico Final Projecto nº 22838 1 ÍNDICE 1. O Projecto 1.1. Os objectivos e a estrutura

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Planejamento de sistemas de informação.

Planejamento de sistemas de informação. Planejamento de sistemas de informação. O planejamento de sistemas de informação e da tecnologia da informação é o processo de identificação das aplicações baseadas em computadores para apoiar a organização

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

BLUEWORKS MEDICAL EXPERT DIAGNOSIS, LDA.

BLUEWORKS MEDICAL EXPERT DIAGNOSIS, LDA. BLUEWORKS MEDICAL EXPERT DIAGNOSIS, LDA. 01. APRESENTAÇÃO DA EMPRESA 2 01. Apresentação da empresa A BlueWorks Medical Expert Diagnosis, Lda. é uma start-up de Coimbra que se dedica ao desenvolvimento

Leia mais

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

Leia mais

Auditoria interna Especialização PwC

Auditoria interna Especialização PwC www.pwc.pt/academy Especialização PwC PwC s Academy Formação de profissionais para profissionais Especialização PwC Este curso com uma forte componente prática, procura dotar os recursos afetos à função

Leia mais

As Ferramentas de SCM e o Suporte do CMM

As Ferramentas de SCM e o Suporte do CMM As Ferramentas de SCM e o Suporte do CMM Como é que as ferramentas de SCM (Software Configuration Management) podem ajudar na melhoria de processos de acordo com o modelo CMM (Capability Maturity Model)?

Leia mais

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição

ANEXO 1. Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI. Instituição de acolhimento. Supervisor nomeado pela instituição INSTITUTO SUPERIOR DE CIÊNCIAS DO TRABALHO E DA EMPRESA Departamento de Ciências e Tecnologias de Informação DCTI Formulário de Candidatura da Instituição Projecto Final de Curso de IGE/ETI ANEXO 1 Instituição

Leia mais

Recrutamento de RH. Perfil de Administração de Base de Dados e Plataforma Aplicacional. ID do Documento:

Recrutamento de RH. Perfil de Administração de Base de Dados e Plataforma Aplicacional. ID do Documento: Recrutamento de RH Perfil de Administração de Base de Dados e Plataforma Aplicacional ID do Documento: Versão: Elaborado por: Aprovado por: Data de Re99visão: 1 Administração de Base de Dados e Plataforma

Leia mais

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 0 2 4 6 8 10 33 34 35 36 37 38 39 40 resolução de problemas recolha e tratamento da informação planeamento / organizção inovação

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Código de Conduta para as Estatísticas Europeias

Código de Conduta para as Estatísticas Europeias Código de Conduta para as Estatísticas Europeias Adotado pelo Comité do Sistema Estatístico Europeu em 28 de setembro de 2011 Tradução realizada pelo INE, IP Preâmbulo Visão do Sistema Estatístico Europeu

Leia mais

Global Incentives Solutions*

Global Incentives Solutions* Incentives Solutions Global Incentives Solutions* Informação sobre incentivos ao investimento Número 6, Outubro de 2007 *connectedthinking What s hot Assinatura dos Programas Operacionais (PO) No passado

Leia mais

COMPUTAÇÃO EMNUVEM AVALIAÇÃO DO RETORNO DO INVESTIMENTO. Pedro Assis. pfa at isep.ipp.pt passis at eu.ipp.pt

COMPUTAÇÃO EMNUVEM AVALIAÇÃO DO RETORNO DO INVESTIMENTO. Pedro Assis. pfa at isep.ipp.pt passis at eu.ipp.pt COMPUTAÇÃO EMNUVEM AVALIAÇÃO DO RETORNO DO INVESTIMENTO Pedro Assis pfa at isep.ipp.pt passis at eu.ipp.pt 8 de Fevereiro de 2011, Jornadas FCCN, FEUP Agenda Enquadramento Retorno do Investimento Metodologia,

Leia mais

1º Relatório Técnico-Científico Projecto Appybaby Candidatura QREN n.º 30189

1º Relatório Técnico-Científico Projecto Appybaby Candidatura QREN n.º 30189 1º Relatório Técnico-Científico Projecto Appybaby Candidatura QREN n.º 30189 Resumo 1. Projecto e âmbito Descrição da natureza do projecto, linhas orientadoras e grandes eixos de desenvolvimento. 2. Resultados

Leia mais

ISO 9001:2000, MPS.BR F, CMMI 3: Uma estratégia de melhoria de processos na BL Informática

ISO 9001:2000, MPS.BR F, CMMI 3: Uma estratégia de melhoria de processos na BL Informática ISO 9001:2000, MPS.BR F, CMMI 3: Uma estratégia de melhoria de processos na BL Informática Gerente de Desenvolvimento Analia Irigoyen Ferreiro Ferreira analia@blnet.com Agenda BL Informática Histórico

Leia mais

Alimentamos Resultados

Alimentamos Resultados Alimentamos Resultados www..pt Somos uma equipa que defende que cada empresa é única, tem as suas características e necessidades e por isso cada projeto é elaborado especificamente para cada cliente. Feed

Leia mais

Fábrica de Software Fatores motivadores, restrições e tendências

Fábrica de Software Fatores motivadores, restrições e tendências Fábrica de Software Fatores motivadores, restrições e tendências Aguinaldo Aragon Fernandes Agenda Revisitando o conceito e escopo da fábrica de software Implicações do uso do conceito de Fábrica de Software

Leia mais

Marketing Digital. Carla Machado. Francesco Berrettini. Responsável das Formações Marketing Digital

Marketing Digital. Carla Machado. Francesco Berrettini. Responsável das Formações Marketing Digital Marketing Digital Francesco Berrettini Responsável das Formações Marketing Digital Carla Machado Coordenadora Pedagógica das Formações Marketing Digital Marketing Digital Digital Marketing - Professional

Leia mais

Lista de Exercícios - COBIT 5

Lista de Exercícios - COBIT 5 Lista de Exercícios - COBIT 5 1. O COBIT 5 possui: a) 3 volumes, 7 habilitadores, 5 princípios b) 3 volumes, 5 habilitadores, 7 princípios c) 5 volumes, 7 habilitadores, 5 princípios d) 5 volumes, 5 habilitadores,

Leia mais

Cumprindo as exigências 6.6 do PCI DSS

Cumprindo as exigências 6.6 do PCI DSS Cumprindo as exigências 6.6 do PCI DSS Em abril de 2008, o Conselho de Padrões de Segurança (SSC, na sigla em inglês) do Setor de Cartões de Pagamento (PCI, na sigla em inglês) publicou um esclarecimento

Leia mais

GESTÃO DE T.I. COBIT. José Luís Padovan jlpadovan@gmail.com

GESTÃO DE T.I. COBIT. José Luís Padovan jlpadovan@gmail.com GESTÃO DE T.I. COBIT José Luís Padovan jlpadovan@gmail.com COBIT Control Objectives for Information and Related Technology Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation. Information

Leia mais

BPM (Business Process Management)

BPM (Business Process Management) Instituto Superior de Economia e Gestão Ano lectivo 2007/2008 Cadeira de Tecnologias de Informação BPM (Business Process Management) Planeamento e Controlo de Gestão Baseados nos Processos de Negócio José

Leia mais

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;

Leia mais

INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA

INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA INTERLIMS SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES PARA LABORATÓRIOS DE ANÁLISES DE ÁGUA O InterLIMS se apresenta

Leia mais

As ações de formação ação no âmbito do presente Aviso têm, obrigatoriamente, de ser desenvolvidas com a estrutura a seguir indicada.

As ações de formação ação no âmbito do presente Aviso têm, obrigatoriamente, de ser desenvolvidas com a estrutura a seguir indicada. Anexo A Estrutura de intervenção As ações de formação ação no âmbito do presente Aviso têm, obrigatoriamente, de ser desenvolvidas com a estrutura a seguir indicada. 1. Plano de ação para o período 2016

Leia mais

Sobre a Prime Control

Sobre a Prime Control Sobre a Prime Control A Prime Control é uma empresa focada e especializada em serviços de qualidade e testes de software. Somos capacitados para garantir, através de sofisticadas técnicas, a qualidade

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Governança de TI: O que é COBIT?

Governança de TI: O que é COBIT? Governança de TI: O que é COBIT? Agenda Governança de TI Metodologia COBIT Relacionamento do COBIT com os modelos de melhores práticas Governança de TI em 2006 Estudo de Caso Referências Governança de

Leia mais

Instituto de Inovação com TIC. [Junho/ 2009]

Instituto de Inovação com TIC. [Junho/ 2009] Instituto de Inovação com TIC [Junho/ 2009] Segurança em aplicações WEB: A nova fronteira rodrigo.assad@cesar.org.br Redes de Computadores (Histórico) Segurança de Redes (Histórico) Robert Tappan

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

Premier. Quando os últimos são os Primeiros

Premier. Quando os últimos são os Primeiros Premier Quando os últimos são os Primeiros Fundada em 1997 Especializada no desenvolvimento de soluções informáticas de apoio à Gestão e consultoria em Tecnologias de Informação. C3im tem como principais

Leia mais

Qpoint Rumo à excelência empresarial

Qpoint Rumo à excelência empresarial Qpoint Rumo à excelência empresarial primavera bss A competitividade é cada vez mais decisiva para o sucesso empresarial. A aposta na qualidade e na melhoria contínua da performance dos processos organizacionais

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA 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 mais

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011 Workshop Maturidade da Governação e Gestão de TI em Portugal Inquérito Nacional 2011 Mário Lavado itsmf Portugal 11-10-2011 Agenda Apresentação dos resultados do estudo de maturidade do ITSM & ITGovervance

Leia mais

COBIT. Governança de TI. Juvenal Santana, PMP tecproit.com.br

COBIT. Governança de TI. Juvenal Santana, PMP tecproit.com.br COBIT Governança de TI Juvenal Santana, PMP tecproit.com.br Sobre mim Juvenal Santana Gerente de Projetos PMP; Cobit Certified; ITIL Certified; OOAD Certified; 9+ anos de experiência em TI; Especialista

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

POCI Aviso n.º3/si/2015 Programa Operacional Fatores de Competitividade INOVAÇÃO PRODUTIVA ENQUADRAMENTO E OBJETIVOS BENEFICIÁRIOS

POCI Aviso n.º3/si/2015 Programa Operacional Fatores de Competitividade INOVAÇÃO PRODUTIVA ENQUADRAMENTO E OBJETIVOS BENEFICIÁRIOS ENQUADRAMENTO E OBJETIVOS POCI Aviso n.º3/si/2015 Programa Operacional Fatores de Competitividade INOVAÇÃO PRODUTIVA O objetivo específico deste concurso consiste em conceder apoios financeiros a projetos

Leia mais

Banco Popular, Espanha

Banco Popular, Espanha Banco Popular, Espanha Tecnologia avançada de automação do posto de caixa para melhorar a eficiência e beneficiar a saúde e segurança dos funcionários O recirculador de notas Vertera contribuiu para impulsionar

Leia mais

Governança de TI com COBIT, ITIL e BSC

Governança de TI com COBIT, ITIL e BSC {aula #2} Parte 1 Governança de TI com melhores práticas COBIT, ITIL e BSC www.etcnologia.com.br Rildo F Santos rildo.santos@etecnologia.com.br twitter: @rildosan (11) 9123-5358 skype: rildo.f.santos (11)

Leia mais

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS METODOLOGIA DE AUDITORIA PARA AVALIAÇÃO DE CONTROLES E CUMPRIMENTO DE PROCESSOS DE TI NARDON, NASI AUDITORES E CONSULTORES CobiT

Leia mais

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo

Leia mais

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Capítulo 7 Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Liliana Ferreira, António Teixeira e João Paulo da Silva Cunha Luís Costa, Diana Santos e Nuno

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Estudo do CMM e do CMMI

Estudo do CMM e do CMMI Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães A Importância do Controle da Qualidade na Melhoria de Processos de Software Ana Liddy Cenni de Castro Magalhães Agenda Contextualização da Qualidade Dificuldades na construção de software Possíveis soluções

Leia mais

Manual de Procedimentos das Entidades Beneficiárias

Manual de Procedimentos das Entidades Beneficiárias Manual de Procedimentos das Entidades Beneficiárias ÍNDICE Introdução...2 Capítulo I Programa Formação Ação para PME...3 I.1 Objetivos...3 I.2 Metodologia de Intervenção...4 I.3 Equipas de Intervenção...11

Leia mais

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br Workshop de Teste de Software Visão Geral Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br 1 AGENDA DO CURSO Conceitos Básicos Documentação Processo Plano de Teste Caso de Teste BIBLIOGRAFIA

Leia mais

Diagnóstico de Competências para a Exportação

Diagnóstico de Competências para a Exportação Diagnóstico de Competências para a Exportação em Pequenas e Médias Empresas (PME) Guia de Utilização DIRECÇÃO DE ASSISTÊNCIA EMPRESARIAL Departamento de Promoção de Competências Empresariais Índice ENQUADRAMENTO...

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Especificação do KAPP-PPCP

Especificação do KAPP-PPCP Especificação do KAPP-PPCP 1. ESTRUTURA DO SISTEMA... 4 1.1. Concepção... 4 2. FUNCIONALIDADE E MODO DE OPERAÇÃO... 5 3. TECNOLOGIA... 7 4. INTEGRAÇÃO E MIGRAÇÃO DE OUTROS SISTEMAS... 8 5. TELAS E RELATÓRIOS

Leia mais

Portugal Brasil Moçambique Polónia

Portugal Brasil Moçambique Polónia www.promover.pt www.greatteam.pt Portugal Brasil Moçambique Polónia QUEM SOMOS - Prestamos serviços técnicos de consultoria de gestão e formação nos diversos setores da economia. - Presentes em Lisboa,

Leia mais

Ilustratown - Informação Tecnológica, Lda.

Ilustratown - Informação Tecnológica, Lda. Ilustratown - Informação Tecnológica, Lda. 01. APRESENTAÇÃO DA EMPRESA 2 01. Apresentação da empresa A é uma software house criada em 2006. A Ilustratown tem por objetivo o desenvolvimento e implementação

Leia mais

Gestão da Tecnologia da Informação

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

Leia mais