ANÁLISE E VIABIALIDADE DE APLICAÇÃO DO PENSAMENTO ENXUTO PARA ATENDER OS PROCESSOS DE PRODUÇÃO DE SOFTWARE DO MODELO DE MATURIDADE MPS.

Transcrição

1 ANÁLISE E VIABIALIDADE DE APLICAÇÃO DO PENSAMENTO ENXUTO PARA ATENDER OS PROCESSOS DE PRODUÇÃO DE SOFTWARE DO MODELO DE MATURIDADE MPS.BR HELVIO JERONIMO JUNIOR (UENF) jeronimohjr@gmail.com Rogerio Atem de Carvalho (IFF/UENF) ratem@cefetcampos.br É crescente o número de organizações que desenvolvem software no Brasil, e muitas destas estão buscando certificar seus processos de produção de software, uma vez que a certificação proporciona uma série de vantagens às mesmas. Neste contexxto, se destaca o modelo de maturidade do Programa de Melhoria do Processo de Software Brasileiro (MPS.BR), tendo este como objetivo a qualidade no processo de desenvolvimento de software, buscando atender à realidade das empresas brasileiras desenvolvedoras de software e, apresentando custos de implementação relativamente menores em relação aos modelos internacionais de qualidade de software. No entanto, apesar do sucesso que o MPS.BR vem conseguindo, as empresas ainda encontram dificuldades em sua implementação, devido à complexidade dos processos tradicionais de produção de software utilizados, e, à relação custo beneficio a curto e médio prazo. Recentemente, princípios e técnicas do Pensamento Enxuto (PE) vêm sendo utilizados pelos Métodos Ágeis (MA) no processo de desenvolvimento de software. O PE é um conjunto de técnicas e princípios que surgiu no Sistema Toyota de Produção, e possui a capacidade de otimizar os processos e eliminar os desperdícios durante a execução dos mesmos. Dada a importância da qualidade no processo de desenvolvimento de software para as empresas brasileiras, este artigo apresenta uma proposta de modelo de mapeamento dos processos no desenvolvimento de software que fazem uso de métodos enxutos para os processos exigidos pelo MPS.BR. Espera-se que o modelo de mapeamento proposto possa contribuir com a análise e viabilidade do quanto o PE, utilizado por MA no desenvolvimento de software, pode ser transposto para atender aos processos exigidos pelo MPS.BR, podendo assim atender níveis de certificação desse modelo de maturidade. Palavras-chaves: Pensamento Enxuto, MPS.BR, Mapeamento, Desenvolvimento de Software.

