MPT Melhoria de Processo de Teste Brasileiro. MPT.BR - Melhoria de Processo de Teste Guia de Implementação Parte 1: Nível 1 (Versão 2.

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

Download "MPT Melhoria de Processo de Teste Brasileiro. MPT.BR - Melhoria de Processo de Teste Guia de Implementação Parte 1: Nível 1 (Versão 2."

Transcrição

1 MPT.BR - Melhoria de Processo de Teste Guia de Implementação Parte 1: Nível 1 (Versão 2.2) Sumário 1 Prefácio Introdução... 5 Os modelos de maturidade de teste de software... 8 Por que não usarmos o MPS.BR ou o CMMI? Objetivo Como começar a implementação do MPT.BR pelo nível Gerência de Projetos de Teste de Software (GPT) Fundamentações teóricas Práticas específicas GPT1 Definir o escopo do trabalho para o projeto GPT2 Estabelecer estimativas para o tamanho das tarefas e dos produtos de trabalho do projeto de teste utilizando métodos apropriados GPT3 - Definir as fases do ciclo de vida do projeto de teste GPT4 Estimar o esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas GPT5 Estabelecer e manter o orçamento e o cronograma do projeto de teste, incluindo marcos e/ou pontos de controle GPT6 Determinar e documentar os riscos do projeto de teste, assim como seu impacto, probabilidade de ocorrência e prioridade de tratamento GPT7 Planejar os recursos humanos para o projeto considerando o perfil e a proficiência necessários para executá-lo Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 1

2 5.2.8 GPT8 Planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho necessário para executar o projeto de teste GPT9 Identificar e planejar os artefatos e dados relevantes do projeto de teste quanto à forma de coleta, armazenamento e distribuição GPT10 Estabelecer os planos para a execução do projeto de teste e reunir no Plano de Teste GPT11 Avaliar a viabilidade de atingir as metas do projeto de teste, considerando as restrições e os recursos disponíveis, fazendo, se necessário, ajustes pertinentes GPT12 Fazer a revisão do Plano de Teste com todos os interessados e obter o compromisso com o mesmo GPT13 Monitorar o progresso do projeto com relação ao estabelecido no Plano de Teste e documentar os resultados GPT14 Gerenciar o envolvimento das partes interessadas (stakeholders) no projeto de teste GPT15 Executar revisões em marcos do projeto e conforme estabelecido no planejamento GPT16 Estabelecer os registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, assim como tratar os mesmos com as partes interessadas GPT17 Estabelecer ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas, assim como implementar e acompanhar até a sua conclusão Práticas genéricas do nível OG 1 Executar o processo PG Atingir os resultados definidos OG 2 Gerenciar o processo PG 2.1 Estabelecer e manter uma política organizacional para o processo Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 2

3 6.2.2 PG 2.2 Planejar a execução do processo PG Monitorar e controlar a execução do processo para atender aos planos PG 2.4 Identificar e disponibilizar os recursos necessários para a execução do processo PG 2.5 Garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência PG 2.6 Garantir a comunicação entre as partes interessadas no processo de forma a manter o seu envolvimento no projeto PG Monitorar e controlar o processo Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 3

4 1 Prefácio O MPT.BR é um modelo para Melhoria de Processo de Teste Brasileiro, que está sendo desenvolvido com o princípio básico de ser compatível com o modelo MPS.BR criado pela Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais. As seguintes organizações: ALATS Associação Latino Americana de Teste de Software RIOSOFT Sociedade Núcleo de Apoio à Produção e a Exportação de Software criaram este modelo com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram o MPS e o CMMI na sua área de desenvolvimento, possam, com um pequeno esforço adicional, também aumentar e comprovar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Necessário se faz uma melhoria de maturidade da área de teste de software. Por outro lado, entende-se também que os processos de desenvolvimento e de teste devem estar fortemente integrados e que esta integração também reflita nos projetos que venham a ser levados adiante usando esses processos. No entanto, sempre é bom lembrar, que o projeto de desenvolvimento, a despeito do processo utilizado ou do nível de maturidade alcançado, crie artefatos com elevados graus de testabilidade e que estes estejam disponíveis após alterações para testes de regressão. À medida que o modelo for evoluindo ou venha a sofrer manutenções serão liberados documentos de suporte para nortear os implementadores e avaliadores, assim como outros documentos relacionados ao modelo. Para obtê-los, bastará acessar o site da ALATS ou da Riosoft na área reservada ao MPT. O Guia de implementação do MPT.BR está subdividido em níveis de maturidade, a exemplo do CMMI e do MPS.BR. O nível 1 (um) contempla apenas a área de processo de Gerência de Projetos. O objetivo é atender áreas de teste de todos os tamanhos, mesmo aquelas com número reduzido de profissionais. Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 4

5 MPT MPS CMMI 1) Nível 0 Sem correspondência Nivel 0 2) Nível 1; Sem correspondência Sem correspondência 3) Nível 2; Nivel G Sem correspondência 4) Nível 3; Nivel F Level 2 5) Nível 4; Nível E Sem correspondência 6) Nível 5; Nível D Sem correspondência No caso do MPT temos 5 (cinco) níveis de maturidade. No primeiro nível (nível 1) a organização precisa implantar apenas a área de processo de Gerência de Projetos de Teste (GPT).Entende-se que empresas que tenham uma equipe de teste de software a princípio estarão no nível 0, embora possam ter práticas que caracterizem outros níveis de maturidade. Desta forma é importante observar que a definição de um nível de maturidade vai depender de uma avaliação das práticas usadas pela organização nos seus projetos de teste de software. Considerou-se que o nível mais alto do modelo será o nível 5 (cinco) e que o nível inicial será o nível 1 (um), sendo que empresas que ainda não implementaram o MPT estarão de uma maneira geral no nível 0 (zero). Isso não significa que executem dos testes de forma pouco eficiente, mas que não têm o seu nível de maturidade reconhecido através do presente modelo. De qualquer forma, a implementação do presente modelo não invalida a necessidade da continuação dos testes unitário e de integração continuarem a ser executados pela equipe de desenvolvimento. Além disso, inspeções e revisões devem continuar a ser feitas. Ou seja, o modelo não elimina nenhuma das outras práticas atualmente em vigor, mas apenas acrescenta outra atividades que irão contribuir para a melhoria do produto final. 2 Introdução Até a década de 90, quando começou-se a usar setores de homologação de software, quase todas as empresas ou organizações que desenvolviam software tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento. Mesmo as empresas que usavam setores de homologação, essa atividade era executada via de regra pelos próprios usuários, que não eram testadores qualificados. Quando, no ciclo de vida do software, era dada como encerrada a etapa de construção, ele passava para a etapa de teste. Os testes eram executados pelos desenvolvedores e em algumas situações pelos Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 5

