DIRETRIZES PARA IMPLEMENTAÇÃO DO MODELO MPT.BR A PARTIR DO MR-MPS-SW

Transcrição

1 DIRETRIZES PARA IMPLEMENTAÇÃO DO MODELO MPT.BR A PARTIR DO MR-MPS-SW Bernardo Tavares Narcizo Projeto de Graduação apresentado ao Curso de Engenharia de Computação e Informação da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientadora: Ana Regina Cavalcanti da Rocha Orientadores: Rio de Janeiro Março de 2015

2 DIRETRIZES PARA IMPLEMENTAÇÃO DO MODELO MPT.BR A PARTIR DO MR-MPS-SW Bernardo Tavares Narcizo PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO DE ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA ESCOLA POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO. Examinada por: Prof. Ana Regina Cavalcanti da Rocha, D.Sc. Prof. Geraldo Xexéo, D.Sc. Prof. Gleison dos Santos Souza, D. Sc. RIO DE JANEIRO, RJ BRASIL MARÇO de 2015

3 Narcizo, Bernardo Tavares Diretrizes para Implementação do modelo MPT.Br a partir do MR-MPS-SW / Bernardo Tavares Narcizo. Rio de Janeiro: UFRJ/ Escola Politécnica, VIII, 304 p.: il.; 29,7 cm. Orientadora: Ana Regina Cavalcanti da Rocha Projeto de Graduação UFRJ/ Escola Politécnica/ Curso de Engenharia de Computação e Informação, Referências Bibliográficas: p Diretrizes de Implementação 2. Melhoria de Processos 3. Modelos de Referência 4. MPT.Br 5. MR-MPS-SW 6. Processos de Software I. Rocha, Ana Regina Cavalcanti da. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Curso de Engenharia de Computação e Informação. III. Título. iii

4 A minha mãe Sandra, ao meu pai Wanderley, por todos os incentivos e ensinamentos; A minha irmã Amanda, a minha família e aos meus amigos, por tudo que representam na minha vida. iv

5 AGRADECIMENTOS A Deus, por me ajudar e dar forças durante toda a vida e em especial durante os desafios que apareceram durante a minha graduação; Aos meus pais, Sandra e Wanderley, pelo incentivo, apoio, suporte e ensinamentos que tornaram possível que eu atingisse esse objetivo. Por todos os princípios passados, por me ensinar o valor da educação e do esforço; À minha irmã, Amanda, por me aturar durante todos esses anos e por me proporcionar momentos de gargalhadas inesquecíveis ao falar coisas sem sentido. Por sempre me lembrar de fazer o meu melhor, para assim ser um bom exemplo para ela; À Ana Regina, minha orientadora, por ter me ajudado com esse trabalho e por ter acreditado no meu potencial. Agradeço pelos conselhos dados durante as conversas, durante as aulas e s; Aos membros da banca, Geraldo Xexéo e Gleison Santos, por terem aceitado participar da apresentação do meu projeto de graduação; À Beatriz Prata por sempre me ajudar com as questões administrativas relacionadas ao curso; A toda minha família, por estarem sempre preocupados e dispostos a me ajudar sempre que fosse preciso. Às minhas tias, Marizete e Roseli, por sempre me lembrarem qual era o meu foco; Ao meu tio Jairo, por sempre me alegrar em momentos de dificuldade; Aos meu tios, Carmem e Delair, por todo apoio; Aos meus avós, Aldina e Antônio, por todos os ensinamentos; A minha avó, Noêmia, por sempre me receber com um sorriso enorme em sua casa; Aos meus primos, Danilo, Debora e Pedro, por serem mais que primos; A todos os amigos que fizeram essa jornada inesquecível, que me apoiaram e ajudaram no meu crescimento como pessoa. Amigos esses que sempre estiveram presentes em momentos de alegria e dificuldade durante o curso, que sempre demonstraram o valor da amizade, que é bem difícil de ser quantificado. Em especial, aos amigos que estão comigo, praticamente desde o começo da faculdade como Bernardo Camilo, Evana Carvalho, Luciano Leite, Luiz Henrique Pinho, Lygia Marina, Nilton Duarte, Pedro Miranda, Pedro de Vasconcellos e Rachel Castro; Agradeço. v

6 Resumo do Projeto de Graduação apresentação à Escola Politécnica/ UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação. Diretrizes para Implementação do Modelo MPT.Br a partir do MR-MPS- SW Bernardo Tavares Narcizo Março/2015 Orientadora: Ana Regina Cavalcanti da Rocha Orientadores: Curso: Engenharia de Computação e Informação Com o crescimento da competitividade no mercado de desenvolvimento de software, as organizações estão buscando maneiras de se destacarem das suas concorrentes. Uma forma é melhorar os processos de desenvolvimento e prestação de serviços através da implementação de modelos de referência. Desse modo, a organização consegue dar aos seus clientes indicadores da qualidade dos softwares produzidos e dos serviços prestados. Diversos modelos de referência são conhecidos e adotados pelas organizações, entre eles estão o MR-MPS-BR (Modelo de Referência para Melhoria de Processo de Software Brasileiro) e o MPT.Br (Melhoria de Processo de Teste). A partir do mapeamento realizado em trabalho anterior (ARAUJO, 2014), foram estabelecidas diretrizes para implementação do modelo MPT.Br em organizações que já possuem um nível de maturidade do modelo MR-MPS-SW. O objetivo das diretrizes é ajudar as organizações a, conhecendo as similaridades entre os dois modelos, economizarem recursos financeiros e tempoao optarem por implementar o segundo modelo. Palavras-chave: Diretrizes de Implementação, Melhoria de Processos, Modelos de Referência, MPT.Br, MR-MPS-SW, Processos de Software. vi

7 Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of the requirements for the degree of Computer and Information Engineer. Guidelines for the implementation of MPT.Br model in organizations that already have a MR-MPS-SW level Bernardo Tavares Narcizo March/2015 Advisor: Ana Regina Cavalcanti da Rocha Advisors: Major: Computer and Information Engineering With the increasing competitiveness in the software development market, organizations are looking for ways to stand out from their competitors. One way is to improve their development processes and services through the implementation of reference models. Thus, the organization can give their customers quality indicators for the software and services produced. Several reference models are adopted by software organizations, which include the MR-MPS-BR (Reference Model for Brazilian Software Process Improvement) and the MPT.Br (Reference Model for Test Process Improvement). Based on the mapping produced on a previous work (ARAUJO, 2014), guidelines have been established to implement the MPT.Br model in organizations that already have a maturity level of the MR-MPS-SW model. The purpose of these guidelines is to leverage the similarities between the two models to support the organization in the implementation of the second model without expending unnecessary resources. Keywords: Guidelines for Implementation, Processes Improvement, Reference Models, MPT.Br, MR-MPS-BR, Software Processes. vii

