FANOR FACULDADES NORDESTE SISTEMAS DE INFORMAO

JEFFERSON MATHEUS DA ROCHA BARBOSA

SCRUMPS: MAPEAMENTO DE PROCESSOS SCRUM PARA AVALIAO DO NVEL G DO MPS.BR

FORTALEZA, NOVEMBRO/2011

JEFFERSON MATHEUS DA ROCHA BARBOSA

SCRUMPS: MAPEAMENTO DE PROCESSOS SCRUM PARA AVALIAO DO NVEL G DO MPS.BR

Projeto de pesquisa (TCC 1) apresentado ao curso de Sistemas de Informao, das Faculdades Nordestes como requisito para obteno do ttulo do grau de bacharel. Orientador: Prof. Msc. Carlos Diego Andrade de Almeida.

FORTALEZA NOVEMBRO/2011

SUMRIO

1 1.1 1.2 1.3 1.4 1.5 1.6 2 2.1 2.2

INTRODUO ............................................................................................................................. 5 Contextualizao ....................................................................................................................... 5 Problemtica .............................................................................................................................. 7 Hipteses .................................................................................................................................... 7 Objetivos .................................................................................................................................... 8 Metodologia ............................................................................................................................... 9 Justificativa .............................................................................................................................. 10 REFERENCIAL TERICO ...................................................................................................... 11 Engenharia de Software.......................................................................................................... 11 Metodologias tradicionais ....................................................................................................... 12 Modelo Cascata ..................................................................................................................... 12 Modelo incremental............................................................................................................... 13 Manifesto gil e metodologias geis ...................................................................................... 14 Scrum ....................................................................................................................................... 16 Product backlog ..................................................................................................................... 16 Sprint backlog ....................................................................................................................... 16 Sprint ..................................................................................................................................... 17 Scrum Master ........................................................................................................................ 17 Product Owner....................................................................................................................... 17 Team Scrum .......................................................................................................................... 18 MPS.BR .................................................................................................................................... 18 ISO/IEC 12207 e ISO/IEC 15504 ......................................................................................... 18 CMMI-DEV ........................................................................................................................... 19 Nveis de implantao do MPS.BR ........................................................................................ 19 Gerncia de Projeto (GPR) ..................................................................................................... 20 Gerncia de Requisito (GRE) ................................................................................................. 21 Atributos de processo do nvel G ........................................................................................... 22 AP 1.1 O processo executado ............................................................................................ 22 AP 2.1 O processo gerenciado........................................................................................... 23 PROJETO ................................................................................................................................. 23 Possvel sumrio ...................................................................................................................... 23

2.2.1 2.2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.5.8 3 3.1

3.2

Cronograma ........................................................................................................................... 254

1

INTRODUO Neste captulo sero apresentados os elementos introdutrios que fazem parte do

projeto de pesquisa.

1.1 Contextualizao Partindo da contextualizao, ser feita uma breve explanao sobre a importncia de se organizar as etapas de produo de um software; como a engenharia de software pode auxiliar as equipes de desenvolvimento na execuo de suas tarefas; contextualizao sobre manifesto gil, metodologias geis, e modelos de maturidade em desenvolvimento de software. O incio desta explicao se dar a partir da crise do software, que foi um ponto na histria onde se tornou perceptvel a preocupao em se organizar os processos de software. A crise do software, que ocorreu em meados dos anos 60, foi um problema acarretado pela falta de prticas eficientes de se produzir software (SOMMERVILLE, 2003). Com esta crise, os sistemas desenvolvidos na poca possuam dificuldade em atender as regras de negcio do cliente com preciso. Devido a processos de desenvolvimento ineficientes e desorganizados, os sistemas frequentemente possuam falhas, o que gerava problemas para o cliente utilizador do sistema. Fizeram-se necessrias ento, formas de padronizar e ordenar a produo de software. Para isto, surgiu a engenharia de software, que buscou em aspectos da engenharia tradicional, prticas que pudessem ser utilizadas nas equipes de desenvolvimento. A partir disto, surgiram vrias metodologias e modelos para se planejar e trabalhar junto s equipes, como por exemplo, o modelo cascata, incremental, evolutivo, espiral, desenvolvimento formal, dentre muitas outras que foram surgindo e outras que evoluram a partir das existentes (SOMMERVILLE, 2003). Com a engenharia de software e o mercado em evoluo num ritmo intenso, as tecnologias em geral tendem a se adaptar s constantes mudanas impostas pelo mercado. Cada vez mais se faz necessrias formas de se desenvolver software num menor espao de tempo possvel, com menor custo e que atenda as regras de negcio do cliente em sua plenitude (PRESSMAN, 2006). Em 2001 foi publicado o Manifesto gil, um movimento idealizado por 17 autores (BECK et al. 2001) que, segundo eles prprios, estavam descobrindo a melhor forma de desenvolver software.