6 usuários. Os primeiros faziam o que atualmente chamamos de teste unitário e teste de integração (desenvolvedores) e os segundos (usuários) executavam o teste de aceitação. Os desenvolvedores testavam se a aplicação estava funcionando e os usuários se ela atendia aos seus requisitos. Esse modelo funcionava adequadamente, mesmo com ressalvas, desde que os primeiros computadores foram instalados. O advento da Internet e das aplicações para ambiente web, tornaram os softwares complicados e difíceis de testar. Uma aplicação pode envolver centenas ou até milhares de componentes, além de ter que funcionar em diversos ambientes, muitos deles completamente heterogêneos. Os desenvolvedores e os usuários não conseguiam mais garantir que uma aplicação tinha sido suficientemente testada para ser liberada para a produção. Alguns defeitos só apareciam quando as aplicações estavam em produção, justamente quando a sua correção é mais cara. Os custos de manutenção aumentaram e a qualidade caiu a níveis inferiores ao das décadas anteriores. O escopo dos problemas causados pelos defeitos deixou de ser restrito ao ambiente institucional e envolveu o próprio negócio da empresa. Apesar desta realidade ainda permanecer na maioria das empresas até os dias atuais, foi em 1979 que Glenford Myers publicou aquele que atualmente ainda é considerado um dos melhores livros de teste de software existentes no mercado, sob o título de The Art of Software Testing (publicado por John Wiley and Sons Inc. em edição revisada em 2004). Este livro continua sendo a bíblia de muitos dos testadores do século 21. Myers basicamente lembrava que testar era procurar defeitos e não provar que o software estava funcionando. Com isso estava quebrando um paradigma que ainda existia e que sobreviveria durante muitos anos. Um artigo publicado na revista Communications of the ACM sob o título The Growth of Software Testing (Gelperin, D. and B. Hetzel. The Growth of Software Testing. - Communications of the ACM 31 (June 1988): ) descrevia um processo de evolução dos testes e lançava um documento denominado Plano de Testes. Esse documento, base de todas as metodologias de teste que usamos hoje em dia, segundo o artigo citado, deveria ser escrito a partir dos requisitos do sistema. Apenas a introdução dessa mudança já ajudava a reduzir a quantidade de defeitos dos softwares, dando aos testadores os objetivos a alcançar durante a atividade de teste. Isso nos leva a uma conclusão, que reporta à existência do documento Plano de Testes há mais de 20 (vinte) anos, ainda que Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 6

7 a popularização do seu uso seja mais recente. Ou seja, foi o primeiro alerta para que os testes convencionais fossem mudados. Embora desde a década de 70, como vimos nos parágrafos anteriores, já existissem trabalhos mostrando que o teste precisava ser re-estruturado, essa mudança só começou a ocorrer de fato no final da década de 90. Decidiu-se então tratar o teste de software não mais como uma atividade do processo de desenvolvimento, mas sim como um processo independente. Desta forma o teste passaria a ser executado por uma equipe de especialistas com o objetivo de diminuir o número de defeitos remanescentes que estavam sendo passados para a produção. Na verdade foi acrescida uma etapa de teste, além dos que já vinham sido feitos pelos desenvolvedores e usuários (teste unitário, teste de integração e teste de aceitação). Incluiu-se o teste de sistema executado por técnicos especializados em teste de software. Essa solução vem sendo gradativamente adotada pelas empresas, com os resultados esperados, qual seja, softwares com índices de qualidade melhores. No entanto, essa mudança organizacional, e ainda não completamente absorvida, trouxe também novos problemas a serem tratados. Não adianta apenas testar, mas sim testar bem. Os custos cairão, mas inicialmente os investimentos são maiores. Se a área de teste não estiver bem organizada, os problemas aparecem num estágio onde os custos são maiores. Cogitou-se então em modelos que permitissem à área de teste de software crescer em níveis de maturidade, e assim melhorar cada vez mais os resultados esperados. De qualquer forma, sempre é bom lembrar que todas essas mudanças não eliminam a responsabilidade da equipe de desenvolvimento de executar os testes unitários e de integração, assim como da continuidade do trabalho de inspeção e revisão dos artefatos. Além disso, uma equipe de teste nos modelos propostos não elimina a atuação de uma equipe de controle de qualidade. Outro problema que os pesquisadores descobriram foi que quanto mais tarde encontrarmos um defeito muito mais caro será corrigi-lo. Defeitos encontrados na fase de produção são muito mais caros do que defeitos encontrados na fase de definição dos requisitos. Para resolver esse problema de custos, considerou-se que o teste de software deveria ser um projeto que começasse junto com o projeto de desenvolvimento. Desta forma os defeitos poderiam ser encontrados no momento em que eram mais baratos de ser corrigidos. Ou seja, havia a necessidade de uma área de teste específica, com profissionais capacitados, e que, além disso, o teste fosse um projeto. Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 7

8 Ao tratarmos o teste como um projeto integrado ao projeto de desenvolvimento, caracterizamos a necessidade da existência de processos específicos para a condução desses projetos. A Regra 10 de Myers mostra que quanto mais tarde os defeitos forem encontrados muito mais caro será corrigi-los. Essa regra mostra numa situação hipotética e de forma ilustrativa como o custo do defeito poderá crescer com o tempo. Isso não quer dizer que todos os defeitos se comportem dentro da mesma escala, mas que defeitos tendem a ser mais caros para serem corrigidos quando descobertos na etapa de produção. Os modelos de maturidade de teste de software Ao mesmo tempo em que se começava a implantar as áreas de teste nas empresas, os especialistas já se preocupavam com os modelos que permitissem a sua melhoria. Datam da década de 90 os primeiros modelos de maturidade de teste. O que é interessante, pois talvez 80% ou mais das empresas que desenvolviam software, ainda não trabalhavam com equipes especialistas em teste de software. Atualmente existe uma verdadeira sopa de Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 8