2 Introdução O software destaca-se como um dos principais instrumentos estratégicos para as organizações, e vem sendo utilizado pelas organizações como instrumento de apoio às diversas atividades e à tomada de decisões (Cordeiro, 2010). Entretanto, apesar da importância de softwares no mercado como instrumento competitivo, produzir software com qualidade é ainda um grande desafio. Dada à importância do software, Pressman (2002) destacava que, a comunidade de software busca continuamente desenvolver soluções que tornem mais fácil, mais rápido e menos dispendioso o desenvolvimento de software com qualidade, objetivando a melhoria continua. Diante desta realidade, desde década de 90 percebe-se a evolução de normas e modelos de maturidade que buscam implementar programas de melhorias de qualidade e certificar os processos de desenvolvimento de software. Dentre estas se destacam: Capability Maturity Model Integration (CMMI) (SEI, 2010), ISO/IEC e ISO/IEC É pertinente destacar que algumas destas são baseadas em processos tradicionais de desenvolvimento de software. No Brasil a maioria das empresas desenvolvedoras de softwares é classificada como: micro, pequena e média, e tendem a enfrentar dificuldades na implementação dessas normas e modelos, uma vez que, fazem uso de processos tradicionais de desenvolvimento e trabalham com grandes lotes de processo. Sendo assim, empresas de grande porte são mais propensas a utilizar estas normas. Visando contribuir com soluções para este problema das empresas brasileiras desenvolvedoras de software, em 2003 foi lançado o Programa de Melhoria do Processo de Software Brasileiro (MPS.BR), para apoiar indústria brasileira de software, nos mercados interno e externo, através da melhoria e avaliação de processos e produtos de software (SOFTEX, 2011). Apesar do sucesso do modelo MPS.BR, é comum um considerável desperdício de tempo e esforço para gerir a execução dos processos em grandes lotes executados por este modelo. Além disso, a falta de orientação no gerenciamento das atividades necessária para a implantação do modelo e a falta de flexibilidade para adaptar-se as mudanças causam desperdício (CARVALHO E SILVA, 2011). Segundo Carvalho e Silva (2011), este paradoxo é semelhante ao enfrentado pela empresa Toyota Automotors quando o processo produtivo vigente era de grande escala de produção, padronizada pelo sucesso da Ford Auto Motors. Ohno (1997) ressalta que, a impossibilidade de seguir os padrões industriais vigentes foi um dos fatores que direcionaram o desenvolvimento do Sistema Toyota de Produção (STP). Estabelecendo uma relação da grande escala de produção e o surgimento do STP com o desenvolvimento de software, verifica-se que em contrapartida aos processos tradicionais de desenvolvimento de software, no qual estes executam as atividades em grandes lotes de processos; destacam-se as abordagens ágeis tais como: extreme Programming (XP), SCRUM, SCRUMBAN e Lean Software Development (LSD), sendo a última baseada em princípios do Pensamento Enxuto (PE) que foi fundamentado no STP. Neste contexto, uma ferramenta apontada para otimizar os processos e, que vem aos poucos sendo utilizado por abordagens ágeis no desenvolvimento de software é o PE. Porém este é 2

3 pouco explorado no processo de desenvolvimento de software dentro da Engenharia de Software (ES). Os autores Poppendieck (2002; 2007), Poppendieck e Poppendieck (2003; 2006), Carvalho e Silva (2011) e Anderson (2010) fornecem um mapeamento detalhado dos princípios do PE para o desenvolvimento de software, demonstrando que é possível utilizá-lo para otimizar os processos no ciclo de desenvolvimento de software. Carvalho e Silva (2011) e Anderson (2010) acrescentam a possibilidade de aplicar o PE para apoiar a implementação de programas de melhoria no processo de desenvolvimento de software, tais como o CMMI e MPS.BR. Devido à escassez do PE utilizado pela ES, a aplicação de métodos enxutos em programas de melhoria de qualidade do processo de desenvolvimento de software é pequena, merecendo uma abordagem exploratória, de forma a contribuir com processo produtivo de software. Sendo assim, este trabalho levanta o seguinte questionamento: É possível aplicar o PE para os processos de desenvolvimento de software exigidos pelo MPS.BR? Diante dos fatos expostos e do questionamento levantado, é apresentado neste artigo uma proposta para analisar a viabilidade e verificar se o PE utilizado no desenvolvimento de software pode ser mapeado para os processos exigidos pelo MPS.BR e ainda, verificar o quanto os métodos enxutos, a luz de um modelo de maturidade voltado para certificação, podem ser utilizados para otimizar os processos na produção de software Este artigo esta estruturado da seguinte forma: a seção 2 traz considerações acerca do mercado brasileiro de software; a seção 3 apresenta as principais características modelo MPS.BR; a seção 4 aborda de forma sucinta o PE utilizado na produção de software. Posteriormente na seção 5 à metodologia proposta por este trabalho é detalhada e, por fim, a seção 6 apresenta as considerações finais, seguidas das referências e anexo. 2. O Mercado Brasileiro de Software O mercado de software e seus serviços correlatos vêm se destacando nos últimos anos. A Figura 1 apresenta a evolução do mercado brasileiro de software e serviços, ilustrando a movimentação em bilhões de dólares e o índice de crescimento no decorrer dos anos. 3

