Universidade Estadual de Campinas Faculdade de Tecnologia Adaptação do Scrum ao Modelo Incremental

1 Universidade Estadual de Campinas Faculdade de Tecnologia Adaptação do Scrum ao Modelo Incremental Leonardo Bertholdo Lidia Regina de Carvalho Freitas Barban

2 Leonardo Bertholdo Lidia Regina de Carvalho Freitas Barban Adaptação do Scrum ao Modelo Incremental Monografia apresentada à Unicamp, junto à Faculdade de Tecnologia, como pré-requisito para conclusão da Disciplina FT027 Tópicos em Computação (Gestão de Projetos e Qualidade) sob orientação do Prof. Dr. Marcos Augusto F. Borges. LIMEIRA SP 2010

3 Bertholdo, Leonardo; Barban, Lidia R. C. F. Adaptação do Scrum ao Modelo Incremental, Limeira, 2010, 18 p. Monografia apresentada à Unicamp, junto à Faculdade de Tecnologia, como pré-requisito para conclusão da Disciplina FT027 Tópicos em Computação (Gestão de Projetos e Qualidade).

Professor Dr. Marcos Augusto F. Borges ----------------------------------------------------------- 4

5 SUMÁRIO 1 INTRODUÇÃO... 1 1.1 Contexto... 1 1.2 Justificativa... 1 1.3 Objetivos... 2 1.4 Organização do Trabalho... 2 2 MODELO INCREMENTAL... 3 3 SCRUM... 5 4 ESTUDO DE CASO... 9 4.1 Ambiente do Estudo de Caso... 9 4.2 Métodos Utilizados... 9 4.3 Descrição do Estudo de Caso... 10 4.4 Resultados e Constatações... 10 5 TRABALHOS RELACIONADOS... 12 6 CONCLUSÃO... 13 REFERÊNCIAS BIBLIOGRÁFICAS... 14

6 LISTA DE FIGURAS Figura 2.1: Modelo incremental... 3 Figura 3.1: Visão do processo na metodologia Scrum... 8 Figura 4.1: Modelo Incremental no produto Gerência da Planta... 9

7 RESUMO Devido à crescente competitividade do mercado atual e aos prazos cada vez mais restritos impostos por seus clientes, as empresas de desenvolvimento de software vem buscando metodologias mais ágeis para gestão do desenvolvimento de software. Há alguns anos, para mitigar os efeitos dessa demanda, muitas empresas adotaram o modelo incremental, cujo principal conceito é o desenvolvimento e a entrega incrementais do software. Recentemente, surgiu uma nova abordagem, denominada Scrum, que procurou otimizar ainda mais a entrega do produto de software aos clientes. Pela experiência dos últimos anos, metodologias ágeis, como o Scrum, muitas vezes precisam ser adaptadas às reais necessidades da empresa. Como este tipo de adaptação foi ainda pouco estudado, o principal objetivo desta pesquisa é contribuir para os estudos de viabilidade relacionados à adaptação do Scrum a metodologias mais tradicionais como o modelo incremental. Para isso, é apresentado um estudo de caso, que mostra as principais dificuldades e benefícios decorrentes dessa adaptação. Palavras-chave: Modelo incremental, métodos ágeis, Scrum. ABSTRACT Due to the increasing competitiveness of the current market and the increasingly strict deadlines imposed by their customers, companies software development has been seeking methodologies more agile for management of software development. A few years ago, to mitigate the effects of this demand, many companies have adopted the incremental model, whose main concept is the incremental development and delivery of software. Recently, came a new approach, called Scrum, which sought to further optimize the delivery of the software product to customers. For the experience of recent years, agile methods, like Scrum, often need to be adapted to real companies needs. As this type of adaptation was still little studied, the main objective this survey is to contribute to feasibility studies related to adapting Scrum to more traditional methods such as the incremental model. For this, it is presented a case study that shows the main difficulties and benefits resulting from this adaptation. Keywords: Incremental model, agile methods, Scrum.