8 SUMÁRIO 1. Introdução Processos de Software Motivação e Objetivo do Trabalho Organização do Trabalho Os Modelos de Referência MPS-SW e MPT.Br O Modelo de Referência MR-MPS-SW O Modelo de Referêmcia MPT.Br Mapeamento dos Modelos MR-MPS-SW e MPT.Br Diretrizes para Implementação do MPT.BR em Organizações que já possuem Nível MPS-SW Introdução Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível G Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível G Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível G Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível G Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível G Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível F Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível F Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível F viii

9 3.10. Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível F Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível F Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível E Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível E Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível E Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível E Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível E Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível D Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível D Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível D Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível D Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível D Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível C Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível C Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível C ix

10 3.25. Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível C Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível C Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível B Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível B Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível B Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível B Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível B Diretrizes para Implementação MPT.BR Nível 1 em Empresas que possuem o MR-MPS-SW Nível A Diretrizes para Implementação MPT.BR Nível 2 em Empresas que possuem o MR-MPS-SW Nível A Diretrizes para Implementação MPT.BR Nível 3 em Empresas que possuem o MR-MPS-SW Nível A Diretrizes para Implementação MPT.BR Nível 4 em Empresas que possuem o MR-MPS-SW Nível A Diretrizes para Implementação MPT.BR Nível 5 em Empresas que possuem o MR-MPS-SW Nível A Conclusão Conclusão Referências Bibliográficas ANEXO I MAPEAMENTO DOS MODELOS MR-MPS-SW E MPT.BR I.1. Processo Gerência de Projetos (GPR) (MR-MPS-SW) x

11 I.2. Processo Gerência de Requisitos (GRE) (MR-MPS-SW) I.3. Processo Gerência de Configuração (GCO) (MR-MPS-SW) I.4. Processo Garantia da Qualidade (GQA) (MR-MPS-SW) I.5. Processo Medição (MED) (MR-MPS-SW) I.6. Processo Definição do Processo Organizacional (DFP) (MR-MPS-SW) I.7. Avaliação e Melhoria do Processo Organizacional (AMP) (MR-MPS-SW). 252 I.8. Processo Gerência de Recursos Humanos (GRH) (MR-MPS-SW) I.9. Gerência de Reutilização (GRU) (MR-MPS-SW) I.10. Processo Verificação (VER) (MR-MPS-SW) I.11. Processo Validação (VAL) (MR-MPS-SW) I.12. Atributos dos Processos (APs) e Resultados dos Atributos dos Processos (RAPs) (MR-MPS-SW) xi

12 ÍNDICE DE FIGURAS Figura 1: Componentes do Modelo MPS (SOFTEX, 2012a)... 6 Figura 2: Níveis de Maturidade dos Modelos (ARAUJO, 2014) Figura 3: Estrutura Interna dos Modelos (ARAUJO, 2014) Figura 4: Modelo de formulário para o Mapeamento MR-MPS-SW e MPT.Br (ARAUJO, 2014) Figura 5: Modelo de formulário para mapear os Resultados dos Atributos de Processos do MR-MPS-SW e as Práticas Genéricas do MPT.Br (ARAUJO, 2014) Figura 6: Exemplo do Mapeamento do GPR 1 (ARAUJO, 2014) xii

13 ÍNDICE DE TABELAS Tabela 1: Níveis de Maturidade do MR-MPS-SW (SOFTEX, 2012a) Tabela 2: Níveis de Maturidade do MPT.Br (SOFTEX RECIFE, 2011a) Tabela 3: Processos do MR-MPS-SW e Áreas de Processos do MPT.Br (ARAUJO, 2014) xiii

14 1. Introdução Este capítulo apresenta uma breve discussão sobre processos de software, descrevendo o que são, qual a importância desses processos para uma organização e a necessidade de garantir a qualidade da execução desses processos. Na seção 1.2 é apresentada a motivação e o objetivo deste trabalho, por fim na seção 1.3 é descrita a organização do trabalho Processos de Software Ao desenvolver um produto de software, cada organização segue um conjunto de passos que resultarão no produto construído. Entretanto, por cada organização seguir o seu próprio método não havia como garantir a qualidade dos produtos gerados. Sendo assim, foram criados padrões para os passos tomados pelas organizações. Esses padrões foram consolidados em normas internacionais, como as ISO/IEC 12207:2008 [ISO/IEC, 2008a], ISO/IEC 20000:2011 [ISO/IEC, 2011] e ISO/IEC ISO/IEC [ISO/IEC, 2003]. Segundo Derniame, Kaba e Wastell (1998), o processo de software é o que define como o desenvolvimento do software será organizado, gerenciado, medido, suportado e melhorado. Com os padrões definidos, as organizações precisam buscar garantir a qualidade dos produtos gerados, pois o mercado atualmente está competitivo e os clientes são exigentes em relação a qualidade do produto que está sendo adquirido. A qualidade do produto está relacionada a qualidade do processo utilizado para desenvolvê-lo, desse modo as organizações necessitam buscar modelos de referência como o MPS.BR 1

15 (Melhoria de Processo de Software Brasileiro) e o MPT.Br (Melhoria de Processo de Teste) para garantir a melhoria dos seus processos de desenvolvimento e teste de software. Ao implementarem esses modelos, as organizações conseguem passar para os clientes, indicadores da qualidade dos seus produtos e também conseguem se destacar dos concorrentes que não possuem tais modelos implementados, ganhando assim vantagem no mercado. Segundo Rodrigues e Kirner (2010), buscar a melhoria dos processos faz a organização adquirir alguns benefícios como: melhor distribuição das atividades; melhor alocação dos recursos; aumento da produtividade; melhor organização e controle dos projetos; melhor precisão no cumprimento de prazos e custos; comprometimento da alta gerência; consultoria externa competente; disponibilidade de recursos humanos; cultura organizacional; e apoio ferramental Motivação e Objetivo do Trabalho Atualmente muitas organizações por razão de mercado ou por exigência de seus clientes necessitam implementar mais de um modelo de processos. Um problema que se apresenta é, então, como realizar implementações conjuntas sem redundâncias desnecessárias que geram aumento de custo e no tempo de implementação. Atualmente, no Brasil, muitas empresas que possuem implementado o modelo MPS-SW (Modelo de Referência MPS para Software) têm a necessidade de implementar, também, o modelo MPT.Br (Melhoria do Processo de Teste Brasileiro). Um trabalho anterior realizado na COPPE/UFRJ (ARAUJO, 2014) realizou o mapeamento entre os modelos MR-MPS-SW e MPT-Br. Este trabalho, no entanto se 2

