Fasci-Tech MAPEAMENTO ENTRE AS PRÁTICAS DO SCRUM E OS PROCESSOS DO NÍVEL G DO MPS.BR

Transcrição

1 MPEMENTO ENTRE S PRÁTICS DO SCRUM E OS PROCESSOS DO NÍVEL G DO MPS.BR Sheila Moutinho Lima 1 Prof. MSc. Wilson Vendramel 2 RESUMO: Este trabalho pretende realizar um mapeamento entre as práticas da metodologia ágil Scrum e os processos do modelo de maturidade MPS.Br, nível G, visando a identificação das consistências que há entre eles. O principal objetivo desta análise é demonstrar que há possibilidades das organizações que utilizam o Scrum - método ágil que enfatiza mais a produção do software do que a documentação - poderem alcançar maturidade em seus processos de desenvolvimento, através da aquisição de certificação do MPS.Br. O mapeamento permite a visualização das adaptações que devem ser realizadas para a utilização do Scrum em conjunto com o MPS.Br pelas empresas. Palavras-Chave: Metodologia Ágil; Scrum; MPS.Br; Qualidade de Processo. BSTRCT: This work intends to carry out a mapping between the practices of agile methodology Scrum and MPS.Br maturity model, the level G, for the identification of consistency there is between them. The main objective of this analysis is to demonstrate that there are possibilities of organizations using Scrum - gile method that emphasizes more the production of software than the documentation - that can reach maturity in their development processes, through the acquisition of certification MPS.BR. The mapping allows visualization of the adjustments that must be made for the use of Scrum in conjunction with the MPS.Br by the companies. Keywords: gile methodology; Scrum; MPS.Br; Quality Process 1. INTRODUÇÃO s metodologias ágeis, como o próprio nome diz, foram criadas para agilizar os processos de desenvolvimento de software, visando à entrega do produto de software ao 1 luna de Iniciação Científica do Curso de Bacharelado em nálise de Sistemas e Tecnologia da Informação da FTEC-São Caetano do Sul. 2 Professor das FTECs São Caetano do Sul e Zona Leste (Orientador do Trabalho).

2 cliente com maior rapidez e eficiência. Essas metodologias são voltadas ao produto, ou seja, desenvolver em tempo hábil um aplicativo sem a necessidade de produção de diversas documentações. Entre as metodologias ágeis existentes, o Scrum, foi escolhido como objeto de estudo nesse trabalho. O Scrum, segundo Martins (2007b), é adaptativo e empírico, ou seja, possui maior flexibilidade no desenvolvimento de software, ao contrário dos métodos tradicionais que são bastante prescritivos, forçando os envolvidos em um projeto a seguirem uma sequência predefinida de passos. O MPS.Br (Melhoria do Processo de Software Brasileiro) é um modelo de maturidade de processo de desenvolvimento de software, que é coordenado pela SOFTEX (ssociação para Promoção da Excelência do Software Brasileiro), com base no modelo de maturidade internacional, o CMMI DEV (Capability Maturity Model Integration for Development), com o objetivo de atender a pequenas e médias empresas, que possuem menos recursos do que as grandes organizações para investirem em uma certificação internacional. Neste trabalho pretende-se analisar as práticas do Scrum com relação ao MPS.Br destacando as características dessa metodologia ágil que estão em consonância com as diretrizes do MPS.Br nível G, para com isso traçar possíveis necessidades de adequação. escolha do nível G de maturidade se deve ao fato de que ele trata, particularmente, do gerenciamento de requisitos e de projeto e é o primeiro nível de certificação que uma empresa adquire. 2. MPS.BR Em dezembro de 2003, a associação para a promoção da excelência do software brasileiro criou o modelo de Melhoria do Processo de Software Brasileiro (MPS.Br). Este modelo visa o aumento da qualidade dos processos de desenvolvimento de software em organizações que não possuem tantos recursos para investimentos em qualidade. O MPS.Br não define novos conceitos, mas adéqua as estratégias de implementação à realidade brasileira (WEBBER et al., 2004 apud SNTN; TIMÓTEO; VSCONCELOS, 2006, p. 134).

