TERESA CRISTINA MONTEIRO MARTINS AVALIAÇÃO DA ADERÊNCIA DE UMA ORGANIZAÇÃO AO NÍVEL G DO MODELO MPS.BR

Transcrição

1 TERESA CRISTINA MONTEIRO MARTINS AVALIAÇÃO DA ADERÊNCIA DE UMA ORGANIZAÇÃO AO NÍVEL G DO MODELO MPS.BR Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. LAVRAS MINAS GERAIS - BRASIL 2009 i

2 TERESA CRISTINA MONTEIRO MARTINS AVALIAÇÃO DA ADERÊNCIA DE UMA ORGANIZAÇÃO AO NÍVEL G DO MODELO MPS.BR Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. Área de concentração: Engenharia e Qualidade de Software Orientador: Prof. Dr. Marcelo Silva de Oliveira Co-orientador: Prof. MSc. André Luiz de Castro Villas Boas LAVRAS MINAS GERAIS - BRASIL 2009 ii

3 Ficha Catalográfica preparada pela Divisão de Processo Técnico da Biblioteca Central da UFLA Martins, Teresa Cristina Monteiro Avaliação da aderência de uma organização ao nível G do modelo MPS.BR / Teresa Cristina Monteiro Martins Minas Gerais, 2009, p.99. Monografia de Graduação Universidade Federal de Lavras. Departamento de Ciência da Computação. 1. Melhoria de processo de software. 2. MPS.BR 3. Qualidade de software. I. MARTINS, T. C. M.. II. Universidade Federal de Lavras. III. Título. i

4 TERESA CRISTINA MONTEIRO MARTINS AVALIAÇÃO DA ADERÊNCIA DE UMA ORGANIZAÇÃO AO NÍVEL G DO MODELO MPS.BR Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras como parte das exigências do curso de Ciência da Computação para obtenção do título de Bacharel em Ciência da Computação. Aprovada em 31 de outubro de 2009 Prof. Dr. Ahmed Ali Abdalla Esmin Prof. Msc. André Luiz de Castro Villas Boas Prof. Dr. Antônio Maria Pereira de Resende Prof. Dr. Marcelo Silva de Oliveira LAVRAS MINAS GERAIS - BRASIL 2009 ii

5 O aprendido é aquilo que fica depois que o esquecimento faz o seu papel. (Rubem Alves) À Nega e Nin Pelos ensinamentos que vão muito além de qualquer faculdade. v

6 Quando se sonha sozinho é apenas um sonho; quando sonhamos juntos, é o começo da realidade (Dom Quixote - Miguel de Cervantes) Agradeço aos que de alguma forma contribuíram com este trabalho, seja com seu apoio ou com seu conhecimento. A Deus, a mão poderosa que abre os meus caminhos. À família, em especial: Pais, irmãos, Madrinha Maria Célia, tio Gilmar, Aparecida, Zezé, Ana Paula e Henrique, meus alicerces. Gui, sempre companheiro, dividindo sonhos, medos, conquistas, alegrias... Aos professores que contribuíram para minha formação, em especial: André, Ahmed e Marcelo, Pessoas que admiro. Aos amigos: Do Alojamento, dos Estágios, da Computação e de Boa Esperança Por colaborarem com meu amadurecimento e proporcionarem tantas alegrias. Rodrigo, Ramon e demais colaboradores da organização estudada, Pela confiança depositada e pela paciência em esclarecer minhas dúvidas. vi

7 AVALIAÇÃO DA ADERÊNCIA DE UMA ORGANIZAÇÃO AO NÍVEL G DO MODELO MPS.BR RESUMO O trabalho apresenta uma avaliação do processo de produção de software de uma organização, por meio da análise de dois projetos, quanto a sua aderência aos processos de Gerência de Requisitos e de Projetos do nível G do modelo MPS.BR. Para a compreensão do trabalho foram apresentados conceitos de qualidade de software, modelos de melhoria de processo e modelo MPS.BR, e o detalhamento do método utilizado para essa avaliação interna, que foi baseada nos guias do próprio modelo e na pesquisa de campo realizada. Os resultados mostraram, por meio de planilhas de avaliação, descrição dos projetos e análise das oportunidades de melhoria detectadas, que a organização não é aderente aos processos do nível G do MPS.BR, mas já começa a adotar algumas práticas com o objetivo de melhorar a qualidade de seus processos e produtos. Com base na realidade observada na organização algumas sugestões de melhorias também foram apresentadas. Palavras -chave: melhoria de processo de software, MPS.BR, qualidade de software. v

8 SUMÁRIO LISTA DE TABELAS LISTA DE FIGURAS 1 INTRODUÇÃO Contextualização e Motivação Objetivos e Estrutura do Trabalho FUNDAMENTAÇÃO TEÓRICA Qualidade Conceitos de qualidade Qualidade do produto e processo Modelos de qualidade de processo e produto ISO ISO ISO ISO ISO Capability Maturity Model Integration CMMI Modelo de melhoria do processo de software brasileiro MPS.BR Modelo de Melhoria do Processo de Software Brasileiro Níveis de maturidade de processo Nível G MPS.BR Processos Capacidade do Processo Processo de gerência de projetos (GPR) Processo de Gerência de Requisitos (GRE) Método de Avaliação (MA-MPS) Adoção do MPS.BR MATERIAIS E MÉTODOS Delineamento da Pesquisa Procedimento Metodológico vi

9 4 RESULTADOS E DISCUSSÃO A organização Processo de Produção de Software Atual Descrições dos projetos observados O projeto finalizado O projeto em execução Diagnóstico dos projetos Proposta de melhorias Considerações sobre a avaliação CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Questionário de apoio às entrevistas APÊNDICE B Planilhas de apoio à avaliação da aderência ao Modelo MPS.BR Nível G vii

10 LISTA DE FIGURAS Figura Projeto Spice (Fonte: Magela (2006))...19 Figura Níveis de capacidade da norma ISO (Fonte: Salviano (2003))...20 Figura 2.3 Comparação entre os níveis de maturidade do MR-MPS.BR e o CMMI (Fonte: Ribeiro (2006))...28 Figura 2.4 Estrutura do MPS.BR (Fonte: MPS.BR Guia Geral (2009, p.13))...32 Figura 2.5 Estrutura do MPS.BR (Fonte: Koscianski; Soares (2007, p. 145))...32 Figura 4.1 Processo de produção de software atual da organização (Fonte: Barreto (2008), p. 51) Figura 4.2 Tela Projetos da ferramenta usada para Gerência de projetos (Fonte: Imagem cedida pela organização estudada)...61 Figura 4.3 Tela Agenda do dia da ferramenta usada para Gerência de projetos (Fonte: Imagem cedida pela organização estudada)...62 viii

11 LISTA DE TABELAS Tabela 2.1 Evolução dos modelos de qualidade (Fonte: Vasconcelos et al. (2006, p.87)) ISO...10 Tabela 2.2 Evolução dos modelos de qualidade (Fonte: Vasconcelos et al. (2006, p. 90), atualizada)...11 Tabela 2.3 Áreas de processo da representação por estágio do CMMI (Fonte: CMMI-DEV (2006))...25 Tabela Comparação das vantagens entre as representações continua e por estágios...26 Tabela 2.5 Níveis de maturidade e processos MPS.BR (Fonte: Koscianski; Soares (2007, p.145))...33 Tabela 2.6 Níveis de maturidade e processos MPS.BR (Fonte: MPS.BR Guia Geral (2009, p. 23)) Tabela 2.7 Escala de avaliação do grau de implementação dos indicadores (Fonte: MPS.BR Guia de Avaliação (2009, p. 47))...44 ix

12 1 INTRODUÇÃO 1.1 Contextualização e Motivação O setor de software brasileiro em constante crescimento, verificou desde seus primórdios, com o surgimento dos conceitos de Engenharia de Software, que a produção de software descontrolada e sem prévio planejamento acarreta inúmeras desvantagens tanto ao cliente quanto à entidade produtora do software. O produto de software diretamente dependente do processo utilizado para sua confecção, uma vantagem competitiva para empresas desenvolvedoras de software é a qualidade de seu processo de desenvolvimento, que impacta na qualidade do produto ou serviço gerado. Um processo de desenvolvimento de qualidade deve estabelecer meios para que o produto ou serviço seja gerado em tempo hábil, com custo mínimo e dentro das especificações dos interessados. Sendo a qualidade uma vantagem competitiva entre as organizações produtoras de software, essas organizações visando seu crescimento têm investido cada vez mais na melhoria de seus processos por meio de modelos específicos. Esses modelos definem boas práticas para a melhoria dos processos e podem ser utilizados como uma base para a comparação entre o que seria o melhor resultado esperado para determinado processo e o resultado encontrado pela organização. Facilitando assim a detecção de possíveis falhas nos processos da organização e a padronização das avaliações dos níveis de qualidade atingidos por cada organização.

13 A organização estudada neste trabalho desenvolve sistemas e soluções em tecnologia, tem pequeno porte, interesse em implantar um modelo de melhoria de processos para a solução de alguns problemas encontrados e aumento de sua competitividade, mas poucos recursos para isso. Entre os modelos e normas estudados nesse trabalho, o MPS.BR se destaca por ser o mais estagiado, ter menor custo e ser voltado à realidade de micro e pequenas empresas, portanto foi o escolhido para a avaliação da organização. 1.2 Objetivos e Estrutura do Trabalho Este trabalho tem por objetivo: Apresentar uma avaliação dos processos, práticas e resultados obtidos pelos projetos de uma organização, com base nas especificações do nível G do modelo MPS.BR, verificando assim, qual o estado de aderência da organização aos processos de Gerência de Projetos e de Requisitos, que são os avaliados no nível G do MPS.BR. Caso os processos não estejam aderentes, verificar onde se encontram as oportunidades de melhoria e apresentar sugestões de melhoria. E foi organizado da seguinte forma: O Capítulo Dois abrange todos os conceitos considerados importantes ao entendimento do leitor sobre o delineamento deste estudo. Apresenta na seção 2.1 conceitos de qualidade e sua aplicação ao produto e processo de software; na seção 2.2 2

14 apresenta ao leitor alguns modelos e normas de qualidade aplicáveis a software, sendo três deles as bases técnicas do modelo foco deste trabalho; a seção 2.3 é totalmente dedicada ao detalhamento do modelo MPS.BR, já que se torna necessário o conhecimento do leitor sobre o modelo, seus estágios, processos envolvidos no estágio em questão e formas utilizadas para avaliação. O Capítulo Três descreve os métodos utilizados para o delineamento deste estudo. O Capítulo Quatro apresenta a análise da organização. Primeiramente, na seção 4.1, a organização foi descrita, buscando apresentar seu perfil sem identificá-la. Na seção 4.2 foi analisado seu processo de produção de software atual, e na seção 4.3 a organização foi avaliada, por meio de dois de seus projetos e algumas sugestões foram propostas. O Capítulo Cinco apresenta as conclusões, contribuições e possíveis trabalhos futuros a serem desenvolvidos a partir deste. 3

15 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Qualidade Qualidade é uma ideia bastante abrangente que pode ser notada atualmente em empresas de diversos setores como uma estratégia para aumentar a produtividade e a satisfação dos clientes, reduzir custos, melhorar resultados; gerando assim, maior competitividade e, consequentemente, maior lucro. Apesar das diferenças existentes entre as formas de produção de software e as de produção de manufaturas, por exemplo, várias estratégias empregadas para a melhoria do processo de um tipo de produção podem ser utilizadas em outro, melhoria essa que impacta diretamente na maior qualidade do produto. Este capítulo apresenta alguns conceitos de qualidade aplicáveis à área de Engenharia de Software; a influência da qualidade do processo sobre a qualidade do produto; e por fim uma visão geral de modelos e normas de qualidade direcionadas ou aplicáveis à produção de software, como forma de unificar e medir a qualidade de seus processos e produtos Conceitos de qualidade Segundo Oliveira (2000), o conceito de qualidade é universalmente aplicado em todas as áreas de expressão humana e é intrínseco ao próprio ser humano. O criador do conceito de Total Quality

16 Control (TQC), Feigenbaum (1991) apud Oliveira (2000, p. 29), define qualidade de uma maneira bem abrangente: Qualidade é a composição total das características de marketing, projeto, produção, e manutenção dos bens e serviços, por meio dos quais tais produtos atenderão as expectativas do cliente. Qualidade, conforme a norma ISO 9000, é definida como sendo todas as características que o consumidor exige de determinado produto ou serviço (ISO 9000 apud Spinola (2005)). Complementar a essa definição tem-se que: Qualidade é a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas" (NBR ISO-8402 / 1986 apud Villas Boas (2007, p.129)), sendo que necessidades explícitas são aquelas propostas pelo criador do produto de acordo com as necessidades apresentadas cliente, e implícitas são aquelas que são esperadas de qualquer software, incluindo questões éticas, modernização, segurança, entre outros (NBR ISO-8402 / 1986 apud Villas Boas (2007)). Aplicada à área de Engenharia de Software, Pressman (2006, p. 349) define qualidade da seguinte forma: Qualidade é a satisfação dos requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo o software desenvolvido profissionalmente. Assim, nota-se que em todas as áreas do conhecimento, um produto, serviço ou qualquer outra entidade pode ser considerada de qualidade quando oferece todas as características necessárias para se alcance a satisfação das necessidades dos interessados. 5