16 limitou a realizar o mapeamento entre os dois modelos sem definir diretrizes para a implementação do MPT.Br em empresas que já possuem algum nível MPS. Estabelecer estas diretrizes é, portanto, o objetivo deste trabalho Organização do Trabalho Este trabalho consta de mais 3 capítulos além desta Introdução. No Capítulo 2, são descritos os modelos de referência MR-MPS-SW e MPT.Br e o mapeamento já realizado entre os dois modelos. O capítulo 3 contém as diretrizes definidas para a implementação do MPT.Br em empresas que já possuem implementado algum nível do MR-MPS-SW. Por fim, no Capítulo 4 é apresentada uma conclusão. 3

17 2. Os Modelos de Referência MPS-SW e MPT.Br Esse capítulo tem o propósito de descrever modelos de referência MR-MPS-SW e MPT.Br e um mapeamento realizado entre os dois modelos em trabalho anterior. Na seção 2.1 está descrito o modelo MR-MPS-SW de acordo com o Guia Geral do MPS- SW (SOFTEX, 2012a). Já a seção 2.2 contém a descrição do modelo MPT.Br de acordo com o Guia Geral do MPT.BR (SOFTEX RECIFE, 2011a). Na seção 2.3 está apresentado o mapeamento entre os dois modelos de acordo com o trabalho realizado por Araujo (ARAUJO, 2014) O Modelo de Referência MR-MPS-SW O Programa MPS.BR (Melhoria de Processo de Software Brasileiro) é um programa coordenado pela SOFTEX (Associação para Promoção da Excelência do Software Brasileiro), com o apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI), da Financiadora de Estudos e Projetos (FINEP), do Banco Interamericano de Desenvolvimento (BID/FUMIN) e do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE). Criado em 2003, seu objetivo é promover a melhoria no processos de software das empresas brasileiras e no processo de oferta de serviços. Essas melhorias qualificam as empresas nacionais a disputar o mercado com as empresas do exterior e aumentam as chances de exportação de produtos de software nacionais. Nas empresas que decidem por implementar o MPS, tal implementação é feita, na maioria das vezes, através de uma Instituição Implementadora (II) credenciada pela SOFTEX. Após a implementação são submetidas a uma avaliação, que é feita por 4

18 uma Instituição Avaliadora (IA) obrigatoriamente credenciada pela Softex. Como resultado da avaliação lhes é atribuído um nível de maturidade em software ou em serviços. O MPS.BR possui como referências técnicas as Normas Internacionais ISO/IEC 12207:2008 [ISO/IEC, 2008a], ISO/IEC 20000:2011 [ISO/IEC, 2011], ISO/IEC ISO/IEC [ISO/IEC, 2003] e o modelo CMMI-DEV (Capability Maturity Model Integration for Development) [SEI, 2010a]. Ele é composto por quatro componentes, são eles: o Modelo de Referência para Software (MR-MPS-SW), o Modelo de Referência MPS para Serviços (MR-MPS-SV), o Método de Avaliação (MA-MPS) e o Modelo de Negócio para Melhoria de Processo de Software e Serviços. A Figura 1 ajuda a entender como essas referências e componentes estão organizados em relação ao MPS. Nesse trabalho, a parte do MPS.BR que estará em foco é o Modelo de Referência MPS para Software (MR-MPS-SW), mas para entendê-lo precisamos primeiro conhecer os conceitos que formam a sua base. Para avaliar e promover a melhoria da qualidade e produtividade de software, o MR-MPS-SW trabalha com os conceitos de maturidade e capacidade de processo. Estes são abordados seguindo a ideia de Níveis de Maturidade, que agrupam diferentes grupos de processos e requisitos que as empresas devem cumprir para estarem aderentes ao MR-MPS-SW em um determinado nível. A capacidade do processo está relacionada ao modo como são executados os processos associados a cada nível de maturidade e estão de acordo com os níveis de capacidade da norma ISO/IEC [ISO/IEC, 2003]. 5

19 Figura 1. Componentes do Modelo MPS (SOFTEX, 2012a) O Modelo de Referência MR-MPS-SW está organizado em sete níveis de maturidade: Nível G - Parcialmente Gerenciado: o processo é executado; Nível F - Gerenciado: o processo e os produtos de trabalho são gerenciados; Nível E - Parcialmente Definido: o processo está parcialmente definido e implementado; Nível D - Largamente Definido: o processo está largamente definido e implementado; Nível C - Definido: o processo está definido e implementado; Nível B - Gerenciado Quantitativamente: o processo é medido e controlado; 6

20 Nível A - em Otimização: o processo é objeto de melhorias incrementais e inovações e é otimizado continuamente. Essa escala se inicia no nível G e progride até o nível A. Os níveis de maturidade indicam onde a empresa deve colocar o esforço de melhoria para subir de nível. Um nível é concluído quando todos os resultados esperados dos processos e atributos de processos são atendidos. A capacidade do processo está relacionada aos Atributos de Processo (AP) e aos Resultados Esperados dos Atributos de Processo (RAP) pertencentes a um dado nível de maturidade. Essa capacidade reflete quão bem o processo é executado e se ele é adotado em toda a organização. Os níveis de maturidade do MR-MPS-SW são acumulativos, ou seja, se uma empresa está no nível E, isso significa que ela tem implementados os processos e os atributos de processo dos níveis E, F e G. Os Atributos de Processo (AP) que devem ser implementados estão definidos no Guia Geral do MPS (SOFTEX, 2012), onde também podem ser encontrados os Resultados Esperados (RAP) para cada AP. AP 1.1 O processo é executado: Este atributo evidencia o quanto o processo atinge o seu propósito. Relacionado a este atributo de processo tem-se o seguinte resultado esperado: - RAP 1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado: Este atributo evidencia o quanto a execução do processo é gerenciada. Relacionado a este atributo de processo tem-se os seguintes resultados 7

21 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). 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. As informações e os recursos necessários para execução do processo são identificados e disponibilizados; - RAP 6. (Até o nível F). 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; - RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; - RAP 8. A comunicação entre as partes interessadas no processo é planejada e executada de forma a garantir o seu envolvimento; - RAP 9. (Até o nível F) 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). O processo planejado para o projeto é executado; 8

22 - 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 evidencia o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. Relacionado a este atributo de processo tem-se os seguintes 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 evidencia o quanto um processo padrão é amntido para apoiar a implementação do processo definido. Relacionado a este atributo de processo tem-se os seguintes resultados esperados: - RAP 15. Um processo padrão é descrito, incluindo diretrizes para sua adaptação; - RAP 16. A sequência e interação do processo padrão com outros processos são determinadas; 9

23 - 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 evidencia o quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. Relacionado a este atributo de processo tem-se os seguintes resultados esperados: - RAP 19. Um processo definido é implementado 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, contituindo 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. AP 4.1 O processo é medido: Este atributo evidencia o 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. Relacionado a este atributo de processo tem-se os seguintes resultados esperados: - RAP 22. As necessidade de informação dos usuários dos processos, requeridas para apoiar objetivos de negócio relevantes da organização, são identificadas; 10