4 Figura 1. Indicadores do mercado brasileiro de software e serviços (ABES, 2011) Segundo a ABES (2011) em 2010 foram identificadas mais de empresas. Destas, 50,1% são dedicadas a Distribuição e Comercialização; 25, 2% a Prestação de Serviços e, 24,7% atuam no Desenvolvimento e Produção de Software, estas, totalizam 2.117, e podem ser classificadas como: Micro, Pequena, Média e Grande, são de suma importância. A Tabela 1 ilustra a relação entre elas e ao total de empresas do ramo de desenvolvimento e produção. Tabela 1. Índice de empresas atuantes no desenvolvimento e produção de software no Brasil Fonte: ABES (2011). Os dados da Tabela 1 demonstram que a maioria das empresas que atuam no desenvolvimento e produção de software são do tipo Micro e Pequena. Esses números indicam a importância que este mercado conquistou, tornando-se um dos mais importantes setores para o desenvolvimento econômico. Com o crescimento do mercado de software no país, e de acordo com as exigências do mercado interno e externo, muitas empresas deste setor buscam certificações de qualidade para seus produtos e processos, e almejam desenvolver software com o mínimo de recursos desperdiçados visando atender a demanda com qualidade. 4

5 3. O Modelo de Melhoria do Processo Brasileiro Software Por necessitar de recursos financeiros de valor elevado, o modelo de maturidade internacional, CMMI, não é muito utilizado pelas empresas de pequeno e médio porte. Neste contexto, a Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) implementa no Brasil, um Programa de Melhoria do Processo de Software (MPS.BR), que visa ser compatível com o modelo CMMI, e oferece mecanismos que facilitam a implantação em empresas de pequeno e médio porte (CARVALHO e SILVA, 2011). O MPS.BR tem como objetivo definir e aprimorar um modelo de melhoria e avaliação de processo de software, visando preferencialmente às micro, pequenas e médias organizações, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software (WEBER et al., 2004; WEBER et al., 2005; ROCHA et al., 2007; SOFTEX, 2011). Neste contexto, o modelo MPS possui três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS) (SOFTEX, 2011), dando sustentação e garantindo que o modelo esteja sendo empregado de forma coerente com as suas definições, conforme ilustrado pela Figura 2. Figura 2. Componentes do Modelo MPS (SOFTEX, 2011) A base técnica para a construção e aprimoramento do modelo de melhoria e avaliação de processo de software é composta pelas normas ISO/IEC (ISO/IEC, 1995), suas emendas 1 (ISO/IEC, 2002b) e 2 (ISO/IEC, 2004) e, pela ISO/IEC (ISO/IEC, 2002a) e suas emendas 2 (ISO/IEC, 2003) e 7 (ISO/IEC, 2008). Além destas, o modelo também cobre o conteúdo da versão 1.3 do CMMI (SEI, 2010), estando compatível com o mesmo. O modelo MPS.BR define sete níveis de maturidade, representando os estágios de melhoria da implementação de processos nas organizações conforme ilustrado no Quadro 1. 5

6 Quadro 1. Níveis de Maturidade do MPS.BR (SOFTEX, 2011) AP = Atributos de Processo. Os níveis de maturidade definidos pelo modelo são: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado), sendo que a escala de maturidade se inicia no nível G e progride até o nível A. Para as organizações alcançarem um determinado nível de maturidade do MPS.BR, todos os Resultados Esperados (RE) dos processos deste nível devem ser atendidos. Atualmente a melhoria de processos de software tem ocorrido cada vez mais em consonância com o MPS.BR. Até agosto de avaliações MPS foram realizadas em empresas em todo Brasil, sendo assim, pode-se dizer que esse modelo tem contribuído com o aumento da qualidade de software (TRAVASSOS e KALINOWSKI, 2011). Com relação à gestão de processos, o MPS.BR não preconiza diretamente um fluxo contínuo e unitário, fato que pode gerar grandes estoques, e ineficiências durante a implantação da melhoria de processos, existindo muitas vezes esforços que não agregam, eficientemente, valor final ao processo que possa impactar no valor final do produto. 4. Pensamento Enxuto no Desenvolvimento de Software Antes de abordar a aplicação do PE no desenvolvimento de software é necessário destacar o papel e a origem dos MA, pois através destes, os princípios do PE são empregados no desenvolvimento de software. Os MA são um conjunto de práticas assimiladas de diversas áreas que se concentram em boas soluções. No contexto da produção são baseados no conhecimento do fluxo de trabalho para manter seu processo. A origem dos métodos enxutos (lean) de produção é baseada no setor manufatureiro norteamericano quando as fábricas japonesas utilizavam eficientemente as práticas da Produção 6

