PAULO HENRIQUE CARROCE SANTESSO

Utilizao de Mtodos geis Scrum com MPS.BR de Nvel G

Londrina 2009

PAULO HENRIQUE CARROCE SANTESSO

Utilizao de Mtodos geis Scrum com MPS.BR de nvel G

Trabalho de Concluso de Curso de Especializao em Anlise, Projeto e Gerncia de Sistemas com nfase em Inteligncia em Negcios Residncia em Software apresentado Coordenao do Curso de Cincia da Computao da Universidade Estadual de Londrina.

Orientadora: Rodolfo Miranda de Barros

Londrina 2009

AGRADECIMENTOS
Agradeo ao CNPq/MCT e ao Fundo Setorial de Tecnologia da Informao CT-Info, pela concesso da Bolsa de Desenvolvimento Tecnolgico e Industrial 382197/2008-9.

RESUMO
A metodologia gil Scrum pode complementar e dar agilidade em determinadas tarefas a um modelo de qualidade tradicional, para empresas desenvolvedoras de software. Neste caso, a metodologia tradicional adotada o MPS.BR, embora ambos utilizem tcnicas e mtodos com algumas caractersticas opostas. O nvel de maturidade escolhido do MPS.BR foi o nvel Parcialmente Gerenciado (nvel G), englobando apenas os processos de Gerncia de Projetos e Gerncia de Requisitos. A utilizao dessas duas tcnicas juntas traz como benefcio um processo disciplinado, a facilidade de implantao da metodologia gil, a agilidade e eficincia para se adaptar a qualquer imprevisto durante o projeto. Alm da certificao do processo de desenvolvimento pelo modelo de qualidade, tornando-a adepta aos padres internacionais, sendo hoje um fator vital para crescimento da empresa.

Palavras-chave: Scrum, MPS.BR, Metodologias geis, Qualidade de Software

SUMRIO

1 2 3 4

INTRODUO ................................................................................................................5 MPS.BR .............................................................................................................................6 SCRUM .............................................................................................................................7 MAPEAMENTO DO SCRUM NAS REAS DE PROCESSO DO MPS.BR ............9 4.1 4.2 GERNCIA DE PROJETO (GPR) ....................................................................................9 GERNCIA DE REQUISITOS (GRE) .............................................................................13 OBTER REQUISITOS ....................................................................................................15 ANALISAR E AVALIAR ACEITAO .............................................................................15 ANALISAR VIABILIDADE TECNOLGICA E DE RECURSOS ............................................16 COMUNICAR CLIENTE ................................................................................................16 MANTER RASTREABILIDADE BIDIRECIONAL DOS REQUISITOS ....................................17

DOCUMENTAO.......................................................................................................15 5.1 5.2 5.3 5.4 5.5

CONCLUSO.................................................................................................................19

REFERNCIAS BIBLIOGRFICAS .................................................................................20

INTRODUO Cada vez mais, empresas e organizaes necessitam de produtos com qualidade, livres de erros e com solues imediatas. Para atender a esta demanda, empresas de software visam, em seus projetos, a diminuio de conflitos, o aumento da confiabilidade e a reduo dos custos, resultando em maior satisfao do cliente. Neste contexto, modelos de qualidade so propostos a fim de medir e garantir a excelncia do software produzido. Isto se d por meio de processos baseados em normas da ISO 9000, implementando o contexto da Engenharia de Qualidade nas empresas (COUTO, 2007). Paralelamente aos processos de melhoria da qualidade, existem as metodologias geis, que apresentam menor burocratizao e demandam maior esforo das pessoas envolvidas. Elas tambm permitem acolher mudanas mais naturalmente e adaptaes em qualquer momento. Deste modo, o presente estudo tem por objetivo mostrar que a juno de uma metodologia gil com um modelo de qualidade tradicional pode ser muito produtiva, embora adaptaes sejam necessrias. O modelo de qualidade escolhido foi o MPS.BR, por ser capaz de atender as exigncias internacionais para avaliao, definio e melhoria dos processos de software. Este modelo tem o intuito de atender principalmente s empresas brasileiras. A metodologia gil selecionada foi o Scrum, que contm aes de monitoramento para identificar impedimentos durante o projeto, e se destaca pelas atividades prticas e de gerenciamento de projetos.