9 letrinhas envolvendo esses modelos de maturidade de teste de software conforme listado adiante: Testability Support Model (TSM) (criado por David Gelperin in 1996) Testing Maturity Model (TMM) (criado pelo Illinois Institute of Technology (IIT) em 1996) Test Process Improvement (TPI) (criado por Koomen and Pol in 1997) Test Organization Maturity (TOMtm) (criado pela empresa Systeme Evolutif) Testing Assessement Program (TAP) (criado pelas empresas Software Futures ltd and IE Testing Consultancy LTD) Testing Improvement Model (TIM) (criado por Ericson, Subotic and Ursing) Testing Maturity Model Integration (TMMi) (criado e mantido pela TMMi Foundation) Maturity Model for Automated Software Testing (criado por Mitchel H. Krause in 1994)MMT Modelo de Melhoria de Teste (criado por Emerson Rios e Trayahu Moreira no livro Teste de Software, editora Altabooks) Nenhum desses modelos possui alguma organização que os represente no Brasil, isso significa que implementá-los será bastante difícil. Além disso, mesmo que o interessado consiga implementar o modelo por conta própria, sem nenhum apoio técnico especializado, será praticamente impossível, ou no mínimo muito caro, conseguir ser avaliado e ter o seu nível de maturidade homologado e reconhecido no mercado. Por que não usarmos o MPS.BR ou o CMMI? A busca por modelos alternativos surgiu porque os técnicos entenderam que modelos pesados como o CMMI não serviam para a área de teste, em razão de o seu tamanho ser muito menor do que o da área de desenvolvimento. Esse pressuposto também é verdade quando pensamos em usar o modelo CMMI em empresas médias ou de pequeno porte. O MPS.BR surgiu no Brasil para atender as empresas desenvolvedoras de software com uma estrutura menor. Desta forma, ao criarmos um modelo de maturidade de teste baseado no MPS.Br, embora usando alguns conceitos do CMMI, estaríamos atendendo também as empresas menores e, logicamente, às áreas de teste que tendem a ser menores do que às áreas de desenvolvimento. Melhoria de Processo de Teste Brasileiro MPT.BR - v.2.2 9

10 A idéia do MPT.BR foi a criação de um modelo para avaliação da maturidade das áreas de teste de software compatível, mas não necessariamente igual, com o modelo MPS.BR, embora totalmente voltado para a área de teste de software. Desta forma, a empresa que implementou o modelo MPS poderá com pouco esforço implementar o modelo MPT. No entanto, a implantação do MPT não depende do uso do MPS pela empresa. Áreas de processo do modelo MPT Nivel 1 Nivel 2 Nivel 3 Gerência de Projetos de Teste - GPT Gerência de Requisitos de Teste - GRT Aquisição AQU (opcional) Gerência de Configuração GCO Garantia da Qualidade - GQA Medição - MED Nivel 4 Gerência de Recursos Humanos - GRH Gerência de Reutilização - GRU (opcional) Gerência de Riscos - GRI Nível 5 Validação - VAL (opcional) Verificação - VER 3 Objetivo A empresa deverá implementar o nível 1 do MPT.BR instalando as seguintes áreas de processo: Melhoria de Processo de Teste Brasileiro MPT.BR - v

11 Gerência de Projetos de Teste de Software (GPT) É sempre importante lembrar que esta área de processo atenderá aos projetos de teste de software, embora possa ser compartilhada por outros processos, mas para isso seriam necessárias outras adequações. No caso deste documento, as áreas de processos foram direcionadas ao processo de teste de software. O que queremos dizer é que a área de processo de gerência de projetos de desenvolvimento poderia, com algumas adaptações, cobrir também os projetos de teste de software. Ou seja, se a empresa já tiver o MPS implantado em qualquer nível, certamente terá uma área de processo de gerência de projetos, o que facilitará bastante a implantação do MPT. Cada área de processo tem a seguinte organização: Área de processo o Práticas específicas o Objetivos genéricos Práticas genéricas Para garantir à aderência a área de processo devem ser implementadas as práticas específicas e as práticas genéricas, que se aplicam a todas as áreas de processo, correspondentes ao nível de maturidade visado. A avaliação de que a unidade de teste alcançou um determinado nível será feita através da comprovação objetiva dos resultados alcançados e do exame das evidências (diretas, indiretas e afirmações) de que a empresa implantou cada uma das práticas específicas e genéricas para aquela área de processo e grau de maturidade visado. 4 Como começar a implementação do MPT.BR pelo nível 1 O nível 1 é o primeiro nível de maturidade do MPT. Exclusivamente no MPT existe um nível 1 que contempla apenas Gerência de Projeto de Teste. Ao final da implantação deste nível a organização deve ser capaz de gerenciar seus projetos de teste de software, de acordo com os requisitos exigidos neste nível de maturidade. Evidentemente, a gerência de projetos de teste deverá evoluir à medida que a organização alcance níveis mais elevados de maturidade. Melhoria de Processo de Teste Brasileiro MPT.BR - v