O manifesto consiste em conceitos chave que priorizam as etapas mais relevantes para o processo de produo de um software, buscando entregar um produto de qualidade ao cliente num curto espao de tempo. As formas de se trabalhar baseadas no Manifesto gil so chamadas de metodologias geis (MARAL, 2009). Uma das metodologias geis o Scrum, que atualmente um dos frameworks mais utilizados em termos de produo de software totalmente baseado no Manifesto gil. O Scrum prope uma abordagem simples e rpida de entregar verses do sistema em desenvolvimento ao cliente, para que possa entrar em produo no menor espao de tempo possvel (SCHWABER e SUTHERLAND, 2010). Em paralelo as metodologias de desenvolvimento, h os modelos de referncia ou modelos de maturidade -, que so um conjunto de boas prticas a serem implantadas nas organizaes com o objetivo de melhorar e padronizar o processo de desenvolvimento de software como um todo. Um dos modelos mais conhecidos o CMMI-DEV que possui cinco nveis de implantao, sendo cada nvel correspondente ao grau de maturidade que a organizao possui atualmente em se tratando de gerncia e execuo dos seus processos. Este grau de maturidade deve estar em evoluo para otimizar ao mximo a produtividade das equipes da organizao (MARAL, 2009). No Brasil, h o modelo MPS.BR (Melhoria do Processo de Software Brasileiro) que baseado no CMMI-DEV e em mais duas normas: a ISO/IEC 12207:2008 e ISO/IEC 15504 (SOFTEX, 2011). Tambm tem como objetivo melhorar e padronizar o processo de desenvolvimento de software. Assim como no CMMI-DEV, o grau de maturidade de uma organizao definido pelo nvel implantado. No MPS.BR h sete nveis de implantao. Com vrias metodologias e modelos disposio, qualquer uma pode se adequar a uma equipe de desenvolvimento. Tambm possvel mesclar as prticas de mais de uma metodologia ou modelo, que o caso deste trabalho: as prticas aliadas do Scrum ao MPS.BR.

1.2 Problemtica Para Pressman (2006), a falta de organizao nos fluxos dos processos pode acarretar em um ambiente catico, onde o produto final tem maiores chances de no atender o resultado esperado, alm de haver grande possibilidade de ser entregue com atrasos e custos maiores que os acordados com o cliente. Num ambiente de mercado crescente onde os resultados tm de ser entregues cada vez mais rpido, os aspectos qualidade com menor custo e prazo de entrega tornaram-se base para empresas que fabricam e vendem software. Um cenrio de desordem numa organizao pode surgir de diversas formas, tais como: Desconhecimento de prticas j eficientes existentes; Falta de busca por informaes novas; Falta de interesse das pessoas que lideram as equipes; As consequncias de uma equipe desorganizada so semelhantes a um ambiente de desenvolvimento na crise do software (SOMMERVILLE, 2003): Produo defasada do software; o O software no atendia a expectativa do cliente; o Os sistemas desenvolvidos possuam uma difcil implementao e manuteno; o Grande carga de retrabalho; Dificuldade nos gerenciamento de projeto; o Processos de software inconsistentes e confusos; o Insatisfao dos membros da equipe.

1.3 Hipteses As possveis solues propostas para a problemtica partem da seguinte hiptese bsica: para se produzir software de qualidade so necessrios processos geis e bem estruturados, assim como, uma boa gesto que reja todo o fluxo de execuo. Baseado nisto, h trs questionamentos a serem feitos: Por que importante melhorar a qualidade do software? Um servio executado dentro das melhores prticas e que possua as melhores ferramentas do mercado, no garantem o melhor produto, mas h todas as condies possveis de faz-lo. A qualidade do produto final definida pelo

cliente, pois a figura que validar o funcionamento do software. Outro fator que interfere diretamente na qualidade do produto final diz respeito qualidade dos processos utilizados (KATSURAYAMA, 2008).

Como possvel melhorar a qualidade do software? Uma das iniciativas obter informaes sobre as prticas, metodologias ou modelos mais utilizados no mercado atual e verificar a que mais se adequa a determinado tipo de organizao ou equipe. Para o escopo deste trabalho, o universo de prticas ser delimitado aos elementos comuns entre Scrum e MPS.BR numa metodologia hbrida, chamada Scrumps.