7 Enxuta no fim da década de 80. Nesta época, os MA baseavam em princípios da Produção Enxuta e, posteriormente, em 1990 James Womack e Daniel Jones introduziram alguns elementos que ampliaram a concepção inicial e desenvolveram um novo conceito denominado Pensamento Enxuto (PE) (WOMACK et al., 1997). O PE 1 é um conjunto de técnicas e princípios que permitem que as empresas eliminem desperdícios durante o processo de produção, minimizando os custos, sem abrir mão da qualidade, garantindo que, o cliente receba somente aquilo que solicitou e especificou, no momento e na quantidade requisitada. A essência da abordagem enxuta demonstra que este pode ser estendido além da produção automobilística, para qualquer setor, assim como para o desenvolvimento de software. Na produção manufatureira, o PE conduziu a partir de 2001 o surgimento de MA no desenvolvimento de software tais como: extreme Programming (XP), Scrum, Feature Driven Development e etc. Estes vêm sendo largamente utilizados no desenvolvimento de software, porém Anderson (2010) ressalta que falham ao interpretar pontos chaves da Produção Enxuta, uma vez que, esta vai além do desenvolvimento ágil, oferecendo uma perspectiva mais abrangente. Alguns conceitos e princípios do PE já foram mapeados para o desenvolvimento de software, conforme ilustrado pela Figura 3, dando origem a abordagens enxutas para produção de software. 1 O PE assim como a Produção Enxuta, tem suas raízes no Sistema Toyota de Produção (SPT) proposto por OHNO em 1988, no qual o STP visava à eliminação de desperdícios com a finalidade de proporcionar a Toyota a capacidade de competir em um ambiente turbulento, com demandas diferenciadas e com crescimento econômico lento. 7

8 Figura 3. Princípios Enxutos no Desenvolvimento de Software O PE aplicado ao desenvolvimento de software define a execução dos processos em um fluxo unitário, buscando eliminar qualquer fonte de estoque desnecessário, atendendo dentre outros, os seguintes princípios: especificação e identificação da cadeia de valor, planejamento do fluxo de valor dos processos, execução dos processos e atividades quando os requisitos forem solicitados atendendo a demanda e ampliação do aprendizado da equipe. 5. Metodologia Proposta A seguir é detalhada a metodologia proposta neste trabalho para mapear as práticas de um determinado Método Ágil (MA) que utiliza os princípios do Pensamento Enxuto (PE) na produção de software para os Resultados Esperados (RE) dos processos do MPS.BR. Isto será realizado através de um Estudo de Caso. Segundo Martins (2008), o Estudo de Caso pede avaliação qualitativa, que possibilita a descrição, compreensão e, a interpretação de fatos e fenômenos, identificando assim os fenômenos da realidade social, fato que não é conseguido plenamente pela avaliação quantitativa. No entanto, Malhotra (2006) considera que combinar pesquisas qualitativa e quantitativa pode fornecer uma compreensão muito rica. Tal fato pode auxiliar na formulação de estratégias bem sucedidas. Logo, a metodologia de pesquisa proposta neste trabalho se classifica como qualitativa e quantitativa, além de ser empírica exploratória, uma vez que envolve a construção de 8