1 1 INTRODUÇÃO Nesse capítulo são apresentados o contexto em que se insere este trabalho acadêmico, bem como os propósitos que levaram à sua realização. Também é mostrada uma breve descrição da estrutura do trabalho desenvolvido. 1.1 Contexto Nos últimos anos, devido a mudanças no ambiente de negócios, as empresas de desenvolvimento de software começaram a sofrer crescentes pressões para reduzir o time-tomarket. Isso se deveu principalmente à competitividade do mercado atual e aos prazos cada vez menos flexíveis impostos pelos clientes. Visando atender às novas exigências, essas empresas começaram a buscar modelos mais ágeis para gestão de projetos de desenvolvimento de software. Como alternativa, muitas empresas adotaram o modelo incremental, que combina conceitos do modelo clássico, também conhecido como modelo em cascata, com a abordagem evolucionária da prototipação e da iteração de processo. Conforme Sommerville (2007), No modelo incremental, um sistema é dividido em incrementos que possuem conjuntos de funcionalidades. O primeiro incremento é definido com as funcionalidades mais prioritárias, e os incrementos subsequentes são definidos com as funcionalidades adicionais. Cada incremento desenvolvido e validado é entregue ao cliente, que pode colocá-lo em operação e assim começar a usufruir antecipadamente de parte do sistema solicitado. Há poucos anos, surgiu uma nova abordagem para gestão de projetos de desenvolvimento de software denominada Scrum. Trata-se de uma metodologia ágil que utiliza conceitos semelhantes aos contemplados no modelo incremental, porém introduz uma série de elementos que procuram otimizar ainda mais a entrega periódica de incrementos funcionais do produto aos clientes. Entre as principais peculiaridades do Scrum estão: a organização dos recursos em equipes pequenas e multidisciplinares, as iterações dos incrementos (chamadas de sprints) normalmente mais curtas e o forte envolvimento do cliente durante todo o processo de desenvolvimento. 1.2 Justificativa A implantação de metodologias formatadas, como o modelo incremental e o Scrum, nem sempre são a melhor opção para uma empresa de desenvolvimento de software que deseja otimizar suas entregas e a satisfação de seus clientes. Em alguns casos, nem todos os

2 conceitos utilizados em uma metodologia podem ser implementados no ambiente da empresa, e outros conceitos considerados importantes para a empresa podem não ser contemplados pela metodologia escolhida. Em situações como essa, o que normalmente ocorre é uma adaptação da metodologia às necessidades da empresa. Esta adaptação muitas vezes acaba por criar uma abordagem híbrida própria da empresa, que pode envolver inclusive conceitos de diversas metodologias. A adaptatividade é uma das características mais marcantes de metodologias ágeis como o Scrum. No entanto, a adaptação dessas metodologias aos modelos tradicionais de desenvolvimento de software é relativamente recente e, por este motivo, ainda pouco pesquisada. Somando-se a este cenário a forte demanda por processos de desenvolvimento de software mais ágeis, nota-se a importância da disseminação das recentes experiências de combinação entre os modelos tradicionais e as novas metodologias ágeis. 1.3 Objetivos O principal objetivo deste trabalho é contribuir para a evolução dos conhecimentos relacionados aos processos de adaptação de metodologias ágeis a modelos tradicionais de desenvolvimento de software. Mais especificamente, tem como intuito obter informações sobre a viabilidade da adaptação do Scrum ao modelo incremental. Para isso, além de estudar as duas metodologias, foi utilizado como embasamento, um caso real de adaptação da metodologia Scrum ao modelo incremental. Com isso, foi possível elencar as principais dificuldades enfrentadas durante a transição do modelo formatado (Incremental) para o modelo híbrido (Incremental/ Scrum), além dos benefícios decorrentes dessa adaptação. 1.4 Organização do Trabalho Este trabalho contém uma introdução que é composta pelo contexto, a justificativa, o objetivo e a organização do trabalho. No segundo capítulo, é apresentado o modelo incremental de desenvolvimeno de software com suas principais características. O capítulo 3 descreve os conceitos mais importantes da metodologia para gestão de projetos de desenvolvimento de software Scrum. O quarto capítulo expõe um estudo de caso, onde ocorre a adaptação do Scrum ao modelo incremental vigente em uma empresa. O capítulo 5 cita alguns trabalhos relacionados a esta pesquisa. Por fim, o último capítulo apresenta às conclusões obtidas com este trabalho.