A partir de quando se pode iniciar um processo de melhoria? A qualquer momento. No modelo MPS.BR, por exemplo, h sete nveis de maturidade que descrevem a situao atual do ambiente de desenvolvimento e a partir de qualquer um deles, possvel se iniciar um processo de melhoria (SOFTEX, 2011).

A partir da hiptese bsica, possvel adicionar hipteses secundrias: Elevando-se o grau de qualidade dos processos, consequentemente, eleva-se a qualidade do software final; Quanto maior a capacidade de gerenciamento, maior o desempenho do fluxo dos processos; Com base nas hipteses, torna-se explcita a necessidade de se modificar um padro que apresenta problemas de funcionamento, por outro que venha agregar valor e melhorar as estruturas de processo e gesto. Esta mudana pode ser feita a partir de qualquer momento. 1.4 Objetivos O objetivo deste trabalho demonstrar a aderncia das prticas do Scrum aos resultados esperados da gerncia de projeto e de requisito presentes no MPS.BR. Este processo, denominado Scrumps, ir ressaltar pontos necessrios para se iniciar uma melhoria nos processos de software ou formao de novas equipes, visando desenvolver software de forma gil e de qualidade, alm de atribuir foco ao cumprimento dos resultados esperados para avaliao do nvel G do MPS.BR.

Objetivos especficos deste trabalho: Estudar sobre gesto de processos numa equipe de desenvolvimento, sob a viso do Scrum: o Demonstrar seu funcionamento em uma equipe; o Ressaltar os maiores obstculos em sua implantao; o Exibir as melhorias que uma equipe pode obter com sua implantao; Estudar fatores que interferem na qualidade do software e maturidade dos processos, sob a viso do MPS.BR: o Analisar os aspectos da gerncia de projeto; o Analisar os aspectos da gerncia de requisito; o Analisar os resultados esperados de ambas as gerncias e sua implantao numa equipe; o Verificar os processos onde o Scrum pode auxiliar em suas execues, visando alcanar os resultados esperados do nvel G do MPS.BR; No fazem parte do escopo deste trabalho: o Explicar sobre outras metodologias geis alm do Scrum; o Explicar sobre outros modelos alm do MPS.BR; o Detalhar outros nveis de implantao do MPS.BR alm do nvel G;

1.5 Metodologia Com o intuito de identificar prticas do Scrum que complementem o modelo MPS.BR, baseada na obra de Marconi e Lakatos (2009), ser realizada uma pesquisa bibliogrfica para a extrao de dados advindos de artigos, peridicos, teses, livros e dissertaes. De forma a integrar os dados coletados, sero realizadas entrevistas com pessoas que possuram, ou possuem, algum tipo de experincia com Scrum e/ou MPS.BR para que possam relatar, de acordo com suas prprias palavras, o resultado que obtiveram aplicando as tais prticas. Para relacionar os dados coletados, ser feita uma anlise crtica a partir dos resultados esperados das gerncias de projeto e de requisito, que fazem parte da avaliao do nvel G do MPS.BR, e relacionar como o Scrum poder auxiliar em cada processo.

1.6 Justificativa A justificativa deste trabalho consiste em exibir um cenrio onde h processos funcionando e software sendo produzido, porm os processos no so bem estruturados assim como a gesto que age por trs de toda a organizao. O resultado disto a produo de um software em que h grandes possibilidades de no satisfazer a expectativa do cliente, que caber dentro de um, ou mais, destes trs fatores: Custo; Prazo; Escopo.

Estes fatores esto interligados, a falta ou excesso de um deles causar um desequilbrio nos outros e isto ir se refletir no resultado do software final. O cenrio ideal de desenvolvimento consiste em: menor custo, menor prazo e cumprimento de 100% do escopo. Uma das formas de se buscar atingir o cenrio ideal, a aplicao de metodologias e modelos que neste trabalho tomam a figura do Scrum e do MPS.BR. O Scrum possui um modelo de gesto gil que se adapta facilmente ao cenrio de constantes mudanas inerentes a um ambiente de desenvolvimento de software, visando uma entrega rpida do produto ao cliente, com qualidade, em prazos e custos cada vez menores. Paralelamente, o modelo MPS.BR objetiva melhorar de forma contnua os processos de desenvolvimento que so executados atravs de uma srie de prticas, englobando desde aspectos gerenciais at rotinas operacionais. Esta melhoria incide diretamente na qualidade do software final. A mesclagem de prticas comuns entre Scrum e MPS.BR, denominada Scrumps, ter como objetivo tomar um cenrio de desenvolvimento de software defasado e desorganizado, conforme citado no incio do captulo; e inici-lo nas prticas propostas pelo nvel G do MPS.BR, para que, gradualmente, torne-se um ambiente de produo de software dinmico, gil, tolervel mudanas, com foco na expectativa do cliente.