MPS.BR MPS.BR (Melhoria de Processo de Software Brasileiro) um modelo de referncia que visa atingir maior qualidade no processo de desenvolvimento de software, principalmente em organizaes com recursos limitados para investimento em qualidade. Este modelo no define novos conceitos, apenas adqua as estratgias de implementao realidade brasileira (SANTANA, TIMTEO & VASCONCELOS). O MPS.BR tem como base para a dimenso de processos as normas NBR ISO/IEC 12207, estabelecendo o que deve ser executado para ter qualidade na produo, no fornecimento, na aquisio e operao de software. O mtodo de avaliao realizado conforme as reas de processo estabelecidas para cada nvel de maturidade, definido com base na ISSO/IEC 15504 (COUTO, 2004). O MPS.BR pode ser divido em guias: Guia Geral, que consiste de uma descrio geral e detalha o modelo de referncia MR-MPS; Guia de Aquisio, a qual descreve o processo de aquisio do software e os servios correspondentes; Guia de Avaliao, que abrange o processo e os requisitos para avaliao; e Guia de Implementao, composto por sete partes, uma para cada nvel de maturidade, que indicam a evoluo dos processos na organizao do MR-MPS. Este nveis, A (Em Otimizao), B (Gerenciado Quantativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado), iniciam-se no G e progridem at o A. A implementao no nvel G demanda a execuo de dois processos. O primeiro, GPR (Gerncia de Projetos), consiste no estabelecimento e manuteno de planos que definem os recursos, atividades e responsabilidades, alm de informar sobre desvios significativos durante o projeto. E o GRE (Gerncia de Requisitos) que visa buscar inconsistncias entre os requisitos, os planos de projetos e os produtos resultantes do projeto.

SCRUM Scrum , criado por Ken Schwaber, , segundo ele mesmo, um processo gil ou ainda um framework para gerenciamento de projetos geis. um processo de gerncia de projetos, certamente no uma metodologia, pois isto seria pesado demais. O termo Scrum tem origem no esporte Rgbi e s ocorre quando os jogadores de um time colaboram para avanar juntos ao campo adversrio (SIQUEIRA). A necessidade deste processo gil vem do reconhecimento de que desenvolvimento de software muito complexo para ser planejado corretamente desde o incio. Devido a essa complexidade, Ken Schwaber destaca que processos empricos devem ser elaborados. Processos empricos baseiam-se nos resultados do processo e visam corrigi-los, aceitando falhas como conseqncia natural da produo, buscando ainda mostr-las o mais breve possvel. O Scrum segue essa abordagem emprica, atravs de atividades de monitoramento e feedback, como reunies dirias (Daily Scrum Meeting) com a equipe de desenvolvimento para ter o controle das atividades em desenvolvimento. Product Backlog a lista de atividades ou requisitos e deve ser classificado com uma chave de identificao, um breve nome descritivo, seu grau de importncia e seu prazo estimado para o trmino. As reunies devem ser em feitas com equipes pequenas, geralmente at sete pessoas, e tem como objetivo principal a identificao e correo de qualquer imprevisto durante o desenvolvimento (SCHWABER, 2004). Esse tempo de desenvolvimento, tambm chamado de Sprints, deve ser executado em iteraes curtas, no mximo de 30 dias. Se durante as reunies dirias so levantados algum impedimento em relao aos Sprints, esses contratempos so registrados num artefato especfico, chamado Impediments Backlog. Ao final de cada Sprint realizada uma reunio para reviso das atividades deste perodo, chamada de Sprint Review. Atravs de papis, o Scrum permite com que cada envolvido assuma determinada responsabilidade, dando capacidade de melhor controle com problemas imprevisveis: - Product Ower: responsvel pelo retorno sobre o investimento do projeto. Tem como funo garantir que o produto entregue atenda as necessidades do patrocinador e priorizar quais funcionalidades deve ser entregue. -Team: Equipe de desenvolvedores, designers, testadores, todos comprometidos a desenvolver o produto esperado, seguindo suas prprias decises para alcanar os objetivos. - Scrum Master: responsvel por guiar o Team, estabelecer um vnculo entre o Product Ower e a equipe, alm de comprometer com que todos sigam o Scrum. Outra res-