3 Segundo a SOFTEX (2009c), o objetivo do programa MPS.BR é adequá-lo ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas, além de procurar ser compatível com os padrões de qualidade aceitos internacionalmente. Santana, Timóteo e Vasconcelos (2006) apontam que o MPS.Br tem um foco maior no gerenciamento do processo utilizado pela organização, não indicando a maneira como realizar determinadas tarefas, mas sim, o que deve ser feito para que a empresa atinja determinado nível de maturidade, sendo que, segundo Webber et al. (2004 apud SNTN; TIMÓTEO; VSCONCELOS, 2006, p. 135), o progresso e o atendimento do nível de maturidade se obtêm quando são atendidos todos os resultados e propósitos do processo e os atributos de processo relacionados àquele nível e aos anteriores. Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria de implantação de processos na organização. O MPS.BR define sete níveis de maturidade que são apresentados na figura 1. escala de maturidade se inicia no nível G e progride até o nível, sendo que o nível G é o que será enfatizado neste trabalho. Figura 1 - Níveis do MPS.Br Fonte: Mountain goat software, 2011.

4 2. 1 NÍVEL G DO MPS.BR De acordo com a SOFTEX (2009b), o nível G deve ser implementado com cautela por estabelecer o início dos trabalhos em implantação de melhoria dos processos de software na 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. No nível G, o projeto pode usar os seus próprios padrões e procedimentos, não sendo necessário que se tenha padrões em nível organizacional. Este nível é composto pelos processos Gerência de Projetos e Gerência de Requisitos, dos quais são esperados os resultados que são apresentados nos quadros 1 e 2. GPR1 GPR2 GPR3 GPR4 GPR5 GPR6 GPR7 GPR8 GPR9 GPR10 GPR11 GPR12 GPR13 GPR14 GPR15 Quadro 1- Gerenciamento de Projeto (adaptado) GERENCIMENTO DE PROJETOS O escopo do trabalho para o projeto é definido s tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados O modelo e as fases do ciclo de vida do projeto são definidos (té 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 O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados 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 Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados O envolvimento das partes interessadas no projeto é gerenciado Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento

5 GPR16 GPR17 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 çõ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 Fonte: Softex, 2009b GRE 1 GRE 2 GRE 3 GRE 4 GRE 5 Quadro 2 - Gerenciamento de Requisitos (adaptado) GERENCIMENTO DE REQUISITOS Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos. O comprometimento da equipe técnica com os requisitos aprovados é obtido. rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos Mudanças nos requisitos são gerenciadas ao longo do projeto Fonte: Softex, 2 3. SCRUM Martins (2007) aponta as origens do termo Scrum como o nome usado para reunião de jogadores, no jogo de Rugby, quando eles se organizam em círculo para planejar a próxima jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma visão de longo prazo, que é ganhar o jogo. Conforme apontado por Schwaber (2001 apud GONÇLVES e REIS FILHO, 2008), o Scrum tem por objetivo definir um processo de desenvolvimento iterativo e incremental podendo ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa. metodologia Scrum propõe uma forma de trabalho flexível que se adapta a ambientes muito dinâmicos, como: mudanças constantes em requisitos de software, trocas de equipes, adaptações de cronogramas e orçamentos, trocas de ferramentas de desenvolvimento ou mesmo de linguagens de programação (KOSCINSKI e SORES, 2007). O Scrum se concentra no que é realmente importante: gerenciar o projeto e criar um produto que acrescente valor para o negócio, sendo que o valor decorre da

6 funcionalidade propriamente dita, do prazo em que ele é necessário, do seu custo e de sua qualidade (MRTINS, 2007). O Scrum possui algumas práticas gerenciais que, de acordo com Silva et al. (2009), são apresentadas no quadro 3: Práticas Product Backlog Daily Scrum Sprint Sprint Planning Meeting Sprint Backlog Sprint Review Meeting Quadro 3 - Práticas do Scrum (adaptado) Definição documento mutável definido pelo cliente no início do projeto, onde estão contidas suas características esperadas em forma de lista ordenada por prioridade. Reuniões diárias de 15 minutos para avaliar o que foi feito no dia anterior, no dia atual e quais foram os impedimentos encontrados. Divisão dos processos do Scrum em iterações Reunião de Planejamento do sprint Documento gerado na reunião de planejamento Reunião de Revisão onde o cliente poderá dar sua opinião, caso necessário, mudar até mesmo o direcionamento do projeto Fonte: Silva et al., 2009 De acordo com Martins (2007), o Scrum trabalha basicamente com três papéis, apresentados no quadro 4. Quadro 4 - Papel no Scrum (adaptado) Papel Definição Dono do Responsável por representar os interesses das pessoas envolvidas no projeto projeto. Ele é responsável pela verba, define os requisitos gerais, define os objetivos de ROI e o plano de releases Mestre Scrum Responsável por forçar os valores e as práticas do Scrum, remover obstáculos, ensinar o processo a todas as pessoas Equipe de Grupo de pessoas responsáveis por desenvolver ou construir as projeto funcionalidades do produto. s equipes são autogerenciadas, autoorganizadas e multifuncionais, geralmente são compostas por 5 a 10 membros (o recomendado são sete pessoas). 5. Fonte: Martins, 2007, p. 255 Segundo Martins (2007), o Scrum possui 3 fases que são apresentadas no quadro

7 Game Fase Prégame Pósgame Quadro 5 - Fase no Scrum (adaptado) Definição Esta fase tem duas partes: planejamento e arquitetura. No planejamento é definido um novo release, com base nas informações conhecidas até o momento tabuladas num Backlog, junto com uma estimativa de prazo e custo. Na parte da arquitetura definem-se as bases para a construção do produto Esta fase é composta por um ou mais Sprints de desenvolvimento, que tem como objetivo o desenvolvimento das funcionalidades de um novo release, sempre respeitando as restriçoes de prazo, requisitos, qualidade, custos e caracteristicas dos concorrentes Nesta fase o produto é preparado para distribuição, incluindo integração, testes adicionais, documentação de usuário, preparação de material para treinamento e de marketing dentre outras coisas Fonte: Martins, 2007, p. 256 a 259 lgumas práticas são sugeridas por Schwaber (2001 apud GONÇLVES e REIS FILHO, 2008), durante o ciclo de vida do Scrum, a saber: entrega de software funcionando ao final de cada Sprint, na qual a meta é, ao final de cada Sprint, entregar algo que agregue valor para o Product Owner; Daily Scrum: Reuniões diárias e de pé, de no máximo 15 minutos compostas pelo Product Owner, o Scrum Master e o time de desenvolvimento, a fim de avaliar o andamento do Sprint e sanar qualquer problema que possa estar ocorrendo; elaboração de um Product Backlog que consiste em listar as histórias/funcionalidades do sistema, juntamente com o esforço necessário para concluí-las, bem como se devem indicar também em que Sprints serão desenvolvidas tais histórias/funcionalidades; elaboração de Sprints Backlogs, que consiste em listar todas as histórias/funcionalidades selecionadas para aquele Sprint e controlar os prazos estipulados para cada item, bem como preenchendo seu estado, por exemplo, se ela está concluída. Nesta etapa, também é gerado um gráfico de Burndown que indica o andamento do Sprint.

8 4. MPEMENTO ENTRE S PRÁTICS DO SCRUM E OS PROCESSOS DO NÍVEL G DO MPS.BR O mapeamento realizado é necessário para verificar se as práticas propostas pelo scrum atendem aos resultados esperados pelo MPS.Br, para o nível G (gerenciamento de projetos e gerenciamento de requisitos). Para a realização do mapeamento será utilizada uma classificação definida por Zanatta e Vilain (2010), conforme o quadro 6: Quadro 6 Classificação do Mapeamento SIGL CLSSIFICÇÃO SIGNIFICDO tendido O processo do MPS.Br foi plenamente atendido pelas práticas do Scrum P Parcialmente tendido O processo do MPS.Br foi parcialmente atendido pelas práticas do Scrum N Não tendido O processo do MPS.Br não foi atendido pelas práticas do Scrum Fonte: Zanatta e Vilain, 2010 GERENCIMENTO DE REQUISITOS O gerenciamento de requisitos, segundo a Softex (2011b), envolve a identificação de requisitos do produto (que devem ser claramente definidos e entendidos), o estabelecimento de um acordo entre o cliente e a equipe do projeto sobre esses requisitos, além do gerenciamento das mudanças que ocorrem nos requisitos ao longo do projeto. Há várias práticas do Scrum que favorecem o gerenciamento de requisitos. Dentro do solicitado pelo MPS.Br, podemos destacar o entendimento dos requisitos junto ao cliente, cujo quesito é válido no Scrum, visto que todo processo de elicitação de requisitos é feito diretamente com o cliente, gerando, através dessa interação, uma lista de requisitos necessários para o desenvolvimento do produto de software, chamado de product backlog. lguns resultados esperados para o gerenciamento de requisitos não são atendidos pelo Scrum, como a rastreabilidade bidirecional dos requisitos que não é prevista. O mapeamento completo entre o Scrum e o gerenciamento de requisitos que pertence ao nível G do MPS.Br é apresentado no quadro 7:

9 Quadro 7 - Mapeamento entre o Scrum e o Gerenciamento de Requisitos no Mps.Br GERENCIMENTO DE REQUISITOS MPS.Br SCRUM Classificação GRE 1 O entendimento dos Elicitação de Requisitos feita requisitos é obtido junto aos fornecedores de requisitos. diretamente com o cliente gerando o Product Backlog. Itens a serem desenvolvidos são separados e entendidos no Backlog do Sprint. Daily Scrum auxilia no entendimento dos requisitos a serem realizados. GRE 2 Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido GRE 3 rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida GRE 4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. GRE 5 Mudanças nos requisitos são gerenciadas ao longo do projeto Equipes auto-organizadas e auto-dirigidas com liberdade para executarem suas atividades. O Scrum Master e o Product Owner trabalham para assegurarem o entendimento e comprometimento da equipe com os requisitos. rastreabilidade não é prevista pelo Scrum. Inconsistências são identificadas durante as reuniões diárias e as ações corretivas são realizadas durante o próprio sprint. Não é prevista uma documentação das inconsistências. O gerenciamento de requisitos é realizado durante o sprint, necessidades de mudanças são adicionadas ao product backlog e realizadas no próximo sprint. Não é previsto que haja um histórico das alterações nos requisitos. N P P

10 GERENCIMENTO DE PROJETO Segundo a Softex (2011b), 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; acompanhar o progresso do projeto, aplicar ações corretivas, caso necessário, entre outras atividades. maior parte do gerenciamento de projetos, segundo os resultados esperados pelo MPS.Br, pode ser atendida pelas diversas práticas do Scrum. O resultado completo do mapeamento entre o Scrum e o gerenciamento de projetos do MPS.Br pode ser visualizado no quadro 8. GPR1 GPR2 GPR3 Quadro 8 - Mapeamento entre o Scrum e o Gerenciamento de Projetos no Mps.Br GERENCIMENTO DE PROJETOS MPS.Br SCRUM Classificação O escopo do trabalho para Documento de visão e backlog o projeto é definido do produto. s tarefas e os produtos de Planejamento do sprint. trabalho do projeto são dimensionados utilizando métodos apropriados O modelo e as fases do O scrum é iterativo e ciclo de vida do projeto incremental, ou seja, a cada são definidos sprint é gerado um novo GPR4 (té 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 a definição de marcos e pontos de controle, são estabelecidos e mantidos GPR6 Os riscos do projeto são identificados e o seu incremento do produto. Não é previsto no scrum o armazenamento de dados históricos de custo, esforço e tempo de projeto que foram executados anteriormente. O custo e o cronograma são definidos na reunião de planejamento de versão para entrega. O Sprint é o marco do projeto. Gráfico de Burndown da Versão para Entrega para acompanhamento do progresso. O orçamento não é previsto pelo scrum. o plano de versão para entrega estabelece os principais riscos N P

11 GPR7 impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo GPR8 (té o nível F) Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados GPR9 GPR10 GPR11 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 Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados do projeto, além do mais, na fase de pré-game são identificados os possíveis riscos do projeto e no game os riscos identificados previamente são observados e controlados durante o desenvolvimento. Os riscos também são tratados nas reuniões diárias do sprint. O scrum prevê o planejamento de recursos humanos através da divisão de papéis em: ScrumMaster, ProductOwner e Time. Cada um possui suas próprias responsabilidades de acordo com a função que lhe é atribuída. Na fase de pré-game é realizado o planejamento dos recursos necessários para execução do projeto, como avaliação e seleção das ferramentas de desenvolvimento e infraestrutura. No scrum são geradas documentações mínimas necessárias para a execução do projeto, como o product backlog, sprint backlog, gráfico de burndown, entre outras. Porém, não é previsto o gerenciamento dos artefatos gerados. O início do planejamento acontece na reunião de planejamento da versão para entrega onde é elaborado o plano de versão para entrega. São definidas as metas viáveis que podem ser alcançadas durante o sprint na reunião de planejamento do sprint de acordo com os recursos disponíveis. justes são realizados, caso necessário, ao final do sprint, durante a P

12 GPR12 GPR13 GPR14 GPR15 GPR16 GPR17 GPR18 O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado Os riscos são monitorados em relação ao planejado O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento 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 GPR19 ções para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados estabelecidas, implementadas são e retrospectiva do sprint. O plano do projeto é revisado a cada término de sprint juntamente com o time do scrum gerando um compromisso entre eles. Para monitoração são utilizados: gráfico de burndown do backlog de versão para entrega, gráfico de burndown do sprint, reuniões diárias do sprint, revisão do sprint. Não é previsto o monitoramento do orçamento. Os itens planejados são constantemente monitorados através de reuniões diárias e reunião de revisão do sprint. Os riscos podem ser monitorados através de: Reuniões diárias, Reunião de Revisão do sprint, Retrospectiva do sprint. O envolvimento das partes interessadas é assegurado através do product owner e do ScrumMaster cada término de um sprint (marco do projeto) é feita uma reunião de revisão. No scrum os problemas são identificados nas reuniões diárias e registrados em quadros brancos. s ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidos durante as reuniões diárias, a reunião de revisão do sprint e a P P

13 acompanhadas até a sua conclusão retrospectiva do sprint, porém o scrum não prevê que haja o registro dessas ações. No quadro 9 é apresentado um resumo do total das classificações do mapeamento proposto, e, em seguida, nos gráficos 1, 2 e 3, pode-se visualizar a porcentagem que representa cada classificação no total: Quadro 9 - Classificações do Mapeamento Classificação GRE GPR 2 14 P 2 4 N 1 1 Total 5 19 Gráfico 1 - Classificações do Mapeamento - Gerenciamento de Requisitos Gráfico 2- Classificações do Mapeamento - Gerenciamento de Projetos

14 Gráfico 3 - Classificações do Mapeamento - Gerenciamento de Requisitos e Projetos 5. CONSIDERÇÕES FINIS Conforme os resultados apresentados pelo mapeamento, que podem ser melhor visualizados nos gráficos 1, 2 e 3, pode-se perceber que o Scrum é aderente ao MPS.Br, pois, juntando as classificações de Gerenciamento de Requisitos e Gerenciamento de Projetos no gráfico 3, temos os seguintes resultados: 67% dos resultados esperados pelo MPS.Br são atendidos pelo Scrum, 25% são parcialmente atendidos, contra apenas 8% dos resultados que não são atendidos pelo Scrum. Entre o gerenciamento de requisitos e o gerenciamento de projetos o mais aderente ao MPS.Br é o gerenciamento de projetos, já que 74% dos resultados esperados pelo MPS.Br são atendidos pelo Scrum, contra 40% no gerenciamento de requisitos. través dos resultados do mapeamento, conclui-se que as empresas que utilizam o Scrum podem perfeitamente alcançar uma certificação de maturidade do MPS.Br, desde que façam algumas adaptações nas práticas do Scrum para serem totalmente aderentes ao MPS.Br. Como trabalho futuro sugere-se a validação do mapeamento proposto por profissionais especializados em Scrum, visto que estas pessoas possuem experiências maiores com essa metodologia ágil e podem confirmar ou refutar com maior precisão as relações estabelecidas no mapeamento.

15 REFERÊNCIS: GILE MNIFESTO. Manifesto for gile Software Development Disponível em: < cesso em: 24/04/2011. RIMOTO, Maurício M.; MURKMI, Edson; CMRGO, Valter V. de; CGNIN, Maria I. dherence nalysis of gile Methods ccording to the MR-MPS Reference Model, 2009, p Disponível em: < bibliotecadigital.sbc.org.br/download.php?paper=2978> cesso em: 23/04/2011. CHENG, Betty H.C.; TLEE, Joanne M. Research Directions in Requirements Engineering, 2007, p. 1. Disponível em: < > cesso em: 29/08/2010. DINIZ, lfranio de Souza. PROREQ Um guia facilitador para a implantação dos processos de gestão de requisitos, f. Dissertação (Mestrado em Ciência da Computação e Matemática Computacional) Instituto de Ciências Matemáticas e de Computação, USP São Carlos, Disponível em: < cesso em: 29/08/2010. GONÇLVES, Eduardo dos Santos; REIS FILHO, Heitor Boeira dos. Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis, 2008, p Disponível em: < cesso em: 26/04/2011. GONSLVES, Elisa Pereira. Conversas sobre Iniciação à Pesquisa Científica, 4ª. edição. Campinas / SP: Editora línea, KOSCINSKI, ndré; SORES, Michel dos Santos. Qualidade de Software, 2ª. edição. São Paulo / SP: Editora Novatec, MRTINS, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML, 4ª. edição. Rio de Janeiro / RJ: Editora Brasport, 2007a. MRTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de software. São Paulo: Editora Brasport, 2007b. MOUNTIN GOT SOFTWRE. n Overview of Scrum for gile Software Development, Disponível em: < cesso em 30/04/2011.

16 OLIVEIR, Valter Castelhano. Propostas de Métodos para gestão de requisitos de sistema integrando modelagem de negócios e linguagens formais, f. Dissertação (Mestrado em Engenharia) Escola Politécnica da Universidade de São Paulo, Disponível em: < /> cesso em: 29/08/2010. PMI-Project Management Institute. GUI PMBOK - Um Guia de Conhecimentos em Gerenciamento de Projetos. 3º edição. EU, SNTN, Celio.; TIMÓTEO, line L.; VSCONCELOS, lexandre M. L. Mapeamento do modelo de Melhoria do Processo de Software Brasileiro (MPS.Br) para empresas que utilizam Extreme Programming (XP) como metodologia de desenvolvimento. Publicação: SBQS, 2006, p Disponível em: < cesso em: 29/08/2010. SCHWBER, Ken. Guia do Scrum, SCRUM liance. Disponível em: < > cesso em 19/08/2011. SILV, F. G.; HOENTSCH, S. C. P.; SILV, L. Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR. Publicação: SCIENTI PLEN, 2009, p. 3. Disponível em: < cesso em: 29/04/2011. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro - Guia de valiação, 2011a. Disponível em: < cesso em: 29/08/2010. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro - Guia de Implementação - Parte 1: Fundamentação para implementação do Nível G do MR-MPS, 2011b. Disponível em: < pdf> cesso em: 29/08/2010. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro - Guia Geral, 2011c. Disponível em: < cesso em: 29/08/2010.

17 SOMMERVILLE, I. Engenharia de Software, 8ª. Edição. São Paulo / SP: Pearson Education do Brasil, WZLWICK, Raul Sidnei. Metodologia da Pesquisa para ciência da computação. Rio de Janeiro: Editora Campus, ZNTT, lexandre Lazaretti; VILIN, Patrícia. Uma análise do método ágil Scrum conforme abordagem nas áreas de processo, gerenciamento e desenvolvimento de Requisitos do CMMI, 2010 < cesso em: 26/04/2011.