2

REFERENCIAL TERICO Este captulo exibir o embasamento terico que ser utilizado como fonte de dados

para desenvolvimento do trabalho. Para isto, as bases de contedo terico que formaro as diretrizes principais so: o framework Scrum e o modelo de maturidade MPS.BR, mas h outras fontes de dados que sero utilizadas para reforar o contedo pertinente ao tema: conceitos de engenharia de software, definies de metodologias tradicionais, Manifesto gil e metodologias geis. 2.1 Engenharia de Software Segundo Sommerville (2003), a Engenharia de Software surgiu da necessidade de se organizar os processos de desenvolvimento de sistemas de grande porte devido ao seu alto grau de complexidade. Na chamada crise do software que esteve presente na dcada de 60, os custos com software aumentavam gradativamente em virtude de processos de desenvolvimento mal estruturados que impactavam no produto final: o sistema possua trechos de cdigo com erros que dificultavam sua manuteno e implementao; e muitas vezes no atendia as expectativas do cliente. Fizeram-se necessrias, ento, formas de se organizar o processo de desenvolvimento de software para acompanhar a complexidade que os sistemas exigiam. A Engenharia de Software trata todos os aspectos de produo de um software, desde os seus estgios iniciais at a manuteno deste sistema, depois que entrou em operao. H uma srie de modelos, ou paradigmas, que indicam vrias formas de se trabalhar com processos de desenvolvimento de software, tambm chamados de modelos de processo de software. Os modelos principais para o foco deste trabalho so o modelo cascata e o modelo incremental, mas tambm h outros: desenvolvimento formal, modelo evolutivo e modelo em espiral (SOMMERVILLE, 2003).

2.2 Metodologias tradicionais A estrutura das metodologias tradicionais, baseadas no modelo cascata, inflexvel e seu excesso de documentao desacelera o ciclo de produo do software. Para um processo continuar, o anterior deve finalizar e esta execuo sequencial alm de comprometer tempo do fluxo, tambm causa dificuldade em ter de retornar a algum processo para consertar uma falha, por exemplo. Dependendo de onde esta falha houvesse acontecido, o projeto teria de ser refeito quase totalmente, causando um aumento significativo no custo e prazo gerando insatisfao por parte do cliente (SOARES, 2004). 2.2.1 Modelo Cascata De acordo com Pressman (2006), o modelo de desenvolvimento em cascata, tambm chamado de ciclo de vida clssico, o mais antigo da engenharia de software e consiste em uma abordagem sistemtica e sequencial. Neste ponto, Pressman (2006) e Sommerville (2003) possuem apresentaes diferentes, embora parecidas, das sequencias dos processos do modelo cascata. O que se pode extrair em comum s duas abordagens apresentado na figura 1.

Figura 1 O modelo cascata.

As atividades devem ser executadas sequencialmente, uma aps finalizar a anterior e assim por diante. Mas na prtica, esses estgios se sobrepem e interagem entre si. Durante a fase de desenvolvimento, normal passar algumas dessas etapas o que pode ocasionar em que problemas deixem de ser identificados e solucionados. Esta prtica pode prejudicar a estrutura do sistema e no atingir as especificaes do cliente (SOMMERVILLE, 2003). De acordo com Pressman (2006), os trabalhos de software atuais devem acontecer rapidamente, pois o modelo cascata causa dependncia entre os processos, chamada de estados de bloqueio retardando o prazo de entrega do software. Em alguns casos o tempo de espera entre processos poder exceder o tempo de trabalho produzido. Para Sommerville (2003), a inflexo do modelo cascata prejudica a tomada de medidas contra mudanas, visto que para este modelo os requisitos devem estar claros e fixos. O que difcil de especificar, pois os requisitos do cliente sempre se modificam. No entanto, em desenvolvimento de software, so utilizadas outras abordagens tendo o modelo cascata como base. 2.2.2 Modelo incremental No modelo incremental, tambm chamado de modelo iterativo e incremental (citar alguma fonte aqui), proposta uma abordagem mais dinmica acerca dos processos de software, podendo-se dividir e trabalhar separadamente cada etapa do desenvolvimento facilitando a modificao do projeto e diminuindo o retrabalho no caso de mudana nos requisitos (SOMMERVILLE, 2003). De acordo com Pressman (2006), o modelo incremental consiste em produzir um sistema atravs de partes entregveis (verses). Os requisitos so coletados, catalogados e priorizados de acordo com a necessidade do cliente. Aps esta fase os requisitos priorizados sero transformados em funcionalidades que o sistema deve executar e uma parte deste sistema, contendo as tais funcionalidades, desenvolvida e entregue ao cliente para validao. O sistema pode, ou no, entrar em operao e o ciclo de desenvolvimento inicia-se novamente, fazendo com que o produto final seja desenvolvido, entregue gradativamente e sendo aperfeioado a cada verso.