24 - RAP 23. Objetivos de medição organizacionais dos processos e/ou subprocessos são derivados das necessidades de informação dos usuários do processo; - RAP 24. Objetivos quantitativos organizacionais de qualidade e de desempenho dos processos e/ou subprocessos são definidos para apoiar os objetivos de negócio; - RAP 25. Os processos e/ou subprocessos que serão objeto de análise de desempenho são selecionados a partir do conjunto de processos padrão da organização e das necessidades de informação dos usuários dos processos; - RAP 26. 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 27. Resultados das medições são coletados, analisados, utilizando técnicas estatísticas e outras técnicas quantitativas apropriadas, e são comunicados para monitorar o alcance dos objetivos quantitativos de qualidade e de desempenho do processo/subprocesso; - RAP 28. Resultados de medição são utilizados para caracterizar o desempenho do processo/subprocesso. - RAP 29. Modelos de desempenho do processo são estabelecidos e mantidos. AP 4.2 O processo é controlado: Este atributo evidencia o quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos. 11

25 Relacionado a este atributo de processo tem-se os seguintes resultados esperados: - RAP 30. Técnicas de análise e de controle para a gerência quantitativa dos processos/subprocessos 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 e preventivas são realizadas para tratar causas especiais, ou de outros tipos, de variação; - RAP 34. Limites de controle são restabelecidos, quando necessário, seguindo as ações corretivas, de forma que os processos continuem estáveis, capazes e previsíveis. AP 5.1 O processo é objeto de melhorias incrementais e inovações: Este atributo evidencia o 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. Relacionado a este atributo de processo tem-se os seguintes resultados esperados: - RAP 35. Objetivos de negócio da organização são mantidos com base no entendimento das estratégias de negócio e resultados de desempenho do processo; 12

26 - RAP 36. Objetivos de melhoria do processo são definidos com base no entendimento do desempenho do processo, de forma a verificar que os objetivos de negócio relevantes são atingíveis; - RAP 37. Dados que influenciam o desempenho do processo são identificados, classificados e selecionados para análise de causas; - RAP 38. Dados selecionados são analisados para identificar causas raiz e propor soluções aceitáveis para evitar ocorrências futuras de resultados similares ou incorporar melhores práticas no processo; - 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 com impacto no alcance dos objetivos de negócio; - RAP 41. Oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo são identificadas, avaliadas e selecionadas com base no impacto no alcance dos objetivos de negócio; - RAP 42. Uma estratégia de implementação para as melhorias selecionadas é estabelecida para alcançar os objetivos de melhoria do processo e para resolver problemas. AP 5.2 O processo é otimizado continuamente: Este atributo evidencia o 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. Relacionado a este atributo de processo tem-se os seguintes resultados esperados: 13

27 - 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 uso de técnicas estatísticas e outras técnicas quantitativas, para verificar se as mudanças no processo corrigiram o problema e melhoraram o seu desempenho; - RAP 46. Dados da análise de causas e de resolução são armazenados para uso em situações similares. A Tabela 1 a seguir mostra como estão distribuídas as áreas de processos e os atributos de processos pelos níveis de maturidade do MR-MPS-SW. Como pode-se observar na Tabela 1, o MR-MPS-SW define dezenove processos, que são agrupados nos sete níveis de maturidade. Esses processos estão especificados através de propósito e resultados esperados. O objetivo geral do processo é definido pelo seu propósito, já os requisitos que a organização deve cumprir estão especificadas nos resultados esperados do processo. 14

28 Nível de Maturidade Tabela 1: Níveis de maturidade do MR-MPS-SW (SOFTEX, 2012a) Processos Atributos de Processo A AP 1.1. AP 2.1, AP 2.2. AP 3.1, AP 3.2. AP 4.1, AP 4.2. AP 5.1, AP 5.2. B Gerência de Projetos (GPR 22-28) AP 1.1. AP 2.1, AP 2.2. AP 3.1, AP 3.2. AP 4.1, AP 4.2. C Gerência de Riscos (GRI) Desenvolvimento para Reutilização (DRE) Gerência de Decisões (GRD) D Verificação (VER) Validação (VAL) Projeto e Construção do Produto (PCP) Integração do Produto (ITP) Desenvolvimento de Requisitos (DRE) E Gerência de Projetos (GPR 20-22) Gerência de Reutilização (GRU) Gerência de Recursos Humanos (GRH) Definição de Processo Organizacional (DFP) Avaliação e Melhoria do Processo Organizacional (AMP) F Medição (MED) Garantia da Qualidade (GQA) Gerência de Portfólio de Projetos (GPP) Gerência de Configuração (GCO) Aquisição (AQU) G Gerência de Projetos (GPR 1-19) Gerência de Requisitos (GRE) AP 1.1. AP 2.1, AP 2.2. AP 3.1, AP 3.2. AP 1.1. AP 2.1, AP 2.2. AP 3.1, AP 3.2. AP 1.1. AP 2.1, AP 2.2. AP 3.1, AP 3.2. AP 1.1. AP 2.1, AP 2.2. AP 1.1. AP 2.1. Nota: Os atributos de processo AP 4.1, AP 4.2, AP 5.1 e AP 5.2 somente devem ser implementados para os processos críticos da orgnização/unidade organizacional, selecionados para análise de desempenho. Os demais atributos de processo devem ser implementados para todos os processos. (SOFTEX, 2012a) Os processos definidos segundo o Guia Geral do MPS-SW (SOFTEX, 2012), em ordem alfabética, são: Avaliação e Melhoria do Processo Organizacional (AMP): O processo Avaliação e Melhoria do Processo Organizacional é responsável por avaliar o quanto os processos padrões da organização ajudam a atingir os 15

29 objetivos estratégicos da mesma. Desse modo, o processo auxilia a organização a planejar e realizar melhorias contínuas nos processos executados. O processo AMP é exigido a partir do Nível E. Aquisição (AQU): O processo Aquisição é responsável por gerenciar a aquisição de produtos, os quais devem satisfazer os objetivos desejados pelo adquirente. Por exemplo, são definidos critérios de aceitação do produto, bem como qual tipo e estratégia de aquisição que serão realizados. O processo AQU é exigido a partir do Nível F. Definição do Processo Organizacional (DFP): O processo Definição do Processo Organizacional tem como objetivo definir e manter um conjunto de ativos de processos padrão para a organização, que deve estar alinhado com as suas necessidades de negócio. O processo DFP é exigido a partir do Nível E. Desenvolvimento de Requisitos (DRE): O processo Desenvolvimento de Requisitos é responsável por identificar e definir os requisitos dos clientes, do produto e de componentes do produto. Esses requisitos são gerados a partir das necessidades, expectativas e restrições identificadas. O processo DRE é exigido a partir do Nível D. Desenvolvimento para Reutilização (DRU): O processo Desenvolvimento para Reutilização tem como objetivo identificar as oportunidades para a reutilização de ativos na organização. Nesse processo o 16