ponsabilidade levantar o Impediments Backlog e cuidar para que a equipe resolva-o com eficincia. O ciclo de vida do Scrum composto por quatro fases, aonde nas duas primeiras so preparadas a infra-estrutura e os recursos necessrios: - Planejamento: fase da viso do projeto e expectativas envolvidas. So criadas as verses iniciais do Product Backlog, a arquitetura de negcios e a arquitetura tcnica em alto nvel; - Preparao: fase de avaliao do projeto, criando itens adicionais em Product Backlog, relacionados equipe, ao tipo do sistema e ambiente de desenvolvimento. A equipe de desenvolvimento selecionada e os mecanismos de comunicao entre eles. - Desenvolvimento: atravs dos Sprints, ocorre o desenvolvimento iterativo e incremental das funcionalidades. - Entrega: fase de entrega final do produto, incluindo as atividades relacionadas, como treinamento do usurio.

MAPEAMENTO DO SCRUM NAS REAS DE PROCESSO DO MPS.BR Neste captulo sero descritos a aderncia de cada fase dos processos do nvel G, junta-

mente com a aplicao de Scrum, se conveniente. A Gerncia de Projetos possui quinze prticas a serem seguidas, enquanto a Gerncia de Projeto segue sete prticas.

4.1

GERNCIA DE PROJETO (GPR)

O objetivo deste processo definir e manter planos que controlem as atividades, recursos e responsabilidades do projeto, assim como acompanhar o desempenho do mesmo, a fim de efetuar correes assim que necessrias. GPR1: O escopo do trabalho para o projeto definido Escopo define todo o trabalho necessrio para entregar um produto que satisfaa as necessidades, caractersticas e funes especificadas do projeto. Deve ficar claro o objetivo e os limites levantados. Na fase de Planejamento do Scrum, o Product Backlog e o documento de viso criado servem para atender este requisito do escopo, possibilitando estimar o tempo de desenvolvimento necessrio para o projeto. GPR2: As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados O escopo divido em componentes menores para melhor gerenciamento. Uma estrutura de decomposio elaborada para fornecer uma referncia ao esforo, cronograma e atividades a serem distribudas, para que as tarefas sejam melhores planejadas e organizadas. O Scrum permite que as estimativas de esforo no sejam derivadas de um mesmo entendimento por parte dos stakeholders das tarefas e dos produtos. Nesta etapa, o Scrum deveria estimular o entendimento das atividades em que os desenvolvedores pudessem discutir os atributos do que deve ser elaborado (SIQUEIRA). GPR3: O modelo e as fases do ciclo de vida do projeto so definidos Ciclo de vida define um conjunto de fases, onde cada uma destas gera atividades a serem atingidas para alcanar a fase posterior. Essa organizao de fases permite maior

10

controle sobre o planejamento do projeto. No Scrum, o ciclo de vida divido em quatro fases: Planejamento, Preparao, Desenvolvimento e Entrega. GRP4: O esforo e custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas A estimativa do custo e esforo necessrio para cada tarefa baseada em anlise de modelos ou dados histricos. Normalmente essa estimativa afetada pelos parmetros da produtividade. O Scrum apenas as estimativas de esforos so includas: em Product Backlog, pouco precisas, apenas para oferecer uma viso ao Product Ower; e em Sprint Backlog, geralmente mais detalhadas, com objetivo de prover controle e visibilidade do desenvolvimento do produto. GRP5: O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, so estabelecidos e mantidos A dependncia entre tarefas e possveis alteraes devem ser identificados atravs de mtodos especficos. Com base no cronograma e na estimativa de custos, elaborado o oramento do projeto. O Product Backlog e a produtividade da equipe ajudam a estabelecer um primeiro cronograma, dividido em Sprints de trinta dias, sendo atualizado automaticamente medida do desenvolvimento do projeto. Como no Scrum o oramento no est contemplado nas atividades, geralmente no possvel ter base deste item atravs do cronograma (SIQUEIRA). GPR6: Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados A identificao dos riscos e suas provveis conseqncias devem ser analisadas e classificadas por priorizao. Esses registros sero levantados durante as reunies dirias e armazenados no Impediments Backlog. GPR7: Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrio para execut-los So determinadas relaes hierrquicas e funes para cada envolvido no projeto, sendo internos ou externos organizao. Ainda so levantadas as informaes sobre competncia exigida para execuo das tarefas ou ento a necessidade de treinamento,