H algumas vantagens em se utilizar o modelo incremental (SOMMERVILLE, 2003): O cliente no precisa esperar at que o sistema esteja totalmente pronto para utiliz-lo, a entrega peridica das verses do sistema permite que o cliente avalie de forma prematura, se o produto atende suas necessidades. Em caso negativo, uma modificao ser feita e entregue numa prxima verso; O cliente utiliza as primeiras verses do sistema para aprimorar o funcionamento do sistema a se adequar s suas necessidades. Desta forma o sistema passa por um processo de refinamento atravs de suas verses; H um risco menor no fracasso do projeto, pois uma vez que um erro ou falha detectado, pode ser facilmente corrigido devido aos processos de desenvolvimento ser trabalhados separadamente; Como as funcionalidades de maior prioridade so entregues nas primeiras verses, estas funcionalidades passam um maior nmero de vezes pela etapa de testes, o que diminui a chance de falha ou erro do sistema em suas operaes mais crticas. Ainda segundo Sommerville (2003), algumas das desvantagens do modelo incremental, a dificuldade de lidar com grandes sistemas (verses com mais de 20 mil linhas) e como h uma necessidade de se entregar uma funcionalidade a cada verso, pode ser que a funcionalidade no possua todos os recursos necessrios ao ser entregue a verso ao cliente. 2.3 Manifesto gil e metodologias geis Segundo Soares (2004), o termo gil em desenvolvimento de software se deu aps a publicao do Manifesto gil no ano de 2001 por dezessete autores (BECK et al. 2001) representando vrias metodologias de desenvolvimento de software como Scrum (SCHWABER, 1995) , XP (BECK, 1999), dentre outras. Com isto foi criada a Agile Alliance, com o objetivo de unificar pontos em comum entre estas metodologias. Os conceitos chave do Manifesto gil so:

Os indivduos e suas iteraes acima de processos e ferramentas; Software funcionando acima de documentao exaustiva; Colaborao do cliente acima de negociao contratual; Respostas s mudanas acima de execuo de um plano.

Estes conceitos propem uma forma de se trabalhar diferente das metodologias tradicionais, pois a complexidade dos sistemas aumenta cada vez mais, exigindo uma forma dinmica de se desenvolver software, onde as mudanas possam ser tratadas no decorrer do projeto e o cliente possa ter um resultado visvel cada vez mais rpido. De acordo com Maral (2009), as metodologias que tem um embasamento no Manifesto gil, so conhecidas como metodologias geis. Alm do manifesto, foram publicados tambm 12 princpios que complementam seus conceitos e guiam as prticas das metodologias geis.Doze princpios do software gil Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face. Software funcionando a medida primria de progresso. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente.

Contnua ateno excelncia tcnica e bom design aumenta a agilidade. Simplicidade - a arte de maximizar a quantidade de trabalho no realizado - essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo.

Tabela 1 Doze princpios do software gil.

2.4 Scrum Para Schwaber e Sutherland (2010), Scrum um framework de gerenciamento de processos empricos, ou seja, no importa a forma que o processo ser executado, mas deve ser gerenciado de alguma maneira. Para isto, o Scrum prope uma abordagem simples do seu fluxo de ao: 2.4.1 Product backlog Documento que contm todos os possveis requisitos que puderam ser coletados at um dado momento. Estes requisitos so priorizados de acordo com o nvel de necessidade e viabilidade para o desenvolvimento. Cada requisito corresponde a uma funcionalidade que o sistema ter de executar. O product backlog passa por constantes atualizaes, pois est sempre recebendo modificaes nos requisitos atuais e adio de novos. Depois de priorizados os requisitos, elaborado o sprint backlog.

2.4.2 Sprint backlog Corresponde a um item do product backlog, descreve com mais detalhes o requisito que ser transformado em uma funcionalidade. Nesta etapa so definidas uma srie de atividades que sero necessrias para implementar a funcionalidade dentro de uma faixa delimitada de tempo: o sprint. Assim como o product backlog, o sprint backlog est em constante atualizao devido as modificaes que ocorrem nos requisitos.