17 2.1.2 Qualidade do produto e processo Um produto de software é considerado de qualidade quando atende às necessidades implícitas e explicitas dos clientes. A Norma ISO 9126, que será apresentada na seção , define características e subcaracteristicas que o produto de software deve manter para ser considerado um produto de qualidade (Villas Boas (2007)). Processo em engenharia de software é definido por Pessoa (2003), como uma sequência de passos para construção de um produto de software e abrange as relações com o fornecedor e com o cliente, gerenciamentos (de projeto, de qualidade, de configuração, de requisitos, de custo, de tempo e de risco) e a engenharia do produto. E o que determina a qualidade desse processo é a sua capacidade de geração das características implícitas de qualidade esperadas para o produto e a aplicação de métodos, técnicas e ferramentas que favoreçam o processo de desenvolvimento do produto de software. Processos de software são complexos e abrangem um número alto de atividades inter-relacionadas. Para Sommerville (2007), para melhorar o processo de software de uma empresa não basta a adoção de métodos, ferramentas específicas ou algum modelo de processo que tenha sido utilizado em outro projeto. Necessita também, da mesma forma que os produtos, de atributos como os citados abaixo pelo próprio Sommerville (2007): Facilidade de compreensão - Até que ponto o processo está explicitamente definido e com que facilidade se pode compreender a definição do processo? 6

18 Visibilidade - As atividades de processo culminam em resultados nítidos, de modo que o progresso do processo seja externamente visível? Facilidade de suporte - Até que ponto as atividades do processo podem ser apoiadas por ferramentas CASE? Aceitabilidade - O processo definido é aceitável e utilizável pelos engenheiros responsáveis pela produção do produto de software? Confiabilidade - O processo está projetado de tal maneira que seus erros sejam evitados ou identificados antes que resultem em erros no produto? Robustez - O processo pode continuar, mesmo que surjam problemas inesperados? Facilidade de manutenção - O processo pode evoluir para refletir os requisitos mutáveis da organização ou melhorias de processo identificadas? Rapidez - Com que rapidez pode ser concluído o processo de entrega de um sistema, a partir de uma determinada especificação? A qualidade do processo impacta diretamente na qualidade do produto gerado por ele, isso porque o processo deve oferecer recursos para a especificação correta do produto e para sua produção. Destacando essa dependência, Pessoa (2003, p. 18) diz que a qualidade de um produto de software é conseguida de forma consistente, em longo prazo, a partir da qualidade do processo. 7

19 Para Pressman (2006), mais que complementares a qualidade de processo e produto são componentes da seguinte relação apresentada por Robert Glass: Satisfação do cliente = produto adequado + máxima qualidade + entrega dentro do orçamento e cronograma (Glass (1998) apud Pressman (2006)). Para Sommerville (2007) essa relação entre qualidade de produto e processo é complexa devido à dificuldade de prever como a organização de um processo irá impactar na qualidade do produto final, mas concorda, de acordo com suas experiências e pesquisas, que a gerência e melhoria do processo certamente podem diminuir as não conformidades na entrega do produto. 2.2 Modelos de qualidade de processo e produto Os avanços tecnológicos, a crescente preocupação na eliminação de defeitos, o aumento na produtividade e a redução de custos, segundo Vasconcelos; Maciel (2003), foram os principais motivos para o surgimento de modelos de qualidade para o processo de manufatura. A partir de 1947, com a fundação da ISO (International Organization for Standardization), segundo Koscianski; Soares (2007), começaram a surgir recomendações para a geração de processos e produtos de qualidade. Mais tarde, na década de 60, essas recomendações começaram a se transformar em critérios, modelos e técnicas que atualmente garantem e padronizam a medição da qualidade. 8

20 Para Magela (2006) é essencial que se defina um modelo para o julgamento de valores medidos para o controle de qualidade. Esse modelo deve ser de cunho internacional e não desenvolvido pela própria empresa; o que pode haver é uma personalização do modelo à realidade da mesma, integrando-o com sua realidade. Vasconcelos (2008), mostra que existem vários modelos e padrões aplicáveis à qualidade de software. Na Tabela 2.1 há uma visão geral da evolução desses modelos, por meio de algumas iniciativas relevantes, desde Tabela 2.1 Evolução dos modelos de qualidade (Fonte: Vasconcelos et al. (2006, p.87)). 9

21 O modelo que será utilizado neste estudo de caso é o de Melhoria de Processo do Software Brasileiro que, segundo Weber et al. (2004), começou a ser desenvolvido em dezembro de 2003, com a participação de sete renomadas instituições: SOFTEX, Riosoft, COPPE/UFRJ, CESAR, CenPRA, CELEPAR e UCB, como será mostrando nas seções posteriores ISO A palavra ISO tem origem grega e significa igualdade, é a abreviatura de International Organization for Standardization. O objetivo das normas ISO é estabelecer um conjunto de padrões para organizações de todo o mundo. 10

22 No Brasil, a ISO é representada pela ABNT (Associação Brasileira de Normas Técnicas). A Tabela 2.2 apresenta algumas normas ISO aplicadas à qualidade de software, focadas em produto ou processo de software. Tabela 2.2 Evolução dos modelos de qualidade (Fonte: Vasconcelos et al. (2006, p. 90), atualizada). ISO DESCRIÇÃO Norma ISO 9126 (NBR ISO/IEC 9126) Define as características que devem estar presentes para a qualidade do software. (funcionalidade, eficiência, usabilidade e portabilidade). Norma ISO (NBR ISO/IEC 12119) Estabelece requisitos de qualidade para pacotes de software. Norma ISO (NBR ISO/IEC 14598) Define um processo de avaliação da qualidade de produto de software. Norma ISO (ISO/IEC NBR 12207) Norma ISO (NBR-ISO , com última alteração em 1993, portanto a NBR está desatualizada) Norma (NBR-ISO 15504) Define o processo de cliclo de vida de software. Apresenta diretrizes para a aplicação da ISO 9001 pro organizações que desenvolvem software ao desenvolvimento, fornecimento e manutenção de software. Evolução da ISO 12207, foi aprovada como norma em 2003, é focada na avaliação de processos organizacionais. Desde sua criação a ISO formalizou a necessidade da definição de padrões internacionais no setor da indústria, contribuindo assim para a evolução do setor. Ela define normas para a garantia da qualidade 11

23 direcionada para produção, serviços, gerenciamento entre outros contextos. Esta organização é não governamental e elabora normas internacionais, com a missão de promover o desenvolvimento da normalização, e o objetivo de facilitar a troca internacional de bens e serviços e a cooperação no desenvolvimento intelectual de atividades científicas, tecnológicas e econômicas (Moreira (2004)) ISO 9001 A norma ISO 9001, introduzida em 1987, especifica requisitos para um sistema de gestão de qualidade. Segundo Spinola (2005) a norma referida pode ser aplicada em empresas, unidades de manufatura e serviços, sem levar em consideração o tipo, tamanho e produto fornecido por ela, inclusive o produto de software. Isso ocorre porque os requisitos da norma são genéricos. A norma ISO 9001 pode ser utilizada quando a organização deseja aumentar a capacidade de fornecimento, fazendo com que os seus produtos correspondam aos requisitos especificados pelos clientes e aos requisitos regulamentares aplicáveis; ou ainda quando a organização deseja aumentar a satisfação do cliente com a aplicação do sistema, incluindo processos de melhoria contínua no mesmo e garantindo a conformidade de requisitos (ABN01, 1.1 apud Spinola (2005)). Para Magela (2006), essa norma estabelece requisitos que asseguram a qualidade dos processos e possibilitam a agregação do fator de confiabilidade ao produto, o atendimento à demanda de clientes, orientação do acompanhamento por processo relevante para a qualidade, 12

24 atenção para a conformidade na produção, e sua aplicação a algum processo ou parte da organização. Ainda segundo Magela (2006), a ISO 9001 define os sistemas de qualidade e modelos que garantem a qualidade externa, e deve ser usada para garantir a conformidade dos requisitos especificados pelo fornecedor com os vários estágios do projeto, desenvolvimento, produção, instalação e assistência técnica. Como a norma é aplicável a todas as atividades de engenharia, um conjunto especial de diretrizes foi desenvolvido para ajudar a interpretar a norma para o uso no processo de software, com essa afirmação Pressman (2006) mostra que a norma, que contém vinte requisitos que devem estar presentes num sistema efetivo de garantia da qualidade se aplica também à engenharia de software. Os tópicos abrangidos por essa norma são listados por Pressman (2006): responsabilidade gerencial, sistema de qualidade, revisão de contrato, controle de projeto, controle de documentos e dados, identificação e rastreabilidade de produto, controle de processo, inspeção e teste, ação corretiva e preventiva, registros de controle de qualidade, auditorias internas de qualidade, treinamento, serviço e técnicas estatísticas. Para que a organização de software seja considerada aderente à ISO 9001 é necessário o estabelecimento de políticas e procedimentos para cuidar de cada um dos tópicos abordados no capítulo anterior e que depois a organização possa demonstrar que essas políticas e procedimentos estão sendo seguidos. 13

25 De acordo com Spinola (2005), a norma é bastante útil em organizações que desenvolvem produtos e serviços em grande escala, organizações que desenvolvem software por encomenda ou ainda organizações terceirizadas de serviços de desenvolvimento, manutenção ou operação de software; isso porque independente de seu tipo, as organizações necessitam de buscas contínuas de melhoria e aumento da satisfação dos clientes. Ainda segundo Spinola (2005), alguns resultados podem ser notados rapidamente com a implantação da norma, são eles: a solução de problemas, simplificação de processos produtivos, maior satisfação dos clientes, melhoria das condições de trabalho e da produtividade ISO 9126 A norma ISO 9126 estabelece um modelo de qualidade para o produto, descrevendo uma forma de medição, quantitativa e qualitativa, dessa qualidade. (ISO/IEC 9126, 1991). Desenvolvida com o objetivo principal de identificar atributos de qualidade para software, são seus atributos principais (ISO/IEC 9126 (1991)): Funcionalidade: Grau com que o software satisfaz as necessidades declaradas. Confiabilidade: Período de tempo em que o software está disponível para uso. Usabilidade: Facilidade de manipulação do software pelos usuários. 14

26 Eficiência: Grau com que o software faz uso otimizado dos recursos do sistema. Manutenibilidade: Facilidade para que se faça reparos no software. Portabilidade: Facilidade de transposição do software de um ambiente para outro. Villas Boas (2007) mostra que a ISO 9126 trata das características de qualidade em uso, que é a visão de qualidade do usuário, medida a partir da percepção de quatro características principais: efetividade, produtividade, segurança e satisfação. Villas Boas (2007) faz ainda a seguinte relação: para obtenção da qualidade em uso é necessária a obtenção da qualidade externa do produto, a qual por sua vez é dependente da obtenção de sua qualidade interna. Logo, as medidas são normalmente necessárias em três níveis, pois atingir os critérios para medidas internas não é usualmente suficiente para garantir a obtenção dos critérios para medidas externas, e atingir os critérios para medidas externas não é usualmente suficiente para garantir a obtenção de critérios para qualidade em uso. A medida da qualidade do produto, de acordo com a norma ISO 9126, descrita por Villas Boas (2007) é diretamente proporcional à sua capacidade de permitir a usuários específicos atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado. Assim, qualidade em uso é a visão do usuário da qualidade de um ambiente contendo software, medida não pelas propriedades do software, mas pelos resultados do uso do software em ambientes. 15

27 ISO A norma ISO/IEC 12207, segundo Machado (2003) tem o objetivo principal de facilitar às organizações a compreensão das partes presentes na obtenção e no fornecimento de produtos de software, por meio de uma estrutura comum para os processos de ciclo de vida do produto de software. Conseguindo assim assinar contratos e executar projetos com mais eficiência. Vasconcelos et al. (2006) afirma que o ciclo de vida de um processo compreende todas as etapas, da a concepção inicial, até a implementação, implantação, uso e manutenção do software; de modo que, ao final de cada etapa, um ou mais documentos são produzidos. Assim, de acordo com Machado (2003), tal norma trata da qualidade do produto de desde a concepção até a descontinuidade do produto de software; e pelos envolvidos na sua produção, na sua manutenção e na sua operação: adquirentes, fornecedores, operadores, desenvolvedores, mantenedores, gerentes, profissionais de qualidade e usuários. Seguindo as definições de Machado (2003), tem-se que, a norma apenas expõe a arquitetura dos processos, não demonstra formas de implementação ou execução das atividades inclusas no processo, nem estabelece um modelo específico de ciclo de vida ou padrão de desenvolvimento de produtos de software. Koscianski; Soares (2007) mostram que a norma oferece uma perspectiva bem diferente das demais, por não definir objetivos, níveis de maturidade organizacional ou de capacidade de processo. Koscianski; Soares (2007) explicam que em vez disso a norma traz uma estrutura que 16