30 foco não são apenas os trechos de códigos e componentes de software, mas sim todo ativo que possa ser reutilizado na organização. Também é desejável a definição de um programa de reutilização para o desenvolvimento de ativos reutilizáveis a partir de engenharia de domínios de aplicação. O processo DRU é exigido a partir do Nível C. Garantia da Qualidade (GQA): O processo Garantia da Qualidade é responsável por garantir que produtos de trabalho e a execução dos processos estão de acordo com os padrões estabelecidos. O processo GQA é exigido a partir do Nível F. Gerência de Configuração (GCO): O processo Gerência de Configuração é responsável por documentar e manter íntegros os produtos de trabalho gerados durante um projeto ou processo. Por exemplo, é estabelecido como os itens de configuração serão armazenados, manuseados e um mecanismo de controle para modificações. O processo GCO é exigisdo a partir do Nível F. Gerência de Decisões (GDE): O processo Gerência de Decisões tem como função analisar possíveis decisões críticas através de um processo formal definido, para que as alternativas identificadas sejam avaliadas através de critérios estabelecidos. A implementação deste processo incluiu a definição de guias organizacionais para a gerência de decisões. O processo GDE é exigido a partir do Nível C. 17

31 Gerência de Portfólio de Projetos (GPP): O processo Gerência de Portfólio de Projetos é responsável por controlar quais projetos são necessários, suficientes e sustentáveis para que a organização consiga atingir os seus objetivos de mercado. A importância desse processo está ligada ao não comprometimento com projetos que não sejam rentáveis ou que tragam prejuízos e desperdícios de recursos para a organização. O processo executa uma qualificação contínua de projetos para garantir que eles justificam os investimentos que estão sendo feitos.. O processo GPP é exigido a partir do Nível F. Gerência de Projetos (GPR): O processo Gerência de Projetos é o responsável por definir e manter os planos de atividades, os recursos e responsabilidades do projeto. O acompanhamento do projeto e correções necessárias no seu decorrer também são realizadas com a implementação deste processo. O GPR evolui à medida que aumentam os níveis de maturidade. No Nível G são requeridos os resultados esperados do GPR 1 até o GPR 19. Já no Nível E são necessários também os resultados GPR 20 a GPR 22, pois agora a gerência de projeto leva em consideração o processo definido para o projeto e os planos integrados. No Nível B a gerência de projetos passa a ter um enfoque quantitativo para refletir a alta maturidade da organização e são implementados os resultados GPR 22 a GPR 28. Gerência de Requisitos (GRE): O processo Gerência de Requisitos é o responsável por gerir os requisitos do produto, dos componentes do produto e do projeto. Verificar se existem 18

32 inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos fornecidos e/ou identificados, também é responsabilidade desse processo. O processo GRE é exigido desde o Nível G. Gerência de Recursos Humanos (GRH): O processo de Gerência de Recursos Humanos é o responsável por gerir e alocar os recursos humanos para os projetos de forma a atender as necessidades do negócio, treinar a equipe da organização e ter procedimentos para gerência do conhecimento organizacional. O processo GRH é exigido a partir do Nível E. Gerência de Riscos (GRI): O processo Gerência de Riscos é reponsável por identificar, analisar, tratar, monitorar e reduzir riscos, sejam eles da organização ou de um projeto específico. Nesse processo os riscos são classificados e priorizados de acordo com critérios definidos, assim é possível decidir quais os riscos devem ser mitigados primeiro. O processo GRI é exigido a partir do Nível C. Gerência de Reutilização (GRU): O processo Gerência de Reutilização é responsável por gerir o ciclo de vida de ativos reutilizáveis. A definição do que é um ativo reutilizável para a organização é uma parte importante desse processo. O processo GRU é exigido a partir do Nível E. 19

33 Integração do Produto (ITP): O processo Integração do Produto tem como objetivo integrar os componentes do produto e formar um produto integrado que está de acordo com o projeto desenvolvido. Também é responsabilidade do ITP garantir que os requisitos funcionais e não-funcionais foram satisfeitos para o ambiente alvo ou para um ambinete de teste equivalente ao ambiente do cliente. O processo ITP é exigido a partir do Nível D. Medição (MED): O processo de Medição é responsável por gerar evidências que mostrem quantitativamente em que estado se encontram os processos executados e os produtos desenvolvidos na organização. Isso é feito através da coleta, armazenamento, análise e relatórios dos dados gerados pelos processos implementados e produtos gerados. A partir dos resultados destas medições devem ser tomadas decisões na organização. O processo MED é exigido a partir do Nível F. Projeto e Construção do Produto (PCP): O processo Projeto e Construção do Produto é responsável por gerar o projeto (design) do produto, assim como desenvolver e implementar a solução que atenda os requisitos desenvolvidos ou recebidos. Uma atribuição do processo é realizar uma análise sobre os componentes do produtos, decidindo se um componente deve ser comprado, reutilizado ou construído. O processo PCP é exigido a partir do Nível D. 20

34 Validação (VAL): O processo Validação tem como objetivo confirmar que o produto ou componente desenvolvido conseguirá atender o seu uso prentendido no ambiente do cliente. O processo VAL é exigido a partir do Nível D. Verificação (VER): O processo Verificação é responsável por confirmar se os produtos de trabalho gerados estão de acordo com os requisitos especificados. Diferente do processo GQA, que se preocupa com a forma dos artefatos, o VER se preocupa com o conteúdo dos mesmos. Testes e revisões por pares podem ser utilizados para verificar se um produto de trabalho está de acordo com os requisitos. O processo VER é exigido a partir do Nível D. O MR-MPS-SW pode ser implementado em diferentes tipos de organização, por exemplo, uma fábrica de software, uma fábrica de teste ou mesmo uma empresa que não desenvolve mas adquire software. Para esses diferentes tipos de instituição a implementação do MR-MPS-SW pode ser personalizada, isso significa que alguns resultados esperados podem ser excluídos dado o objetivo da empresa. Para empresas do tipo Fábrica de Teste, o MPS.BR possui o Guia de Implementação Parte 10 (SOFTEX, 2011a), que aborda as características específicas da implementação do MR- MPS-SW nesse tipo de organização. 21

