O Modelo Processo de Software Brasileiro MPS-Br
|
|
|
- Suzana Benke Lisboa
- 10 Há anos
- Visualizações:
Transcrição
1 O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), que conta com apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O objetivo do programa MPS.BR é a Melhoria de Processo do Software Brasileiro. A base técnica para a construção e aprimoramento deste modelo de melhoria e avaliação de processo de software é composta pelas normas ISO/IEC 12207:2008 [ISO/IEC, 2008a] e ISO/IEC [ISO/IEC, 2003]. O MR-MPS foi também definido em conformidade com o CMMI-DEV [SEI, 2006]. Figura 1-Componentes do MPSBr O modelo MPS está dividido em três (3) componentes (Figura 1): Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo MPS. O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém as definições dos níveis de maturidade, processos e atributos do processo. O Guia de Aquisição é um documento complementar destinado a organizações que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém requisitos do MR-MPS, mas boas práticas para a aquisição de software e serviços correlatos.
2 O Guia de Implementação nas partes 1 a 7 sugere formas de implementar cada um dos níveis do MR-MPS. A parte 8 do Guia de Implementação sugere formas de como uma unidade organizacional que faz Aquisição de produtos pode implementar o MR-MPS. As explicações presentes nos Guias de Implementação não constituem requisitos do modelo e devem ser consideradas apenas em caráter informativo. O Guia de Avaliação contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras O modelo MPS está descrito por meio de documentos em formato de guias: Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação; Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS [SOFTEX, 2009b]; Guia de Avaliação: descreve o processo e o método de avaliação MA- MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA) [SOFTEX, 2009a]; Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS [SOFTEX, 2009c], [SOFTEX, 2009d], [SOFTEX, 2009e], [SOFTEX, 2009f], [SOFTEX, 2009g], [SOFTEX, 2009h], [SOFTEX, 2009i], [SOFTEX, 2009j], [SOFTEX, 2009k] e [SOFTEX, 2009l]. 2-O Modelo de Referência ( Softex, 2009) 2.1-Níveis de maturidade Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível.
3 2.2-Processo Os processos no MR-MPS são descritos em termos de propósito e resultados e estão detalhados na seção 9 do Guia Geral. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo. Figura 2-Estrutura do Modelo de Referência
4 Tabela 1-Níveis, Processos e Atributos de Processo Por exemplo, para o processo Gerência de Requisitos (GRE) temos: Propósito: O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Resultados esperados: GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
5 GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. 2.3-Capacidade do processo A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. No MR-MPS, à medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido neste nível superior. Os diferentes níveis de capacidade dos processos são descritos por nove atributos de processo (AP). O alcance de cada atributo de processo é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP), conforme definido a seguir: AP 1.1 O processo é executado Este atributo é uma medida do quanto o processo atinge o seu propósito. Resultado esperado: RAP 1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado Este atributo é uma medida do quanto a execução do processo é gerenciada. Resultados esperados: RAP 2. Existe uma política organizacional estabelecida e mantida para o processo; RAP 3. A execução do processo é planejada; RAP 4. (Para o nível G)4. A execução do processo é monitorada e ajustes são realizados; RAP 4. (A partir do nível F). Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados; RAP 5. (Até o nível F)5 As informações e os recursos necessários para a execução do processo são identificados e disponibilizados; RAP 5. (A partir do nível E) Os recursos e informações necessários para executar o processo definido são disponibilizados, alocados e utilizados; RAP 6. (Até o nível F)6 As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas; RAP 6. (A partir do nível E) Os papéis requeridos, responsabilidades e autoridade para execução do processo definido são atribuídos e comunicados;
6 RAP 7. (Até o nível F)7 As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP 7. (A partir do nível E) As pessoas que executam o processo definido são competentes em termos de formação, treinamento e experiência; RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento; RAP 9. (Até o nível F)8 Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização; RAP 9. (A partir do nível E) Métodos adequados para monitorar a eficácia e adequação do processo são determinados e os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização; RAP 10. (Para o nível G)9 O processo planejado para o projeto é executado. RAP 10. (A partir do nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades. AP 2.2 Os produtos de trabalho do processo são gerenciados Este atributo é uma medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. Resultados esperados: RAP 11. Os requisitos dos produtos de trabalho do processo são identificados; RAP 12. Requisitos para documentação e controle dos produtos de trabalho são estabelecidos; RAP 13. Os produtos de trabalho são colocados em níveis apropriados de controle; RAP 14. Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades. AP 3.1. O processo é definido Este atributo é uma medida do quanto um processo padrão é mantido para apoiar a implementação do processo definido. Resultados esperados: RAP 15. Um processo padrão é descrito, incluindo diretrizes para sua adaptação para o processo definido para um projeto; RAP 16. A sequência e interação do processo padrão com outros processos são determinadas; RAP 17. Os papéis e competências requeridos para executar o processo são identificados como parte do processo padrão; RAP 18. A infra-estrutura e o ambiente de trabalho requeridos para executar o processo são identificados como parte do processo padrão. AP 3.2 O processo está implementado Este atributo é uma medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. Resultados esperados: RAP 19. Um processo definido é implementado para o projeto baseado nas diretrizes para seleção e/ou adaptação do processo padrão; RAP 20. A infra-estrutura e o ambiente de trabalho requeridos para executar o processo definido são disponibilizados, gerenciados e mantidos; RAP 21. Dados apropriados são coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo;
7 RAP 22. Produtos de trabalho e lições aprendidas são coletados e armazenados na biblioteca de ativos de processo, para uso futuro e apoio à melhoria contínua do processo. AP 4.1 O processo é medido Este atributo é uma medida do quanto os resultados de medição são usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e apoia o alcance dos objetivos de negócio definidos. Resultados esperados: RAP 23. As necessidades de informação dos processos, requeridas para apoiar objetivos de negócio relevantes da organização, são identificadas; RAP 24. A partir do conjunto de processos padrão da organização e das necessidades de informação, são selecionados os processos e/ou subprocessos que serão objeto de análise de desempenho; RAP 25. Objetivos de medição do processo e/ou subprocesso são derivados das necessidades de informação do processo; RAP 26. Objetivos quantitativos de qualidade e de desempenho dos processos e/ou subprocessos são definidos para apoiar os objetivos de negócio; RAP 27. Medidas, bem como a frequência de realização de suas medições, são identificadas e definidas de acordo com os objetivos de medição do processo/subprocesso e os objetivos quantitativos de qualidade e de desempenho do processo; RAP 28. Resultados das medições são coletados, analisados e comunicados para monitorar o atendimento dos objetivos quantitativos de qualidade e de desempenho do processo/subprocesso; RAP 29. Resultados de medição são utilizados para caracterizar o desempenho do processo/subprocesso. AP 4.2 O processo é controlado Este atributo é uma medida do quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos. Resultados esperados: RAP 30. Técnicas de análise e de controle de desempenho são identificadas e aplicadas quando necessário; RAP 31. Limites de controle de variação são estabelecidos para o desempenho normal do processo; RAP 32. Dados de medição são analisados com relação a causas especiais de variação; RAP 33. Ações corretivas são realizadas para tratar causas especiais de variação; RAP 34. Limites de controle são redefinidos, quando necessário, seguindo as ações corretivas; RAP 35. Modelos de desempenho do processo são estabelecidos e mantidos. AP 5.1 O processo é objeto de melhorias e inovações Este atributo é uma medida do quanto as mudanças no processo são identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo. Resultados esperados: RAP 36. Propostas de melhoria são coletadas e analisadas para estabelecer os objetivos de melhoria do processo, que são definidos de forma a apoiar os objetivos de negócio relevantes; RAP 37. Defeitos e outros problemas são identificados, classificados e selecionados para análise;
8 RAP 38. Defeitos e outros problemas selecionados são analisados para identificar sua causa raiz e soluções aceitáveis para evitar sua ocorrência futura; RAP 39. Dados adequados são analisados para identificar causas comuns de variação no desempenho do processo; RAP 40. Dados adequados são analisados para identificar oportunidades para aplicar melhores práticas e inovações; RAP 41. Oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo são identificadas; RAP 42. Uma estratégia de implementação é estabelecida e executada para alcançar os objetivos de melhoria do processo e para resolver problemas. AP 5.2 O processo é otimizado continuamente Este atributo é uma medida do quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo. Resultados esperados: RAP 43. O impacto de todas as mudanças propostas é avaliado com relação aos objetivos do processo definido e do processo padrão; RAP 44. A implementação de todas as mudanças acordadas é gerenciada para assegurar que qualquer alteração no desempenho do processo seja entendida e que sejam tomadas as ações pertinentes; RAP 45. As ações implementadas para resolução de problemas e melhoria no processo são acompanhadas com medições para verificar se as mudanças no processo corrigiram o problema e melhoraram o seu desempenho; RAP 46. Dados da análise de causas de problemas e de sua resolução são armazenados para uso em situações similares. 3-O Método de Avaliação O método de avaliação do MPS-Br é calcado nas seguintes etapas: Planejar a avaliação Definir cronograma da avaliação Selecionar projetos: pelo menos 2 projetos concluídos e dois projetos em andamento Definir participantes: gerentes e lideres de projeto, desenvolvedores, grupos de engenharia de software ( qualidade, métricas, gerência de configuração, etc). Definir a equipe de avaliação:
9 Tabela 2- Equipes de avaliação por nível Preparar a avaliação Coletar dados por meio da seguinte planilha:
10 Figura 3-Planilha para coleta de dados Para cada resultado de processo e RPA, preencher a planilha contendo evidências de implementação dos resultados em cada projeto avalado. Tais evidências podem ser: Diretas: Documentos ou artefatos encontradas diretamente no projeto em questão. Por exemplo, para GRE1, uma ata contendo a assinatura de todos os fornecedores de requisitos, atestando que estes estão entendidos, mediante uma lista de critérios avaliados, para o projeto em questão. Indiretas: Modelos de documentos ou artefatos (templates) que indiretamente indicam que o resultado pode ser atingido. Por exemplo, um template da ata citada para evidências diretas. Afirmações: Afirmações obtida junto aos participantes de entrevistas, indicando que determinado resultado é implementado. Para cada evidência, marcar um X nas colunas dos quatro projetos, indicando a presença das evidências nos mesmos. Identificar também as fontes de tais evidências na coluna correspondente. Executar a avaliação Consiste essencialmente em: Análise dos dados coletados. Entrevistas marcadas com antecedência, que mostram o grau em que os colaboradores da organização entendem e usam os processos Verificação dos dados
11 Atribuição do nível de maturidade MPS-Br. Os passos seguintes de 1) a 5) descrevem a verificação dos dados e a consequente atribuição no nível de maturidade MPS-Br. 1)Atribuir um grau de implementação dos resultados de processo e RAP para cada projeto. Para tal, preenche-se a parte inferior das colunas de projeto na planilha de coleta de dados (Figura 3) com os seguintes graus: N - Não implementado; P - Parcialmente implementado; L - Largamente implementado; T - Totalmente implementado; NA Pelo estágio de desenvolvimento, o resultado não pôde ser avaliado. F - Fora de escopo Para atribuir o grau de implementação de cada resultado esperado ou RAP para cada projeto, utiliza-se a seguinte tabela: Tabela 3-Regras para atribuição do grau de implementação de resultados esperados e RAPs para os projetos
12 2)Agregar os resultados obtidos em 1) para atribuir o grau de implementação de cada resultado esperado e RAP para a organização. Nessa etapa, documentam-se também pontos fortes e fracos e oportunidades de melhoria. Na planilha de coleta de dados (Figura 3), preenche-se a parte inferior da coluna ORG, com o grau de implementação da organização, segundo a seguinte tabela: Tabela 4-Regras para atribuição do grau de implementação para resultados esperados e RAPs para a organização 3)Atribuir um grau de implementação de cada atributo de processo (AP) para a organização. Para tal, utilizar a seguinte tabela:
13 Tabela 5-Regras para atribuição do grau de implementação de APs para a organização 18 Esta porcentagem deve ser vista de forma global no que se refere ao grau de implantação do atributo de processo e é, ao mesmo tempo, uma avaliação qualitativa e quantitativa. Considerações relacionadas à caracterização de Resultado de Atributo de Processo - RAP 1 e Atributo de Processo - AP 1.1 A caracterização dada a RAP 1 (O processo atinge seus resultados definidos) é uma apreciação consolidada dos resultados esperados do processo. O grau T em AP 1.1 significa um alcance de mais do que 85% do conjunto dos resultados esperados do processo, sem fraquezas significativas ou sem atribuição de Não Implementado (N). Analogamente, os graus L, P e N refletem o alcance do conjunto dos resultados esperados do processo, segundo os percentuais da tabela 5. 4)Caracterizar um processo como SATISFEITO ou NÃO SATISFEITO para a organização. Um processo está SATISFEITO quando: - Todos os resultados esperados para o processo foram caracterizados como T (Totalmente implementado) ou L (Largamente implementado). - A caracterização dos atributos de processo satisfaz às exigências da Tabela 3.6. Em qualquer outra situação o processo é caracterizado como NÃO SATISFEITO.
14 Tabela 6- Caracterização de APs para satisfazer aos níveis MPS-Br. 5)Atribuir o nível MPS Br requerido se todos os processos tiverem sido caracterizados como SATISFEITOS. É possível também, atribuir-se um nível MPS Br inferior ao solicitado pela organização. Relatar resultado final da avaliação Geração do Relatório Final da Avaliação, que contém objetivos, projetos avaliados, participantes da avaliação, resultados por processo avaliado, nível de maturidade alcançado pela organização. Registro do Resultado O relatório final é registrado no Banco de Dados Softex e divulgado em 4-Implementação do MPS-Br. Implementar o MPS-Br é estruturar a organização para que os resultados esperados e RAPs de cada processo sejam atingidos. A implementação é feita com base em:
15 CMMi staged Norma ISO Guias de Implementação do SOFTEX. Referências bibliográficas importantes em Engenharia de Software, como Pressmann, Sommerville, Wilson de Pádua, dentre outros. Processos são implementados por Atividades. Atividades são realizada por papéis, normalmente necessitam de artefatos de entrada para serem realizadas e produzem artefatos de saída. Pré-atividades são realizadas antes de uma atividade específica e pós-atividades, após a mesma. A Figura 4 abaixo exibe um diagrama de fluxo de dados que mostra as atividades A1, A2 e A3 seus respectivos papéis P1, P2 e P3, os artefatos de entrada AE1 e AE2, entradas de A1 e A2 respectivamente e os artefatos AS1, AS2 e AS3, saídas de A1, A2 e A3 respectivamente. AS1 e AS2 são também entrada de A3. Figura 4-Exemplo de representação de um processo As tabelas a seguir (padrão SOFTEX) devem ser preenchidas para descrever cada uma das atividades do processo Atividade: Descrição: Pré-atividades: A1 Descrever detalhadamente a atividade aqui. Buscar essa descrição na literatura (Pressmann, Sommerville, Wilson de Pádua, etc), no bom senso ou ainda, na experiência própria. NÃO TEM
16 Pós-atividades: Artefatos de entrada: Artefatos de saída: Papéis: Atividade: Descrição: Pré-atividades: Pós-atividades: Artefatos de entrada: Artefatos de saída: Papéis: Atividade: Descrição: A2 AE1 AS1 P1 A2 A1 A3 AE2 AS2 P2 A3 Pré-atividades: A2 Pós-atividades: NÃO TEM Artefatos de AS1,AS2 entrada: Artefatos de saída: AS3 Papéis: P3 Tabelas 7, 8 e 9. Descrição das atividades A1, A2 e A3. A utilização do CMMI staged facilita a definição das atividades de um processo. Para implementar um processo no MPS-Br, podemos buscar seu processo correspondente no CMMi. Cada processo do CMMi possui um conjunto de specific practices (SP) que vão corresponder aos resultados do MPS-Br (em todos os processos do CMMI, as SPs são praticamente iguais aos resultados de processo correspondentes do MPS-Br). Cada SP vai possuir subpractices, que vão ser as atividades do MPS Br, e work products, que serão artefatos de entrada e saída. Cada RAP vai corresponder a uma generic practice (GP) do CMMi. A tabela abaixo resume esse mapeamento do MPS-Br para o CMMi: Estrutura do MPS-Br Correspondente no CMMi Processo Processo Resultado de processo Specific practices-sp (práticas específicas) Atividades Subpractices (subpráticas) Artefatos de entrada e saída Work products (produtos de trabalho) RAP Generic Practice-GP (prática genérica) Tabela 10-Mapeamento do MPS-Br para o CMMi
17 Como exemplo, veremos o processo Gerência de Requisitos do MPS-Br. Os resultados deste são os seguintes: GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. No CMMi staged temos as seguintes SPs (pág. 93 em português e pág. 84 do manual em inglês): SP 1.1 Obter um Entendimento dos Requisitos SP 1.2 Obter Compromisso sobre os Requisitos SP 1.3 Gerenciar Mudanças nos Requisitos SP 1.4 Manter a Rastreabilidade Bidirecional dos Requisitos SP 1.5 Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos Repare que a SP 1.1 é o GRE 1, a SP 1.2 é o GRE 2, a SP 1.3 é o GRE 5, a SP 1.4 é a GRE 3 e a SP 1.5 é o GRE 4. Quando não houver essa correspondência, o implementador deve pesquisar em outras fontes, usar o bom senso ou sua experiência prática. Tomemos a SP 1.1. Seus produtos de trabalho (work products) são os seguintes (pág. 85 inglês e pág. 94 português) : 1.Listas de critérios para distinguir os fornecedores apropriados de requisitos 2. Critérios para a avaliação e aceitação dos requisitos 3. Resultados de análises contra os critérios 4. Um conjunto de requisitos acordados E suas subpráticas são as seguintes (pág. 85 inglês e pág. 94 português) : 1 Estabelecer critérios para distinguir os fornecedores apropriados de requisitos 2 Estabelecer critérios objetivos para a aceitação de requisitos. 3 Analisar os requisitos para assegurar que os critérios estabelecidos estão sendo atendidos. 4 Chegar a um entendimento dos requisitos com o fornecedor dos requisitos, de forma que os participantes do projeto possam estabelecer compromissos com relação a eles. Cada uma das subpráticas acima será uma atividade de implementação do GRE 1.
18 E os work product serão artefatos de entrada e saída da atividade. As tabelas abaixo exibem a descrição das atividades do GRE 1 correspondentes às subpráticas de 1 a 4 citadas acima. Atividade: Descrição: Pré-atividades: Pós-atividades: Artefatos de entrada: Artefatos de saída: Papéis: 1 Estabelecer critérios para distinguir os fornecedores apropriados de requisitos Esta avidade consiste em, através de reunião, definir quem quais serão critérios para definição dos fornecedores de requisitos para um determinado projeto.tais critérios podem ser embasados na experiência, freqüência com que usa o sistema, importância no processo, etc... NÃO TEM 2 Estabelecer critérios objetivos para a aceitação de requisitos. NÃO TEM 1-Listas de critérios para distinguir os fornecedores apropriados de requisitos Analista de negócios, cliente Atividade: Descrição: Pré-atividades: Pós-atividades: Artefatos entrada: de 2 Estabelecer critérios objetivos para a aceitação de requisitos. A falta de critérios de aceitação muitas vezes resulta numa verificação inadequada, um caro retrabalho ou a rejeição do cliente. Exemplos de critérios de aceitação são (CMMi, pág 95 português): Clara e apropriadamente declarados Completos Consistentes uns com os outros Identificados de forma única Apropriados para serem implementados Verificáveis (podem ser testados) Rastreáveis Etc 1 Estabelecer critérios para distinguir os fornecedores apropriados de requisitos 3 Analisar os requisitos para assegurar que os critérios estabelecidos estão sendo atendidos. 1-Listas de critérios para distinguir os fornecedores apropriados de requisitos Artefatos de saída: Papéis: 2. Critérios para a avaliação e aceitação dos requisitos Analista de negócios, analista de sistemas
19 Atividade: Descrição: Pré-atividades: Pós-atividades: Artefatos de entrada: Artefatos de saída: Papéis: 3 Analisar os requisitos para assegurar que os critérios estabelecidos estão sendo atendidos. Verificar os requisitos frente aos critérios de aceitação pré estabelecidos, em uma reunião com duração máxima de duas horas, em que os participantes discutirão a aderência dos mesmos...etc 2 Estabelecer critérios objetivos para a aceitação de requisitos. 4 Chegar a um entendimento dos requisitos com o fornecedor dos requisitos, de forma que os participantes do projeto possam estabelecer compromissos com relação a eles. 2. Critérios para a avaliação e aceitação dos requisitos 3. Resultados de análises contra os critérios Analista de negócios, analista de sistemas, gerente, cliente. Atividade: Descrição: Pré-atividades: Pós-atividades: Artefatos de entrada: Artefatos de saída: Papéis: 4 Chegar a um entendimento dos requisitos com o fornecedor dos requisitos, de forma que os participantes do projeto possam estabelecer compromissos com relação a eles. Consiste em uma reunião entre os participantes do projeto e os fornecedores de requisitos para chegar a uma aprovação (compromisso) de quais requisitos serão efetivamente implementados. Nessa reunião, verificam-se as reais necessidades, identificam-se ambigüidades, inconsistências e imcompletezas nos requisitos. Etc.. 3 Analisar os requisitos para assegurar que os critérios estabelecidos estão sendo atendidos. NÃO TEM 3. Resultados de análises contra os critérios 4. Um conjunto de requisitos acordados Analista de negócios, analista de sistemas, gerente, cliente, etc.. Tabelas 11 a 14- Exemplo de implementação do GRE 1 por meio de quatro atividades (subpráticas) do processo gerência de requisitos do CMMi. Referências: SOFTEX. Guia Geral do MPS-Br SOFTEX. Guia de Avaliação do MPS-Br. 2009
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 [email protected] Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software
Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.
Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura O Modelo Wesley Torres Galindo [email protected] Agenda O que é? Motivação Organização do MPS.BR Estrutura
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
Políticas de Qualidade em TI
Políticas de Qualidade em TI Prof. www.edilms.eti.br [email protected] Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade
Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro
Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Realidade das Empresas Brasileiras ISO/IEC 12207 ISO/IEC 15504 CMMI Softex Governo Universidades Modelo de Referência para
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
Modelos de Maturidade: MPS.BR. Aécio Costa
Modelos de Maturidade: MPS.BR Aécio Costa Criado em 2003 pela Softex para melhorar a capacidade de desenvolvimento de software nas empresas brasileiras. Objetivo: Impulsionar a melhoria da capacidade de
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
FACULDADE SENAC GOIÂNIA
FACULDADE SENAC GOIÂNIA NORMA ISO 12.207 Curso: GTI Matéria: Auditoria e Qualidade de Software Professor: Elias Ferreira Acadêmico: Luan Bueno Almeida Goiânia, 2015 CERTIFICAÇÃO PARA O MERCADO BRASILEIRO
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
Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013)
Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013) Professor Gledson Pompeu [email protected] Acesse nosso site em WWW.DOMINANDOTI.COM.BR Versões atualizadas de notas de aula e listas de
Rede TSQC / SOFTEX Workshop de Aquisição de software Guia de Aquisição MPS.BR
Rede TSQC / SOFTEX Workshop de Aquisição de software Guia de Aquisição MPS.BR Danilo Scalet [email protected] Editor do Guia de Aquisição 1 2 1 MPS.BR: Desenvolvimento e Aprimoramento do Modelo Realidade
Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira [email protected] www.ufpa.br/srbo
Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira [email protected] www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação
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
Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira
Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados
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
Este atributo evidencia o quanto o processo atinge o seu propósito
Alterações no Guia Geral:2011 Este documento lista todas as alterações realizadas nos resultados esperados de processos e resultados esperados de atributos de processo presentes no MR-MPS versão de 2011
APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR
APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR Fonte: http://www.softex.br/mpsbr/_home/default.asp Apostilas disponíveis no site 1 NORMAS: NBR ISO NBR ISO/IEC CMM SPICE Continuação... 2 NORMAS VISÃO GERAL NBR
Melhoria do Processo de Software MPS-BR
Melhoria do Processo de Software MPS-BR Fabrício Sousa Pinto [email protected] O que é Qualidade? O problema da gestão da qualidade não é que as pessoas não sabem a respeito dela. O problema é que
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
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),
Implantação de um Processo de Medições de Software
Departamento de Informática BFPUG Brazilian Function Point Users Group Implantação de um Processo de Medições de Software Claudia Hazan, MSc., CFPS [email protected] Agenda Introdução Processo de Medições
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
Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE
Prof. Dr. Ivanir Costa Unidade IV QUALIDADE DE SOFTWARE introdução As mudanças que estão ocorrendo nos clientes e nos ambientes de negócios altamente competitivos têm motivado as empresas a modificarem
Modelo de Referência para melhoria do processo de software (MR mps)
Modelo de Referência para melhoria do processo de software (MR mps) Projeto mps Br: Modelo de Referência para Melhoria de Processo de Software CMMI SPICE SCAMPI MODELO PARA MELHORIA DO PROCESSO DE SOFTWARE
Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: ([email protected]) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
MPS.BR Melhoria de Processo do Software Brasileiro
l MPS.BR Melhoria de Processo do Software Brasileiro SUMÁRIO 1. Introdução 2. Modelo MPS 3. Programa MPS.BR: Resultados Alcançados (2004-2008) e Resultados Esperados (2004-2010) 4. MPS.BR Lições Aprendidas
MODELO CMM MATURIDADE DE SOFTWARE
MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo
Política Organizacional para Desenvolvimento de Software no CTIC
Política Organizacional para Desenvolvimento de Software no CTIC O CTIC/UFPA Centro de Tecnologia da Informação e Comunicação da Universidade Federal do Pará define neste documento sua Política Organizacional
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
Avaliação de Riscos Aplicada à Qualidade em Desenvolvimento de Software
Rafael Espinha, Msc [email protected] +55 21 9470-9289 Maiores informações: http://www.primeup.com.br [email protected] +55 21 2512-6005 Avaliação de Riscos Aplicada à Qualidade em
Gerenciamento de Projeto: Monitorando e Controlando o Projeto II. Prof. Msc Ricardo Britto DIE-UFPI [email protected]
Gerenciamento de Projeto: Monitorando e Controlando o Projeto II Prof. Msc Ricardo Britto DIE-UFPI [email protected] Sumário Reportar o Desempenho Realizar o Controle Integrado de Mudanças Reportar o
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
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 [email protected] Qualidade de Software 2009 Instituto
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: [email protected] CMM E CMMI
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: [email protected] CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico
Implantação do Processo Aquisição na Synapsis Brasil. Carlos Simões Ana Regina Rocha Gleison Santos
Implantação do Processo Aquisição na Synapsis Brasil Carlos Simões Ana Regina Rocha Gleison Santos Data: 20/10/2009 Agenda Empresa Problema Alternativas Implementação Forma de contratação Processo Aquisição
F.1 Gerenciamento da integração do projeto
Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: [email protected]
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: [email protected] 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
Melhorias de Processos de Engenharia de Software
Melhorias de Processos de Engenharia de Software CMMI 1 Profa. Reane Franco Goulart O que é CMMI? O Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processos que fornece às
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
PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira
PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos
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
MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral
MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral Este guia contém a descrição geral do Modelo MPS e detalha o Modelo de Referência (MR-MPS) e as definições comuns necessárias para seu entendimento
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
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
Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares
Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares O Project Management Institute é uma entidade sem fins lucrativos voltada ao Gerenciamento de Projetos.
Porque estudar Gestão de Projetos?
Versão 2000 - Última Revisão 07/08/2006 Porque estudar Gestão de Projetos? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para projetos
Adriano Marum Rômulo. Uma Investigação sobre a Gerência de Projetos de Desenvolvimento de Software em Órgãos do Governo do Ceará com Base no MPS-BR
Adriano Marum Rômulo 2014 Uma Investigação sobre a Gerência de Projetos de Desenvolvimento de Software em Órgãos do Governo do Ceará com Base no MPS-BR Agenda I. Introdução II. Referencial Teórico III.
CHECK LIST DE AVALIAÇÃO DE FORNECEDORES Divisão:
4.2.2 Manual da Qualidade Está estabelecido um Manual da Qualidade que inclui o escopo do SGQ, justificativas para exclusões, os procedimentos documentados e a descrição da interação entre os processos
PR 2 PROCEDIMENTO. Auditoria Interna. Revisão - 2 Página: 1 de 9
Página: 1 de 9 1. OBJETIVO Estabelecer sistemática de funcionamento e aplicação das Auditorias Internas da Qualidade, fornecendo diretrizes para instruir, planejar, executar e documentar as mesmas. Este
C.M.M. Capability Maturity Model Modelo de Maturidade da Capacidade
UNISUL Universidade do Sul de Santa Catarina. Campus da Grande Florianópolis Pedra Branca. CIÊNCIA DA COMPUTAÇÃO ENGENHARIA DE SOFTWARE ALUNO: Volnei A. Caetano Palhoça 02 de Junho de 2000 C.M.M. Capability
Processo de Implementação de um Sistema de Gestão da Qualidade
3 Processo de Implementação de um Sistema de Gestão da Qualidade Não existe um jeito único de se implementar um sistema da qualidade ISO 9001: 2000. No entanto, independentemente da maneira escolhida,
LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE
Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?
Sistema de Gestão da Qualidade
Sistema de Gestão da Qualidade Coordenadora Responsável Mara Luck Mendes, Jaguariúna, SP, [email protected] RESUMO Em abril de 2003 foi lançado oficialmente pela Chefia da Embrapa Meio Ambiente o Cronograma
Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0
O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok
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
Gerenciamento de Projetos Modulo III Grupo de Processos
Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha [email protected] http://waltercunha.com PMBoK Processos de Gerenciamento de Projetos Para que um projeto seja bem-sucedido,
CÓPIA NÃO CONTROLADA. DOCUMENTO CONTROLADO APENAS EM FORMATO ELETRÔNICO. PSQ PROCEDIMENTO DO SISTEMA DA QUALIDADE
PSQ PROCEDIMENTO DO SISTEMA DA QUALIDADE PSQ 290.0339 - PROCEDIMENTO DO SISTEMA DA QUALIDADE APROVAÇÃO CARLOS ROBERTO KNIPPSCHILD Gerente da Qualidade e Assuntos Regulatórios Data: / / ELABORAÇÃO REVISÃO
[email protected]
UM BREVE DESCRITIVO DO MODELO MPS-BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO) E SUAS PERSPECTIVAS PARA O FUTURO CLÉVERSON TRAJANO PRÉCOMA PORTES PÓS-GRADUAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO
CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação
Conhecimento em Tecnologia da Informação CobiT 5 Como avaliar a maturidade dos processos de acordo com o novo modelo? 2013 Bridge Consulting All rights reserved Apresentação Sabemos que a Tecnologia da
1 2009 CBG Centro Brasileiro de Gestão
1 2009 CBG Centro Brasileiro de Gestão ISO 9001:2015 Histórico da série 2 2009 CBG Centro Brasileiro de Gestão Histórico da série REVISÕES DA SÉRIE ISO 9000 2000 2008 2015 1994 1987 3 2009 CBG Centro Brasileiro
ENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [[email protected]] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
PROCEDIMENTO GERENCIAL
PÁGINA: 1/10 1. OBJETIVO Descrever o procedimento para a execução de auditorias internas a intervalos planejados para determinar se o sistema de gestão da qualidade é eficaz e está em conformidade com:
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
Secretaria de Gestão Pública de São Paulo. Guia de Avaliação de Maturidade dos Processos de Gestão de TI
Secretaria de Gestão Pública de São Paulo Guia de Avaliação de Maturidade dos Processos de Gestão de TI Objetivos As empresas e seus executivos se esforçam para: Manter informações de qualidade para subsidiar
Qual a diferença entre certificação e acreditação? O que precisamos fazer para obter e manter a certificação ou acreditação?
O que é a norma ISO? Em linhas gerais, a norma ISO é o conjunto de cinco normas internacionais que traz para a empresa orientação no desenvolvimento e implementação de um Sistema de Gestão da Qualidade
Melhoria de Processos de Software com o MPS.BR
Melhoria de Processos de Software com o MPS.BR Prof. Dr. Marcos Kalinowski (UFF) [email protected] Agenda do Curso Motivação para processos de software Visão geral do programa MPS.BR e do modelo MPS-SW
Palestra Informativa Sistema da Qualidade NBR ISO 9001:2000
Palestra Informativa Sistema da Qualidade NBR ISO 9001:2000 ISO 9001:2000 Esta norma considera de forma inovadora: problemas de compatibilidade com outras normas dificuldades de pequenas organizações tendências
ESTUDO COMPARATIVO NBR ISO 13485:2004 RDC 59:2000 PORTARIA 686:1998 ITENS DE VERIFICAÇÃO PARA AUDITORIA
ESTUDOCOMPARATIVO NBRISO13485:2004 RDC59:2000 PORTARIA686:1998 ITENSDEVERIFICAÇÃOPARAAUDITORIA 1. OBJETIVO 1.2. 1. Há algum requisito da Clausula 7 da NBR ISO 13485:2004 que foi excluída do escopo de aplicação
Políticas de Qualidade em TI
Políticas de Qualidade em TI Prof. www.edilms.eti.br [email protected] Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações
Aplicando Avaliações de Contextualização em Processos de Software Alinhados ao nível F do MR-MPS V1.2
Aplicando Avaliações de Contextualização em Processos de Software Alinhados ao nível F do MR-MPS V1.2 IV Workshop de Implementadores W2-MPS.BR 2008 Marcello Thiry [email protected] Christiane von
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
Definição de Processos Reutilizáveis para Desenvolvimento de Software com Aquisição
Definição de Processos Reutilizáveis para Desenvolvimento de Software com Aquisição VIII Workshop Anual do MPS (WAMPS 2012) Autores: Fabrício Souto Cardoso (Eletrobras e COPPE/UFRJ) Dr.ª Ana Regina Rocha
MPS.BR. O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro. A proposta MPS.BR nasceu com base nos moldes CMMI.
MPS.BR O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro. A proposta MPS.BR nasceu com base nos moldes CMMI. ISO - 12207 para desenvolvimento de software. ISO - 15504 para avaliação
MUDANÇAS NA ISO 9001: A VERSÃO 2015
MUDANÇAS NA ISO 9001: A VERSÃO 2015 Está em andamento o processo de revisão da Norma ISO 9001: 2015, que ao ser concluído resultará na mudança mais significativa já efetuada. A chamada família ISO 9000
Programa MPS.BR: resultados e perspectivas
Programa MPS.BR: resultados e perspectivas Ana Regina Rocha Programa de Engenharia de Sistemas e Computação Coordenadora da Equipe Técnica do Modelo MPS Uma Organização com bom desempenho gasta 80% de
NORMA ISO/IEC 14598. Isac Aguiar isacaguiar.com.br [email protected]
NORMA ISO/IEC 14598 Isac Aguiar isacaguiar.com.br [email protected] Contexto Normas e Modelos de Qualidade Engenharia de Software Qualidade de Software ISO/IEC 14598 - Avaliação da Qualidade de Produto
MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral MPS de Software
MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral MPS de Software Este guia contém a descrição geral do Modelo MPS e detalha o Modelo de Referência MPS para Software (MR-MPS-SW) e as definições
Lista de verificação (Check list) para planejamento e execução de Projetos
www.tecnologiadeprojetos.com.br Lista de verificação (Check list) para planejamento e execução de Projetos Eduardo F. Barbosa Dácio G. Moura Material didático utilizado na disciplina Desenvolvimento de
Planejamento e Gerência de Projetos de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás
Planejamento e Gerência de Projetos de Software Prof.: Ivon Rodrigues Canedo PUC Goiás Projeto É um trabalho que visa a criação de um produto ou de serviço específico, temporário, não repetitivo e que
Expansão do Programa MPS.BR - Melhoria de Processo do Software Brasileiro (2012-2015)
Expansão do Programa MPS.BR - Melhoria de Processo do Software Brasileiro (2012-2015) Projeto 2.04 do PBQP Software Ciclo 2012 1. Introdução 2. Dados do Projeto 3. Resultados Propostos 4. Produtos Esperados
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
Gerenciando Riscos no Desenvolvimento de Software
Rafael Espinha, MSc [email protected] João Condack, MSc [email protected] Maiores informações: http://www.primeup.com.br [email protected] +55 21 2512-6005 Gerenciando Riscos
Engenharia de Software II: Desenvolvendo o Orçamento do Projeto. Prof. Msc Ricardo Britto DIE-UFPI [email protected]
Engenharia de Software II: Desenvolvendo o Orçamento do Projeto Prof. Msc Ricardo Britto DIE-UFPI [email protected] Sumário Criação do Plano de Gerenciamento de Custos do Projeto Estimar os Custos Determinar
POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS
POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS Versão 2.0 30/10/2014 Sumário 1 Objetivo... 3 2 Conceitos... 3 3 Referências... 4 4 Princípios... 4 5 Diretrizes... 5 5.1 Identificação dos riscos...
MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F:
MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F: um estudo de caso. Rodrigo Pereira Assunção 1 Fabrício Pires Vasconcellos 2 RESUMO: Muitas empresas têm buscado no modelo de
SIMPROS 2001. Experiência de implantação da norma ISO 9001:2000 a partir da utilização da ISO/IEC TR 15504 (SPICE) para Melhoria de Processos
Experiência de implantação da norma ISO 9001:2000 a partir da utilização da ISO/IEC TR 15504 (SPICE) para Melhoria de Processos Adilson Sérgio Nicoletti Blumenau, SC - setembro de 2001 Conteúdo Apresentação
ISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu ([email protected])
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
O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto
Gerais Processo Produto Propostas NBR ISO 9000:2005 define principios e vocabulário NBR ISO 9001:2000 define exigências para sistema de gerência de qualidade NBR ISO 9004:2000 apresenta linha diretivas