28 para a definição dos processos da organização, tendo como objetivo definir uma linguagem comum em meio ao grande número de métodos, técnicas, módulos e normas que tratam de qualidade. A norma divide os processos em (ISO/IEC (1995)): Primários: processos básicos do ciclo de vida do produto de software. Exemplos: desenvolvimento, operação e manutenção. De apoio: processos que colaboram com a qualidade e o sucesso de outros processos fundamentais. Exemplos: documentação, verificação, revisões, auditorias. Organizacionais: processos relacionados com a operação da organização em si. Exemplos: gerência, infra-estrutura, melhoria, recursos humanos ISO A norma ISO 15504, de acordo com Koscianski; Soares (2007) apresenta uma estrutura para a realização de avaliações dos processos das organizações, podendo ser aplicada tanto em organizações que buscam melhorias internas, quanto para a avaliação de terceiros ao realizarem contratos de prestação de serviços ou fornecimentos de produtos. Koscianski; Soares (2007) explicam que a norma deriva de um estudo iniciado em 1991 sobre a necessidade de uma norma voltada para avaliação de processos de software, que gerou em 1993 o projeto SPICE (Software Process Improvement and Capability determination), que tinha como objetivo auxiliar o início do projeto de norma, executar testes de 17

29 campo para obter dados de experiências práticas e despertar o mercado para o surgimento da futura norma ISO 15504, apresentada a seguir. A norma era focada somente em software e baseada nos processos da ISO 12207, somados aos processos de integração do software. A norma internacional, composta de cinco partes, introduziu o conceito de modelo de referência de processo. Atualmente é genérica e não exclusiva a software (Koscianski; Soares (2007)). As cinco subdivisões da norma são mostradas por Salviano (2003): ISO/IEC : Conceitos e Vocabulário; ISO/IEC : Executando uma Avaliação (Modelo de Referência, normativo); ISO/IEC : Guia sobre como executar uma avaliação; ISO/IEC : Guia sobre como utilizar resultados de Avaliação; ISO/IEC : Exemplo de Modelo de Avaliação de Processo. Magela (2006) reforça a ideia de que a norma define o modelo bidimensional, já que tem por objetivo a realização de avaliações de processos de software com foco na melhoria de processos (gerar um perfil de processos identificando pontos fortes e fracos, que serão utilizados para elaboração de um plano de melhorias) e a determinação de capacidade dos processos visando à avaliação de um fornecedor em potencial. Podendo ser utilizada também como referência para a melhoria de processos. O modelo SPICE foi ilustrado por Magela (2006) da seguinte forma: 18

30 Figura Projeto Spice (Fonte: Magela (2006)) Ainda segundo Magela (2006), níveis de capacidade geram dois benefícios: Reconhecimento das dependências entre as práticas de um processo; Melhor identificação das melhorias prioritárias, com base numa sucessão plausível de implementação do processo. A norma ISO/IEC é uma das responsáveis pela origem do termo de modelo contínuo, emprega a arquitetura contínua, a qual define níveis de capacidade de processo (dimensão de capacidade) e de processo (dimensão de processo). Esta arquitetura possibilita que processos sejam escolhidos conforme o objetivo, a situação e a estratégia de negócios e guia a avaliação e a melhoria destes processos de acordo com seus seis níveis seqüenciais e acumulativos de capacidade que, quando 19

31 empregados, podem ser uma medida do resultado da avaliação de algum processo específico ou um guia para a melhoria (Salviano (2003)). A próxima figura demonstra os níveis de capacidade da norma ISO 15504: Figura Níveis de capacidade da norma ISO (Fonte: Salviano (2003)) Salviano (2003) mostra na figura que a capacidade de um processo, de acordo com a ISO 15504, é medida do nível Incompleto, até o seu topo, Em Otimização, conforme descrito abaixo de cada nível. Desta forma representa a capacidade de crescimento do processo implementado, onde a escala de zero a cinco mede o grau com o qual o processo avaliado atinge seu propósito e seus objetivos atuais projetados para o negócio, e define uma rota para a melhoria deste processo. 20

32 2.2.2 Capability Maturity Model Integration CMMI Conforme Vasconcelos Et. Al (2006), o Projeto CMMI, traduzido como Projeto de Integração dos Modelos de Maturidade e de Capacidade, foi executado pelo Software Engineering Institute (SEI), em cooperação com a indústria e governo. E teve por objetivo consolidar um framework para modelos, evoluir e integrar os modelos já desenvolvidos pelo SEI (inicialmente os modelos SW-CMM, SE-CMM e IPD-CMM), e gerar produtos associados como material de treinamento e método de avaliação. Vasconcelos (2006) afirma que o CMMI surgiu inicialmente pela integração e evolução de três modelos: a versão 2.0 do Capability Maturity Model for Software (SW-CMM), o System Engineering Capability Maturity Model: EIA 731 (SE-CMM) e o Integrated Product Development Capability Maturity Model (IPD-CMM). Segundo Salviano (2006), esta integração e evolução impactaram principalmente na redução do custo da implementação e na criação da melhoria de processo multidisciplinar baseada em modelos. Salviano (2006) explica que esta redução de custo é obtida devido à eliminação de inconsistências; redução de duplicações, melhoria da clareza e entendimento, utilização de terminologia comum, utilização de estilo consistente, estabelecimento de regras de construção uniformes, manutenção de componentes comuns, garantia da consistência com a Norma ISO/IEC Quanto a multidisciplinariedade, Salviano (2006) afirma que esta se deve a abrangência do CMMI que além da engenharia 21

33 de software, cobre também a engenharia de sistemas, fontes de aquisição e a cadeia de desenvolvimento de produto. Koscianski; Soares (2007) dão uma visão geral do que trata cada disciplina abrangida pelo CMMI: Engenharia de Sistemas: tem o objetivo obter sistemas bemsucedidos, independente do software, propondo produtos e soluções por meio da análise, projetos, validação, teste de implementação, treinamento e suporte. Cadeia de desenvolvimento de produto: abordagem sistemática que utiliza a colaboração dos stakeholders para satisfazer as expectativas e requisitos dos clientes. Fontes de aquisição: visam a aquisição de produtos que realizem funções específicas ou adicionem modificações em produtos específicos do projeto. Engenharia de Software: processo técnico de desenvolvimento de software, envolvendo também atividades de gerenciamento de projetos, desenvolvimento de ferramentas, métodos e teorias que dão apoio à produção de software. Salviano (2006) afirma que a arquitetura do CMMI é composta basicamente pela definição de um conjunto de áreas de processo, que por sua vez são organizadas em duas representações diferentes: uma como um modelo por estágio, semelhante ao SW-CMM, e outra como um modelo contínuo (semelhante à ISO/IEC 15504). A descrição do modelo mostra que a representação contínua tem a vantagem de oferecer máxima flexibilidade na utilização de um modelo CMMI para melhoria de processo. Isso porque, a organização foca na 22

34 melhoria do desempenho de um ponto problemático associado a um processo isolado, ou ainda, trabalha em várias áreas, dependendo dos objetivos estratégicos da organização. Além disso, a organização pode melhorar diferentes processos com diferentes ênfases ao longo do tempo (CMMI-DEV V1.2, 2006). Na representação contínua, cada área de processo é medida pelo seu nível de capacidade os níveis de capacidade são definidos pelo CMMI-DEV (2006), da seguinte forma: Nível de Capacidade 0: Incompleto - é aquele que não é executado ou é executado parcialmente. Uma ou mais metas específicas da área de processo não são satisfeitas. Nível de Capacidade 1: Executado Caracterizado como processo executado, satisfaz às metas específicas da área de processo, apoiando e viabilizando o trabalho necessário para produzir os produtos de trabalho. Nível de Capacidade 2: Gerenciado É um processo executado (nível de capacidade 1) que dispõe de infra-estrutura adequada para apoiar o processo; é planejado e executado de acordo com uma política; emprega pessoas experientes que possuem recursos adequados para produzir saídas controladas; envolve partes interessadas relevantes; é monitorado, controlado e revisado; e sua aderência em relação à descrição de processo é avaliada. Nível de Capacidade 3: Definido - É um processo gerenciado (nível de capacidade 2), adaptado a partir do conjunto de processos-padrão da organização de acordo com as diretrizes para adaptação da organização, e contribui com produtos de trabalho, 23

35 medidas e outras informações de melhoria de processo para os ativos de processo da organização. Possui um escopo de padrões, descrições de processo e procedimentos. Nível de Capacidade 4: Gerenciado Quantitativamente É um processo definido (nível de capacidade 3), controlado por meio de técnicas estatísticas e outras técnicas quantitativas. Objetivos quantitativos para qualidade e para desempenho de processo são estabelecidos e utilizados como critérios na gestão de processo. A qualidade e o desempenho de processo são entendidos em termos estatísticos e gerenciados ao longo da vida do processo. Nível de Capacidade 5: Em Otimização - É um processo gerenciado quantitativamente (nível de capacidade 4) e melhorado com base no entendimento das causas comuns de variação inerentes ao processo. O foco de um processo em otimização é a melhoria contínua do desempenho de processo tanto por meio de melhorias incrementais quanto de inovação. A representação por estágios, segundo CMMI-DEV (2006), oferece uma forma sistemática e estruturada para abordar a melhoria de processo, baseada em modelo, enfocando um estágio por vez. Onde para se atingir determinado estágio, determinadas áreas de processo devem estar implementadas. Essas áreas são organizadas em níveis de maturidade, o que reduz a necessidade de escolhas associadas à melhoria de processo. Ainda segundo o CMMI-DEV (2006) a representação por estágios prescreve uma ordem de implementação das áreas de processo de acordo com níveis de maturidade, definindo um caminho de melhoria para a 24

36 organização, do nível inicial ao nível em otimização. Nessa representação, as áreas de processo são agrupadas nos níveis de maturidade como mostra a tabela 2.3 Tabela 2.3 Áreas de processo da representação por estágio do CMMI (Fonte: CMMI-DEV (2006)) Monitoramento e Controle de Projeto Planejamento de Projeto Nível de Maturidade2 - Gerenciado Garantia da Qualidade de Processo e Produto Medição e Análise Gestão de Configuração Gestão de Requisitos Gestão de Contrato com Fornecedores Análise e Tomada de Decisões Nível de Maturidade 3 - Definido Gestão Integrada de Projeto +IPPD Definição dos Processos da Organização +IPPD Foco nos Processos da Organização Treinamento na Organização Integração de Produto Desenvolvimento de Requisitos Gestão de Riscos Solução Técnica Validação Verificação Gestão Quantitativa de Projeto 25

37 Nível de Maturidade 4 Gerenciado Quantitativamente Nível de Maturidade 5 Em otimização Desempenho dos Processos da Organização Implantação de Inovações na Organização Análise e Resolução de Causas A próxima tabela mostra uma comparação das vantagens de cada uma das representações. Tabela Comparação das vantagens entre as representações continua e por estágios Representação Contínua Permite livre escolha da seqüência de melhorias, de forma a melhor satisfazer aos objetivos estratégicos e mitigar as áreas de risco da organização. Permite visibilidade crescente da capacidade alcançada em cada área de processo. Permite que melhorias em diferentes processos sejam realizadas em diferentes níveis. Representação por Estágios Permite que as organizações tenham um caminho de melhoria prédefinido e testado. Foca em um conjunto de processos que fornece à organização uma capacidade específica caracterizada por cada nível de maturidade. Resume os resultados de melhoria de processo em uma forma simples: um único número que representa o nível de maturidade. Reflete uma abordagem mais Baseia-se em uma história recente que ainda não dispõe de relativamente longa de utilização, dados para demonstrar seu retorno com estudos de casos e dados que do investimento. demonstram o retorno do investimento. Assim, a adoção de dois tipos de representação (contínua e por estágios), dá a organização a liberdade de escolha entre prover melhorias 26