3 2 MODELO INCREMENTAL Podemos definir o modelo incremental como um processo de ciclo de vida iterativo e incremental com características do ciclo de vida seqüencial (TRAMMELL, 1996). No modelo em cascata as fases são seqüenciais: os requisitos são definidos, o projeto do sistema é criado, implementado e testado, é feita a integração e teste de sistema para finalmente entrar em produção. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa (PRESSMAN, 2006), ou seja, a cada incremento é fornecida uma parte do sistema aos clientes. O cliente define quais são os serviços principais e a partir da identificação dos serviços é feito o levantamento de requisitos e mapeado o primeiro incremento. Os processos de especificação, projeto, implementação e testes são feitos a cada incremento até o produto final ser entregue ao cliente gerando um sistema completo, conforme mostra a Figura 2.1. Figura 2.1: Modelo incremental Quando um modelo incremental é usado, o primeiro incremento é freqüentemente chamado de núcleo do produto (PRESSMAN, 2006). O núcleo do produto serve de base para os outros incrementos.

4 A cada incremento entregue ao cliente é desenvolvido um plano para o próximo incremento. Este processo é feito a cada termino e início dos incrementos e tem por objetivo alterar o núcleo do produto para atender o cliente (PRESSMAN, 2006). A interação do usuário é primordial no desenvolvimento incremental principalmente na definição dos principais serviços e no retorno (feedback) da utilização do sistema. As principais características do modelo incremental segundo Sommerville (2007) são: Os processos de especificação, projeto e implementação são concorrentes. O sistema é desenvolvido em uma série de incrementos. Ferramentas de apoio ao desenvolvimento interativo. são: De acordo com Sommerville (2007), as vantagens do desenvolvimento incremental Entrega dos incrementos ao cliente, ou seja, partes do sistema em funcionamento. Participação dos clientes ou usuários no processo de desenvolvimento incremental. são: Alguns dos problemas do desenvolvimento incremental segundo Sommerville (2007) Problemas no gerenciamento de grandes sistemas Problemas em montar um contrato para atender ambas as partes interessadas

5 3 Métodologias Ágeis e SCRUM Em 2001 um grupo de pesquisadores se reuniu com o intuito de criar melhores práticas para o desenvolvimento de software. Do resultado da reunião criou-se O Manifesto para Desenvolvimento Ágil de Software (MANIFESTO ÁGIL, 2001), modificando a importância dos valores aplicados no desenvolvimento de software: Estamos descobrindo melhores modos de desenvolvimento de software fazendo-o e ajudando outros a fazê-lo. Por meio deste trabalho passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano O manifesto também apresentou 12 princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

6 Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade é essencial e deve ser assumida em todos os aspectos do projeto. As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizadas. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo com a necessidade. Definir um processo como ágil significa permitir que a equipe possa adaptar e aperfeiçoar tarefas, manter apenas os trabalhos essenciais implementados, simplificar os trabalhos essenciais, fazer entregas incrementais do software funcionando ao cliente o mais rápido possível (PRESSMAN, 2006). Scrum é uma metodologia ágil de desenvolvimento de software, seu nome está relacionado a uma atividade que ocorre durante o jogo de rugby onde o grupo de jogadores se juntam ao redor da bola e trabalham juntos para mover a bola pelo campo (PRESSMAN, 2006). Os princípios do Scrum são compatíveis com o manifesto ágil: Pequenas equipes. O processo precisa ser adaptado para garantir que o melhor produto seja produzido. Produzir incrementos de software. Trabalho de desenvolvimento dividido. Teste e documentação são realizados durante todo o desenvolvimento. Os princípios do Scrum norteiam o processo de desenvolvimento de software que tem as seguintes atividades: levantamento de requisitos, análise, projeto, evolução e entrega. [Pressman, 2006] Os papéis no Scrum são: Product Owner, Scrum Master e Time. Scrum Master: Responsável por garantir o entendimento do processo do Scrum, responsável por motivar e treinar a equipe. Product Owner: Responsável pela priorização de requisitos que devem ser implementados, ou seja, responsável pelo gerenciamento do Product Backlog (lista de funcionalidades que serão implementadas no projeto).