12 Algumas empresas poderão sentir-se seguras para iniciar a instalação do MPT pelo nível 2 (dois), equivalente ao nível G do MPS.BR, e, neste caso, implantar as duas áreas de processo (GPT e GRT). Para esta implementação é muito importante que a empresa utilize projetos de teste de software paralelos aos projetos de desenvolvimento de software. Ou seja, ao iniciar um projeto de desenvolvimento de software, a organização deverá ao mesmo tempo iniciar um projeto de teste de software, de forma a que os dois projetos possam caminhar de forma paralela e integrada. Cada projeto deverá ter um gerente ou líder de projeto formalmente constituído. O nível 1 exige a seguinte área de processo: Gerência de Projetos de Teste de Software (GPT) Se tratarmos o projeto de teste como um projeto paralelo e integrado ao projeto de desenvolvimento, não é difícil entender que ambos poderão se sustentar num processo de gerência de projetos, que poderia ser único para os dois ou poderia ser separado. De qualquer forma o enfoque principal neste documento serão os projetos de teste de software. Os mesmos requisitos que servem para desenvolver o software também servem para criar os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem requisitos de teste a partir dos requisitos do usuário. Não nos resta outra opção a não ser a de aceitar que a área de teste precisa de uma gerência de requisitos, mas isso será tema apenas para o nível 2. Para que a organização seja avaliada no nível 1 precisa comprovar que todas as práticas estejam implementadas. A organização poderá ter as práticas implementadas sem ter um processo de gerência de projetos. Isso é difícil, mas não impossível. A implantação de uma área de processo não é obrigatória em nenhum nível, embora seja fortemente sugerido que seja assim. Trata-se apenas de uma forma de facilitar o uso das práticas exigidas. A organização pode comprovar a efetiva utilização das práticas de uma área de processo, sem que esta tenha sido implementada. Da mesma forma como já é aceito no MPS.BR. Melhoria de Processo de Teste Brasileiro MPT.BR - v

13 5 Gerência de Projetos de Teste de Software (GPT) 5.1 Fundamentações teóricas Segundo o PMI (Project Management Institute), órgão mundialmente reconhecido como referência quando se fala em gerência de projetos, e responsável pela publicação e atualização do PMBOK (Project Management Body of Knowledge), a mais conhecida referência em gerência de projetos, temos a seguinte definição: Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Se analisarmos com cuidado a definição do PMI podemos ver que a mesma se aplica também aos projetos de teste de software. Os projetos de teste de software são temporários, ou seja, terminam junto com a liberação do software para a produção.isso não significa que nas futuras manutenções do mesmo software novos projetos de teste sejam abertos. Para facilitar o entendimento precisamos considerar que o produto da área de teste é o Serviço de Teste ou o Software Testado. Veja que a definição do PMBOK fala em produto, serviço ou resultado exclusivo. Entendemos também que não seria errado afirmar que o produto seria o Software Testado. Deve também ser lembrado que os softwares entram em produção e sofrem manutenção e que voltam a ser testados. Neste caso teremos outros projetos de manutenção do software e de teste do software, que, naturalmente, poderá ser um teste de regressão, desde que os artefatos de teste tenham sido preservados. Um cuidado que vamos precisar ter é que algumas vezes o mesmo artefato poderá atender a uma evidência do projeto de desenvolvimento do software como também ao projeto de teste do software. Isso, no entanto, não inviabiliza a sua utilização como evidência. Algumas atividades executadas (não confundir com o MPS) nesta área de processo envolvem o seguinte: O desenvolvimento do Plano de Teste; A interação com todos os envolvidos no projeto de teste, inclusive os envolvidos com o projeto de desenvolvimento; O comprometimento dos interessados (stakeholders) no Plano de Teste, ou seja, a equipe de teste e demais profissionais, tais como desenvolvedores e usuários/clientes; O monitoramento e o controle do Plano de Teste durante toda a evolução do projeto de teste e até a sua conclusão. Melhoria de Processo de Teste Brasileiro MPT.BR - v

14 A elaboração do Plano de Teste deverá ter início após o recebimento dos requisitos do negócio. Isso deve ser feito em comum acordo com a equipe do projeto de desenvolvimento, pois poderão existir requisitos específicos do projeto de teste, embora, na maior parte das situações, os requisitos de teste sejam os mesmos dos requisitos de desenvolvimento. Lembre-se que os planos de teste não dizem respeito apenas a grandes projetos. A experiência tem demonstrado que projetos pequenos, com poucas horas envolvidas, produzem resultados melhores se forem bem planejados. 5.2 Práticas específicas GPT1 Definir o escopo do trabalho para o projeto Normalmente o escopo geral do projeto de teste de software é testar o software que está sendo desenvolvido. Uma das melhoras formas de estabelecermos o escopo do projeto de teste é definir uma WBS (work breakdown structure) ou EAP (estrutura analítica do projeto). A EAP não é um documento estático, pois evolui e se complementa à medida que o plano de projeto vai sendo elaborado na etapa inicial do projeto, embora possa sofrer mudanças no andamento do projeto. Basicamente a EAP é uma forma de separar o trabalho do projeto em unidades lógicas gerenciáveis ou pacotes de trabalho. A EAP deverá também ser a base para a elaboração das estimativas. Ao estimarmos o tamanho e esforço de cada pacote de trabalho teremos um resultado mais acurado para o projeto como um todo. De qualquer forma convém lembrar que devemos ter nesta prática o escopo do projeto descrito em linhas gerais e também os requisitos do projeto de teste extraídos do projeto de desenvolvimento. Um visão resumida da EAP também deveria ser criada. Descrição em linhas gerais do escopo do projeto Descrição das atividades envolvidas no desenvolvimento do projeto Descrição dos pacotes de trabalho Descrição genérica do sistema a ser testado EAP Preliminar Lista de requisitos Outro documento que permita definir o escopo do projeto Melhoria de Processo de Teste Brasileiro MPT.BR - v

15 Desta forma poderíamos dizer que o escopo do projeto define todo o trabalho necessário para entregar um produto e/ou serviço que satisfaça as necessidades, características e funções especificadas para o projeto. No entanto devemos tomar um pouco de cuidado quando se trata de projetos de teste de software cujo resultado final será o serviço de teste de software ou o software testado. Muitas vezes o escopo do serviço de teste é parte do software que está sendo desenvolvido. Com isso queremos afirmar que o escopo do projeto de desenvolvimento pode não coincidir com o escopo do projeto de teste. Pode-se desenvolver um software e, por exemplo, testar parte dele. Algumas empresas chegam inclusive a ter vários projetos de teste de software para testar um único software. Por exemplo, um grupo de requisitos faria parte de um projeto. Neste caso usa-se um Plano Máster de Teste que seria subdividido em Planos de Teste mais específicos. No entanto, é bom lembrar, que poderão existir outras tarefas que não fazem parte da EAP do projeto de desenvolvimento e que estarão no projeto de teste. De qualquer forma a EAP deverá permitir que estimativas de esforço e tempo sejam feitas baseada em critérios estáveis GPT2 Estabelecer estimativas para o tamanho das tarefas e dos produtos de trabalho do projeto de teste utilizando métodos apropriados O objetivo principal desta prática deve ser estabelecer e manter estimativas para os artefatos e para as tarefas do projeto de teste, dimensionando o tamanho de cada um deles. Alguns dos produtos para os quais deverão ser feitas estimativas são os seguintes: Produtos de trabalho que serão entregues, tais como Plano de Teste, Casos de Teste, e outros que não serão entregues Algumas tarefas: Gerar massa de teste, preparar ambiente de teste, Executar caos de teste (grupar ou detalhar), etc. Algumas medidas de tamanho incluem as seguintes: Métrica de funcionalidades Complexidade de casos de uso Complexidade de requisitos Tamanho em pontos de função do software que será testado Melhoria de Processo de Teste Brasileiro MPT.BR - v