35 2.2. O Modelo de Referência MPT.Br O modelo MPT.Br (Melhoria de Processo de Teste) é gerenciado pela SOFTEX- RECIFE (Centro de Tecnologia de Software para Exportação do Recife), e pela RIOSOFT (Sociedade Núcleo de Apoio à Produção e Exportação de Software do Rio de Janeiro), ambos agentes SOFTEX. O modelo MPT.Br tem como objetivo estimular o uso de melhores práticas durante as atividades do ciclo de vida de teste do produto, para assim melhorar o processo de teste da organização. Os objetivos do modelo, segundo o Guia de Referência do Modelo MPT.Br (SOFTEX-RECIFE, 2011), são: Tornar-se um modelo de referência para definição, implantação e melhoria dos processos de teste; Abordar a melhoria contínua nos processos de teste conforme os objetivos organizacionais e nível de maturidade almejado; Fornecer uma base para avaliação e consequente identificação do grau de maturidade presente nas organizações; e Reunir as melhores práticas e estruturá-las segundo o grau de complexidade versus o nível de maturidade que a mesma estará relacionada. O MPT.Br foi definido tendo como bases técnicas alguns modelos de referência em teste de software, como Testing Maturity Model Integration (TMMi) (TMMi Foundation, 2012) e o Test Process Improvement (TIP) (Koomen e Pol, 1997), e modelos de referência em melhoria de processo de software, como o CMMi-DEV (SEI, 22

36 2010a) e o MR-MPS-SW (SOFTEX, 2012). O modelo MPT.Br é composto por dois componentes, são eles: o modelo de referência, que mostra a estrutura, as áreas de processo e as práticas do modelo; e o guia de avaliação, que possui as instruções e os processos necessários para que a avaliação de uma organização com base no MPT.Br seja realizada. O modelo também é dividido em Níveis de Maturidade como o MR-MPS-SW, entretanto existem menos níveis no MPT. Seguindo o Guia de Referência do MPT.Br (SOFTEX-RECIFE, 2011), os níveis são: Nível 1 Parcialmente gerenciado: No primeiro nível de maturidade estão contidos os requisitos mínimos que a organização deve executar para demonstrar que a disciplina de teste é aplicada nos projetos. Também é necessário demonstrar que essa aplicação ocorre de forma planejada e controlada. Nível 2 Gerenciado: Nesse nível de maturidade existe uma maior visibilidade para a aplicação do processo de teste. Os processos passam a ser monitorados e padrões são definidos. O escopo do projeto agora é controlado pelo processo de gestão de mudanças. Nível 3 Definido: O processo de teste torna-se organizacional. São adotados processos padrões, a garantia da qualidade é instituída com o objetivo de auxiliar na definição dos processos, um programa de medição é implantado na organização e responsabilidades são definidas para a organização do teste. Neste nível o ciclo de vida de teste é integrado ao ciclo de vida de desenvolvimento. Nível 4 Prevenção de defeitos: O foco passa a ser a melhoria sistemática da qualidade do produto e a prevenção de defeitos. Um processo de gestão de defeitos existe, ou seja, quando um defeito é identificado no ciclo de vida, ações são tomadas para mitigá-lo e prevenir que novos defeitos com a mesma causa 23

37 raiz apareçam. Também são realizadas análises de riscos dos atributos nãofuncionais e atividades de teste que visam minimizar tais riscos. Nível 5 Automação e Otimização: O foco desse nível é estabelecer um processo de melhoria contínua e automação do teste. Existe, por exemplo, uma abordagem sistemática para escolha de ferramentas CASE. Os níveis do MPT.Br são compostos por um conjunto de áreas de processos, que representam um agrupamento de práticas que devem ser implementadas pela organização para atingir um objetivo. Existem dois tipos de práticas, as práticas genéricas, que devem ser aplicadas a cada área de processo do nível de maturidade desejado, e as práticas específicas, que são diferentes para cada área de processo. Assim como no MR-MPS-SW, os níveis de maturidade no MPT.Br são acumulativos, então para uma organização chegar ao Nível 3 ela precisa ter implementado todas as práticas genéricas e específicas das áreas de processos dos Níveis 1 e 2. As práticas, específicas e genéricas, são compostas por seis componentes e estruturadas da seguinte maneira (SOFTEX-RECIFE, 2011): 1. Identificador: Apresenta um identificador da prática específica, uma abreviatura; 2. Nome: Apresenta o nome da prática específica; 3. Objetivo: Dentro de uma caixa cinza, apresenta um resumo sobre o objetivo da prática específica; 4. Texto Informativo: Apresenta alguns conceitos relacionados à area de processo. Pode conter alguma dicas para aplicação da prática. 24

38 5. Produtos típicos: Apresenta sugestões de produtos de trabalho que geralmente são os resultados esperados da prática ou que contém as informações pedidas por ela. 6. Elaborações: No caso de uma prática genérica, as elaborações são instruções para aplicação da prática a cada área de processo. As Práticas Genéricas (PGs) que devem ser atendidas pelas organizações estão completamente definidas no Guia de Referência do MPT.Br e aqui serão apresentados os seus objetivos: PG1 Atingir os resultados definidos: O objetivo desta prática genérica é gerar os produtos de trabalho e fornecer os serviços que são esperados a partir da execução do processo. PG2 Estabelecer uma política organizacional: O objetivo desta prática é estabelecer e manter uma política organizacional para o processo. PG3 Planejar a execução do processo: Esta prática objetiva a definição de como será executado um determinado processo. 25

39 PG4 Identificar e disponibilizar recursos: O objetivo desta prática é garantir que os recursos indispensáveis para executar o processo serão identificados previamente e estarão disponíveis quando forem necessários. PG5 Definir responsabilidade e autoridade: O objetivo desta prática é definir, atribuir e comunicar as responsabilidades para executar o processo, definindo também a autoridade. PG6 Prover treinamento: O objetivo desta prática é garantir que as pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. PG7 Controlar produtos de trabalho (a partir do Nível 2): O objetivo desta prática genérica é estabelecer e manter a integridade de produtos de trabalho do processo ao longo do ciclo de vida dos mesmos, através de níveis de controle. PG8 Monitorar e controlar o processo (a partir do Nível 2): O objetivo desta prática é monitorar e controlar a execução dos processos conforme o que foi planejado. 26

40 PG9 Fornecer visibilidadea do processo para a gerência superior (a partir do Nível 2): O objetivo desta prática genérica é proporcionar visibilidade apropriada do processo para a gerência de nível superior. A Tabela 2 a seguir mostra como estão distribuídas as áreas de processo e as práticas genéricas pelos níveis de maturidade do MPT.Br. Tabela 2: Níveis de maturidade do MPT.Br (SOFTEX-RECIFE, 2011a) Nível de Áreas de Processo Maturidade 1 Gerência de Projetos de Teste (GPT 1-20) Projeto e Execução de Teste (PET 1-4) 2 Gerência de Projetos de Teste (GPT 21-25) Gerência de Requisitos de Teste (GRT) Projeto e Execução de Teste (PET 5-6) 3 Fechamento de Teste (FDT) Garantia da Qualiadade (GDQ) Gerência de Projetos de Teste (GPT 26-28) Medição e Análise de Teste (MAT) Organização do Teste (OGT 1-10) Projeto e Execução de Teste (PET 7) Teste de Aceitação (TDA) Teste Estático (TES) Treinamento (TRE) 4 Avaliação da Qualidade do Produto (AQP) Gestão de Defeitos (GDD) Organização do Teste (OGT 11-12) Teste Não-Funcional (TNF) 5 Automação da Execução do Teste (AET) Controle Estatístico do Processo (CEP) Gestão de Ferramentas (GDF) Práticas Genéricas PG1 a PG6 PG1 a PG9 PG1 a PG9 PG1 a PG9 PG1 a PG9 27