9 hipóteses, levantamento bibliográfico dos temas relacionados, Estudo de Caso através de Grupos de Focos e aplicação de questionários. 5.1 O Estudo de Caso A metodologia proposta será executada através de um Estudo de Caso que será realizado na Biblioteca Digital (BD), um dos projetos de software desenvolvidos pelo Núcleo de Pesquisas de Sistemas de Informação (NSI) do Instituto Federal Fluminense (IFF). O NSI trabalha aproximadamente 11 anos em parcerias com empresas internacionais e nacionais e, em projetos do governo. Este núcleo de pesquisa utiliza MA e, recentemente vem utilizando os princípios e métodos do PE no processo de desenvolvimento de software. Serão mapeados os processos leans de desenvolvimento de software utilizado pelas metodologias XP e Scrum, estas que por sua vez, são utilizadas no desenvolvimento da BD. A BD é desenvolvida sobre encomenda da Secretária Profissional e Tecnológica (SETEC) do Ministério da Educação e Cultura (MEC), um dos órgãos do Governo Federal. O desenvolvimento da BD é praticado conforme preconizado pelos métodos enxutos. 5.2 Etapas da Metodologia A Figura 4 ilustra o modelo conceitual e as etapas da metodologia proposta. Nas subseções a seguir cada etapa é detalhada. Figura 4. Etapas da Metodologia Proposta Identificar as vantagens e dificuldades na implantação do MPS.BR (Etapa 1) 9

10 Nesta etapa da metodologia, um questionário será aplicado a um grupo de implementadores do MPS.BR e, posteriormente entrevistas serão realizados a um pequeno grupo de Gerentes (Gerentes de Projeto e Desenvolvimento) da BD com o objetivo de confrontar os dados coletados através do questionário com a opinião dos Gerentes da BD. O questionário é dividido por dimensões e cada uma dessas é constituída por um bloco de critérios. Quanto às dimensões e critérios existentes no questionário, estas foram escolhidas com base em literaturas concernentes (ROCHA, MONTONI, SANTOS et al., (2005); HAUCK, WANGENHEIM, THIRTY (2007)), no qual estas foram utilizadas para identificar os fatores de sucesso, vantagens e dificuldades na implementação de processos de melhoria de software. As dimensões deste questionário encontram-se descritas no Anexo A deste artigo. As perguntas deste questionário são tipo fechado e para julgar estas a escala de Likert de 5 pontos será utilizada para identificar o grau de concordância, sendo esta a saber: Quadro 2. Escala para julgamento das vantagens e dificuldades da utilização do MPS.BR Como é possível observar no Quadro 2, o valor 5 refere-se a um critério no qual o grau de concordância é Concordo Totalmente e, o valor 1 refere-se a um critério no qual o grau de concordância é Discordo Totalmente Relacionar Práticas (Etapa 2) Esta etapa consiste em duas fases, sendo estas: (1) Relacionar as práticas de cada processo existente nos 7 níveis de maturidade do MPS.BR Busca-se nesta fase identificar como os processos do MPS.BR e os RE são executados. Para isto, será realizada uma análise documental com base no Guia de Implementação deste modelo e, entrevistas e grupos de focos serão realizados com implementadores deste modelo. As variáveis existentes nesta fase a serem mensuradas são: (i) independentes: as práticas executadas nos processos do modelo MPS.BR e, (ii) dependentes: os processos existentes e cada nível do MPS.BR, os RE de cada processo e o nível maturidade. (2) Relacionar as práticas dos princípios do PE utilizado pelos MA no processo de desenvolvimento de software No que tange o levantamento das práticas dos princípios do PE utilizado pelos MA no desenvolvimento de software, será analisada e relatada à execução das atividades no desenvolvimento da BD. Visa-se identificar para os princípios do PE e seus respectivos métodos, quais os benefícios destes aplicados ao desenvolvimento de software, sendo possível identificar à dinâmica e o fluxo da execução dos processos neste projeto. Para conduzir esta fase da metodologia, entrevistas e grupos de focos serão realizados com os Gerentes deste projeto para obter os métodos de desenvolvimento de software adotados. 10