16 Tamanho do projeto de teste usando uma métrica confiável, como por exemplo, análise de pontos de teste, pontos de caso de teste, complexidade de requisitos, etc. Número de requisitos com a respectiva complexidade 1. O ideal seria que artefatos fossem produzidos de tal forma que o gerente do projeto possa entender e demonstrar que o projeto teve seu tamanho estimado com base em critérios racionais e compreensíveis. Tamanho e complexidade das tarefas e dos produtos de trabalho Modelos usados para elaborar as estimativas Indicadores e históricos usados nas estimativas. Uma das formas mais usadas de medir o tamanho do projeto de teste de software é a complexidade dos requisitos ou dos casos de uso. No entanto, convém lembrar que há necessidade de manutenção de uma base histórica 2 para que os números sejam constantemente revistos e atualizados. No caso de projetos de teste de software existem algumas medidas de tamanho usadas pelas organizações como análise de pontos de teste ou pontos de casos de teste. Muitas empresas usam técnicas de medição baseadas em complexidade de requisitos. De qualquer forma deve ser guardado um histórico que sirva para calibrar as medições à medida que novos projetos sejam iniciados. Uma das opções seria usar a EAP Estrutura Analítica do Projeto como base para as estimativas, embora nada impeça de serem utilizados outros documentos, desde que a finalidade seja atingida. O tamanho é a dimensão das funcionalidades sob o ponto de vista do usuário. 1 Complexidade de requisito é uma métrica adotada por algumas empresas para definir o esforço necessário para que aquele requisito seja desenvolvido. Essa medida é expressa em valores como alta, média e baixa. Outras métricas podem vir a serem usadas. Um histórico do tempo gasto para desenvolver esses requisitos servirá depois de base de informação para estimativas futuras. O mesmo modelo pode ser aumentado para suportar o esforço necessário para testar os requisitos. 2 Ver acima Melhoria de Processo de Teste Brasileiro MPT.BR - v

17 Pode ser usada, também, uma associação entre o número de casos de teste e a complexidade dos requisitos. Isso poderá ser obtido usando dados históricos. O tempo gasto na execução dos casos de teste deve fazer parte da base histórica. Uma maneira comum de se medir seria classificar os casos de uso por nível de complexidade e estimar o tempo necessário para testar cada caso de uso com base em indicadores históricos GPT3 - Definir as fases do ciclo de vida do projeto de teste Pode existir mais de um ciclo de vida 3 do projeto que já seja usado numa organização. Neste caso deve haver uma atividade que envolve a escolha do ciclo de vida para aquele projeto específico. A definição do ciclo de vida, formada por um conjunto de fases, permitirá estabelecer alguns pontos de controle do projeto, onde alguns produtos poderão ser entregues ou produzidos. Ou seja, em cada fase um conjunto de artefatos pode ser produzido, os quais poderão também fazer parte do plano de comunicações do projeto. Esses pontos de controle podem ser usados para revisões do planejamento e para acertos importantes na condução do projeto. Deve ser tomado muito cuidado com a ligação entre as estimativas e o ciclo de vida do projeto de teste, ou seja, GPT2 e GPT3. Ciclo de vida do projeto de teste de software com fases e, se possível, subfases GPT4 Estimar o esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas O tamanho é muitas vezes a entrada básica para a estimativa do esforço, prazo e, conseqüentemente, do custo. As estimativas devem ser elaboradas usando um modelo racional formal, de fácil entendimento e uso pelos envolvidos no projeto. Este racional é que vai determinar o grau de credibilidade do modelo usado. As estimativas de esforço e custo são, normalmente, baseadas nos resultados de análises utilizando modelos e/ou dados históricos aplicados ao tamanho, atividades e outros parâmetros de planejamento. 3 Por ciclo de vida entendemos o seguinte: Planejar, Especificar, Executar, Terminar. Outros ciclos de vida poderão vir a ser usados de acordo com o ambiente e necessidade da área de teste. Melhoria de Processo de Teste Brasileiro MPT.BR - v

18 No caso do projeto não ter nenhuma indicação histórica que possa servir de base para a estimativa, os riscos de erros serão maiores. De qualquer forma, existe uma tendência, no decorrer do tempo e do desenvolvimento de novos projetos, para que as estimativas sejam cada vez mais acuradas. Inicialmente pode-se usar técnicas de estimativas como, por exemplo, o Delphi 4, usando para isso um grupo de especialistas. A EAP do projeto deve ser usada como base para as estimativas. Uma das técnicas usadas seria estimar o esforço a partir da complexidade do requisito. Outra técnica seria medir o tamanho do projeto de teste usando métodos tais como análise de pontos de teste, e garantir a calibragem do modelo através de dados históricos. Racional dos cálculos de estimativa Estimativa dos esforços do projeto de teste Estimativa dos custos do projeto de teste GPT5 Estabelecer e manter o orçamento e o cronograma do projeto de teste, incluindo marcos e/ou pontos de controle O orçamento e o cronograma do projeto de teste devem ser estabelecidos com base nas estimativas de esforço e custo. Cronograma do projeto de teste Dependências do cronograma do projeto de teste Orçamento do projeto de teste 4 O método Delphi é um método de tomada de decisão em grupo que se caracteriza pelo fato de cada membro do grupo isoladamente, sem contato com os outros, apresentar as suas propostas ou estimativas Um moderador avalia o resultado final e chega ao valores que precisa para o seu objetivo. No nosso caso seriam estimativas para projetos de teste de software numa organização que ainda não tem uma base histórica de informações de outros projetos. Os profissionais envolvidos devem ser especialistas de reconhecido conhecimento técnico sobre o assunto. Melhoria de Processo de Teste Brasileiro MPT.BR - v