41 Como observa-se na Tabela 2, o MPT.Br define dezesseis Áreas de Processo, que são agrupadas nos cinco níveis de maturidade. Essas áreas são estruturadas a partir de seis componentes da seguinte maneira: 1. Identificador: Apresenta um identificador da área de processo, uma abreviatura; 2. Nome: Apresenta o nome da área de processo; 3. Objetivo: Dentro de uma caixa cinza, apresenta um resumo sobre o objetivo da área de processo, que será alcançado através das práticas específicas da área; 4. Texto Informativo: Apresenta alguns conceitos relacionados à area de processo. 5. Lista de práticas específicas: Apresenta a listagem das siglas e títulos das práticas específicas que compõem a área de processo. 6. Práticas específicas: Apresenta um detalhamento de cada prática específica que faz parte daquela área de processo. No Guia de Referência do MPT.Br estão definidas as Áreas de Processo, as quais possuem objetivos que serão alcançados através da implementação das Práticas Específicas (PEs) de cada área. Aqui serão apresentadas cada área bem como seus objetivos e identificadores, em ordem alfabética: Automação da Execução do Teste (AET): O objetivo dessa área de processo é estabelecer e manter uma estratégia para a automação da execução de teste. Isso inclui definir objetivos, elaborar um framework e analisar o Retorno do investimento na automação de teste. A execução de casos de teste é uma das tarefas que são alvos da automação. A implementação da área de processo AET é exigida apenas no Nível 5. 28

42 Avaliação da Qualidade do Produto (AQP): Essa área de processo é responsável por definir quais os objetivos quantitativos de qualidade para o produto e fornecer os meios para que esses objetivos sejam atingidos. Vale destacar o relacionamento dessa área com a Medição e Análise de Teste, que fornece os mecanismos e infraestrutura necessários para a medição da qualidade do produto. A implementação da área de processo AQP é exigida a partir do Nível 4. Controle Estatístico do Processo (CEP): Essa área de processo tem o objetivo de gerenciar e controlar estatisticamente o desempennho dos processos. O controle estatístico é importante para organizações de alta maturidade, que necessistam saber o comportamento de seus processos, pois é um dos meios de analisar os processos e conhecer tais comportamentos. Entretanto, nem todos os processos da organização devem ser colocados sobre esse controle, pois ele necessita de muito esforço e recursos para ser executado. A implementação da área de processo CEP é exigida apenas no Nìvel 5. Fechamento do Teste (FDT): O objetivo dessa área de processo é organizar e tornar sistemático os procedimentos adotados para finalizar o teste do software. Quando um teste é finalizado e os critérios de saída estão satisfeitos, então aquela fase ou tipo de teste pode ser encerrado, isso significa, por exemplo, que os ativos de teste devem ser armazenados e os resultados do teste devem ser documentados e 29

43 reportados aos stakeholders relevantes. A implementação da área de processo FDT é exigida a partir do Nível 3. Gestão de Defeitos (GDD): A área de processo Gestão de Defeitos é responsável por gerenciar ações preventivas para as causas raiz dos defeitos. Aqui análises são feitas para identificação das causas raiz dos defeitos encontrados. Também deve ocorrer a priorização e seleção, de acordo com custo da correção, das causas para que planos de ações sejam estabelecidos. A implementação da área de processo GDD é exigida a partir do Nível 4. Gestão de Ferramentas (GDF): O objetivo dessa área de processo é gerenciar a identificação, análise, seleção e implantação de ferramentas na organização. A utilização de uma ferramenta de software pode trazer muitas benefícios à produtividade de uma organização, mas é neessário uma boa gestão dessas ferramentas, pois a aquisição de uma ferramenta também pode trazer prejuízos, por exemplo a incompatibilidade com outros softwares já utilizados ou a ausência de suporte por parte dos fornecedores. Evitar esses problemas é responsabilidade da área de processo GDF e isso é feito através da análise da real necessidade de uma ferramenta, seleção entre as opções disponíves e avaliação da efetividade da ferramenta após a sua implantação. A implementação da área de processo GDF é exigida a partir do Nível 5. 30

44 Garantia da Qualidade (GDQ): Essa área de processo é responsável por estabelecer um mecanismo de avaliação de processos e produtos de trabalho. O foco da Garantia da Qualidade é avaliar os produtos de trabalho e processos e garantir que eles possuem aderência aos procedimentos e padrões adotados pela organização. É importante que a avaliação seja executada de forma objetiva, seguindo critérios definidos e feita por pessoas independentes do projeto, para evitar conflitos de interesse. A implementação da área de processo GDQ é exigida a partir do Nível 3. Gerência de Projetos de Teste (GPT): O objetivo dessa área de processo é estabelecer e manter os planos para gerenciar, monitorar e controlar as atividades até o encerramento do projeto. Aqui é definido um Plano de Teste, que deve conter os objetivos do teste, o escopo do teste e a estratégia de teste. O plano também deve apresentar uma análise de risco do produto e do projeto. Um cronograma deve ser elaborado. Uma vez que o plano tenha sido estabelecido, ele deve ser monitorado para o caso de no decorrer do projeto discrepâncias sejam encontradas. A implementação da área de processo GPT é exigida a partir do Nível 1. Gerência de Requisitos de Teste (GRT): Essa área de processo é responsável por fornecer subsídios para gerenciar os requisitos do projeto de teste, identificar inconsistências entre estes, os planos e produtos de trabalho do projeto. Para garantir que não existem inconsistências, os requisitos, sejam eles gerados ou recebidos, devem ser aprovados junto aos 31

45 fornecedores de requisitos e caso ocorram alterações nos requisitos estas devem passar por um procedimento definido para gestão de mudanças. Também é importante manter a rastreabilidade bidirecional entre o requisito e os produtos de trabalho relacionados a ele, o que permite quantificar o impacto que uma mudança de requisito irá gerar nos demais produtos do projeto. A implementação da área de processo GRT é exigida a partir do Nível 2. Medição e Análise de Teste (MAT): O objetivo dessa área de processo é desenvolver e sustentar uma capacidade de medição utilizada para dar suporte às necessidades de informação gerenciais relacionadas ao teste. A implementação da área de processo MAT é exigida a partir do Nível 3. Organização do Teste (OGT): O objetivo dessa área de processo é definir a estrutura do teste dentro da organização. Com a implementação dessa área são tratados os aspectos ligados à institucionalização do processo de teste. A definição de processos padrões de teste também ocorre como requisito de OGT, assim como a definição de regras para sua adaptação e evolução a partir da definição e implantação de ações de melhorias. OGT também é responsável pela integração do ciclo de vida do teste ao ciclo de vida do desenvolvimento do software. A implementação da área de processo OGT é exigida a partir do Nível 3. 32