11

se for o caso. A equipe do projeto deve ter, como requisito, competncia para criar o Product Backlog. Se algum treinamento for necessrio, esta requisio inserida no Product Backlog. GPR8: As tarefas, os recursos e o ambiente de trabalho necessrio para executar o projeto so planejados As tarefas e os recursos necessrios para atend-las, como ferramentas, servios, componentes ou despesas, devem ser especificados e planejados. O Scrum Master e o Product Ower so responsveis por garantir esses recursos, tomando conhecimento pelas reunies no incio de cada iterao e tambm pelos mtodos de remoo dos impedimentos levantados pela equipe. GPR9: Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana Os dados do projeto podem ser relatrios, estudos, anlises, atas de reunies. Podem estar em qualquer formato e qualquer meio. Tambm podem ter diversas formas de distribuio. necessrio, porm, a identificao dos dados mais relevantes para poder ter uma distribuio controlada, alm de armazenada. No Scrum, a comunicao feita pessoalmente, durante as reunies, com documentao do restante das informaes. No existe um plano de comunicao para padronizar a forma de coleta de dados. GPR10: Planos para a execuo do projeto so estabelecidos e reunidos no Plano de Projeto Plano de projeto um grupo de documentos com informaes definidas e reunidas para o projeto, como ciclo de vida, tamanho, esforo, oramento, cronograma, riscos. O documento de viso e o Product Backlog do Scrum se encaixam perfeitamente nesta categoria. GPR11: A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so realizados

12

Deve ser feita uma avaliao no incio do projeto, seguindo uma viso geral dos objetivos e caractersticas dos resultados esperados, examinando aspectos tcnicos, financeiros e humanos. Esta avaliao deve ser refeita conforme o progresso do projeto, verificando se os requisitos para atingir a meta esto disponveis. As reunies dirias (Daily Meeting) dispem a visibilidade necessrias para acompanhamento das metas e suas restries. GPR12: O Plano de Projeto revisado com todos os interessados e o compromisso com ele obtido essencial a reviso do plano de projeto para atingir as metas de todos envolvidos, conciliando diferenas possveis diferenas. Caso haja diferenas, devem ser resolvidos os conflitos existentes. A equipe, Scrum Master e Product Ower revisam os planos no incio e no fim de cada Sprint. GPR13: O progresso do Projeto monitorado com relao ao estabelecido no Plano de Projeto e os resultados so documentados A avaliao dos planos ligados ao projeto devem ser revistas sempre, procurando obter dados sobre aderncia em relao ao cronograma e esforo necessrio para realiz-los. Nas reunies dirias possvel prever possveis imprevistos de aderncia e monitorar o andamento do projeto. GPR14: O envolvimento das partes interessadas no projeto gerenciado Todos envolvidos interessantes do projeto (como cliente, usurio, membros da equipe, diretoria) sero levantados, descritos em quais fases sero necessrios e seus comprometimentos. Suas comunicaes devem trazer informaes relativas a prazo, custo e recursos necessrios. As prticas de Scrum so ideais para comunicao e colaborao entre a equipe e os usurios do projeto. GPR15: Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento Atividades de vital importncia ou incio e fim de cada fase do projeto devem ter o planejamento revisado para verificar se podem atender os requisitos exigidos pela prxima fase ou verificar se todos os critrios foram atendidos. Ao final de cada Sprint o

13