38 como um todo ou somente na área de processo que lhe é interessante fazer. Apesar dos vários pontos fortes sobre o modelo, Koscianski; Soares (2007) apresentam uma possível crítica sobre o grau de complexidade do modelo no que diz respeito a grande quantidade de termos novos e detalhes difíceis de serem totalmente implementados. Segundo eles a documentação provida pelo SEI é extensa e complexa, e é imprescindível recorrer a consultorias especializadas para sua implementação, o que é um dos fatores que contribui para o preço o alto de sua implementação Modelo de melhoria do processo de software brasileiro MPS.BR Buscando um modelo adequado ao perfil de empresas brasileiras, com diferentes tamanhos e características, públicas e privadas e que seja compatível com os padrões de qualidade aceitos internacionalmente, aproveitando-se de toda a competência existente em outros padrões e modelos de melhoria de processo já disponíveis, começou em dezembro de 2003 o desenvolvimento do Modelo de Melhoria de Processo de Software Brasileiro, o MPS.BR (SOFTEX, (2009a)). Este modelo foi desenvolvido por pesquisadores de várias instituições brasileiras públicas e privadas, sob a coordenação da SOFTEX, e é baseado nas normas ISO/IEC 15504, ISO/IEC e CMMI. A junção de alguns atributos dos três modelos em que foi baseado somado a seu objetivo de se adaptar à realidade das micro, pequenas e médias empresas 27

39 brasileiras, fez com que o MPS.BR atingisse os objetivos de seu projeto inicial descrito por Weber et al. (2004), se tornando um modelo (SOFTEX (2009,a)): Com sete níveis de maturidade, o que possibilita uma implantação mais gradual e adequada a pequenas empresas. A próxima figura ilustra essa diferença mostrando a equivalência entre os níveis existentes no MPS.BR e no CMMI. Figura 2.3 Comparação entre os níveis de maturidade do MR-MPS.BR e o CMMI (Fonte: Ribeiro (2006)). Compatível com o CMMI e a norma ISO/IEC Criado para o Brasil, onde a maior parte das empresas que desenvolvem software são micro, pequenas ou médias empresas. De custo acessível. Por todos os diferenciais apresentados anteriormente, o MPS.BR será o modelol adotado para o estudo de caso que será o objetivo 28

40 principal deste trabalho. Por tanto, a próxima seção será toda dedicada à descrição deste modelo. 2.3 Modelo de Melhoria do Processo de Software Brasileiro Sobre o projeto MPS.BR, Weber et al. (2004) afirma que sob a coordenação do SOFTEX, uma entidade privada, sem fins lucrativos; o programa reúne sete renomadas instituições brasileiras, com competências complementares na melhoria de processos de software em empresas, são elas: três instituições de ensino, pesquisa e centros tecnológicos, COPPE/UFRJ (Instituto Alberto Luiz Coimbra de Pós- Graduação e Pesquisa de Engenharia da Universidade Federal do Rio de Janeiro), CESAR (Centro de Estudos e Sistemas Avançados do Recife) e CenPRA (Centro de Pesquisa Renato Archer); uma sociedade de economia mista, a CELEPAR (Companhia de Informática do Paraná), hospedeira do Subcomitê de Software da Associação Brasileira de Normas Técnicas (ABNT); e duas organizações não-governamentais integrantes do Programa SOFTEX, RIOSOFT (Sociedade Núcleo de Apoio à Produção e Exportação de Software do Rio de Janeiro) e Sociedade Núcleo SOFTEX 2000 de Campinas. Desde o início do projeto, a COPPE/UFRJ convidou a Universidade Católica de Brasília (UCB) para ser sua parceira no projeto, e assim ela posteriormente se uniu ao grupo. 29

41 A base técnica utilizada para a construção do MPS.BR é formada pelas normas NBR ISO/IEC a definição de processos, propósitos e resultados e a ISO/IEC definição da capacidade de processos e requisitos de avaliação, por isso o modelo está totalmente aderente a essas normas. O conteúdo do CMMI também está presente no MPS.BR por meio da complementação de processos em relação aos da norma NBR ISO/IEC (SOFTEX (2009,a)). O foco principal do modelo, de acordo com Koscianski; Soares (2007), são as micro e pequenas empresas brasileiras, já que este atende à necessidade de implantação dos princípios de engenharia de software, seguindo as principais abordagens internacionais para definição, avaliação e melhoria de processo de software, tudo isso de forma adequada ao contexto das empresas brasileiras que dispõem poucos recursos. O modelo possui três componentes, segundo o SOFTEX (2009a), são os seguintes: Modelo de Referência MR-MPS: Contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MRMPS. É descrito no Guia Geral MPS.BR e está em conformidade com a Norma Internacional ISO/IEC , Modelo de Negócio MN-MPS: Descreve regras de negócio para implementação do MR-MPS, avaliação seguindo o MA-MPS, organização de grupos de empresas para implementação do MR- MPS e avaliação MA-MPS, certificação de Consultores de 30

42 Aquisição e programas anuais de treinamento do MPS.BR por meio de cursos, provas e workshops. Método de Avaliação (MA-MPS): possui o processo de avaliação, os requisitos para os avaliadores e as instituições avaliadoras e os requisitos para verificação da aderência ao modelo MR-MPS. É baseado na norma ISO/IEC (ISO/IEC (2003)) e descrito no Guia de Avaliação MPS.BR. Os documentos que descrevem o MPS.BR, de acordo com o próprio SOFTEX (2009a), são: Guia Geral: Descreve o modelo MPS, detalha o Modelo de Referência (MR-MPS), seus componentes e as definições necessárias para seu entendimento e aplicação. Guia de Aquisição: Descreve um processo de aquisição de software e serviços correlatos. Visa apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS. 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. Guia de Implementação: Dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS. A próxima figura representa a estrutura do modelo com: suas bases (ISO/IEC 12207, ISO/IEC e CMMI), componentes (Método de Avaliação, Modelo de Negócio, Modelo de Referência) e os guias e documentos que descrevem e auxiliam na implementação do modelo. 31

43 Figura 2.4 Estrutura do MPS.BR (Fonte: MPS.BR Guia Geral (2009, p.13)) Segundo o SOFTEX (2009a), o Modelo de Referência MR-MPS, por meio de seus guias, define os níveis de maturidade que são, segundo o próprio guia, uma combinação entre processos e capacidade de processos. Essa combinação é detalhada por Koscianski; Soares (2007) na figura a seguir: Figura 2.5 Relação entre os processos e a capacidade dos processos do Modelo MPS.BR (Fonte: Koscianski; Soares (2007, p. 145)). 32

44 2.3.1 Níveis de maturidade de processo O SOFTEX (2009a), define níveis de maturidade como patamares de evolução de processos que caracterizam os estágios de melhoria de implementação de processos na organização. Assim, o nível de maturidade de organização permite prever seu desempenho futuro em uma ou mais disciplinas. O MR-MPS, ainda segundo o SOFTEX (2009a), define sete níveis de maturidade são eles: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). Para cada um destes níveis de maturidade, definiu-se um perfil de processos e um perfil de capacidade de processos que indicam onde a organização deve se esforçar para melhoria visando atender os objetivos de negócio. A tabela a seguir mostra os níveis de maturidade com seus respectivos processos: Tabela 2.5 Níveis de maturidade e processos MPS.BR (Fonte: Koscianski; Soares (2007, p.145)) Inovação e implantação na organização Análise de causas e resolução A B C Desempenho do processo organizacional Gerência quantitativa do projeto Análise de decisão e resolução Gerência de riscos Desenvolvimento de requisitos Solução técnica Integração do produto 33

45 D E F G Liberação do produto Instalação do produto Verificação Validação Treinamento Avaliação e melhoria do processo organizacional Definição do processo organizacional Adaptação do processo para gerência de projeto Medição Gerência de configuração Aquisição Garantia da qualidade Gerência de requisitos Gerência de projetos Essa divisão estagiada foi baseada nos níveis de maturidade do CMMI-SE/SW e tem o objetivo de possibilitar a implementação e avaliação mais gradativa e adequada às micro, pequenas e médias empresas, permitindo a visibilidade dos resultados de melhoria de processos em curto prazo (SOFTEX (2009a)) Nível G MPS.BR Sendo o primeiro nível de maturidade do MR-MPS, o nível G estabelece o início dos trabalhos em implantação de melhoria dos processos de software em uma organização e ao final da implantação deste nível a organização deve ser capaz de gerenciar parcialmente seus projetos de desenvolvimento de software. Os pontos importantes na implantação do nível G: A mudança de cultura organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software; e a 34

46 definição do conceito acerca do que é projeto para a organização (SOFTEX (2009b)). Ainda segundo o MPS.BR Guia de Implementação nível G (SOFTEX (2009a)), o projeto pode usar os seus próprios padrões e procedimentos, não é necessário que se tenha padrões em nível organizacional. Mas se a organização possuir processos já definidos e os projetos necessitarem adaptar os processos existentes, esse fato deverá ser declarado durante o planejamento do projeto. Diversas organizações de software trabalham com evolução de produtos e precisam adequar as suas formas de trabalhar para se tornarem organizações orientadas a projetos. No nível G dois processos são avaliados: Gerência de Projetos e Gerência de Requisitos, no MPS.BR Guia Implementação Nível G (2009) os resultados esperados para esses processos numerados conforme mostrado a seguir. Para o processo de Gerência de Projetos: GPR1 - O escopo do trabalho para o projeto é definido; GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados; GPR3 - O modelo e as fases do ciclo de vida do projeto são definidas; GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas; GPR5 - O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos; 35

47 GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados; GPR7 - Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo; GPR8 Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados; GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança; GPR10 Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos; GPR11 - A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados; GPR12 - O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido; GPR13 O projeto é gerenciado utilizando-se o plano do projeto e outros planos que afetam o projeto e os resultados são documentados; GPR14 - O envolvimento das partes interessadas no projeto é gerenciado; GPR15 - Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento; 36

48 GPR16 - Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas; GPR17 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão. Para o processo de Gerência de Requisitos: GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos; GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto Processos De maneira geral processo pode ser definido como um conjunto de atividades inter-relacionadas ou interativas, que transforma insumos (entradas) em produtos (saídas) (ABNT, 2001 apud SOFTEX (2009a)). No MR -MPS, segundo o SOFTEX (2009a), os processos são descritos em termos de propósitos e resultados. Sendo que o propósito 37

49 descreve o objetivo geral a ser atingido durante a execução do processo, e os resultados esperados do processo estabelecem o que deve ser obtido com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um artefato produzido ou uma mudança significativa de estado ao se executar o processo Capacidade do Processo Como foi apresentado na seção anterior; processos são descritos em termo de propósitos e resultados esperados. Segundo o SOFTEX (2009a) a capacidade de um processo é expressa pelo grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. Então, para se representar a capacidade de um processo existe um conjunto de atributos de processo descrito em termos dos resultados esperados. Na proporção em que são atingidos os resultados esperados dos atributos de processo, maior habilidade em desempenhar o processo é alcançada pela organização, o que indica um aumento na capacidade do processo. O atendimento aos atributos do processo, pelo atendimento aos resultados esperados dos atributos do processo, é requerido para todos os processos do respectivo nível de maturidade que se quer atingir. E os níveis são acumulativos, por tanto para se atingir um nível superior é necessário o atendimento aos resultados esperados dos atributos daquele nível e de todos os níveis inferiores (SOFTEX (2009a)). 38

50 A próxima tabela apresenta os níveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nível. Tabela 2.6 Níveis de maturidade e processos MPS.BR (Fonte: MPS.BR Guia Geral (2009, p. 23)). Os diferentes níveis de capacidade dos processos são descritos pelos seguintes atributos de processo (AP), segundo o SOFTEX (2009a), são eles: 39

51 AP 1.1 O processo é executado. AP 2.1 O processo é gerenciado. AP 2.2 Os produtos de trabalho do processo são gerenciados. AP 3.1. O processo é definido. AP 3.2 O processo está implementado. AP 4.1 O processo é medido. AP 4.2 O processo é controlado. AP 5.1 O processo é objeto de melhorias e inovações. AP 5.2 O processo é otimizado continuamente Processo de gerência de projetos (GPR) Projetos, para Prado (1999), são esforços temporários levados a efeito para produzir um produto ou serviço único. Por serem temporários, possuem um ciclo de vida dentro do qual ocorrem etapas distintas. Ainda conforme Prado (1999), a execução de projetos na área da informática difere de outros tipos de projetos (construção, montagem, pesquisa, etc), isso devida à complexidade do empreendimento, à constante dificuldade de visualizar claramente o produto que está sendo desenvolvido e às dificuldades de comunicação entre executor e usuário ou cliente. A gerência de projetos é definida no PMBOK (Project Management Body of Knowledge) (PMBOK, 2004, p. 24) como a 40