7 Time (Equipe): Responsável pela execução e implementação das funcionalidades. Eventos com duração fixa empregados no Scrum: Sprint Planning Release: Reunião de Planejamento da Release Sprint Planning Meeting: Reunião de Planejamento da Sprint Sprint Daily Scrum: Reunião Diária Sprint Review: Revisão da Sprint Sprint Retrospective: Restrospectiva da Sprint O principais artefatos do Scrum são: O Sprint: É uma interação de duas a quatro semanas, todas as sprint tem como resultado um incremento do produto que pode ser entregue. O Product Backlog: Lista priorizada do que o produto precisa ou pode ter. Backlog da Sprint: Lista de tarefas para produzir o Backlog do Product em um incremento entregável. Burndown: É uma medida, pode variar dentro do contexto. Podemos ter um Burndown de Sprint para medir o quanto falta ds tarefas dentro do tempo do Sprint. Relacionamento entre os papéis, artefatos e eventos descritos na Figura 3.1: O Product Owner, juntamente com o Scrum Master são responsável por manter a lista priorizada de requisitos que devem ser implementados do Product Backlog. A cada Sprint, o time decide quais itens do Product Backlog serão implementados Sprint Backlog em uma reunião especial denominada Sprint Planning Meeting. O time é responsável por implementar a funcionalidade escolhida e demostrar ao Product Owner do Sprint Sprint Review. No final do Sprint o time faz uma revisão do trabalho Retrospectiva do Sprint. Uma reunião diária de 15 minutos denominada Daily Scrum é realizada. Na Daily Scrum, cada desenvolvedor deve responder a três perguntas: O que eu fiz desde a última Daily Scrum?

8 O que eu vou fazer hoje? Existe algum obstáculo que me impeça de fazer o trabalho? Figura 3.1: Visão do processo na metodologia Scrum

9 4 ESTUDO DE CASO O propósito deste estudo de caso é adquirir conhecimento e experiência nos processos de adaptação de metodologias ágeis a modelos tradicionais de desenvolvimento de software por meio de um caso real. Em particular, espera-se contribuir com novas informações sobre a viabilidade da adaptação do Scrum ao modelo incremental tradicional. 4.1 Ambiente do Estudo de Caso O ambiente escolhido para esse estudo de caso foi o de uma empresa de grande porte que atua, entre outros segmentos, no desenvolvimento de aplicações voltadas para a área de telecomunicações. Esta empresa desenvolve um produto de software denominado Gerência da Planta, o qual tem como principais clientes grandes operadoras do setor de telecomunicações. Basicamente, este produto tem como finalidade gerenciar todas as informações relacionadas à infra-estrutura da rede de telefonia instalada em campo, bem como os serviços que esta infraestrutura provê aos assinantes da operadora. Até pouco tempo, a empresa utilizava o modelo incremental puro nos projetos de evolução e manutenção deste produto, conforme ilustra a Figura 4.1. No entanto, há alguns meses, passou a introduzir alguns conceitos da metodologia ágil Scrum em seu processo de desenvolvimento de software. Projeto GP-5.2 Versão 5.2 Versão 5.2 Patch 5.2.1 Versão 5.2 Patch 5.2.1 Patch 5.2.2 Figura 4.1: Modelo Incremental no produto Gerência da Planta 4.2 Métodos Utilizados Devido à introdução do Scrum ainda estar em um estágio experimental, não foram encontradas fontes textuais que explanassem detalhadamente como está se dando a adoção deste novo paradigma.