progresso do projeto e o cumprimento das atividades so revisados durante o Sprint Review. GPR16: Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas Durante o monitoramento de possveis imprevistos no projeto, os problemas encontrados devem ser analisados e registrados, devendo ser gerenciados at sua resoluo, com base nos planos de aes. Estes problemas so gravados num quadro ou no Impediments Backlog. Cabe ainda ao Scrum Master a identificao e resoluo destes. GPR17: Aes para corrigir desvios em relao ao planejada e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso Como os problemas encontrados, suas respectivas aes corretivas tambm devem ser analisadas, registradas e acompanhadas at chegar sua resoluo. Caso haja conseqncias das aes tomadas, essas tambm devem ser analisadas e registradas. O Scrum Master responsvel pelas aes corretivas, mas em Scrum no h registro do planejamento ou acompanhamento destas aes.

4.2

GERNCIA DE REQUISITOS (GRE)

Este processo tem como principal objetivo gerenciar todos os requisitos recebidos e gerados pelo projeto, alm de identificar inconsistncias entre os requisitos, os planos de projeto e os produtos de trabalho do projeto. GRE1: O entendimento dos requisitos obtido junto aos fornecedores de requisitos Os requisitos do projeto devem estar claramente definidos com os fornecedores das informaes. desejvel que os fornecedores sejam identificados e aprovados pelo patrocinador do projeto. Atravs do plano de projeto, deve ser feito o registro do stakeholder e a forma de comunicao com ele. Alm disso, o cliente precisa estar ciente se

14

as necessidades e expectativas esto sendo atendidas. Toda essa gerncia junto ao fornecedor deve ser controlada pelo Scrum Master. GRE2: Os requisitos de software so aprovados utilizando critrios objetivos Com base em alguns critrios estabelecidos, os requisitos de software devem ser aprovados pela equipe tcnica e pelo cliente. Mudanas nos requisitos podem ter como conseqncia uma alterao no cronograma, exigindo sempre uma aprovao para execut-las. Durante as reunies dirias possvel o monitoramento dos requisitos, caso haja alguma conseqncia. Cabe ao Scrum Master monitorar e corrigir qualquer imprevisto ao projeto. GRE3: A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida A relao entre os requisitos e os produtos de trabalho deve ser analisada e identificada, a fim de ressaltar possveis impactos, tanto em requisitos entre si como em desde um requisito fonte at um mdulo do produto. Se for encontrada alguma inconsistncia, ela deve ser registrada no Impediments Backlog. GRE4: Revises em planos e produtos de trabalho do projeto so realizados visando identificar e corrigir inconsistncias em relao aos requisitos Do mesmo modo que problemas podem ser encontrados entre os requisitos e os produtos, revises devem ser efetuadas para garantir este controle. As inconsistncias encontradas devem ser analisadas e registradas, bem como as aes corretivas. Estas aes devem ser monitoradas at que sejam totalmente resolvidas. A avaliao das tomadas corretivas feita durante a Sprint Review, o perodo de reviso no final de cada Sprint. GRE5: Mudanas nos requisitos so gerenciadas ao longo do projeto Caso haja alteraes nos requisitos, ou ento a insero de novos, a necessidade das mudanas devem ser registradas e um histrico das decises deve estar disponvel, analisando possveis impactos sobre o projeto, como em cronograma, conseqncias em outros requisitos, esforo, riscos e custo. Caso algum requisito com conseqncia fora resolvido, deve ser excludo da lista de Impediments Backlog.

15

DOCUMENTAO A documentao a seguir sobre a Gerncia de Requisitos.

5.1

OBTER REQUISITOS Descrio Obter requisitos Obter os requisitos de software atravs de contato formalmente estabelecido com o cliente (interno e externo).. Canais autorizados de contato com o cliente. Solicitao do cliente registrada no formulrio de briefing de projeto de sistema. Analista de sistemas, Scrum Master Responsvel formalmente designado pelo cliente e pela empresa. Formulrio de briefing de projeto de sistema. Formulrio de briefing de projeto de sistema preenchido. Obter o formulrio de briefing de projeto de sistema. Encaminhar formulrio de briefing de projeto de sistema preenchido para anlise dos coordenadores de rea.

Item Nome Descrio Critrio de Entrada Critrio de Sada Responsvel Participante Artefato(s) Requerido(s) Artefato(s) Gerado(s) Pr-atividades Ps-atividades