2.4.3 Sprint o tempo determinado para se implementar a funcionalidade que fora planejada no product backlog e, em seguida, no sprint backlog. Normalmente dura entre 2 e 4 semanas. Durante este perodo so divididas atividades que sero executadas diariamente a fim de se produzir uma verso para ser entregue ao cliente no final do sprint. Todos os dias, feita uma reunio entre todos os membros da equipe a fim de discutir o que foi feito, quais as dificuldades ou impedimentos que esto enfrentando e o que ser feito no prximo dia de trabalho. Essas reunies so realizadas normalmente pela manh com durao de 15 minutos, e so conhecidas pelo nome de daily meeting scrum. Ao o trmino do sprint, feita uma retrospectiva entre todos os membros da equipe levantando aspectos positivos, negativos e o que pode ser melhorado na execuo do prximo sprint. Ao final do sprint, o ciclo recomea: as mudanas sugeridas pelo cliente ou novos requisitos iro para o product backlog, que por sua vez sero priorizados e listados num sprint backlog que, por conseguinte ser desenvolvido atravs do sprint para se produzir uma nova verso do sistema contendo uma nova funcionalidade. Alm dos elementos de gerenciamento que foram apresentados, h tambm papis que possuem funes especficas na execuo do Scrum:

2.4.4 Scrum Master o responsvel por manter a prtica do Scrum entre todos os membros da equipe. Tambm resolve impedimentos e problemas que venham a interferir na execuo do fluxo de produo do software.

2.4.5 Product Owner Responsvel pelo resultado final do produto, pela manuteno do product backlog, priorizao dos requisitos e por tornar claro o entendimento entre todos os membros da equipe sobre o que o sistema deve fazer.

2.4.6 Team Scrum Corresponde ao time de desenvolvedores que iro implementar as funcionalidades no sistema descritos no sprint backlog. Seus membros se auto-organizam para definir e executar as atividades do sprint. Tambm so responsveis por identificar impedimentos que venham a interferir no processo de desenvolvimento prejudicando o andamento do projeto.

2.5 MPS.BR O MPS.BR (acrnimo de Melhoria de Processo do Software Brasileiro) um modelo de maturidade dos processos em desenvolvimento de software e possui sete nveis de implantao que iniciam do G (parcialmente gerenciado) at o A (em otimizao) (SOFTEX, 2011). De acordo com o Guia de Implementao do nvel G do MPS.BR (SOFTEX, 2011), este modelo objetiva alcanar uma srie de resultados que so preestabelecidos em funo dos processos decorrentes na organizao de acordo com o nvel em que se est sendo avaliado. O modelo prope de forma livre a implementao de tais processos, contudo os resultados devem ser atingidos de acordo com seu Guia de Avaliao1. O MPS.BR possui como referncia as normas internacionais ISO/IEC 12207:2008 (ISO/IEC, 2008a), ISO/IEC 15504 (ISO/IEC, 2003) e o modelo CMMI-DEV (SEI, 2010) (SOFTEX, 2010).

2.5.1 ISO/IEC 12207 e ISO/IEC 15504 A norma ISO/IEC 12207:2008 abrange o ciclo de vida dos processos de software. Contm processos, atividades e tarefas que devem ser aplicadas durante a aquisio de um produto de software ou servio e durante o fornecimento, desenvolvimento, operao, manuteno e eliminao dos produtos de software (ISO/IEC, 2008a).

1

O Guia de Avaliao do MPS.BR contm mtodos de avaliao dos resultados esperados para organizaes

que implantaram algum nvel do MPS.BR.

Os processos da ISO/IEC 12207 sero avaliados pela norma ISO/IEC 15504, que trata da avaliao dos processos de software, fornecendo informaes nos contextos de melhoria e capacidade dos processos. Descreve tambm, como os processos se encaixam e dispe de orientao de como eles devem ser aplicados num contexto especfico (ISO/IEC, 2003).

2.5.2 CMMI-DEV CMMI-DEV (Capacity Maturity Model Integration for Development) um modelo que possui uma abordagem de melhoria dos processos para desenvolvimento de software a fim de torn-los mais efetivos, eficazes para se produzir um resultado com maior qualidade. Esta melhoria feita atravs da aplicao de melhores prticas que podem ser utilizadas em pequenas equipes, projetos e organizaes inteiras (SEI, 2011).

2.5.3 Nveis de implantao do MPS.BR O MPS.BR objetiva melhorar o processo de desenvolvimento de software em uma organizao. Esta melhoria acontece de forma progressiva, para isto, h sete nveis de implantao do MPS.BR que seguem exatamente esta ordem (SOFTEX, 2010): Nvel G: Parcialmente gerenciado; Nvel F: Gerenciado; Nvel E: Parcialmente definido; Nvel D: Largamente definido; Nvel C: Definido; Nvel B: Gerenciado quantitativamente; Nvel A: Em otimizao. No que tange ao foco deste trabalho, apenas o nvel G ser abordado, pois destina-se a organizaes que buscam iniciar uma melhoria no gerenciamento de seus processos. A implementao do nvel G possui duas vertentes: a Gerncia de Projeto (GPR) e a Gerncia de Requisito (GRE) (SOFTEX, 2011).