10 Por este motivo, para coletar os dados para a análise do estudo de caso foi utilizada a técnica de entrevistas. Os entrevistados foram escolhidos de acordo com o conhecimento e a vivência que tinham nos projetos de evolução e manutenção deste produto. São eles: dois coordenadores de projeto e dois líderes de equipe (equivalente ao papel de Scrum Master). 4.3 Descrição do Estudo de Caso Conforme foi dito, os projetos relacionados ao produto Gerência da Planta utilizavam o processo de desenvolvimento baseado no modelo incremental. Com base nas entrevistas realizadas, foram observadas as seguintes mudanças com a introdução de conceitos da metodologia Scrum: Os recursos passaram a ser divididos em equipes, sendo que cada uma delas passou a ser responsável por uma feature do projeto dentro de um sprint do projeto. Essas equipes são pequenas (até 10 pessoas) e multidisciplinares, envolvendo pessoas das áreas de requisitos, desenvolvimento, banco de dados e testes. Cada equipe passou a contar com um líder de equipe (algo equivalente ao papel do Scrum Master), que atua como uma facilitador removendo eventuais obstáculos. Cada feature do conjunto de features do projeto (Product Backlog) passou a ser desenvolvida em um sprint que normalmente dura até 4 semanas. Passaram a ser realizadas as Daily Meetings, que na verdade ocorrem em dias alternados. O gráfico Burndown Chart, que mostra a quantidade de horas restantes para a conclusão do sprint em função do tempo, passou a ser utilizado. 4.4 Resultados e Constatações Pode-se notar que apenas alguns conceitos do Scrum foram utilizados puramente; alguns foram adaptados e outros não implementados. Mesmo com a implementação parcial desta metodologia, já foi possível observar alguns impactos positivos decorrentes da quebra do paradigma do modelo incremental puro. A análise dos resultados desta mudança ainda está na fase de coleta de indicadores, porém já foi percebida uma considerável melhora na interação entre os membros das diferentes áreas (requisitos, codificação, banco de dados e testes) envolvidas nos projetos. De acordo com as análises iniciais, outro efeito positivo foi uma pequena redução nos esforços.

11 Uma das constatações desse estudo de caso está relacionada à multidisciplinaridade da equipes que é recomendada pelo Scrum. Em outras palavras, cada um dos integrantes da equipe deveria teoricamente possuir conhecimento genérico das diferentes áreas, que abrangem a especificação, a construção e a validação do software. O ponto negativo dessa característica é que muitas vezes um especialista pode acabar se envolvendo com assuntos que não são de seu domínio, o que faz com que seu potencial não seja totalmente aproveitado. Outra consideração a ser feita com relação aos recursos humanos, é que o líder da equipe (papel que equivale ao Scrum Master) normalmente é um especialista da área de codificação, e o ideal seria que fosse alguém com conhecimento genérico de outras áreas também, como requisitos e testes. Ainda relacionado à questão da liderança, foi constatado que apesar de existir um papel semelhante ao do Scrum Master e um dos conceitos do Scrum ser o autogerenciamento das equipes, no modelo adaptado deste estudo de caso ainda persiste o papel do coordenador de projeto. Nesse modelo, as equipes e os sprints são organizados por feature do projeto (o conjunto dessas features equivale ao Product Backlog). Pelo Scrum, ao final de cada sprint, deveria ser entregue ao cliente um software com valor de negócio agregado. No entanto, como as funcionalidades do produto em questão são grandes e muito interdependentes tornase difícil organizar os sprints de modo que cada um deles consiga entregar um software com real valor de negócio. Por exemplo: no sprint 1 será desenvolvida a funcionalidade A, porém esta funcionalidade somente faz sentido se for integrada à funcionalidade B, a qual será desenvolvida no sprint 2. Nesse exemplo, pode-se ver que não faz sentido entregar o software no sprint 1, já que esta entrega não agregará nenhum valor ao seu negócio para o cliente. Devido a esta forte interdependência entre as funcionalidades do produto, os resultados dos sprints intermediários não são entregues ao cliente. Também pode-se notar que, por motivos de disponibilidade, não há envolvimento do cliente (papel que seria equivalente ao Product Owner) em tempo integral. Para simular este papel, quando é necessário tratar alguma questão referente ao produto que está sendo desenvolvido, existe uma pessoa da área de requisitos que faz a interface com o cliente. Por fim, como os integrantes que compõem as equipes não trabalham próximos fisicamente, também foi observado que a falta de um leiaute adequado pode dificultar relativamente a comunicação interna da equipe.