5.2

ANALISAR E AVALIAR ACEITAO Descrio Analisar e avaliar aceitao Analisar os requisitos registrados na solicitao, identificando o tipo do mesmo. Analisar o impacto no projeto, considerando escopo, custo e prazo, e o impacto da mudana do requisito no sistema. Aps o entendimento da solicitao, decidir e registrar se os requisitos sero aceitos para o desenvolvimento do produto pela empresa. Verificar se o formulrio de briefing de projeto de sistema est devidamente preenchido e registrado. Aceitao de requisitos atravs do formulrio de briefing de projeto de sistema analisado conforme critrios de classificao. Requisito da solicitao do cliente analisado e entendido. Tipo de requisito identificado e anlise de impacto no projeto registrado. Deciso sobre aceitao e planilha de mtricas registradas. Scrum Master Responsvel formalmente designado pelo cliente e pela empresa. Formulrio de briefing de projeto de sistema preenchido. Formulrio de briefing de projeto de sistema analisado. Requisito identificado atravs do formulrio de briefing de projeto de sis-

Item Nome Descrio

Critrio de Entrada

Critrio de Sada Responsvel Participante Artefato(s) Requerido(s) Artefato(s) Gerado(s)

16

Pr-atividades Ps-atividades

tema, anlise de impacto no projeto e anlise da mudana de requisitos preenchida. Deciso sobre aceitao registrada. Obter critrios de anlise, aceitao e de classificao de requisito. Encaminhar para anlise de viabilidade tecnolgica e de recursos se o requisito foi aceito para desenvolvimento ou para a atividade comunicar o cliente sobre a no aceitao caso o requisito no seja aceito.

5.3

ANALISAR VIABILIDADE TECNOLGICA E DE RECURSOS Descrio Analisar viabilidade tecnolgica e de recursos Analisar viabilidade tecnolgica e de recursos para desenvolvimento do requisito e a disponibilidade de recursos para execuo do processo. Anlise e aceite dos requisitos no projeto. Estudo de viabilidade tecnolgica e de recursos para desenvolvimento do requisito registrado. Analista de sistemas, Scrum Master Responsvel formalmente designado pela empresa. Formulrio de briefing de projeto de sistema analisado. Requisito identificado atravs do formulrio de briefing de projeto de sistema. Deciso sobre aceitao registrada. Anlise da viabilidade tecnolgica e de recursos registrada. Planilha de mtricas preenchida. Obter critrios para estudo de viabilidade tecnolgica e de recursos. Submeter a tarefa Comunicar o cliente. Caso a anlise seja positiva, solicitar o aceite do cliente nas condies apontadas pelo estudo de viabilidade tecnolgica e de recursos, seno relatar os motivos pelo qual a solicitao no vivel. Caso seja identificado algum impedimento, registrar em Impediments BackLog.

Item Nome Descrio Critrio de Entrada Critrio de Sada Responsvel Participante Artefato(s) Requerido(s) Artefato(s) Gerado(s) Pr-atividades Ps-atividades

5.4

COMUNICAR CLIENTE Descrio Comunicar cliente Caso a anlise de viabilidade tecnolgica e de recursos seja positiva solicitar a aceitao formal do cliente para desenvolvimento do requisito analisado apresentando a proposta de desenvolvimento, seno relatar ao cliente os motivos pelo qual a solicitao no foi aceita. Anlise de viabilidade tecnolgica e de recursos concluda. Proposta de desenvolvimento de requisito enviada ao cliente ou comunicao relatando os motivos pelo qual a solicitao no foi aceita. Departamento comercial. Responsvel formalmente designado pelo cliente e pela empresa. Estudo de viabilidade tecnolgica e de recursos.

Item Nome Descrio

Critrio de Entrada Critrio de Sada Responsvel Participante Artefato(s) Requerido(s)

17

Artefato(s) Gerado(s) Pr-atividades Ps-atividades