52 aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus requisitos. Assim, a meta da gerência de projetos é conseguir atender aos requisitos para satisfazer as necessidades, desejos e expectativas das partes interessadas. (PMBOK, 2004, p. 53). Todavia, conforme Rouiller (2008), satisfazer ou exceder estas necessidades envolve um balanceamento entre as várias demandas concorrentes em relação ao escopo, tempo, custo e qualidade (objetivos do projeto); e aos requisitos identificados (necessidades) e requisitos não identificados (expectativas). Para o SOFTEX (2009b), a Gerência de Projetos visa atingir alguns propósitos que evoluem à medida que a organização cresce em maturidade, são eles: Estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, Prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. Ainda seguindo o SOFTEX (2009b), o processo Gerência de Projetos (GPR) envolve várias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução do projeto; e conhecer o progresso do projeto, de maneira que ações corretivas possam ser tomadas quando a execução do projeto desviar do planejado. 41

53 Processo de Gerência de Requisitos (GRE) Dorfmann e Thayer (1990) apud SOFTEX (2009a) definem requisito de software como sendo a capacidade requerida pelo usuário para que determinado produto ou componente de produto possua as características necessárias para resolver um problema ou alcançar um objetivo ou para satisfazer a um contato, padrão, especificação ou outros documentos formalmente impostos. Segundo Sommerville (2007), os requisitos devem ser definidos nas fases iniciais do projeto e tem a função de especificar o que deve ser implementado. São descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistema. Um requisito pode descrever: Uma facilidade encontrada no nível do usuário; Uma propriedade geral do sistema; Uma restrição do sistema; Uma restrição ao desenvolvimento do sistema. Gerência de requisitos envolve, segundo o MPS Guia de Implementação (2009), identificar os requisitos do produto e dos componentes do produto do projeto e estabelecer e manter um acordo entre o cliente e a equipe de projeto sobre esses requisitos, bem como, controlar e tratar as mudanças nos requisitos. Para Sommerville (2007), a gerência de requisitos deve abordar os seguintes aspectos: Gerenciar as mudanças em requisitos existentes (pertencentes a especificação), gerenciar o relacionamento entre os 42

54 requisitos, gerenciar as dependências entre o documento de requisitos e outros documentos produzidos durante o processo. No nível G do MPS.BR, o propósito do processo de 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 (MPS.BR Guia de implementação, 2009, p. 18) Método de Avaliação (MA-MPS) O método de avaliação é descrito pelo MPS.BR - Guia de Avaliação (2009), segundo ele, o método consiste num conjunto de atividades e tarefas realizadas para atingir seu propósito que é o de verificar a maturidade da unidade organizacional na execução de seus processos de software. Os resultados obtidos do processo de avaliação são: dados e informações que caracterizam os processos de software da organização, a determinação do grau em que os resultados esperados são alcançados, o grau com que os processos atingem seu propósito, e a atribuição de um nível de maturidade do MR-MPS à organização (SOFTEX (2009c)). Para se atribuir um grau de implementação dos resultados dos processos e atributos de processo, o método de avaliação estabelece alguns indicadores, que podem ser segundo Weber et al. (2004): Direto (ID): objetivo de uma atividade, sendo produtos intermediários resultado de uma atividade; 43

55 Indireto (II): documentos que indicam que uma atividade pode ser realizada. São utilizados para confirmar que uma organização tem condições de implementar um resultado; Afirmação (IA): são obtidas de entrevistas e/ou apresentações com os envolvidos no projeto avaliado, onde é questionado como uma prática foi realizada. Além disso, confirmam a implementação do processo, seus resultados e atributos. O método de avaliação utiliza uma escala que caracteriza o grau de implementação de um resultado esperado do processo e de um resultado esperado de atributo do processo nos projetos, a tabela é apresentada a seguir: Tabela 2.7 Escala de avaliação do grau de implementação dos indicadores (Fonte: MPS.BR Guia de Avaliação (2009, p. 47)) 44

56 A organização, segundo o SOFTEX (2009c), pode ser avaliada somente em um setor definido por ela mesma ou pela empresa. No caso de uma avaliação visando o nível G, a organização deve ter ao menos um projeto finalizado e outro em andamento para serem submetidos à avaliação, sendo que estes devem ser representativos na organização avaliada. O resultado de uma avaliação, seguindo o método de avaliação MPS.BR tem validade de três anos a partir da data de conclusão da avaliação na organização. 2.4 Adoção do MPS.BR Qualidade possui diversas definições aplicáveis a várias áreas e é o ponto chave dos diversos processos que visam a geração de produtos que satisfaçam as necessidades de todos os interessados, sejam eles clientes ou os responsáveis pelo desenvolvimento do mesmo. Para que estes estejam satisfeitos é desejável que o projeto evite o re-trabalho, correções, custo e futuras manutenções. Como visto, para atingir-se o produto esperado, são necessários processos de qualidade, que devem sofrer melhorias constantes para se adequarem aos diversos projetos da empresa. Para isso, utiliza-se modelos que permitam a implantação, padronização da medição e melhoria da qualidade dos processos. Esses modelos podem ser orientados a avaliação e melhoria do produto, do processo ou do sistema de gestão de qualidade; ser voltados para a Engenharia de Software ou genéricos; e ainda estagiados ou contínuos. Assim, cabe a organização a escolha do modelo que melhor se aplica a seu perfil e necessidades. 45

57 A adoção do modelo MPS.BR vem como estratégia para a melhoria do processo de software das empresas brasileiras. Para oferecer um processo de implantação mais gradativo, o modelo possui níveis de maturidade que definem o grau em que o mesmo está implantado na organização, cada nível de maturidade possui áreas de processo, onde são analisados os processos da organização. No nível G por exemplo, são avaliados os processos de gerência de projetos e de requisitos. Os processos por sua vez são avaliados pela sua capacidade que é medida por meio dos atributos que possui e dos resultados obtidos com a adoção dos mesmos. Nos próximos capítulos, a fundamentação teórica sobre a melhoria de processos apresentada anteriormente será aplicada ao estudo da organização em questão. 46

58 3 MATERIAIS E MÉTODOS Este capítulo tem a finalidade de apresentar o delineamento da pesquisa utilizada para o levantamento de dados e aplicação dos mesmos à realidade da organização. 3.1 Delineamento da Pesquisa Estudo de caso, segundo Yin (1994), é a investigação de um fenômeno em seu ambiente natural a partir de múltiplas fontes de evidência, com o objetivo de explorar, descrever e/ou explicar esse fenômeno. O estudo de caso de natureza básica é aquele, explica Zambalde et al. (2008), que tem como objetivo entender ou descobrir novos fenômenos, com foco em conhecimentos básicos e fundamentais. E o estudo de caso classificado como de objetivo exploratório é aquele que, de acordo com Jung (2004), fornece ao pesquisador mais conhecimento sobre o tema e sobre o problema de pesquisa, e sobre o qual não exige a formulação de grandes teorias, mas sim a experimentação para coleta de dados que servirão de base para a formulação de modelos inovadores ou explicativos. O presente trabalho visa a investigação da situação de uma organização, com base na concepção expressa em um modelo de melhoria de processo de software, a partir de pesquisas bibliográficas e documentais, além do uso de entrevistas apoiadas por um questionário. Não buscando a formulação de um novo processo, mas sim a geração de

59 uma visão geral de um processo de produção de software já existente quanto aos conceitos do modelo. Partindo dos conceitos de classificação metodológica e da síntese do trabalho apresentados anteriormente, conclui-se que o mesmo se classifica como um estudo de caso realizado em campo, de natureza básica e com objetivo exploratório. 3.2 Procedimento Metodológico Para se realizar este estudo de caso é imprescindível que o pesquisador conheça previamente conceitos e aplicações relacionados à engenharia e qualidade de software, melhoria de processos, normas, modelos e estratégias para a qualidade. Para isso, foi necessária uma pesquisa bibliográfica visando a construção de uma base conceitual sobre: a adoção de modelos de qualidade, principais modelos existentes, e principalmente sobre a metodologia do modelo de melhoria adotado neste estudo. Para a análise da organização em questão e a aplicação das teorias estudadas na pesquisa bibliográfica, foi feita uma pesquisa documental levantando dados sobre os processos, projetos e práticas adotadas por ela. Além de entrevistas com alguns colaboradores para o conhecimento de informações não documentadas. Essas entrevistas foram guiadas por um questionário Apêndice A - construído com base principalmente na pesquisa bibliográfica, apoiada pela experiência do pesquisador em conjunto com os orientadores. Estas pesquisas trouxeram ao pesquisador 50

60 grande conhecimento sobre o tema, além da oportunidade de reconhecer as dificuldades e vantagens da aplicação prática dos conceitos estudados. Tendo em vista o perfil da organização onde foi feito o estudo e as informações recolhidas sobre os diversos modelos de melhoria de processo existentes; o modelo escolhido foi o mais adequado por atender as necessidades de melhoria das micro e pequenas empresas brasileiras, não deixando de ser compatível com os modelos internacionais préexistentes; apresentando um caminho de melhoria mais gradual, fator esse que oferece a possibilidade de visualizar os resultados em curto prazo (SOFTEX (2009a)). A apresentação dos resultados obtidos foi por meio da descrição crítica dos processos da organização aplicados a dois de seus projetos, com a comparação entre eles e comparação com o modelo de melhoria em questão. Além da apresentação de planilhas Apêndice B - com os indicadores que visam comprovar a adoção de práticas para a obtenção dos resultados esperados e dos atributos de processo exigidos pelo modelo. 51

61 4 RESULTADOS E DISCUSSÃO A organização em questão foi avaliada de acordo com a metodologia descrita anteriormente. Nesta seção serão descritos resultados e conclusões tiradas a partir das observações que verificam o grau de implementação dos atributos e resultados dos processos do nível G do MPS.BR. Serão apresentados: o processo de produção de software seguido pela organização na execução de seus projetos, algumas características de dois de seus projetos, oportunidades de melhoria detectadas a partir da análise desses projetos, da documentação da organização e de entrevistas, e por fim a avaliação da aderência da organização aos processos de gerência de requisitos e gerência de projetos do nível G do MPS.BR. 4.1 A organização Organização é "uma combinação de esforços individuais que tem por finalidade realizar propósitos coletivos. Por meio de uma organização torna-se possível perseguir e alcançar objetivos que seriam inatingíveis para uma pessoa" (Maximiano (1992)). O alvo deste estudo de caso são os processos e práticas de uma organização de pequeno porte, da área tecnológica, fundada em 2006, com o intuito de unir esforços para a promoção do desenvolvimento intelectual, econômico e social de seus participantes.

62 A organização atua na área de TI elaborando, desenvolvendo e implementando soluções tecnológicas livres para os mais variados setores da academia, indústria, comércio e serviços. 4.2 Processo de Produção de Software Atual Foi proposto por Coelho (2007), um processo de desenvolvimento de software para a organização em questão, baseado em quatro modelos de processos: Racional Unified Process (RUP), Processo de Desenvolvimento de Software 2 (PDS2), Processo para Aplicativos extensíveis InterativoS (PRAXIS) e extreme Programming (XP). Seguem as definições de Coelho para esses três modelos: RUP: modelo interativo incremental, dividido em fases, foi desenvolvido com o propósito de padronizar o processo de desenvolvimento de software, sua aplicação é formada por componentes interconectados por meio de interfaces bem definidas. São alguns conceitos utilizados no RUP: Responsável, Atividade, Fluxo e Subfluxo (Vasconcelos, 2008). PDS2: processo baseado no RUP, para padronizar os sistemas desenvolvidos por terceiros, mais aplicados a projetos menores. Baseado assim como o RUP em elementos básicos: Papéis, Artefatos, Atividades e Fluxo de atividades (Coelho, 2007). PRAXIS: Baseado no SW-CMM, utilizando-se da notação UML, o PRAXIS é um modelo com enfoque educacional, com o 53

63 objetivo de dar suporte ao treinamento em engenharia de software e à implantação de processos (Paula Filho, 2003). XP: Modelo de desenvolvimento ágil, que envolve os seguintes valores: comunicação, simplicidade, feedback e coragem, baseados nesses valores possui doze práticas que consistem no núcleo principal do processo, é composto por fases e atribui papéis aos envolvidos (Vasconcelos,2008). Posteriormente, esse processo desenvolvido por Coelho (2007) foi adaptado por Barreto (2008), a partir da necessidade de melhoria do antigo no que diz respeito às fases relacionadas com o teste de software, abaixo está a figura que representa o processo que foi desenvolvido por Coelho (2007), sendo que as atividades marcadas (atividades de teste) são as incorporadas por Barreto (2008). Assim, a organização possui um processo de software definido, mas com abrangência e detalhamento restritos, como exemplo disso temse que, várias práticas que serão apresentadas nas próximas seções - que a organização já tem adotado no seu dia a dia não constam no seu processo. Assim, essas práticas não são disseminadas ao nível da organização e dependem mais da comunicação entre os colaboradores e da competência e experiência dos mesmos e dos gerentes, do que de um processo padrão. 54

64 Figura 4.1 Processo de produção de software atual da organização (Fonte: Barreto (2008), p. 51). 55

