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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Objetivos da Aula: Os objetivos desta aula visam definir termos e conceitos da qualidade. Para tal, pretende-se discutir a relação que se estabelece

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

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

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

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

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

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

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

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro

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

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

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

A Importância de um Processo de Testes Certificado: Estudo de Caso da implantação da certificação MPT.Br em uma pequena empresa

A Importância de um Processo de Testes Certificado: Estudo de Caso da implantação da certificação MPT.Br em uma pequena empresa i A Importância de um Processo de Testes Certificado: Estudo de Caso da implantação da certificação MPT.Br em uma pequena empresa Carla Cristina Veras Abdalla Coelho Universidade Federal do Rio de Janeiro

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

Simulações em Aplicativos

Simulações em Aplicativos Simulações em Aplicativos Uso Avançado de Aplicativos Prof. Marco Pozam mpozam@gmail.com A U L A 0 4 Programação da Disciplina 20/Agosto: Conceito de Project Office. 27/Agosto: Tipos de Project Office.

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.0) Este guia contém orientações para a implementação do Nível G do Modelo de Referência MR-MPS. Dezembro

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

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

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software Este guia contém orientações para a implementação do Modelo

Leia mais

Manual de Gerenciamento de Projetos

Manual de Gerenciamento de Projetos TRIBUNAL REGIONAL DO TRABALHO DA 4ª REGIÃO ASSESSORIA DE GESTÃO ESTRATÉGICA ESCRITÓRIO DE PROJETOS ESTRATÉGICOS (EPE) Manual de Gerenciamento de Projetos SISTEMA DE GESTÃO ESTRATÉGICA Anexo da Portaria

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

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

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

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

Aula Nº 10 Planejamento da Comunicação

Aula Nº 10 Planejamento da Comunicação Aula Nº 10 Planejamento da Comunicação Objetivos da Aula: Os objetivos desta aula visam analisar as necessidades de informação para se manter os stakeholders internos e externos bem como a equipe de projetos

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 Este guia contém orientações para a implementação do nível

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

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

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

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

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

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

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

Gestão de Projetos de Software

Gestão de Projetos de Software Gestão de Projetos de Software Atividade Essencial à Engenharia de Software U Antonio Mendes da Silva Filho antoniom.silvafilho@gmail.com Professor e consultor em área de tecnologia da informação e comunicação

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

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

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

Capability Maturity Model Integration - CMMI

Capability Maturity Model Integration - CMMI Capability Maturity Model Integration - CMMI Para Desenvolvimento Versão 1.2 M.Sc. Roberto Couto Lima ÍNDICE 1. Definição ------------------------------------------------------------------------------------------------------------

Leia mais

a) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema

a) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema Simulado CTFL- BSTQB Tempo de duração: 60 minutos 1. Considerando as seguintes afirmações: I. 100% de cobertura de sentença (comando) garante 100% de cobertura de desvio II. 100% de cobertura de desvio

Leia 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

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

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

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

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

Mapeamento GRH. 1. Introdução

Mapeamento GRH. 1. Introdução Mapeamento GRH 1. Introdução 1.1. Finalidade Este documento tem duas finalidades principais: a) Averiguar semelhanças e diferenças entre modelos, normas e guias de boas práticas para gestão de recursos

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

4ª Parte Processo de Teste

4ª Parte Processo de Teste 4ª Parte Processo de Teste Atividades de preparação Ø Planejamento: define itens a testar, aspectos gerenciais e recursos necessários; para a execução da bateria de testes. Ø Desenho: completa as especificações

Leia mais

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

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

Leia mais

Aula 3 Fase de Iniciação de projetos

Aula 3 Fase de Iniciação de projetos Aula 3 Fase de Iniciação de projetos Objetivos da Aula: Os objetivos desta aula são, basicamente, apresentar as atividades que constituem a fase inicial dos projetos. Alem disso, vamos discorrer sobre

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

Aula Nº 06 Determinação do Orçamento

Aula Nº 06 Determinação do Orçamento Aula Nº 06 Determinação do Orçamento Objetivos da Aula: Os objetivos desta aula são, basicamente, apresentar os processos aplicados que possibilitem identificar os recursos necessários para se conduzir

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

Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público.

Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público. Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público. Sérgio Ricardo Fortes 1 ; Ana Cristina Dalborgo 2 1 EMTU Rua Joaquim Casemiro, 290, Bairro Planalto São Bernardo do Campo-SP

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

PROJETOS IV. Plano do Projeto Exportação da Bebida Voltz Equipe Style Project (07/10/2009)

PROJETOS IV. Plano do Projeto Exportação da Bebida Voltz Equipe Style Project (07/10/2009) PROJETOS IV Plano do Projeto Exportação da Bebida Voltz Equipe Style Project (07/10/2009) Assinaturas de Aprovação Responsabilidade Organizacional Assinatura Data Gerente de Projeto 07/10/2009 Líder de

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

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

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

Gerenciamento de Escopo na Gestão de Projetos

Gerenciamento de Escopo na Gestão de Projetos Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior aebjr@terra.com.br MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 3: Fundamentação para Implementação do Nível E do MR-MPS-SW:2012

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 3: Fundamentação para Implementação do Nível E do MR-MPS-SW:2012 MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 3: Fundamentação para Implementação do Nível E do MR-MPS-SW:2012 Este guia contém orientações para a implementação do nível

Leia mais

IV PLANO DE GERENCIAMENTO DE TEMPO

IV PLANO DE GERENCIAMENTO DE TEMPO IV PLANO DE GERENCIAMENTO DE TEMPO 1 - Descrição do Plano de Gerenciamento detempo (PMBOK) O gerenciamento de tempo do projeto inclui os processos necessários para realizar o término do projeto no prazo.

Leia mais

Gerenciamento de Projetos Modulo IV Integração

Gerenciamento de Projetos Modulo IV Integração Gerenciamento de Projetos Modulo IV Integração Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) LONDRINA - PR 2014 GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

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

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

PMBOK/PMI Project Management Body of Knowledge. Gerenciamento de Projetos

PMBOK/PMI Project Management Body of Knowledge. Gerenciamento de Projetos PMBOK/PMI Project Management Body of Knowledge Gerenciamento de Projetos Organização de Projetos GERENCIAMENTO DE PORTFÓLIOS GERENCIAMENTO DE PROGRAMA GERENCIAMENTO DE PROJETOS GERENCIAMENTO DE SUBPROJETOS

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

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

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

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

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

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

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

Melhoria de Processos de Software com o MPS.BR

Melhoria de Processos de Software com o MPS.BR Melhoria de Processos de Software com o MPS.BR Prof. Dr. Marcos Kalinowski (UFF) kalinowski@acm.org Agenda do Curso Motivação para processos de software Visão geral do programa MPS.BR e do modelo MPS-SW

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

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

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2012 MPS.BR - Melhoria de Processo do Brasileiro Guia de Implementação Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2012 Este guia contém orientações para a implementação do nível G do

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