2.5.4 Gerncia de Projeto (GPR) Segundo o Guia de Implementao do Nvel G do MPS.BR (SOFTEX, 2011), na gerncia de projeto esto atribudos os papis, responsabilidades, atividades que devem ser executadas para atingir o escopo e o andamento do projeto. um processo evolutivo at os prximos nveis do MPS.BR, no entanto alguns outros aspectos vo sendo incorporados conforme a evoluo. Para uma organizao iniciar sua melhoria em gerncia de projetos, aplicando os conceitos do nvel G do MPS.BR, devem ser atingidos 19 resultados esperados:

N GPR 1 GPR 2

Resultado esperado O escopo do trabalho do projeto definido. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados.

GPR 3 GPR 4

O modelo e as fases do ciclo de vida do projeto so definidos. (At o nvel F) O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas. O oramento e o cronograma do projeto, incluindo a definio de marcos e pontos de

GPR 5 controle, so estabelecidos e mantidos. Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e GPR 6 prioridade de tratamento so determinados e documentados. Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento GPR 7 necessrios para execut-lo. (At o nvel F) Os recursos e o ambiente de trabalho necessrios para executar o projeto so GPR 8 planejados. Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, GPR 9 armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana. Um plano geral para a execuo do projeto estabelecido com a integrao de planos GPR 10 especficos. A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries GPR 11 e recursos disponveis. Se necessrio, ajustes so realizados. O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido e GPR 12 mantido.

O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so GPR 13 monitorados em relao ao planejado. Os recursos materiais e humanos bem como os dados relevantes do projeto so monitorados GPR 14 em relao ao planejado. GPR 15 Os riscos so monitorados em relao ao planejado. GPR 16 O envolvimento das partes interessadas no projeto planejado, monitorado e mantido. GPR 17 Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento. Registros de problemas identificados e o resultado da anlise de questes pertinentes, GPR 18 incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas. Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos GPR 19 problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso.

Tabela 2 Resultados esperados do Gerenciamento de Projeto (GPR).

2.5.5 Gerncia de Requisito (GRE) Diz respeito a elicitao, anlise, identificao de inconsistncias e relao dos requisitos com o projeto (SOFTEX, 2011). Para aprimorar o processo de gerncia de requisito, devem ser alcanados cinco resultados:N Resultado esperado

GRE 1 O entendimento dos requisitos obtido junto aos fornecedores de requisitos. Os requisitos so avaliados com base em critrios objetivos e um comprometimento da GRE 2 equipe tcnica com estes requisitos obtido. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e GRE 3 mantida. Revises em planos e produtos de trabalho do projeto so realizadas visando a identificar e GRE 4 corrigir inconsistncias em relao aos requisitos. GRE 5 Mudanas nos requisitos so gerenciadas ao longo do projeto.

Tabela 3 Resultados esperados da Gerncia de Requisitos (GRE)

2.5.6 Atributos de processo do nvel G Para Sommerville (2003), um processo para desenvolvimento de um software consiste em um conjunto de atividades que iro gerar um produto final. Para a implantao do nvel G do MPS.BR (SOFTEX, 2011) os processos de desenvolvimento de software devem possuir atributos de processo (AP 1.1 e AP 2.1) que, assim como a gerncia de projeto e a gerncia de requisito, tambm possuem resultados esperados.

2.5.7 AP 1.1 O processo executado O atributo de processo AP 1.1 e seu resultado esperado.N RAP 1 Resultado esperado O processo atinge seus resultados definidos.

Tabela 4 Resultado esperado do atributo de processo AP 1.1

2.5.8 AP 2.1 O processo gerenciado O atributo de processo AP 2.1 e seus resultados esperados.N Resultado esperado

RAP 2 Existe uma poltica organizacional estabelecida e mantida para o processo. RAP 3 A execuo do processo planejada. RAP 4 (Para o nvel G) A execuo do processo monitorada e ajustes so realizados. As informaes e os recursos necessrios para a execuo do processo so identificados e RAP 5 disponibilizados. (At o nvel F) As responsabilidades e a autoridade para executar o processo so definidas, RAP 6 atribudas e comunicadas. As pessoas que executam o processo so competentes em termos de formao, treinamento RAP 7 e experincia. A comunicao entre as partes interessadas no processo planejada e executada de forma a RAP 8 garantir o seu envolvimento. (At o nvel F) Os resultados do processo so revistos com a gerncia de alto nvel para RAP 9 fornecer visibilidade sobre a sua situao na organizao. RAP (Para o nvel G) O processo planejado para o projeto executado. 10Tabela 5 - Resultado esperado do atributo de processo AP 2.1