11 As variáveis presentes nesta fase são: (i) independentes: as práticas executadas pelas MA que utilizam os princípios e métodos do PE e; (ii) dependentes: princípios e métodos enxutos do PE aplicado ao desenvolvimento de software Realizar Mapeamento (Etapa 3) Esta etapa consiste na estruturação de um mapeamento das práticas dos MA que utilizam os princípios do PE para as práticas executadas nos processos do modelo MPS.BR. Este mapeamento será realizado com base nos dados obtidos na Etapa 2. Para a estruturação do mapeamento a ferramenta 5W1H será utilizada, no qual esta possibilita de forma estruturada identificar os processos e conhecer os mesmos, sendo esta direcionada para programas de melhorias. Os seguintes níveis de atendimento serão verificados neste mapeamento. - Será verificado o nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE em relação ao RE de cada processo do MPS.BR. Para isso as seguintes condições foram estabelecidas: Quadro 3. Classificação do nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE Resultados esperados de cada processo = Expressa o conceito de em relação. A partir desta classificação, posteriormente é possível: - Verificar o nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE em relação a cada processo de cada nível do MPS.BR, segundo as seguintes condições: Quadro 4. Classificação do nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE Cada processo de cada nível do modelo de maturidade E a partir da classificação obtida de acordo com as condições apresentadas no Quadro 4 é possível: - Verificar o nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE em relação a cada nível do MPS.BR, segundo as seguintes condições: 11

12 Quadro 5. Classificação do nível de atendimento das práticas executadas pelo MA que utiliza os princípios e métodos do PE A cada nível do modelo de maturidade MPS.BR 4) Apresentar Modelo Mapeado (Etapa 4) Esta etapa consiste em apresentar um modelo contendo o mapeamento realizado destacando assim, os níveis de atendimento e quais princípios do PE estão presentes nestes. 5) Analisar Modelo (Etapa 5) Após obter um modelo de mapeamento contendo seus respectivos níveis de atendimento, é possível realizar uma análise sobre os resultados e, se necessário pode fazer o uso de técnicas estatísticas para obter interpretações minuciosas dos dados. De acordo com os resultados obtidos será possível: Discutir quais processos e níveis do MPS.BR são mais propensos a serem implementados por práticas executadas pelos MA que utilizam os princípios do PE; Identificar quais princípios do PE são mais utilizados para otimizar os processos e reduzir custos de produção no desenvolvimento de software; Identificar quais níveis e processos do MPS.BR apresentam dificuldades na implementação por parte de organizações que utilizam MA sob influência do PE e; Discutir como determinados RE poderiam ser atendidos pelas práticas ágeis que utilizam princípios do PE. 6. Considerações Finais Para alcançar destaque no mercado, a maioria das empresas desenvolvedoras de software estão buscando inserir qualidade nos seus processos de produção e certificá-los, porém desejam também atender a demanda com o mínimo de recursos desperdiçados e entregar os softwares desenvolvidos o mais rápido possível aos seus clientes. Visando contribuir com essa problemática, neste trabalho é apresentada uma proposta de metodologia, buscando responder a questão chave que foi levantada inicialmente, uma vez que o PE é apontado em possuir a capacidade de otimizar os processos, bem como reduzir os custos na produção, independentemente do setor é ramo de atividade. Espera-se que através da metodologia proposta seja possível analisar e verificar a viabilidade do quanto os métodos enxutos utilizado pelos MA podem ser aplicados ao desenvolvimento de software sob a ótica dos processos exigidos pelo modelo de maturidade MPS.BR. Sendo 12