65 O processo possui uma descrição, em Coelho (2007), de cada uma de suas atividades, de seus artefatos, dos papéis de cada integrante da equipe e do fluxo, que segundo ele, é o ciclo de vida do processo. Porém, não existia uma formalização e documentação padronizada para a execução das atividades descritas no mesmo ou ainda modelos dos artefatos e documentos que deverão ser produzidos ao final de cada fase ou atividade. As atividades de gerência de requisitos seguidas pela organização são sucintamente demonstradas nesse processo padrão, já que na descrição das atividades do processo proposta por Coelho (2007), constam como práticas que visam o gerenciamento de requisitos: levantamento de requisitos mediante entrevistas junto ao cliente e/ou demais pessoas envolvidas na utilização do sistema, criação de um documento de requisitos seguindo os critérios estabelecidos para sua confecção e análise da viabilidade do projeto mediante o documento de requisitos. A organização realiza algumas outras atividades para a garantir o gerenciamento de requisitos: apresentação do documento de requisitos ao cliente para validação, ainda que não realizada formalmente; atualização do documento de requisitos em caso de modificação das especificações; apresentação dos requisitos à equipe de colaboradores para que também validem-no, e em alguns casos a criação de um protótipo. Atividades estas que ainda não foram incluídas no processo seguido atualmente pela organização. Algumas das atividades do processo de Coelho (2007), podem ser relacionadas ao processo de gerência de projetos, são elas: a 56

66 documentação de um diagrama de casos de uso e de um diagrama de classes, e análise da viabilidade do projeto. Já o registro das tarefas e do andamento das mesmas, para a geração de futuros relatórios e estimativas; apresentação do projeto aos interessados; e capacitação dos recursos humanos, não constam no processo descrito para a organização e são práticas exercidas atualmente. 4.3 Descrições dos projetos observados Dois projetos da organização foram observados, sendo um terminado e outro em execução, já que, como visto na seção 2.3.3, essa é a quantidade mínima de projetos que a organização deve possuir para que seja realizada uma avaliação do nível G do MPS.BR. Foram apontados indicadores diretos e indiretos, observados nesses projetos, para se atribuir um grau de implementação de cada resultado e atributo dos processos de Gerência de Requisitos e de Projetos, que são conforme mostrado na seção , os processos avaliados pelo nível G do MPS.BR. As planilhas com esses indicadores foram preenchidas juntamente com a unidade organizacional, conforme indica o MPS Guia de Avaliação (2009) planilhas disponíveis nos apêndice B, e nelas foi criada uma coluna observações onde, a partir dos dados repassados pelos colaboradores da organização por meio da planilha, foi feito um protótipo de avaliação de cada um dos resultados esperados e dos atributos de processo propostos pelo nível G do MPS.BR, bem como a análise da documentação e entrevistas realizadas com os colaboradores e demais responsáveis pelos projetos. 57

67 As próximas duas subseções descrevem alguns dos fatores observados nos dois projetos, conforme essas planilhas, entrevistas e documentos O projeto finalizado O projeto finalizado, chamado aqui de Projeto dois, consiste num sistema monousuário 1, portável 2, com banco de dados embutido, composto por cadastros e relatórios sobre funcionários, alunos e outros; com o objetivo de auxiliar no gerenciamento de uma escola. O patrocinador do projeto dois não reside na cidade onde a empresa está localizada, assim, o contato entre organização e cliente foi predominantemente por telefone e , havendo, conforme informado na entrevista com o responsável pelo projeto, duas ou três reuniões durante o mesmo. Depois de acordadas com o cliente as especificações do sistema, foi realizado por alguns participantes da organização, um estudo dessas especificações, e a partir delas foi confeccionado para o projeto um documento de requisitos bem detalhado, seguindo um padrão já existente na organização, onde os requisitos são divididos em funcionais e não funcionais e organizados em seções de acordo com seus atributos, sendo também atribuído a cada requisito um identificador único. Também é padrão do documento, que os requisitos sejam organizados em Essenciais (aquele sem o qual o sistema não pode funcionar), Importantes (o sistema 1 monousuário usado por um único usuário. 2 portável capaz de ser executado em várias arquiteturas 58

68 entra em funcionamento, mas não de forma satisfatória) e Desejáveis (o sistema funciona satisfatoriamente, por tanto estes podem ser deixados para versões posteriores). E ainda, que os requisitos sejam especificados de forma não ambígua, completa e consistente; podendo ser compreendidos, verificados, validados, modificados e rastreados. No documento de requisitos é também descrito, ainda que bem sucintamente, o objetivo do projeto e algumas características do cliente. Considerado pequeno, o projeto contou com a participação de dois colaboradores, escolhidos em reunião pela equipe, que utilizou o critério de maior experiência e conhecimento da tecnologia a ser utilizada. Os responsáveis pelo desenvolvimento associaram os requisitos a tarefas que foram dividas entre eles obedecendo-se as especificações do documento de requisitos, que foi o documento principal desse projeto. Foi acordado entre o cliente e a organização um prazo para a entrega do sistema, assim, a equipe de desenvolvimento visava cumprir o prazo de conclusão do projeto como um todo, já que não eram estabelecidos prazos isolados para o cumprimento as tarefas. Foi utilizado como instrumento de planejamento um check-list onde todas as tarefas foram anotadas pra verificação de sua execução. O projeto sofreu algumas modificações, tanto a pedido do cliente, quanto por necessidade da equipe de desenvolvimento. Essas mudanças foram tratadas informalmente perante os clientes e foram documentadas por meio da atualização do documento de requisitos, por isso houve quatro versões do documento. Um protótipo do sistema foi o artifício utilizado pela equipe para garantir um entendimento comum entre cliente e equipe de desenvolvimento sobre os requisitos do sistema. 59

69 O processo de desenvolvimento de software da organização, mostrado na seção 4.2, foi parcialmente utilizado pela equipe, ainda que de maneira intuitiva. Houve um atraso na entrega de 100% com relação ao tempo previsto, o que foi atribuído pela equipe à indisponibilidade de um dos colaboradores alocados para desenvolvimento do projeto. Após a entrega do produto algumas não conformidades tiveram de ser corrigidas. O atraso do projeto e a manutenção do sistema repercutiram no custo do sistema, que também excedeu o que estava previsto. O excesso de manutenção fez com que a organização preferisse refazer o sistema ao invés de realizar mais manutenções, o projeto foi refeito e atualmente o novo sistema está sendo desenvolvido O projeto em execução O projeto em execução, chamado de Projeto um, tem o objetivo de informatizar os principais setores de uma universidade, proporcionando o compartilhamento de dados entre os setores, sua confiabilidade e integridade, diminuição de tarefas repetitivas e de re-trabalho, e facilidade na tomada de decisões. O projeto é dividido em módulos implantados gradualmente, onde cada módulo corresponde a um setor da universidade e é composto por submódulos referentes às subdivisões dos setores. Devido à grande importância dos dados resguardados pelo sistema e da grande variedade e quantidade de usuários, o mesmo exige alta disponibilidade, confiabilidade, segurança, funcionalidade, manutenibilidade e eficiência. 60

70 Como a organização tem estreita relação com a universidade, cliente do projeto, o contato entre eles foi facilitado. Após reuniões com os patrocinadores, as necessidades apontadas por eles foram estudadas e posteriormente confeccionado o documento de requisitos nos mesmos padrões do projeto dois mostrado na seção , com a diferença de que, o escopo do projeto foi mais bem definido contendo de maneira sucinta seus objetivos, motivação para o projeto e seus limites; além de uma descrição bem detalhada do perfil do cliente. O Projeto um contou com a participação de seis colaboradores escolhidos da mesma forma que no projeto dois seção Foi todo documentado na ferramenta Dotproject 3, onde cada cliente da organização é cadastrado com todas as informações necessárias e seus contatos. Esses clientes são associados aos projetos, e estes divididos em tarefas, onde cada tarefa corresponde a um dos requisitos acordados com o cliente. Dependendo de sua complexidade e tamanho, as tarefas são subdivididas, mantendo registradas em cada uma, suas especificações, o colaborador responsável, a dependência com outras tarefas, o prazo, tempo estimado e tempo gasto para a execução. A figura abaixo ilustra a forma como cada,projeto é visualizado. Figura 4.2 Tela Projetos da ferramenta usada para Gerência de projetos (Fonte: Imagem cedida pela organização estudada). 3 Dotprojet - Sistema web livre utilizado para gerência de projetos 61

71 Cada participante do projeto visualiza suas atividades conforme mostrado na próxima tela. Para cada projeto que participa, ele visualiza as tarefas em desenvolvimento ou futuras, o nome da tarefa, suas especificações, seu criador, os usuários associados a ela, sua duração estimada, data de encerramento, entre outras informações. Figura 4.3 Tela Agenda do dia da ferramenta usada para Gerência de projetos (Fonte: Imagem cedida pela organização estudada). A ferramenta armazena também outros documentos necessários para a execução do projeto, entre eles: documento de requisitos, documento de casos de teste, diagramas de classe e do funcionamento do sistema. Além disso, a partir do registro diário das tarefas executadas pelos participantes do projeto, a ferramenta formula relatórios de produtividade individual e da equipe, e com relação ao prazo para o desenvolvimento do projeto. Todas as pessoas envolvidas com o projeto têm acesso a essa ferramenta, inclusive os clientes, que podem utilizá-la para acompanhamento e contato com a organização. 62

72 A ferramenta Mantis vem sendo estudada e será implantada a partir dos próximos módulos desse projeto com a finalidade de documentar e gerenciar falhas. O projeto sofreu modificações nos requisitos e prazos e estas foram tratadas da mesma forma que no projeto dois. O processo de desenvolvimento de software padrão da organização foi seguido sistematicamente pelos componentes da equipe, mas a ferramenta Dotproject, que auxiliaria no gerenciamento do projeto não foi bem utilizada pela maior parte dos colaboradores envolvidos. Desde o princípio foi identificado que haveria um atraso na entrega do produto, realmente houve esse atraso, mas ele não excedeu ao esperado. Segundo as afirmações nas entrevistas isso se deve a falhas no cumprimento do contrato por parte do cliente no que diz respeito a contratação de pessoal para o projeto Diagnóstico dos projetos A organização em questão, sendo uma empresa jovem, começa agora a se interessar pela implantação de processos para a melhoria da qualidade, visando solucionar alguns problemas como: Atraso nos prazos pré-definidos e consequentemente na entrega; Falta de comprometimento por parte de alguns clientes e colaboradores; Excesso de manutenção em projetos finalizados, havendo inclusive alguns projetos que atualmente estão sendo refeitos; 63

73 Re-trabalho, já que algumas não-conformidades do produto poderiam ser identificadas antes de seu completo desenvolvimento ou até mesmo de sua entrega; Estimativas incorretas de custo, escopo e tempo; A organização possui um processo de desenvolvimento de software definido, que como visto nas seções anteriores foi desenvolvido após o estudo do perfil da empresa e depois de sua implantação sofreu várias modificações até seu estado atual, mostrado na figura 3.1. Apesar de que, durante o período de análise deste trabalho, foi constatado que a organização adotou várias práticas para melhorar o resultado de seus projetos e essas práticas não foram percebidas dentro desse processo de desenvolvimento de software que é a diretriz para todos os projetos realizados pela organização. Comparando-se os dois projetos utilizados neste estudo de caso, podemos notar que a adoção de práticas para a melhoria do processo se intensificou durante a execução do Projeto um, como se pode observar nas planilhas de indicadores apêndices B. O projeto em andamento possui vários fatores que não estão presentes no projeto finalizado, o que demonstra a conscientização sobre a importância da melhoria de processos por parte da organização e conseqüente implantação de atividades que provoquem essa melhoria. Seguem abaixo algumas práticas, por meio das quais se pode notar a melhoria do projeto um em relação ao projeto dois: Melhor estruturação do documento de requisitos e melhor planejamento da interação entre as partes interessadas. Documentação de todas as tarefas e suas especificações. 64

74 Condições para que haja controle das atividades que estão sendo executadas. Levantamento de dados para futuras estimativas. Intensificação dos cursos de treinamento em novas tecnologias. Criação de diagramas de classe. A partir das informações recolhidas na empresa e análise dos atributos e resultados esperados para a obtenção do nível G do MPS.BR, oportunidades de melhoria a nível organizacional foram encontrados por meio da análise dos dois projetos: Falta de documentação da comunicação com o cliente e da concordância do mesmo com as especificações e com o próprio projeto, esse tipo de documentação é essencial para caso ocorra desencontro de informações entre a organização e o cliente, durante o projeto. Mudanças no projeto e nos requisitos não são tratadas e documentadas formalmente, além de que a análise de viabilidade dessas mudanças não é feita em conjunto com a equipe e nem documentada. Para que essa análise seja consistente é necessário que se consulte todos os envolvidos nas mudanças, bem como todas as partes do projeto que tenham relação direta ou indireta com a porção a ser modificada. O projeto fica inconsistente com o produto gerado, caso não haja a documentação das mudanças realizadas. Falta de documentação das reuniões e outros tipos de comunicação com os colaboradores, o que pode levar à falta de 65