3 PROJETO Este captulo visa apresentar o projeto do trabalho, demonstrando o planejamento das prximas etapas que devem ser realizadas na busca de alcanar os objetivos estabelecidos para o trabalho. 3.1 Possvel sumrio Introduo: o Motivao; o Objetivos; o Metodologia; o Estrutura; Gerenciamento de projeto: o Viso geral sobre gerenciamento de projeto;

Requisitos: o O que so requisitos; o Engenharia de requisitos;

Modelo MPS.BR: o Descrio; o Bases do MPS.BR; o Gerncia de requisitos; Resultados esperados; o Gerncia de projetos; Resultados esperados;

Scrum: o Viso geral; o Papis; o Pre game: Product backlog; Sprint backlog; o Game: Sprint; o Post game: Entrega e evoluo do software;

Scrumps Alcanando o nvel G do MPS.BR atravs de prticas Scrum: o Viso geral e objetivos: o Gerncia de requisito: Alcanando os resultados esperados; o Gerncia de projeto: Alcanando os resultados esperados; o Processos, papis e ferramentas;

3.2 CronogramaMs/Tarefa Pesquisa bibliogrfica Entrevistas Anlise dos dados Produo do trabalho Apresentao dez/11 jan/12 fev/12 mar/12 abr/12 mai/12 jun/12

Pesquisa bibliogrfica: perodo em que ser realizada a coleta de dados advinda de trabalhos acadmicos, tais como, livros, teses, monografias, trabalhos de concluso de curso e artigos cientficos;

Entrevistas: sero realizadas entrevistas de carter qualitativo com pessoas que possuram ou possuem experincia com Scrum e/ou MPS.BR; Anlise dos dados: neste perodo os dados da pesquisa bibliogrfica e entrevistas sero confrontados e preparados para serem inseridos no trabalho; Produo do trabalho: durante todos os outros perodos, exceto a apresentao, haver uma estrutura montada do trabalho preparada para receber os dados, tal estrutura ser modificada conforme os dados sero atualizados;

Apresentao: apresentao final do trabalho de concluso de curso.

5 BIBLIOGRAFIA ALMEIDA, Carlos Diego Andrade de. Continuidade da Execuo dos Processos de Software em Empresas Avaliadas no MPS.BR. 2011. 94f. Dissertao (mestrado) Universidade de Fortaleza.

FIGUEIREDO, Andr Lus Gouva de. ECO - Um Ecossistema para o Desenvolvimento gil de Sistemas Web. 2005. 137f. Dissertao (mestrado) Universidade de So Paulo.

KATSURAYAMA, Anne Elise. Apoio Garantia da Qualidade do Processo e do Produto em Ambientes de Desenvolvimento de Software Orientados a Organizao. 2008. 171f. Dissertao (mestrado) Universidade Federal do Rio de Janeiro.

KNIBERG, Henrik. Scrum e XP direto das Trincheiras. S.l: C4Media Inc, 2007.

MARAL, Ana Sofia Cysneiros. SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI. 2009. 205f. Dissertao (mestrado) Universidade de Fortaleza.

MONTEIRO, Renata Wariss, et al. O Esforo Requerido para Institucionalizao de Processos de Software na Prodepa. Programa de Engenharia de Sistemas de Computao. Rio de Janeiro: COPPE/UFRJ, 2008.

OLIVEIRA. Juliano Silva de. Metodologia Scrum Aplicada aos Processos de Gerncia e Desenvolvimento de Requisitos do Modelo MPS.BR. 2010. 72f. Trabalho de Concluso de Curso (graduao) Universidade de Santa Cruz do Sul.

PRESSMAN, Roger S.: Engenharia de Software. 6ed. So Paulo: McGrawHill, 2006.

SCHWABER, Ken; SUTHERLAND, Jeff: Scrum Guide. S.l: scrum.org, 2010.

SCRUM

ALLIANCE.

S.l,

nov.

2011.

What

is

Scrum?.

Disponvel

em:

. Acesso em: 11 nov. 2011.

SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Conselheiro Lafaiete, MG: Universidade Presidente Antnio Carlos, 2008.

SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral. [s.l]: SOFTEX, 2011, 57 p.

______. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MRMPS. [s.l]: SOFTEX, 2011, 48 p.