13 assim, possível atingir níveis de certificação desse modelo e contribuir com o processo de melhoria da qualidade no desenvolvimento de software. Referências Bibliográficas ABES Associação Brasileira de Empresas de Software. Mercado Brasileiro de Software Panorama e Tendências, ANDERSON, D. J. Kanban: Successful Evolutionary Change for your Technology Business. Blue Hole Press,WA, Sequim., p.262, CARVALHO E SILVA, F. L. Mapeamento e Aplicação da Produção Enxuta para o Processo de Desenvolvimento de Software. Dissertação (mestrado) - Universidade Estadual do Norte Fluminense. Engenharia de Produção, CORDEIRO, A. G. Priorização de requisitos e avaliação da qualidade de software segundo a percepção dos usuários. Dissertação (mestrado) - Universidade Estadual do Norte Fluminense. Engenharia de Produção, ISO/IEC, Information Technology Software Life Cycle Processes, ISO/IEC, Information Technology Process Assessment. Part 1 Concepts and vocabulary; part 2 Performing an assessment; part 3 Guidance on performing an assessment; part 4 Guidance on use for process improvement and process capability de termination; and part 5 An exemplar process assessment model, 2002a. ISO/IEC, PDAM Information Technology - Amendment to ISO/IEC 12207, 2002b. ISO/IEC, PDAM Information Technology - Amendment to ISO/IEC 12207, ISO/IEC, Information Technology - Process Assessment Part 2 - Performing an Assessment, ISO/IEC, TR Information Technology - Process Assessment - Part 7: Assessment of organizational maturity, HAUCK, J., WANGENHEIM, C. G. & THIRY, M. Suportando a Modelagem de Processo de Monitoração e Controle em Micro e Pequenas Empresas, Alinhado ao CMMI, MPS.BR e ISO/IEC SBQS (Simpósio Brasileiro de Qualidade de Software) Porto das Galinhas, PE, MARTINS, G. A. Estudo de Caso: uma Estratégia de Pesquisa. 2ª. Ed, São Paulo : Atlas, MALHOTRA, N. K. Pesquisa de Marketing: uma Orientação Aplicada. 4. ed. Porto Alegre: Bookman, OHNO, T. O Sistema Toyota de Produção: além da produção em larga escala. Bookman, Porto Alegre, p.151, POPPENDIECK, M. & POPPENDIECK, T.: Lean Software Development: An Agile Toolkit for Software Development Managers. 1. ed. Boston: Addison-Wesley Professional Implementing Lean Software Development: From Concept to Cash POPPENDIECK, M. Principles of Lean Thinking. Poppendieck.LLC 7666 Carnelian Lane Eden Prairie, MN 55346, USA, Lean Software Development. 29th International Conference on Software Engineering. IEEE, PRESMAN, R. S. Engenharia de Software. 5.ed. Rio de Janeiro: McGraw-Hill, ROCHA, A. R. C., MONTONI, M., WEBER, K.C., et al. "A Nationwide Program for Software Process Improvement in Brazil". In: Quality of Information and Communications Technology, QUATIC th International Conference on the, pp , Lisboa, Portugal, September ROCHA, A. R., MONTONI, M., SANTOS, G., et al. Fatores de Sucesso e Dificuldades na Implementação de Processos de Software Utilizando o MR-MPS e o CMMI. In: Encontro de Implementadores do MPS.BR, Brasilia,

14 SEI, CMMI for Development (CMMI-DEV), Version 1.3, Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. SOFTEX, MPS.BR - Guia Geral. ISBN Disponível em: Acesso em Janeiro de TRAVASSOS, G. H. & KALINOWSKI, M. imps 2008: Informações para acompanhar e evidenciar variação de desempenho nas empresas que adotaram o Modelo MPS. Relatório Técnico do Projeto imps, TRAVASSOS, G. H. & KALINOWSKI, M. imps Caracterização e Variação de Desempenho de Organizações que Adotaram o Modelo MPS. Campinas, SP: SOFTEX, ISBN: , WEBER, K. C., ARAUJO, E. E. R., ROCHA, A. R., MACHADO, C. A. F., SCALET, D. & SALVIANO, S. F. Brazilian software process reference model and assessment method. In: Computer and information sciences, ISCIS 2005, 20th international symposium, proceedings, Vol NCS, pp , Istanbul, Turkey, October 26-28, WEBER, K. C., ROCHA, A. R., MONTONI, M., et al. Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira. Anais da Conferência Latino-Americana de Informática, Vol. 30, pp , Arequipa, Peru WOMACK, J., JONES, D. & ROOS, D. A máquina que mudou o mundo. Rio de Janeiro, Ed. Campus, Agradecimentos Os autores agradecem ao apoio fornecido pela Fundação Carlos Chagas Filho de Amparo à Pesquisa do Estado do Rio de Janeiro (FAPERJ) e pela Universidade Estadual do Norte Fluminense Darcy Ribeiro (UENF). 14

15 ANEXO A: Dimensões do instrumento de coletas de dados a ser aplicado aos implementadores do modelo MPS.BR na 1ª Etapa da Metodologia Proposta. 15