75 comprometimento dos mesmos em relação ao projeto e possível divergência de entendimento sobre algum assunto discutido. Escopo parcialmente definido, o que impacta em futuras falhas nas estimativas de tempo, custo e tamanho do projeto e produto. Ausência de um processo de monitoramento e retorno dos gerentes de projeto sobre os resultados das atividades que estão sendo desenvolvidas, essa prática evitaria o re-trabalho, caso desvios do projeto fossem identificados antecipadamente. Falta de dados históricos para a estimativa de tempo e custo do projeto, o que impacta em futuras falhas no orçamento e cronograma. Não existe documentação sobre os riscos, falhas, problemas dos projetos e sobre ações corretivas, assim, as previsões desses eventos dependem da habilidade dos colaboradores da organização. Falta de documentação sobre a análise de viabilidade, caso fosse documentada, alguns aspectos dessa análise poderiam auxiliar em futuras análises necessárias durante o mesmo projeto ou em projetos similares. Não estabelecimento de marcos de revisão durante a execução do projeto. Conflitos tratados informalmente e sem o conhecimento de toda a equipe podem gerar futuras discordâncias sobre o projeto. Ausência da prática de registrar quais recursos, inclusive humanos, serão necessários e por quanto tempo serão utilizados 66

76 em determinado projeto, o que pode evitar que o mesmo recurso não seja alocado ao mesmo tempo a projetos diferentes. Ausência de um processo documentado de gerenciamento de projetos e requisitos eficaz, o que evitaria o seguimento intuitivo e informal de práticas organizacionais. Falta de motivação de alguns colaboradores em contribuir com a correta documentação das informações do projeto e em participar das ações de melhoria. Vários dos pontos mostrados anteriormente já são de conhecimento da organização, a qual já está planejando algumas melhorias a serem executadas a partir dos próximos módulos do projeto em andamento. Ainda que não obedeça a um processo documentado que inclua atividades de gerência de requisitos e gerência de projetos a serem desenvolvidas a nível organizacional; vários indicadores de resultados esperados pelo nível G do MPS.BR já podem ser, ainda que parcialmente, notados na organização, que atualmente estuda para fazer uso de outros artifícios para obter resultados positivos nos próximos projetos, alguns exemplos disso são: Estimativas de custos e prazos do projeto passarão a ser feitas a partir de dados históricos, primeiramente retirados do projeto um, cujos dados de produtividade já estão sendo registrados, e posteriormente da análise conjunta dos projetos que forem sendo finalizados. Definição mais detalhada do escopo e confecção de um plano do projeto, representado a partir da união de todos os planos que 67

77 atualmente são registrados separadamente na ferramenta Dotproject. Futura implantação da ferramenta Mantis, a partir do segundo módulo do Projeto um, para gerenciamento de falhas. Conscientização dos colaboradores quanto à importância de fornecerem informações corretas e periódicas à ferramenta de auxílio à gerência de projetos. Elaboração de um novo processo de produção de software, que inclua e padronize todas as atividades realizadas pela organização. Pode-se notar que apesar das várias ações de melhoria que a organização visa implantar e da notável evolução entre o projeto finalizado e o que está em execução, a ausência de processos de gerência de requisitos e de projetos definidos faz com que os colaboradores não tenham uma sequência predefinida de atividades a serem cumpridas para a geração de projetos e produtos de qualidade. As ações de melhoria devem ser planejadas, controladas e monitoradas para que passem a ser procedimentos padrão na organização e não atividades realizadas intuitivamente e sem conhecimento de seus propósitos e resultados. Sobre as evidências de que os atributos do processo são alcançados, nota-se que durante a execução dos projetos existe a preocupação que esse projeto obtenha sucesso, independentemente da aplicação ou não do processo pré-definido, embora a organização tenha consciência da dependência entre eles. 68

78 4.4 Proposta de melhorias Para que a organização adote o modelo MPS.BR, atendendo aos atributos e atingindo os resultados esperados nos processos abrangidos pelo nível G, seguem algumas sugestões de ações que podem contribuir para a melhoria: Trazer ao conhecimento de todos os colaboradores, as práticas de melhoria, conscientizando-os das melhorias que podem ser alcançadas a partir dessas práticas. Criação de registros da comunicação entre o cliente, colaboradores e a gerência da organização e documentação formal dos acordos estabelecidos. Criação de modelos para os documentos relacionados aos projetos, incluindo todas as especificações que deve conter no documento, visando evitar que alguma informação importante não seja levada em consideração. Apresentação e treinamento de todos os colaboradores sobre as novas práticas de gerência de projetos e de requisitos: suas atividades, fluxos, artefatos e papéis; e sobre o processo de documentação, incluindo as formas de armazenamento, tipos de modelos a serem utilizados, como e em que situações documentar. Escolha de colaboradores da organização para serem capacitados para o gerenciamento dos projetos e que se responsabilizem por garantir o entendimento e a aplicação das boas práticas dentro da organização. 69

79 Adoção da prática de monitoramento periódico das atividades que estiverem sendo realizadas, detectando desvios do processo. Obtenção do comprometimento de toda a equipe com a correta execução do processo definido e com o uso de todos os mecanismos de apoio a ele. Estabelecimento no plano do projeto, de marcos para a revisão do mesmo. Disseminação do conhecimento sobre cada projeto, deixando bem claro a todos os envolvidos o seu objetivo, motivação, necessidades dos clientes. Planejamento das formas de comunicação entre todos os envolvidos. Liberdade para que os colaboradores proponham melhorias que gerem maior qualidade dos projetos e produtos da organização, a diminuição de não conformidades e re-trabalho, e o crescimento da organização. A aplicação dessas melhorias somadas às que já estão sendo estudadas e aplicadas pela organização tendem a aproximar a mesma aos processos especificados no MPS.BR e a uma futura aderência ao modelo, garantindo para os atributos e resultados de processo do nível G, um grau de implementação entre Largamente e Totalmente Implementado. 4.5 Considerações sobre a avaliação Verificou-se que a organização possui um processo de desenvolvimento definido e que deveria ser utilizado como norte para 70

80 todos os projetos executados por ela, e esse processo é executado parcialmente. Visando a melhoria da qualidade de seus produtos e projetos a organização está começando a adotar algumas práticas para estabelecer um processo de gerência de requisitos e projetos. Como isto está sendo feito há pouco tempo ainda não existem resultados sobre a adoção dessas novas práticas e ainda existem vários outros pontos de melhoria a serem analisados e aplicados. Esses pontos devem ser incluídos no processo e esse processo mais bem conhecido e seguido pelos integrantes da organização, que devem estar conscientes dos benefícios de sua aplicação. Neste capítulo foram detalhados os projetos por meio dos quais foi gerado o protótipo de avaliação segundo os critérios do nível G do MPS.BR, feita uma análise crítica do processo de desenvolvimento seguido atualmente pela organização, demonstradas resumidamente algumas diferenças entre as formas de gerenciamento de ambos os projetos, citadas as práticas que a organização adotou para auxiliar no gerenciamento de projetos e apresentadas algumas sugestões de possíveis práticas a serem adotadas para a aproximação da organização aos processos englobados pelo nível G do MPS.BR. 71

81 5 CONCLUSÕES O trabalho objetivou avaliar os processos, práticas e resultados obtidos pelos projetos de uma organização, com base nas especificações do nível G do modelo MPS.BR, verificando seu nível de aderência e propondo sugestões de melhoria. Para isso foram realizadas pesquisas de campo e bibliográfica. A bibliográfica apontou conceitos de melhoria de processo e produto que mostram que para que uma organização se torne mais competitiva em determinado setor, inclusive na área de produção de software, é necessário que ela ofereça a seus clientes produtos de qualidade, ou seja, que correspondam a suas necessidades. E que atualmente o modelo mais adequado para pequenas empresas, como é o caso da organização estudada neste trabalho, é o modelo MPS.BR. Durante a pesquisa de campo foi possível identificar que os colaboradores mais antigos da organização, a partir de suas experiências com antigos projetos, já tinham consciência da importância da adoção de práticas para o gerenciamento de seus projetos e requisitos. Essa conscientização da organização e seu interesse para uma futura implantação de um modelo de melhoria de processo, visando a diminuição dos diversos problemas encontrados por ela atualmente, impactaram positivamente na pesquisa, já que trouxe ao pesquisador maior facilidade na busca de informações dentro da organização. É possível notar ainda que houve uma grande evolução entre o projeto que já havia sido terminado e o projeto em execução, sobretudo no que diz respeito à gerenciamento de projetos.

82 Por meio da descrição dos projetos, apresentação das oportunidades de melhoria em seus processos e planilhas de indicadores, o trabalho atingiu seu objetivo apresentando uma avaliação dos processos existentes na organização tendo como base os processos de Gerência de Requisitos e Projetos do MPS.BR. Com essa avaliação verificou-se que a organização realiza algumas atividades que a aproximam, ainda que parcialmente, da aderência aos processos do nível G do modelo. Assim, em seu estado atual não é possível afirmar que ela é aderente ao nível G do MPS.BR. Para sua maior aproximação desse objetivo, algumas sugestões de melhoria foram propostas. O trabalho mostrou o detalhamento da situação atual da organização com relação à cada resultado esperado e atributos dos processos de gerência de projetos e de requisitos, contribuindo assim para identificação das falhas e futura adequação dos processos da organização aos do nível G do modelo. Colaborou para o melhor entendimento da organização sobre os aspectos que estão sendo melhorados com a adoção de novas práticas durante a execução do projeto em andamento, além da identificação de pontos que devem ser melhorados. Trabalhos futuros são propostos como desdobramento deste: A proposta de um processo adequado à organização estudada, que inclua atividades para corrigir as não conformidades encontradas por meio deste estudo e padronizar as práticas atuais que colaboram para o bom gerenciamento de projetos e requisitos. 73

83 Aplicação das sugestões de melhoria apresentadas neste trabalho, para a verificação dos resultados, constatação das melhorias e nova verificação do nível de aderência da organização ao nível G. 74

84 6 REFERÊNCIAS BIBLIOGRÁFICAS BARRETO, R. S. Estudo e proposta de um processo de teste para uma cooperativa de software livre Monografia (Graduação em Ciência da Computação) Universidade Federal de Lavras, Lavras, MG. Disponível em: Acessado em Setembro de COELHO, A. C. Estudo e proposta de um processo de desenvolvimento de software em uma cooperativa de software livre Monografia (Graduação em Ciência da Computação) Universidade Federal de Lavras, Lavras, MG. Disponível em: Acessado em Setembro de ISO/IEC Information Technology - Software life cycle processes ISO/IEC 9126, International Standard. Information Technology Software Product Evaluation Quality characteristics and guidelines for their use JUNG, C. F. Metodologia para pesquisa & desenvolvimento aplicada a novas tecnologias, produtos e processos. Ed. Rio de Janeiro: Axcel Books, KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2ª edição. Ed. São Paulo: Novatec, MACHADO, C. Â. F. Definindo processos do ciclo de vida de software usando a norma NBR ISO/IEC Ed. Lavras/MG: FAEPE/UFLA, 2003.

85 MAGELA, R. Engenharia de software aplicada: fundamentos. 1ª edição. Ed. Rio de Janeiro: Alta Books, MAXIMIANO, A. C. A. Introdução a administração. 3ª edição. Ed. São Paulo: Atlas, MOREIRA, R. T. Gestão do Conhecimento em Qualidade de Software: Construção de um Portal da Qualidade de Software para o Brasil Monografia (Graduação em Ciência da Computação) Universidade Federal de Lavras, Lavras, MG OLIVEIRA, M. S. de. Qualidade na educação universitária Tese de Doutorado - Universidade de São Paulo USP, SP, Brasil. PAULA FILHO, W. de P. Engenharia de software; fundamentos, métodos e padrões. 2.ed. Ed. Rio de Janeiro: Editora LTC, PESSOA, M. S. de P. Introdução ao CMM-Modelo de Maturidade da Capacidade de Processo de Software. Ed. Lavras/MG: FAEPE/UFLA, PMBOK, Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, Norma Nacional Americana ANSI/PMI ª edição, Ed. Project Management Institute, PRADO, D. S. do, Gerência de projetos em tecnologia da informação. Ed. Belo Horizonte/ MG: Editora de Desenvolvimento, PRESSMAN, R. S. Engenharia de Software. 6ª edição, Ed. McGrawHill, RIBEIRO, A. F.; DUARTE, M. N. M.; Gerenciamento de projetos, MPS.BR e qualidade em software. In: Eventos Técnicos - PMIMG 2006: 6º Evento, Belo Horizonte-MG, Agosto de Disponível em: Acessado em agosto de