46 Projeto e Execução do Teste (PET): Essa área de processo tem como objetivo identificar, elaborar e executar casos de teste, registrando a execução do teste e as divergências entre os resultados atuais e esperados na forma de incidentes. Em organizações com baixo nível de maturidade em teste, as práticas específicas dessa área visam garantir que os teste são executados corretamente, por isso não há preocupação com o uso adequado da documentação. Já em organizações com um alto nível de maturidade de teste, as práticas exigem que existam padrões de documentação e uso de técnicas formais para especificação de casos de teste. A implementação da área de processo PET é exigida a partir do Nível 1. Teste de Aceitação (TDA): O objetivo dessa área de processo é assegurar que o teste de aceitação seja planejado e executado para validar se as expectativas dos usuários estão sendo satisfeitas. O teste de aceitação é um teste formal, que visa garantir que o produto está apto para o uso, o resultado depende da decisão do cliente de aceitar ou não o produto baseado em critérios de aceitação definidos. É importante que o teste de aceitação se inicie cedo no ciclo de vida do desenvolvimento do software, pois ele permite a detecção antecipada de problemas baseado nas neessidade do usuário. A implementação da área de processo TDA é exigida a partir do Nível 3. 33

47 Teste Estático (TES): Essa área de processo é responsável por verificar se os produtos de trabalho atendem aos seus requisitos e que os defeitos sejam encontrados cedo no ciclo de vida de desenvolvimento do software. O teste estático é caracterizado pela não execução do software.a implementação da área de processo TES é exigida a partir do Nível 3. Teste Não-Funcional (TNF): O objetivo dessa área de processo é endereçar os riscos não-funcionais do produto através do teste não-funcional. Os riscos identificados devem ser analisados pelos stakeholders relevantes e uma estratégia de teste deve ser ajustada para incluir ações que mitigam esses riscos. A partir da estratégia definida, casos de teste não-funcional devem ser executados e os incidentes identificados devems er gerenciados até sua conclusão. A implementação da área de processo TNF é exigida a partir do Nível 4. Treinamento (TRE): O objetivo dessa área de processo é desenvolver habilidades e conhecimentos para que os integrantes dos projetos possam desempenhar seus papéis de modo eficiente. Essa área envolve a identificação de necessidade de treinamento estratégico para a organização, o qual deve ser elaborado para atender as necessidades da organização. A eficácia dos treinamentos deve ser observada e avaliada. A implementação da área de processo TRE é exigida a partir do Nível 3. 34

48 Algumas áreas de processo do MPT.Br possuem processos equivalentes no MR- MPS-SW e isso favorece a implementação conjunta dos dois modelos em uma organização. Outra possibilidade é o caso de uma organização que já se encontra em um determinado nível do MR-MPS-SW e opta por ser avaliada, também, no modelo MPT.Br. Tal organização já possui implementados os processos necessários para o seu nível do MR-MPS-SW e precisa saber o que necessita, de fato, implementar a mais para conseguir o nível almejado do MPT. Um primeiro passo para a decisão sobre o que necessita ser implementado, neste caso, pode ser realizado com base no mapeamento realizado entre os dois modelos (ARAUJO, 2014) e que será descrito na próxima seção Mapeamento dos Modelos MR-MPS-SW e MPT.Br Quando uma organização já possui um nível do MR-MPS-BR e decide por implementar o MPT.Br ela não precisa começar o procedimento de implementação do zero, pois os modelos possuem estruturas semelhantes. Isso significa que algumas áreas de processo, práticas específicas e genéricas do MPT.Br possuem processos, resultados esperados, atributos de processos e resultados esperados dos atributos de processos equivalentes no MR-MPS-BR. As semelhanças e diferenças entre os dois modelos foram analisadas e mapeadas em uma dissertação de mestrado da COPPE (ARAUJO, 2014). Esta seção descreve este mapeamento. O mapeamento realizado consistiu em comparar os resultados esperados dos processos do MR-MPS-SW com os objetivos das práticas específicas das áreas de processos do MPT.Br. Outra comparação realizada no mapeamento foi entre os resultados de atributos de processo do MR-MPS-SW e as práticas genéricas do MPT.Br. 35

49 Algumas questões foram analisadas para que o mapeamento pudesse ser feito, uma delas foi a direção do mapeamento, isto é, qual dos modelos seria usado como origem para a comparação. A escolha foi o MR-MPS-SW por ser mais difundido no Brasil e ser anterior ao MPT.Br. Para realização do mapeamento foram analisados os guias de ambos os modelos, são eles: o Guia Geral MPS de Software (SOFTEX, 2012a), o Guia de Implamentação para Fábrica de Teste - Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste. (SOFTEX, 2011a) e o Guia de Referência do Modelo MPT.Br (SOFTEX-RECIFE, 2011). A análise realizada identificou que o conceito de níveis de maturidade é utilizado em ambos os modelos. No MPT.Br existem apenas 5 níveis enquanto no MR-MPS-SW existem 7, entretanto os Níveis C, D e E do MPS são subdivisões que se aproximam bastante do Nível 3 do MPT. Ao observarmos a Figura 2 podemos entender melhor a similaridade entre as divisões em níveis dos modelos. Figura 2. Níveis de Maturidades dos Modelos (ARAUJO, 2014) 36

50 Outra semelhança observada entre os modelos é a estrutura interna que ambos possuem. O MR-MPS-SW é dividido em processos, que possuem resultados esperados, atributos de processos e resultados esperados dos atributos de processo. Já o MPT possui áreas de processos com suas práticas específicas e práticas genéricas. Entretanto, o as duas estruturas tem similaridade, como pode ser observado na Figura 3. Após a análise da estrutura dos dois modelos e identificação da similaridade, a autora decidiu que o mapeamento seria realizado comparando os processos do MR- MPS-SW com as áreas de processo do MPT.Br; os resultados esperados dos processos do MR-MPS-SW com as práticas específicas do MPT e os resultados dos atributos de processo do MR-MPS-SW com as práticas genéricas do MPT. Figura 3. Estrutura Interna dos Modelos (ARAUJO, 2014) Embora o mapeamento tenha mostrado que a maioria dos processos do MR-MPS- SW tem uma área de processo correspondente no MPT.Br, mostrou que existem os que não possuem tal correspondência. Desse modo, os processos do MPS-SW que não possuem área de processo correspondente no MPT foram excluídos do mapeamento, 37