19 Através do cronograma deverão ser definidos os pontos de controle do projeto. Outra preocupação muito importante deverá ser a inter-relação entre os cronogramas do projeto de desenvolvimento e o cronograma do projeto de teste GPT6 Determinar e documentar os riscos do projeto de teste, assim como seu impacto, probabilidade de ocorrência e prioridade de tratamento Os riscos do projeto de teste devem ser identificados e analisados de tal forma que não interfiram no planejamento e na continuidade do projeto. Riscos identificados Impacto e probabilidade de ocorrência dos riscos Prioridade de tratamento dos riscos Planos de mitigação e de contingência. O que se propõe neste nível é que a organização tenha uma lista de riscos do projeto de teste de software. É importante lembrar que existem os riscos do projeto de desenvolvimento que são diferentes dos riscos do projeto de teste. A lista de riscos deve identificar os riscos, indicar a probabilidade de ocorrência, o impacto, o plano de mitigação e o plano de contingência. Essa lista deverá ser monitorada no andamento do projeto. Normalmente, as organizações já possuem uma lista de verificação com os riscos mais usuais nos seus projetos. Os projetos de teste de software possuem riscos próprios, normalmente diferentes dos riscos do projeto de desenvolvimento. Os riscos devem ser monitorados através de mecanismos formais estabelecidos no plano do projeto (plano de teste) GPT7 Planejar os recursos humanos para o projeto considerando o perfil e a proficiência necessários para executá-lo O conhecimento necessário para a evolução do projeto requer treinamento do pessoal envolvido no projeto como também a contratação de pessoal com o perfil necessário. Por contratação entende-se também a utilização de recursos internos da organização que estavam alocados em outros projetos ou em outras atividades. Melhoria de Processo de Teste Brasileiro MPT.BR - v

20 Os requisitos para a alocação de recursos humanos dizem respeito àqueles necessários à condução bem sucedida do projeto. Por exemplo, se o projeto envolver a execução de testes de desempenho ( performance ), deve-se projetar treinamento nessa ferramenta ou a utilização de técnicos que a conheçam. A não disponibilidade de técnicos no ambiente da empresa poderá implicar em contratações ou terceirização de alguma atividade. Importante: No cumprimento desta prática considerar os perfis necessários e o pessoal técnico envolvido considerando a sua disponibilidade. Planilha com o perfil das necessidades de recursos humanos do projeto Lista dos recursos humanos do projeto indicando as necessidades de contratação Qualificações do pessoal e as necessidades de treinamento. O líder do projeto deverá informar se o treinamento será feito internamente ou se deverá ser contratado externamente. Isso deve ser planejado de forma a não interferir na evolução do projeto. Neste caso os recursos devem ser identificados através do seu perfil técnico, e esclarecidos se eles estão disponíveis, já estão capacitados ou se precisarão ser buscados fora do ambiente do projeto GPT8 Planejar as tarefas, os recursos (não humanos) e o ambiente de trabalho necessário para executar o projeto de teste A EAP do projeto de teste de software poderá servir de base para definir os recursos necessários para a execução de cada uma das tarefas, assim como o ambiente de trabalho onde essas tarefas serão executadas. Entende-se por recursos, tudo aquilo que envolve o ambiente de teste, tais como, força de trabalho (que serão tratados em outra prática específica), equipamentos, ferramentas de automação, metodologias, etc. Isso deve ser planejado tomando-se como base a EAP do projeto de teste, que será, neste momento, detalhada. Outros tipos de documentos poderão ser usados desde que a finalidade seja atingida. Este resultado é importante porque recursos especiais precisam de orçamento e planejamento para sua aquisição, o que pode se tornar crítico em alguns projetos. Melhoria de Processo de Teste Brasileiro MPT.BR - v

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo

Leia mais

Guia de Referência do Modelo MPT.Br

Guia de Referência do Modelo MPT.Br Guia de Referência do Modelo MPT.Br Copyright c 2011 - SOFTEXRECIFE Direitos desta edição reservados pela SOFTEXRECIFE A distribuição ilimitada desse documento está sujeita a copyright Sumário Parte I:

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

Aula Nº 9 Gerenciamento de Recursos Humanos em projetos

Aula Nº 9 Gerenciamento de Recursos Humanos em projetos Aula Nº 9 Gerenciamento de Recursos Humanos em projetos Objetivos da Aula: Os objetivos desta aula visam tratar da identificação bem como do estabelecimento de uma estrutura organizacional apropriada ao

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

PROCESSO DE TESTE DE SOFTWARE. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br

PROCESSO DE TESTE DE SOFTWARE. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br PROCESSO DE TESTE DE SOFTWARE Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br PROJETO DE TESTE DE SOFTWARE Deixa eu te dizer uma coisa. Teste de Software é um projeto. Certo? CERTO? Você

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

Os custos para implementação do modelo no nível 1 são detalhados na tabela abaixo: Estimativa de Custo (R$) Royalties MPT (R$) (15%) Total