Documento de aceitao do cliente caso a anlise de viabilidade tecnolgica e de recursos seja positiva ou documento relatando os motivos do no aceite da solicitao. Obter o estudo de viabilidade tecnolgica e de recursos. Se a anlise da viabilidade for positiva e o cliente no aceitar as condies propostas encerrar e arquivar o projeto, caso contrrio, prosseguir com o projeto e aps assinatura do contrato, selecionar o item aceito e encaminhar para a atividade manter rastreabilidade bidirecional. Caso a anlise da viabilidade seja negativa encerrar o processo.

5.5

MANTER RASTREABILIDADE BIDIRECIONAL DOS REQUISITOS Descrio Manter rastreabilidade bidirecional dos requisitos Manter atualizada uma matriz de rastreabilidade bidirecional do requisito. Aceitao formal do cliente (assinatura do contrato) para desenvolvimento do requisito. Matriz de rastreabilidade bidirecional atualizada. Analista de sistemas. Scrum Master Aceitao formal do cliente. Formulrio de briefing de projeto de sistema. Matriz de rastreabilidade anterior. Matriz de rastreabilidade atualizada. Obter matriz de rastreabilidade conforme modelo caso seja um novo projeto ou a matriz de rastreabilidade anterior se j existir um projeto. Encerrar a execuo do processo.

Item Nome Descrio Critrio de Entrada Critrio de Sada Responsvel Participante Artefato(s) Requerido(s) Artefato(s) Gerado(s) Pr-atividades Ps-atividades

18

19

CONCLUSO A adoo de metodologias geis vem crescendo a cada dia por mostrar agilidade e

ampla adaptao a imprevistos, mostrando-se uma alternativa vivel e fcil de implementar (SANTANA, TIMTEO & VASCONCELOS). Ainda assim, estas metodologias pecam pela falta de englobamento e documentao, sendo caracterstica prpria dos mtodos geis. J o MPS.BR consegue ter uma ampla viso nos diversos ambientes de desenvolvimento, porm necessitando maior burocracia para o gerenciamento. A combinao dessas duas tcnicas se mostrou satisfatria e vivel de ser alcanada, ressaltando-se que foi analisado apenas para o primeiro nvel do MPS.BR. Em trabalhos futuros, deve ser analisada a implementao do Scrum em nveis de maturidade superiores ao Nvel G do MPS.BR, visando encontrar os mesmos resultados que foram encontrados neste artigo.

20

REFERNCIAS BIBLIOGRFICAS COUTO, A. B.; CMMI Integrao dos Modelos de Capacitao e Maturidade de Sistemas. Ed. Cincia Moderna. Rio de Janeiro, 2007. KNIBERG, H. Scrum e XP direto das Trincheiras. Disponvel em: <

http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches>. Acesso em: 06 de

junho de 2009. OLIVEIRA, A. C. G. de; GUIMARES, F. A.; FONSECA, I. A.. Utilizando Metodologias geis para atingir MPS.BR nvel F na Powerlogic. Disponvel em: <

http://www.softex.br/portal/softexweb/uploadDocuments/_mpsbr/T1-PowerLogicWE.pdf>. Acesso em: 19 de junho de 2009.

Melhoria de Processo de Software Brasileiro Guia Geral. verso 1.2. Disponvel em: <WWW.softex.com.br>. Acesso em: 23 de maio de 2009. Melhoria de Processo de Software Brasileiro Guia de Implementao Parte 1: Nvel G. verso 1.1. Disponvel em <WWW.softex.com.br>. Acesso em: 23 de maio de 2009. SANTANA, C. A.; TIMTEO, A. L.; VASCONCELOS, A. 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. Disponvel em: <bibliotecadigital.sbc.org.br/download.php?paper=973>. Acesso em: 01 de julho de 2009. SCHWABER, K. AGILE PROJECT MANAGEMENT WITH SCRUM. ed. Microsoft Press. Washington, 2004. SIQUEIRA, H. B. A.. MAPEAMENTO DAS PRTICAS DE SCRUM NAS REAS DE PROCESSO DO CMMI E UMA PROPOSTA PARA SUA ADERNCIA. Disponvel em: < www.cin.ufpe.br/~tg/2007-1/hbas.pdf>. Acesso em: 01 de julho de 2009.