12 5 TRABALHOS RELACIONADOS Fagundes (2008) faz uma comparação entre os processos propostos pelos métodos ágeis Scrum, XP (Extreme Programming), FDD (Feature Driven Development) e ASD (Adaptive Software Development), visando a auxiliar a equipe de desenvolvimento na escolha do método que melhor se adapte a suas expectativas. Para fazer a comparação, foram utilizadas as tradicionais atividades do modelo incremental. Para cada atividade é apresentada uma descrição da tarefa correspondente em cada método analisado. Marçal (2008) apresenta um mapeamento entre o CMMI e a metodologia ágil Scrum, mostrando as diferenças entre eles e identificando como as organizações estão adotando práticas complementares em seus projetos para tornar essas duas abordagens mais integráveis. A pesquisa pode ser útil para organizações que seguem o modelo CMMI e estão planejando melhorar a agilidade dos seus processos, ou para ajudar as organizações a definir um novo modelo de gestão do projetos baseando-se em ambas as metodologias. Szimanski (2009) expõe um estudo de caso onde ocorre a extensão da metodologia ágil Scrum para as áreas de processo do MPS.BR nível G aplicada em uma pequena fábrica de software. Segundo os autores, o estudo realizado pode contribuir de forma relevante para organizações que desejam promover a melhoria da qualidade dos seus produtos, por meio da introdução de práticas ágeis no seu processo de desenvolvimento de software mantendo a compatibilidade com o MPS.BR.

13 6 CONCLUSÃO Esta pesquisa foi realizada com a finalidade de contribuir para a evolução dos conhecimentos relacionados aos processos de adaptação de metodologias ágeis a formas tradicionais de desenvolvimento de software, como o modelo incremental. De certa forma, podemos considerar o modelo incremental como um precursor do Scrum, pois um dos principais conceitos desta última metodologia a entrega periódica de software com valor de negócio está alinhado com a essência do modelo incremental. Com o estudo de caso foram levantadas algumas questões que merecem reflexão como: a dificuldade notória em se implantar integralmente os conceitos de metodologias ágeis em um ambiente que utiliza um modelo mais tradicional, as possíveis desvantagens da multidisciplinaridade das equipes e a dificuldade em se implementar de forma confiável e eficiente o autogerenciamento das equipes. Também foi possível notar alguns obstáculos existentes para se realizar entregas com real valor de negócio e de forma incremental, em situações onde as funcionalidades do produto são grandes e muito interdependentes. Baseado no estudo realizado, pode-se concluir que a decisão de adotar metodologias ágeis no processo de desenvolvimento de software depende de vários fatores como: a complexidade do produto de software, a maturidade e o comprometimento das equipes, a disponibilidade do cliente, a cultura da empresa, entre outros. Como não existem prescrições prontas que considerem as inúmeras combinações destas variáveis, a adoção dessas metodologias demandará sempre uma análise aprofundada em cada caso, para avaliar quando e como deverá ser implantada ou adaptada a metodologia escolhida.

14 REFERÊNCIAS BIBLIOGRÁFICAS FAGUNDES, P. B.; DETERS, J. I.; SANTOS, S. S. Comparação entre os processos dos métodos ágeis: XP, SCRUM, FDD e ASD em relação ao desenvolvimento iterativo incremental. E-Tech: Atualidades Tecnológicas para Competitividade Industrial. Florianópolis, v. 1, n. 1, p. 37-46, 1º. sem. 2008. MANIFESTO ÁGIL. Apresenta texto sobre o manifesto ágil. Disponível em: <http://agilemanifesto.org/>. Acesso em: 15 jun. 2010. MARÇAL, A. S. C. et al. Blending Scrum practices and CMMI project management process areas. Innovations in Systems and Software Engineering, Londres, v. 4, n. 1, p.17-29, abr. 2008. PRESSMAN, R. S. Engenharia de Software. 6ª ed. Rio de Janeiro: McGraw-Hill, 2006. 40, 41, 60, 69, 70 p. SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson, 2007. 552 p. SZIMANSKI, F.; ALBUQUERQUE, J.; FURTADO, F. Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 161-170. TRAMMELL, C. J. et al. The incremental development process in Cleanroom software engineering. Decision Support Systems 17, 1996, 55-71 p.