Os custos para implementação do modelo no nível 1 são detalhados na tabela abaixo: Estimativa de Custo (R$) Royalties MPT (R$) (15%) Total Por que implantar o MPT.Br por Emerson Rios O MPT.Br Melhoria de Processo de Teste de Software Brasil foi desenvolvido num projeto conjunto entre a Softex Recife e a Riosoft, ambas agentes Softex (Associação

Leia mais

Análise de Riscos em Teste de Software

Análise de Riscos em Teste de Software Análise de Riscos em Teste de Software Emerson Rios Diretor do Instituto de Teste de Software - iteste Presidente da Associação Latino Americana de Teste de Software - ALATS emersonrios@alats.org.br Abstract.

Leia mais

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

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

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Fatores Críticos de Sucesso em GP

Fatores Críticos de Sucesso em GP Fatores Críticos de Sucesso em GP Paulo Ferrucio, PMP pferrucio@hotmail.com A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos

Leia mais

Gerência de Projeto de Testes Segundo o Modelo do PMI por Emerson Rios

Gerência de Projeto de Testes Segundo o Modelo do PMI por Emerson Rios Gerência de Projeto de Testes Segundo o Modelo do PMI por Emerson Rios Nos últimos anos, as empresas mais preocupadas com a qualidade dos sistemas de aplicação passaram a introduzir, no seu ambiente, um

Leia mais

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL Porto Alegre, Agosto de 2008. Sumário Apresentação Programa MPS.BR Reutilização no MPS.BR Gerência de reutilização Desenvolvimento para reutilização

Leia mais

Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR

Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR Bernardo Grassano, Eduardo Carvalho, Analia I.F. Ferreira, Mariano Montoni bernardo.grassano@projectbuilder.com.br,

Leia mais

Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos

Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos Agenda: Carlos Simões cs@synapsisbrasil.com.br carlossimoes@cos.ufrj.br

Leia mais

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

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

Estudo de caso para implantação do modelo MR-MPS-SV

Estudo de caso para implantação do modelo MR-MPS-SV Estudo de caso para implantação do modelo MR-MPS-SV Giovani Hipolito Maroneze 1, Jacques Duílio Branches 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.001 86.057-970

Leia mais

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE Karla Pires de Souza (FPM ) karlapsouza@hotmail.com Angelita Moutin Segoria Gasparotto (FPM ) angelita@usp.br A atividade de teste de

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Qualidade de Software

Qualidade de Software Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br A expressão ISO 9000 (International Organization for Standardization) designa um grupo de normas técnicas que estabelecem

Leia mais

Gerência de Projetos CMMI & PMBOK

Gerência de Projetos CMMI & PMBOK Gerência de Projetos CMMI & PMBOK Uma abordagem voltada para a qualidade de processos e produtos Prof. Paulo Ricardo B. Betencourt pbetencourt@urisan.tche.br Adaptação do Original de: José Ignácio Jaeger

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

INSTRUÇÃO DE SERVIÇO PARA ELABORAÇÃO DE PLANOS GERAIS DE PROJETOS DE SISTEMAS OU APLICATIVOS

INSTRUÇÃO DE SERVIÇO PARA ELABORAÇÃO DE PLANOS GERAIS DE PROJETOS DE SISTEMAS OU APLICATIVOS INSTRUÇÃO DE SERVIÇO PARA ELABORAÇÃO DE PLANOS GERAIS DE PROJETOS DE SISTEMAS OU APLICATIVOS IS-CGMI-02/2005 Aprovada pela Portaria nº 1494 de 22/11/2005 Histórico de Versões Data Versão Descrição Autor

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Implementação utilizando as melhores práticas em Gestão de Projetos

Implementação utilizando as melhores práticas em Gestão de Projetos Implementação utilizando as melhores práticas em Gestão de Projetos Objetivo dessa aula é mostrar a importância em utilizar uma metodologia de implantação de sistemas baseada nas melhores práticas de mercado

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

Gerenciamento de Projeto

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

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 29 3.1 GERENCIAMENTO DO ESCOPO O Gerenciamento do Escopo do Projeto engloba os processos necessários para assegurar que o projeto inclua todas

Leia mais

Políticas de Segurança da Informação. Aécio Costa

Políticas de Segurança da Informação. Aécio Costa Aécio Costa A segurança da informação é obtida a partir da implementação de um conjunto de controles adequados, incluindo políticas, processos, procedimentos, estruturas organizacionais e funções de software

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

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

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

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

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

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Carlos Alberto Rovedder, Gustavo Zanini Kantorski Curso de Sistemas de Informação Universidade Luterana do Brasil (ULBRA) Campus

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

Elaboração dos documentos

Elaboração dos documentos Estudo de Caso Área de conhecimento Gerência de Escopo Projeto Correspondência Eletrônica nos Correios S.A. A Presidência dos Correios vislumbrou a possibilidade da Empresa apresentar aos seus clientes

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

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Plano de Gerência de Configuração

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

Leia mais

I - Uma vez fechada a declaração de escopo, não é possível alterá-la. II - Uma parte interessada tem o poder de vetar a implantação do projeto.

I - Uma vez fechada a declaração de escopo, não é possível alterá-la. II - Uma parte interessada tem o poder de vetar a implantação do projeto. Bateria PMBoK Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ 1. (CESGRANRIO/Petrobras 2008) A Estrutura Analítica do Projeto

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 1: Nível G (Versão 1.1) Este guia contém orientações para a implementação do nível G do Modelo de Referência MR-MPS. Julho

Leia mais

Estabelecer os procedimentos para o gerenciamento dos sistemas e demais aplicações informatizadas do TJAC.

Estabelecer os procedimentos para o gerenciamento dos sistemas e demais aplicações informatizadas do TJAC. Código: MAP-DITEC-001 Versão: 00 Data de Emissão: 01/01/2013 Elaborado por: Gerência de Sistemas Aprovado por: Diretoria de Tecnologia da Informação 1 OBJETIVO Estabelecer os procedimentos para o gerenciamento

Leia mais

3 Gerenciamento de Projetos

3 Gerenciamento de Projetos 34 3 Gerenciamento de Projetos Neste capítulo, será abordado o tema de gerenciamento de projetos, iniciando na seção 3.1 um estudo de bibliografia sobre a definição do tema e a origem deste estudo. Na

Leia mais

Gerenciamento de Projetos. Prof. Dr. Rodolfo Miranda de Barros rodolfomdebarros@gmail.com

Gerenciamento de Projetos. Prof. Dr. Rodolfo Miranda de Barros rodolfomdebarros@gmail.com Gerenciamento de Projetos Prof. Dr. Rodolfo Miranda de Barros rodolfomdebarros@gmail.com MODELO DE GERENCIAMENTO PMI PMI (Project Management Institute); O modelo PMI é divido em áreas de conhecimento da

Leia mais

Aula 2 Governança do projeto Papéis e Responsabilidades

Aula 2 Governança do projeto Papéis e Responsabilidades Aula 2 Governança do projeto Papéis e Responsabilidades Objetivos da Aula: Nesta aula, iremos conhecer os diversos papéis e responsabilidades das pessoas ou grupos de pessoas envolvidas na realização de

Leia mais

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

Leia mais

Introdução. Escritório de projetos

Introdução. Escritório de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é um documento formal que descreve normas,

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano Unidade I GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Objetivo Estimular o aluno no aprofundamento do conhecimento das técnicas de gestão profissional de projetos do PMI. Desenvolver em aula

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste Este guia contém orientações para a implementação do

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

Estudo de Caso. Projeto Correspondência Eletrônica nos Correios S.A.

Estudo de Caso. Projeto Correspondência Eletrônica nos Correios S.A. Estudo de Caso Projeto Correspondência Eletrônica nos Correios S.A. A Presidência dos Correios vislumbrou a possibilidade da Empresa apresentar aos seus clientes um novo serviço, que foi denominado de

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Análise de Pontos por Função

Análise de Pontos por Função Análise de Pontos por Função Uma Aplicação na Gerência de Subcontratação de Software Claudia Hazan, MSc. Certified Function Point Specialist Agenda! Introdução à Gerência de Subcontratação! Melhores Práticas:!

Leia mais

GOVERNO DO ESTADO DE ALAGOAS SECRETARIA DE ESTADO DA FAZENDA DE ALAGOAS COORDENADORIA SETORIAL DE GESTÃO DA INFORMÁTICA E INFORMAÇÃO

GOVERNO DO ESTADO DE ALAGOAS SECRETARIA DE ESTADO DA FAZENDA DE ALAGOAS COORDENADORIA SETORIAL DE GESTÃO DA INFORMÁTICA E INFORMAÇÃO RESPOSTA AOS QUESTIONAMENTOS DA UNITECH 1) No item 5.2 dos critérios de qualidade, entendemos que não será aceita declaração, desacompanhada do certificado de qualidade. É correto o nosso entendimento?