86 ROUILLER, A. C. Gerência de Projetos de Software. Ed. Lavras/MG: FAEPE/UFLA, SALVIANO, C. F. Melhoria e avaliação de processo com ISO/IEC (SPICE) e CMMI. Ed. Lavras/MG: FAEPE/UFLA, SALVIANO, C. F. Melhoria e Avaliação de Processo de Software com o Modelo ISO/IEC :2006. Ed. Lavras/MG: FAEPE/UFLA, SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral: Versão de atualizada em setembro de Disponível em: Último acesso em Outubro de Ocorrência: 2009a. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de implementação - Parte 1, Nìvel G. Versão Disponível em: cao_parte_1_2009.pdf. Último acesso em Outubro de Ocorrência: 2009b. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de avaliação. Versão Disponível em: pdf. Último acesso em Outubro de Ocorrência: 2009c. SOMMERVILLE, I. Software engineering. 8th edition. Ed. Harlow, England: Addison-Wesley, SPINOLA, M. de M. ISO 9000 para software. Lavras/MG: FAEPE/UFLA, ª edição. Ed 77

87 VASCONCELOS, A. M. L. de; MACIEL, T. M. de M. Introdução à engenharia de software e aos princípios de qualidade. Ed. Lavras/MG: FAEPE/UFLA, VASCONCELOS, A. M. L de; ROUILLER, A. C; MACHADO, C. A. F; MEDEIROS, T. M. M. Introdução à Engenharia de Software e à Qualidade de Software. Ed. Lavras/MG: FAEPE/UFLA, VASCONCELOS, A. M. L. de. Engenharia de Software para Software Livre 1. Ed Lavras/MG: FAEPE/UFLA, VILAS BOAS, A. L. de C. Qualidade e Avaliação de Produto de Software. Ed. Lavras/MG: FAEPE/UFLA, WEBER, K. C.; ROCHA, A. R.; ALVES, A.; AYALA, A. M.; GONÇALVES, A.; PARET, B.; SALVIANO, C.; MACHADO, C. F.; SCALET, D.; PETIT, D.; ARAÚJO, E.; BARROSO, M. G.; OLIVEIRA, K.; OLIVEIRA, L. C. A.; AMARAL, M. P.; CAMPELO, R. E. C.; MACIEL, T. Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira. In: XXX CONFERENCE LATINOAMERICANA DE INFORMÁTICA (CLEI2004), Arequipa, Peru, Setembro de YIN, R. K. Case study research: design and methods. 2nd. ed. Thousand Oaks, ZAMBALDE, A. L.; PÁDUA, C. I. P. S.; ALVES, R. M. O documento científico em Ciência da computação e Sistemas de Informação. Lavras/MG: Departamento de Ciência da Computação/Universidade Federal de Lavras,

88 APÊNDICE A Questionário de apoio às entrevistas No questionário de apoio, para cada resultado esperado dos processos avaliados, foram propostas perguntas por meio das quais se buscou de maneira imparcial verificar quais as possíveis práticas existentes na organização que pudessem levar ao alcance do respectivo resultado. Foi utilizado apenas para apoiar as entrevistas, a partir dessas perguntas surgiram as discussões sobre as práticas e problemas da organização. ENTREVISTA DE AVALIAÇÃO MPS.BR GERÊNCIA DE REQUISITOS GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos 1. Como vocês levantam as necessidades de seus clientes? 2. Os requisitos tem sofrido alterações após o início do projeto? 3. Onde e como essas necessidades são registradas? Qual o nível de detalhe desse registro? 4. Esse registro é aprovado por alguém? *Se sim:* 4.1.Por quem? 4.2.Quando? 4.3.A aprovação também é documentada? 5. O que garante que cliente e cooperativa têm o mesmo entendimento sobre essas necessidades? 6. Com base em quê a cooperativa assume que pode atender a essas necessidades? 7. Em algum momento o cliente pode mudar de ideia em relação ao que

89 ele julga necessário inicialmente? *Se sim: * 7.1.Qual o procedimento? GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido 1. Como é escolhida a equipe que trabalhará no projeto? 2. Como é feita a divisão de tarefas? 3. Como essa equipe conhece as necessidades do cliente? 4. O que garante que o trabalho executado por ela está de acordo essas necessidades? 5. Existe algum retorno ou aceite da equipe técnica com relação aos requisitos a serem satisfeitos? *Se sim:* 5.1. Isso é registrado de alguma forma? GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida 1. É possível mostrar que os produtos que estão sendo desenvolvidos são compatíveis com as necessidades dos clientes? 1.1. Quando isso é possível? 1.2. Como? GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos 1. Durante o processo de desenvolvimento é possível identificar se os planos estão caminhando para a geração de produtos conforme as necesidades dos clientes? 1.1. Quando? 2. Quando o cliente muda de opinião sobre alguma parte do produto, o que acontece com o que já foi ou está sendo produzido? GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto 1. Quando o cliente muda de opinião sobre alguma parte do produto ou 80

90 em relação ao projeto: 1.1. Qual procedimento é realizado? 1.2. Essa mudança impacta em quais níveis do projeto? 1.3. Existe algum tipo de registro sobre isso? 1.4. Existe algum tipo de estudo sobre essas mudanças? 1.5. Existe uma pessoa especifica para gerenciar essas mudanças? GERÊNCIA DE PROJETOS GPR1 - O escopo do trabalho para o projeto é definido 1. Como se define o que deve ser feito pelo projeto? Em que isso é baseado? 2. É possível que o projeto fuja de seu objetivo principal? 3. Como se garante que o foco do projeto se mantenha na satisfação das necessidades do cliente? 4. Vocês mantêm controle sobre o que é necessário ou não de ser gerado pelo projeto? 5. Isso é registrado de alguma forma? GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados 1. Como são planejadas as tarefas a serem realizadas durante o projeto? 1.1. Com a participação de quem? 1.2. Isso é registrado? 2. Como o trabalho definido no escopo é dividido em tarefas menores? É utilizada alguma estrutura de decomposição ou ferramenta para esse trabalho? GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos 1. Vocês utilizam algum modelo de ciclo de vida do projeto? *Se sim:* 1.1. Qual? 1.2. Como funciona? 81

91 1.3. É dividido em fases? *Se sim:* O que acontece ao final de cada fase? O que acontece caso ocorra algum problema com alguma tarefa que deveria ser realizada em determinada fase? GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas 1. O que é considerado para estimar o tempo necessário para a realização de cada uma das atividades do projeto? 1.1. E o esforço necessário? 1.2. E o custo gerado pelo desempenho de cada tarefa? 2. Isso é registrado? *Se sim:* 2.1. Esses registros são mantidos por quanto tempo na organização? 3. A produtividade da cooperativa de um modo geral também pode ser medida? *Se sim:* 3.1. Quando? 3.2. Como? GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos 1. A equipe tem prazo para o desenvolvimento de suas atividades? *Se sim:* 1.1. Onde esses prazos são definidos? 1.2. Por quem os prazos são definidos? 1.3. Eles costumam ser respeitados? 1.4. *Se existir fases no ciclo de vida do projeto:* Esses prazos definidos tem alguma relação com as fases do ciclo de vida do projeto? 2. Como os custos do projeto são repassados para os clientes? 3. Depois de estabelecidos os prazos eles costumam ter alterações? *Se sim:* 3.1. Como isso é gerenciado? 82

92 4. E o orçamento passado inicialmente para o cliente, costuma ser alterado? *Se sim:* 4.1. Em que condições? GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados 1. Quando começam um novo projeto é possível identificar possíveis problemas que ele possa apresentar futuramente? *Se sim:* 1.1. Quem faz essa análise? 1.2. Quando ela é feita? 2. Esses problemas podem ser evitados? *Se sim* 2.1. De que maneira? 2.2. Caso o problema não possa ser evitado, o que é feito? (* eles precisam de planos de mitigação*) GPR7 - Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo 1. Como são selecionadas as pessoas que participarão no projeto? 2. Que fatores são considerados para essa escolha? 3. Isso é registrado de alguma forma? 4. Como se garante que a pessoa terá capacidade para realizar as tarefas para as quais foi escalada? GPR8 - Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados 1. Como as pessoas envolvidas no projeto sabem quais recursos (equipamentos, serviços, ferramentas..) irão utilizar? 2. Quando isso é definido? 3. Isso é registrado de alguma forma? 4. Quem é responsável por isso? 5. O que garante que esses recursos estarão disponíveis quando necessários? 83

93 6. Os mesmos recursos são usados em mais de um projeto? *Se sim:* 6.1. Como são compartilhados? (* lembre que aqui pode-se ter compartilhamento de pessoas entre projetos também. *) GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança. 1 Dentre os listados abaixo, quais são tipos dados registrados pela cooperativa? 1.1 Relatórios 1.2 Informações passadas informalmente 1.3 Estudos e análises 1.4 Atas de reuniões 1.5 Documentação 1.6 Lições aprendidas 1.7 Artefatos gerados 1.8 Itens de ação 1.9 Indicadores. 2 Os dados que são coletados são armazenados de que forma? 3 Por quanto tempo? 4 Quem tem acesso a eles? GPR10 - Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos 1 Existe um plano geral que por meio do qual se tem uma visão de todos os planos específicos do projeto? 2 Quando um documento é consultado, o que garante que todos os outros que tenham relação com ele também serão consultados? GPR11 - A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados 1. O que garante que o projeto tem condições de atingir todas as suas 84

94 metas? 2. E que o projeto terá o retorno esperado? 3. A cooperativa faz algum tipo de análise para verificar se é possível satisfazer as necessidades do cliente? GPR12 - O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido 1. Quem são as pessoas envolvidas no planejamento do projeto? 2. Existe algum tipo de aprovação por parte dessas pessoas? 3. O que garante que o plano do projeto abrange todos os recursos necessários para a execução das tarefas de todas as pessoas envolvidas? 4. É possível prever se com o plano de projeto atenderá a todas as necessidades especificadas pelo cliente inicialmente? 5. Em relação ao plano do projeto existe algum tipo de retorno das pessoas envolvidas (clientes e equipe)? GPR13 - O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados 1. Durante o projeto existe algum guia, documento ou outro meio usado para orientar a ordem ou forma como as tarefas devem ser realizadas? 2. O que ocorre depois de terminada uma tarefa? Existe algum procedimento especifico a ser realizado, pessoa a ser comunicada ou registro feito? 3. Utilizam alguma ferramenta que auxilie na gerencia de projetos? GPR14 - O envolvimento das partes interessadas no projeto é gerenciado 1. Como os envolvidos no projeto (clientes e participantes da organização) sabem em que momento deverão atuar? Como eles são chamados a participar e quando? 2. Esse envolvimento é controlado de alguma forma? 85

95 GPR15 - Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento 1. Como se acompanha a execução do projeto? 1.1. Quando? 1.2. Quem está envolvido? 1.3. O que é tratado nesse tipo de revisão? 1.4. Existe registro? De que forma? GPR16 - Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas 1. O que acontece caso algum problema seja identificado? 2. Problemas que ocorrem no decorrer do projeto são registrados de alguma forma? 3. O que acontece com o projeto enquanto um problema está sendo solucionado? GPR17 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão 1. Quando detectado um problema, existe a possibilidade de evitar que ele possa ocorrer novamente? Como isso é feito? 86

96 APÊNDICE B Planilhas de apoio à avaliação da aderência ao Modelo MPS.BR Nível G As planilhas mostradas a seguir foram preenchidas a partir das informações fornecidas por dois gerentes de projeto da organização avaliada. Para compreendê-las melhor seguem algumas orientações: A primeira coluna da planilha corresponde aos indicadores apontados pela organização como evidências ou práticas que garantem a obtenção do respectivo resultado esperado, sendo que os indicadores são classificados como Diretos (ID), Indiretos (II) ou de Afirmação (IA) como mostrado na seção A segunda coluna da planilha é marcada quando a prática ou indicador da coluna A é adotada (o) a nível organizacional. Foram consideradas de nível organizacional as práticas que os colaboradores tinham conhecimento de que deveriam ser adotadas em todos os projetos da organização. A terceira coluna é marcada quando o indicador da primeira coluna foi detectado no projeto em andamento, chamado aqui de projeto um (P1); A quarta coluna é marcada quando o indicador da primeira coluna foi detectado no projeto finalizado, chamado aqui de projeto dois (P2); Após a listagem dos indicadores de cada resultado esperado ou atributo de processo existe uma linha com o seguinte texto: (T, L, P, N,

97 NA), onde é sugerida pelo pesquisador uma avaliação sobre a aderência àquele resultado esperado e observações que justificam o resultado estão contidas na quinta coluna da planilha. 88

98 89

99 90

100 91

101 92

102 93

103 94

104 95

105 96

106 97

107 98

108 99