Leia mais

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI

Leia mais

Simulado ITIL V3 Português Sicoob

Simulado ITIL V3 Português Sicoob Simulado ITIL V3 Português Sicoob Dezembro 2009 1 de 40 A Implementação do Gerenciamento de Serviços Baseados na ITIL requer preparação e planejamento do uso eficaz e eficiente de quais dos seguintes?

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

Gerenciamento de Projetos Gerenciamento de Custos

Gerenciamento de Projetos Gerenciamento de Custos Gerenciamento de Projetos Gerenciamento de Custos Metodologia Aula Teórica Exemplos e Exercícios práticos Questões de concursos anteriores Metodologia e Bibliografia Bibliografia PMBOK, 2004. Project Management

Leia mais

Horário: 13:00 às 15:00 horas (hora de Brasília) IDENTIFICAÇÃO DO CANDIDATO INSTRUÇÕES

Horário: 13:00 às 15:00 horas (hora de Brasília) IDENTIFICAÇÃO DO CANDIDATO INSTRUÇÕES P1-MPS.BR - Prova de Introdução ao MPS.BR Data: 21 de maio de 2007 Horário: 13:00 às 15:00 horas (hora de Brasília) Nome: e-mail: Nota: INSTRUÇÕES Você deve responder a todas as questões. O total máximo

Leia mais

Gerenciamento de Projetos Exercícios gerais com questões de concursos anteriores

Gerenciamento de Projetos Exercícios gerais com questões de concursos anteriores Gerenciamento de Projetos Exercícios gerais com questões de concursos anteriores Programa 1. Conceitos básicos do PMBOK. 2. Gerenciamento do ciclo de vida do sistema: determinação dos requisitos, projeto

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 QUALIDADE DE SOFTWARE Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 Objetivos Apresentar o processo de gerenciamento de qualidade e as atividades centrais da garantia de

Leia mais

Fábrica de Software 29/04/2015

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

Leia mais

ISO 9001:2008. Alterações e Adições da nova versão

ISO 9001:2008. Alterações e Adições da nova versão ISO 9001:2008 Alterações e Adições da nova versão Notas sobe esta apresentação Esta apresentação contém as principais alterações e adições promovidas pela edição 2008 da norma de sistema de gestão mais

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos. Nasario de S. F. Duarte Jr.

Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos. Nasario de S. F. Duarte Jr. Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos Nasario de S. F. Duarte Jr. Resumo Embora organizações projetizadas (empresas que trabalham sob projetos) existam

Leia mais

Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso

Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso Programa Brasileiro da Qualidade e Produtividade em Software PBQP SW Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso Categoria 2.36: Métodos de Gestão Soltin - Soluções

Leia mais

MINI-CURSO Gerenciamento de Projetos para Economistas

MINI-CURSO Gerenciamento de Projetos para Economistas MINI-CURSO Gerenciamento de Projetos para Economistas ECONOMISTA - RIVAS ARGOLO 2426/D 62 9905-6112 RIVAS_ARGOLO@YAHOO.COM.BR Objetivo deste mini curso : Mostrar os benefícios do gerenciamento de projetos

Leia mais

Implementação CERTICS em uma empresa avaliada no modelo de referência MPS-SW nível G

Implementação CERTICS em uma empresa avaliada no modelo de referência MPS-SW nível G Relato da Experiência Implementação CERTICS em uma empresa avaliada no modelo de referência MPS-SW nível G Fumsoft Allan M. R. Moura Charles H. Alvarenga Visual Sistemas Breno F. Duarte Paulo Lana www.visual.com.br

Leia mais

Perguntas para avaliar a efetividade do processo de segurança

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

Leia mais

Análise de Risco na Validação de Sistemas Computadorizados

Análise de Risco na Validação de Sistemas Computadorizados Análise de Risco na Validação de Sistemas Computadorizados Meg Lima Andrade Agenda Objetivos; Conceito de Sistemas Computadorizados; Conceito de Risco; Identificação de Riscos; Avaliação de Riscos; Classificaçã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

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit)

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) Agenda A palestra Angola Cliente O projeto Usando o PMBOK Usando o Cobit Lições Aprendidas Conclusão

Leia mais

Engenharia de Software II: Definindo Projeto III. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Definindo Projeto III. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Definindo Projeto III Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Explorando as Áreas de Conhecimento de Gerenciamento de Projeto Entendendo como Projetos Acontecem

Leia mais