• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR
 

TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR

on

  • 11,338 views

Trabalho de conclusão apresentado ao curso de Sistemas de Informação da Universidade de Santa Cruz do Sul, para obtenção do título de Bacharel em Sistemas de Informação. ...

Trabalho de conclusão apresentado ao curso de Sistemas de Informação da Universidade de Santa Cruz do Sul, para obtenção do título de Bacharel em Sistemas de Informação.

Orientadora: Prof.ª Daniela Duarte da Silva Bagatini.

Statistics

Views

Total Views
11,338
Views on SlideShare
11,330
Embed Views
8

Actions

Likes
3
Downloads
554
Comments
0

4 Embeds 8

http://tecnologia-de-valor.blogspot.com 4
http://tecnologia-de-valor.blogspot.com.br 2
http://www.slideshare.net 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Document Transcript

    • CURSO DE SISTEMAS DE INFORMAÇÃO Juliano Silva de Oliveira METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Capão da Canoa, junho de 2010.
    • UNIVERSIDADE DE SANTA CRUZ DO SUL METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Trabalho de conclusão apresentado ao curso de Sistemas de Informação da Universidade de Santa Cruz do Sul, para obtenção do título de Bacharel em Sistemas de Informação. Orientadora: Prof.ª Daniela Duarte da Silva Bagatini. Capão da Canoa, junho de 2010.
    • “In the end, The Love you take Is equal to The Love you make.” (The Beatles – The End)
    • AGRADECIMENTOS Este é o trabalho que culmina minha passagem pelo curso de Sistemas de Informação, logo, é impossível não deixar de lembrar que diversas pessoas possibilitaram que eu pudesse chegar até este ponto. Agradeço, aos meus familiares – que sempre estiveram do meu lado –, aos meus colegas – que junto comigo, batalharam por este curso –, aos meus professores – que, a pesar das longas viagens, sempre estavam dispostos a dar o melhor de si –, e a todos que de forma direta ou indireta, contribuíram para minha chegada até aqui.
    • RESUMO Este trabalho trata do mapeamento entre os processos de Gerência de Requisitos e Desenvolvimento de Requisitos do Modelo MPS.BR alinhados a metodologia ágil Scrum. MPS.BR é um modelo de qualidade do processo de software fundamentado em normas e modelos conceituados, organizado de maneira a facilitar sua implantação por pequenas e médias empresas de desenvolvimento de software do mercado brasileiro. Scrum é uma metodologia ágil, amparada nos princípios e valores do Manifesto Ágil. É um framework para gerenciamento de projetos de desenvolvimento de software, baseado em processos empíricos, com iterações curtas e entregas rápidas de software pronto. Os processos de Gerência e Desenvolvimento de Requisitos, do Modelo MPS, foram mapeados com as práticas Scrum. Alguns resultados esperados dos processos mapeados são parcialmente ou não satisfeitos pela prática Scrum. Nestes casos, algumas ações podem ser tomadas no intuito de adicionar características, que não destituem os conceitos básicos de Scrum, mas que satisfazem os processos do modelo MPS.
    • ABSTRACT This paper is about a mapping between MPS.BR model’s Requirements Management and Requirements Development processes aligned at Scrum Agile Methodology. MPS.BR is a Process Quality Model based at standards and other models conceptualized, organized to facilitate its implantation at small and medium software development companies from Brazilian market. Scrum is an Agile Methodology, based at Agile Manifesto’s principles and values. It’s a framework for management software development projects, based at empirical processes, with short iterations and quick delivery of software done. The MPS.BR model’s Requirements Management and Requirements Development process were mapped with Scrum practices. Some process expected results mapped are partly or not satisfied by the Scrum practices. In these cases, some actions can be taken to add features that not deprive the Scrum basic concepts, but satisfy the MPS model’ processes.
    • LISTA DE ABREVIATURAS ABNT Associação Brasileira de Normas Técnicas AP Atributos de Processo BP Backlog do Produto BPV Backlog do Produto para a Versão BS Backlog da Sprint BV Bussines Value CMMI-DEV Software Capability Maturity Model for Development DRE Processo de Desenvolvimento de Requisitos GRE Processo de Gerência de Requisitos IEC International Electrotechnical Commission ISO International Organization for Standardization JAD Joint Application Development MPS.BR Melhoria do Processo de Software Brasileiro MR-MPS Modelo de Referência do MPS.BR PCP Processo de Projeto e Construção do Produto PO Product Owner RAP Resultados esperados de atributos de processo ROI Return Of Investiment RPVE Reunião de Planejamento da Versão para Entrega SM ScrumMaster SOFTEX Associação para Promoção da Excelência do Software Brasileiro SPICE Software Process Improvement and Capability Eternation TS Time Scrum VAL Processo de Validação VER Processo de Verificação XP Extreme Programming
    • SUMÁRIO 1 INTRODUÇÃO ..................................................................................................................... 9 2 REQUISITOS DE SOFTWARE ......................................................................................... 11 2.1 Visão geral sobre requisitos.............................................................................................. 11 2.2 Tipos de requisitos ............................................................................................................ 14 2.2.1 Requisitos funcionais..................................................................................................... 14 2.2.2 Requisitos não funcionais .............................................................................................. 14 2.2.3 Requisitos de domínio ................................................................................................... 16 2.3 Processo de engenharia de requisitos ............................................................................... 16 2.3.1 Estudo de viabilidade..................................................................................................... 17 2.3.2 Elicitação e análise de requisitos ................................................................................... 18 2.3.3 Validação de requisitos.................................................................................................. 19 2.3.4 Gerenciamento de requisitos ......................................................................................... 20 2.4 Requisitos e os modelos MPS.BR e Scrum ...................................................................... 21 3 FRAMEWORK SCRUM .................................................................................................... 22 3.1 Visão geral sobre metodologias ágeis .............................................................................. 23 3.2 Introdução ao Scrum ......................................................................................................... 23 3.2.1 Times Scrum, seus papéis e responsabilidades ............................................................. 24 3.2.2 Eventos .......................................................................................................................... 25 3.2.3 Artefatos ........................................................................................................................ 27 3.2.4 Software Pronto ............................................................................................................. 29 3.3 Fluxo do Scrum ................................................................................................................ 29 4 MODELO MPS.BR ............................................................................................................. 33 4.1 Introdução ao Modelo MPS.BR ....................................................................................... 33 4.2 Base técnica do Modelo MPS.BR .................................................................................... 34 4.3 Estrutura do MR-MPS.BR................................................................................................ 36 4.3.1 Níveis de maturidade ..................................................................................................... 36 4.3.1.1 Processos .................................................................................................................... 37 4.3.1.2 Capacidades de processos........................................................................................... 38 4.4 Processo de Gerência de Requisitos ................................................................................. 39
    • 4.4.1 Processo GRE – Propósito............................................................................................. 40 4.4.2 Processo GRE – Resultados Esperados ......................................................................... 40 4.5 Processo de Desenvolvimento de Requisitos ................................................................... 42 4.5.1 Processo DRE – Propósito............................................................................................. 43 4.5.2 Processo DRE – Resultados Esperados ......................................................................... 43 5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 46 5.1 Mapeamento entre os processos GRE e DRE com Scrum ............................................... 46 5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum ......................... 51 5.3 Estendendo o Scrum ......................................................................................................... 53 6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 55 6.1 Dificuldades práticas na implantação do processo GRE .................................................. 56 6.2 Dificuldades práticas relacionadas a requisitos de software ............................................ 57 6.3 Dificuldades práticas relacionadas ao Scrum ................................................................... 58 6.4 Além das limitações de MPS e Scrum ............................................................................. 59 7 CONCLUSÃO ..................................................................................................................... 60 7.1 Trabalhos futuros .............................................................................................................. 61 8 REFERÊNCIAS .................................................................................................................. 62 ANEXO A – Manifesto Ágil - Valores .................................................................................. 65 ANEXO B – Manifesto Ágil - Princípios............................................................................... 66 ANEXO C – Atributos de Processo - AP 1.1 ......................................................................... 67 ANEXO D – Atributos de Processo - AP 2.1 ......................................................................... 68 ANEXO F – Atributos de Processo - AP 3.1 ......................................................................... 70 ANEXO G – Atributos de Processo - AP 3.2 ......................................................................... 71
    • 9 1 INTRODUÇÃO A sociedade moderna, formada por indivíduos, luta diariamente contra o acaso e o caos. O ser humano parece estar sempre caminhando no sentido de buscar uma ordem para o contexto em que vive, seja pensando a respeito do sentido de sua própria existência ou buscando administrar os processos existentes de uma maneira mais eficiente e eficaz. As instituições que compõe a sociedade moderna têm em sua formação estes indivíduos, logo, a necessidade de ordenar, administrar, aplicar uma forma de trabalho nestas organizações é inerente ao seu processo de gerenciamento. Segundo Chiavenato (2000), toda a produção de bens e serviços é realizada dentro de organizações. Na área da tecnologia da informação, não é diferente, todos os produtos e serviços, mesmo o de desenvolvimento de software, é realizado por organizações. E elas estão sob as mesmas regras das demais empresas. Lutam diariamente para sobreviver ao mercado. Dentre as estratégias utilizadas para serem competitivas, as organizações, desde cedo, têm focado no controle de seus processos, buscando produzir mais e com mais qualidade, ao mesmo tempo em que se consome menos. Na história das organizações, existiram diversos modelos que propiciaram este pensamento, como o Taylorismo, o Fordismo ou o Toyotismo (CHIAVENATO, 2002). A indústria do software também tem os seus modelos. Ao entender que, devemos ter plena consciência dos modelos, devemos entender também, e com muito mais ênfase, os modelos que hoje estão na vanguarda das gestões organizacionais. Com isto em mente, a pretensão do presente trabalho é de poder apontar como uma organização pode melhorar seus produtos, serviços e processos, sob o ponto de vista dos requisitos de software, usando o modelo MPS.BR juntamente com o modelo de desenvolvimento ágil Scrum. Este trabalho será focado nos processos do MPS.BR relacionados a requisitos de software justamente porque requisitos e Scrum têm um ponto fortemente em comum: o foco
    • 10 em pessoas e as implicações do envolvimento delas no processo de desenvolvimento de software. Para tal objetivo, uma visão geral sobre requisitos será apresentada no capítulo dois; o capítulo três fará uma apresentação das metodologias ágeis e um maior detalhamento do Scrum; o capítulo quatro mostra o modelo MPS.BR, com um foco maior sobre os processos de gerência e desenvolvimento de requisitos; o capítulo cinco, é dedicado ao mapeamento, resultados e análise do uso do Scrum associado aos processos de requisitos do MPS.BR; o capítulo seis trará considerações a respeito da possibilidade da aplicação prática do assunto abordado; e por fim as conclusões do trabalho.
    • 11 2 REQUISITOS DE SOFTWARE Os requisitos são intrínsecos ao processo de desenvolvimento de software, entendê-los corretamente evita a grande maioria dos problemas que uma aplicação poderá ter. Requisitos são temas recorrentes em diversos trabalhos acadêmicos. Neste trabalho, para que se possa compreender o que o modelo MPS.BR e o Scrum apregoam a respeito de requisitos, faz-se uma abordagem da área apresentando algumas considerações a respeito. 2.1 Visão geral sobre requisitos Requisitos segundo Parzianello (2009) “são descrições das propriedades necessárias e suficientes de um produto de software que devem ser atendidas para garantir que se cumpra o que foi projetado, atendendo as necessidades de seus usuários”. De acordo com Ávila (2007), requisitos são “o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema de negócio no qual o cliente faz parte”. Ou ainda, são necessidades ou expectativas expressas, geralmente, de forma implícita ou obrigatória (Associação Brasileira de Normas Técnicas – ABNT, 2000). Podemos entender requisitos como necessidades de um cliente ou usuário que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. Enxergando o contexto dos requisitos de uma maneira mais ampla, podemos dizer que eles possuem três focos: negócios, usuários e o software. Os requisitos de usuário dirão o quê deve ser feito, enquanto que os requisitos de negócio, são elementos que correspondem às regras do negócio, respondem o porquê algo deve ser feito. E os requisitos de software mostrarão como a solicitação do usuário será atendida dentro das regras do negócio (figura 1).
    • 12 Figura 1 – O Contexto dos Requisitos Fonte: PARZIANELLO, 2009. Entender os requisitos é descobrir o que o cliente quer com o sistema (WAZLAWICK, ntender ( 2004, p. 24). Logo, por requisitos abrangerem todas as características importantes do software que será produzido, a elaboração destes torna se uma das fases mais importantes de todo o torna-se importan projeto de software. É na análise de requisitos que boa parte dos erros são introduzidos. Cenários, como apresentado na tabela 1 por Ávila (2007), mostram que defeitos não tratados ainda na fase de Á , requisitos podem aumentar consideravelmente o custo do desenvolvimento do projeto. Ao contrário, a correção, ainda nesta fase, possui um custo baixo (conforme primeira linha da ne conforme tabela 1). Tabela 1 – Cenário Atual de Desenvolvimento % do custo de % dos erros % dos erros Custo relativo desenvolvimento esenvolvimento introduzidos encontrados de correção Análise de Requisitos 05 55 18 1 Projeto 25 30 10 1 - 1.5 Codificação teste de 50 unidade Teste 10 10 50 1-5 Validação e 10 Documentação Manutenção 05 22 10 - 100 Fonte: ÁVILA, 2007.
    • 13 Diversos estudos de caso mostram que pelo menos um terço dos defeitos encontrados nos projetos de software são originados de erros no levantamento de requisitos (PARZIANELLO, 2009). Pela sua importância, a análise de requisitos é uma das fases que mais precisam atenção. E mesmo tendo consciência a respeito de sua natureza e de como elicitar requisitos, ainda há uma grande dificuldade em atingir o sucesso nessa tarefa em um projeto de software. Um ponto que não pode ser deixado de lado, em nenhuma fase da produção de um software ou de qualquer produto ou serviço, e que na fase de análise de requisitos assume uma importância maior ainda, é a natureza humana. Ela está envolvida em cada ação para se chegar ao entendimento dos requisitos, e cabe aos analistas entender o impacto da natureza humana ao elicitar requisitos de software. Chiavenato (2002, p. 113) expõe através da Hierarquia das Necessidades de Maslow, que nas motivações humanas, muitas de nossas necessidades são implícitas, e podem ser organizadas em níveis, com uma hierarquia de importância e influência. Estes requisitos dos seres humanos apresentados por Maslow, de realização pessoal, estima, amor/relacionamento, segurança e fisiologia, são implícitos. Requisitos implícitos fazem parte dos humanos assim como fazem parte dos softwares. A Norma NBR ISO 9000:2000, ao conceituar requisitos, diz que eles podem ser implícitos ou obrigatórios, e explica em nota que, “geralmente implícito significa que é uma prática costumeira ou usual para a organização, seus clientes e outras partes interessadas, e que a necessidade ou expectativa sob consideração está implícita”. A mesma norma também aponta que “um requisito especificado é um requisito declarado, por exemplo, em um documento” (ABNT, 2000, p. 7). Logo, requisitos implícitos para quem os solicita, acabam não sendo especificados por não serem implícitos para os analistas que deveriam documentá-los. Tem-se então um problema entre a maneira como diferentes pessoas enxergam a realidade.
    • 14 Assim, sendo requisitos um tema central no cenário de desenvolvimento de software, é necessário conhecer algumas das principais definições da engenharia de requisitos, importante no dia a dia de profissionais envolvidos com o ciclo de vida do software. 2.2 Tipos de requisitos Sommerville (2003) classifica os requisitos de software em três tipos: Requisitos funcionais, Requisitos não funcionais e Requisitos de domínio. 2.2.1 Requisitos funcionais Requisitos funcionais são declarações detalhadas das funções que o sistema deve executar e como deve ser seu comportamento diante de entradas e situações específicas (SOMMERVILLE, 2003). Ávila (2007) citam alguns exemplos de requisitos funcionais: • O software deve permitir o cadastro de produtos. • O software deve permitir o gerenciamento do estoque. • O software deve permitir a geração de relatório dos produtos em estoque. 2.2.2 Requisitos não funcionais Requisitos não funcionais são as restrições sobre as funções que serão oferecidas pelo sistema. Eles também podem ser a respeito de requisitos relacionados ao processo utilizado para o desenvolvimento do software, como especificações dos padrões de qualidade. Os requisitos não funcionais surgem em razão do usuário, do orçamento disponível, das políticas organizacionais ou até mesmo de necessidades externas, como necessidades legais ou de segurança (SOMMERVILLE, 2003). Segundo Andrade (2007), alguns exemplos de requisitos não funcionais são:
    • 15 • O software deve ser compatível com o browser IE (versão 5.0 ou superior) e Firefox (1.0 ou superior); • O software deve garantir que o tempo de retorno das consultas não seja maior e consultas do que cinco segundos. Os diferentes tipos de requisitos não funcionais estão representados na figura 2, classificados por Sommerville (2003) conforme a sua procedência procedência: Figura 2 – Tipos de Requisitos Não Funcionais Fonte: SOMMERVILLE, 2003 Os requisitos de produto são procedentes do comportamento do produto, como o desempenho, o espaço requerido e outros. Requisitos organizacionais especificam políticas e . procedimentos do cliente e do desenvolvedor, como questões relacionadas aos padrões que serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são representados pelos requisitos externos. los
    • 16 2.2.3 Requisitos de domínio Nascimento (2009) e Sommerville (2003) explicam que os fundamentos do domínio da aplicação são representados pelos requisitos de domínio, que descrevem características do sistema e qualidades que refletem o domínio, ao invés de serem captados a partir dos usuários do sistema. Andrade (2007) indica alguns exemplos de requisitos de domínio: • O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3) / 5; • Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos. 2.3 Processo de engenharia de requisitos Sommerville (2003) aponta que a engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos do sistema. Ávila (2007) descreve diferentes definições encontradas na literatura técnica: • Termo usado para descrever as atividades relacionadas à investigação e definição de escopo de um sistema de software; • Processo sistemático de desenvolvimento de requisitos através de um processo de análise onde os resultados das observações são codificados e a acurácia das observações é constantemente verificada; • Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema; • Atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A figura 3 descreve, de maneira geral, o processo de engenharia de requisitos, composto por atividades relacionadas.
    • 17 Figura 3 – Processo de Engenharia de Requisitos Fonte: SOMMERVILLE, 2003. 2.3.1 Estudo de viabilidade Autores como Sommerville (2003), recomendam que ao iniciar o projeto de um novo recomendam sistema, o processo de engenharia de requisitos deve ser iniciado com um estudo de genharia viabilidade que indicará se vale a pena ou não seguir adiante no projeto. Ele explica que o estudo de viabilidade deve responder as seguintes perguntas: • O sistema contribui para os objetivos gerais da organização? • O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo? • O sistema pode ser integrado com outros sistemas já em operação? Deve-se buscar informação através dos gerentes de departamentos, engenheiros de se software e usuários finais do sistema e através do relatório de estudo de viabilidade recomendar se o desenvolvimento do sistema deve iniciar/continuar ou não, podendo sugeri continuar sugerir mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento disponível ou o cronograma de desenvolvimento.
    • 18 2.3.2 Elicitação e análise de requisitos Após os estudos de viabilidade apontarem que o projeto deve seguir em frente, inicia- se a etapa de elicitação e análise dos requisitos. É nesta etapa que os requisitos são obtidos. A elicitação é a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado pelo cliente. Para isso, os responsáveis pelo desenvolvimento do sistema terão de trabalhar com os clientes e usuários finais a fim de descobrir as necessidades e restrições relacionadas ao sistema a ser desenvolvido (SPÍNOLA, 2009). A etapa de elicitação e análise de requisitos, como já comentado anteriormente, é um estágio decisivo e difícil dentro do projeto de qualquer sistema, por diversos fatores, como os listados por Ávila (2007): • Falta de conhecimento do usuário das suas reais necessidades; o Usuário com vaga noção do que precisa e do que um produto de software pode oferecer; • Falta de conhecimento do desenvolvedor do domínio do problema; o Desenvolvedor sem conhecimento adequado do domínio, o que leva a decisões erradas; • Domínio do processo de levantamento de requisitos pelos desenvolvedores; o Desenvolvedor não ouve o que os usuários têm a dizer e força suas próprias visões e interpretações. • Comunicação inadequada entre os desenvolvedores e usuários; o Usuários incapazes de expressar suas necessidades apropriadamente; o Significados diferentes a termos comuns; • Dificuldade de o usuário tomar decisões; o Falta de entendimento sobre as conseqüências das decisões ou as alternativas positivas; • Problemas de comportamento; o O levantamento de requisitos é um processo social; o Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham;
    • 19 • Questões técnicas; o Complexidade crescente dos sistemas atuais; No interesse de obter-se um melhor desempenho na elicitação, técnicas foram criadas para apoiar essa atividade. Spínola (2009) comenta algumas delas: • Entrevista: Técnica no qual os requisitos são levantados através de entrevistas com os usuários. Essa técnica pode ser realizada de diversas formas e na literatura técnica há uma boa quantidade de materiais que orientam como aplicar corretamente esta técnica de levantamento de requisitos. • Prototipação: É o desenvolvimento de uma versão inicial do sistema para experimentação. Isso permitirá aos usuários identificar os pontos fortes e fracos do sistema. Essa técnica possui como desvantagem os custos de aprendizagem e os custos de desenvolvimento. • JAD (Joint Application Development): Técnica que deve ser usado no caso em que existe a necessidade de consenso entre diversos usuários. Ela permite que todos os envolvidos tenham uma visão global do sistema através de reuniões e workshops que promovam interação e aumentem o comprometimento dos envolvidos com os requisitos a serem levantados. • Questionários: Técnica indicada para quando há diversos grupos de usuários que podem estar em diferentes locais. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados. Esta técnica permite a padronização das perguntas e tratamento estatístico das respostas. 2.3.3 Validação de requisitos Enquanto a análise de requisitos envolve trabalhar com requisitos incompletos, o processo de validação deve ser executado no sentido de elaborar-se um esboço completo do documento de requisitos (SOMMERVILLE, 2003). Durante esse processo, deve-se examinar a especificação do software, assegurando que os requisitos estão livres de ambigüidades, inconsistências ou omissões, detectando ou
    • 20 corrigindo possíveis problemas ainda durante a fase de definição dos requisitos (ÁVILA, 2007). Esse processo é finalizado após obter o aceite do cliente sob os requisitos levantados. A dificuldade dessa atividade não deve ser subestimada, pois os usuários devem pensar no sistema em operação e imaginar como o sistema se adequaria ao seu trabalho. Devido a essa dificuldade, raramente o processo de validação consegue descobrir todos os problemas com os requisitos. 2.3.4 Gerenciamento de requisitos Ávila (2007) afirma que o processo de gerenciamento de requisitos é a atividade de administrar os requisitos ao longo do tempo. Explica que softwares complexos estão sempre sendo modificados. Isso ocorre por conta da natureza volátil dos requisitos, que são influenciados por diversos fatores, como mudanças externas nos ambientes (como mudanças de legislação, mercado ou estratégia da empresa), erros cometidos no processo de elicitação dos requisitos, entre outros. As modificações necessárias precisam ser gerenciadas de uma maneira ordenada, para que não se perca controle dos prazos e custos de desenvolvimento do projeto (ÁVILA, 2007). Os benefícios dessa prática são a longo prazo e algumas atividades precisam ser levadas em conta durante o gerenciamento dos requisitos, como o controle das mudanças, a gerência de configuração e a rastreabilidade. Devido às necessidades de alterações dos requisitos, é preciso ter um único canal para o controle das mudanças, podendo assim, diferenciar o que era requisito original, o que foi introduzido e o que foi descartado. Ávila (2007) indica que antes de aceitar ou rejeitar alguma mudança, deve-se analisá-la conforme os impactos e custos que ela pode ter no sistema. Para isso indica os seguintes passos: • Checar validade de solicitação de mudança; • Identificar os requisitos diretamente afetados com a mudança; • Identificar dependências entre os requisitos para buscar os requisitos afetados indiretamente;
    • 21 • Assegurar com solicitante a mudança a ser realizada; • Estimar custos da mudança; • Obter acordo com o usuário sobre o custo da mudança. A Gerência de Configuração: Consiste em definir os critérios que permitem realizar modificações, seja na especificação dos requisitos ou na implantação do sistema, e o controle sistemático das modificações de maneira a manter a consistência e a integridade do software com as especificações. A rastreabilidade é a capacidade de acompanhar a vida de um requisito bidirecionalmente, ou seja, partindo de requisitos e chegando ao projeto ou partindo de projeto e chegando a requisitos. 2.4 Requisitos e os modelos MPS.BR e Scrum Tanto o modelo MPS.BR como o Scrum não resolverão os problemas relacionados a requisitos. Ambos apenas fornecem ferramentas para gerenciar melhor os requisitos, sendo que o primeiro é focado nos processos que envolvem a gerência dos requisitos e o segundo assume que os requisitos mudam ao longo do processo de desenvolvimento e tem como estratégia iterações curtas, que permitem uma avaliação dos requisitos periodicamente. Tais modelos servem como guias de boas práticas para o alcance do sucesso de um projeto de software. Nos capítulos seguintes, os requisitos serão vistos sob o ponto de vista da metodologia ágil e do modelo de processo, e ao final, tentaremos mostrar como eles podem trabalhar de maneira conjunta e como isso pode contribuir para o sucesso da gestão dos requisitos e conseqüentemente para o sucesso do produto ou serviço a ser desenvolvido.
    • 22 3 FRAMEWORK SCRUM Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê-la. O provê desenvolvimento ágil de softwares é, para muito , algo intangível, que não existe. Mas uma oftwares muitos, série de profissionais, de todas as partes do mundo, dedicam-se a aplicar os conceitos das se metodologias ágeis, divulgando e aprimorando esses conceitos que ganham, cada vez mais a aceitabilidade dentro das empresas de tecnologia da informação. empres Dentre os principais métodos ágeis de desenvolvimento de software podem ser citados: Scrum, Extreme Programming, Lean Software Development, entre outros. O gráfico 1 corrobora a afirmação inicial mostrando a pesquisa apresentada pela VersionOne (2009), inicial, rando respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou alguma variação deste, é utilizado por mais de 70 % dos participantes. Gráfico 1 – Utilização de metodologias ágeis Fonte: VERSIONONE, 2009. Este capítulo tem como foco os conceitos básicos que levam ao entendimento do Scrum e que permitirão uma avaliação do uso deste framework juntamente com o modelo MPS.BR.
    • 23 3.1 Visão geral sobre metodologias ágeis As metodologias ágeis são o resultado do esforço de um grupo de dezessete desenvolvedores experientes e consultores, que em 2001, compuseram um manifesto o qual valoriza um conjunto de valores e práticas comuns para o desenvolvimento de software de uma maneira mais ágil. O manifesto ágil identifica valores e princípios que devem prevalecer no desenvolvimento de software (BECK, 2001 apud DIAS, 2010; ANEXOS A e B). Segundo Dias (2010), a essência das metodologias ágeis é o enfoque do desenvolvimento de software calcado na agilidade, na flexibilidade, nas habilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo. A agilidade não significa a falta de estrutura, mas sim a capacidade de adaptação a situações inesperadas. Podemos identificar quatro aspectos que o manifesto ágil impulsiona: a cultura, a comunicação, as pessoas e o processo. O manifesto prega que os projetos dêem o suporte necessário às necessidades da equipe, formando profissionais motivados e confiantes, que reflitam sobre como tornarem-se mais efetivos, empregando seus esforços em entregar software funcionando (PRIKLADNICKI, 2009). Como comentado anteriormente, Scrum é um de vários métodos ágeis, como o Adaptative Software Development (ASD), Crystal Clear, Extreme Programming, Lean Software Development, Feature Driven Development (FDD), Agile Unified Process. Pela importância que tem adquirido perante a comunidade de desenvolvedores e pelas características que garantem um compromisso com a entrega de valor ao cliente, sem perder o foco nos processos, na cultura e nas pessoas que desenvolvem, o Scrum faz parte do escopo deste trabalho. 3.2 Introdução ao Scrum Porque Scrum? No Guia do Scrum, Schwaber (2009), explica que Scrum não é um processo e nem uma técnica, é um framework com objetivo de transparecer a eficácia, onde se
    • 24 pode empregar diversos processos e técnicas. Scrum é baseado em processos empíricos, possui uma abordagem iterativa e incremental, o que permite uma maior previsibilidade e controle dos riscos. Ao assumir que o objetivo do projeto é o produto e não a documentação, Scrum busca gerar apenas a documentação suficiente e necessária para atingir o objetivo de entregar um produto que dê ao cliente um retorno rápido do seu capital investido. Ao defender que abraçar as mudanças é mais importante do que seguir um plano, Scrum vem de encontro às metodologias tradicionais de desenvolvimento de software, exigindo muita disciplina e organização para que se tenha a habilidade de ser flexível com estabilidade (MACHADO, 2009). O Scrum consiste em Times Scrum com seus papéis associados, Eventos com duração fixa e Artefatos. O framework possui também Regras, que irão delimitar a atuação dos diferentes papéis e eventos e serão descritas ao longo deste capítulo (SCHAWBER, 2009, p. 4). 3.2.1 Times Scrum, seus papéis e responsabilidades Schwaber (2009), explica que os Times Scrum devem ter como objetivo a flexibilidade e produtividade e que para isso eles necessitam ser auto-organizados, interdisciplinados e trabalharem em iterações. Os Times Scrum têm pelo menos três papéis: o ScrumMaster, o Product Owner e o Time. O ScrumMaster é a pessoa responsável por garantir que o processo seja entendido e seguido, é ele quem deve verificar se o Time Scrum está aderindo aos valores, princípios, práticas e regras do Scrum. Apesar do ScrumMaster não gerenciar o Time Scrum, pois este deve ser auto-organizado, ele deve fazer com que o Time Scrum entenda e use autogerenciamento e interdisciplinaridade. A responsabilidade de gerenciar o Backlog do Produto (lista de requisitos) que será desenvolvido é do Product Owner. Ele também é responsável por garantir que o trabalho
    • 25 realizado pelo Time tenha valor, garantindo uma priorização correta dos itens do Backlog. Seu sucesso depende que haja respeito com relação as suas decisões. O Time é formado pelos desenvolvedores de software, que a cada Sprint, baseados nas prioridades do Backlog, devem entregar Software Pronto. Times também precisam tomar a decisão de como realizar a tarefa de entregar o Software Pronto dentro do prazo, e para isso precisam ser auto-organizados e interdisciplinares. 3.2.2 Eventos Os Eventos no Scrum devem possuir regularidade e por isso têm duração fixa. Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint são os elementos com duração fixa empregados no framework. Na Reunião de Planejamento da Versão para Entrega, o Time Scrum estabelecerá, através de planos e metas, quais as prioridades do Backlog do Produto que formarão o Backlog do Produto para a Versão, quais os riscos envolvidos, qual a data de entrega e o provável custo da versão a ser entregue. O planejamento deverá levar em conta o objetivo de alcançar a satisfação do cliente e o retorno do investimento (ROI1) desejados, ele permitirá que a organização avalie o progresso do projeto, possibilitando correções nos planos a cada Sprint. A Sprint é um evento de duração fixa, na qual o ScrumMaster deverá garantir que nenhuma mudança afete o objetivo da Sprint. Por mudança, entendem-se também as mudanças na composição do time e das metas de qualidade. As Sprints são formadas pela reunião de Planejamento da Sprint, o desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. No Scrum, para diminuir a complexidade do projeto, recomenda-se que as Sprints tenham entre duas a quatro semanas. Dessa forma, evita-se que o plano de desenvolvimento 1 ROI significa em inglês Return Of Investiment, é a relação entre o dinheiro ganho ou perdido através de um investimento, e o montante de dinheiro investido. (WIKIPEDIA. Retorno sobre investimento. Disponível em: < http://pt.wikipedia.org/wiki/Retorno_sobre_investimento >. Acesso em: jun. 2010.)
    • 26 do projeto perca a validade pelas mudanças que podem ocorrer em um plan planejamento muito longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período compreendido por cada Sprint. As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião, Schwaber (2004), recomenda uma duração de oito horas para Sprints de um mês e no caso de horas Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time discutir quais itens do Backlog do Produto serão produzidos na Sprint. O time poderá dar sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner. Porém cabe ao Time definir, baseado em sua experiência, qual a quantidade de itens será ime possível produzir dentro da Sprint. entro Na segunda etapa o time deve discutir como os itens escolhidos serão transformados em Software Pronto. As tarefas para a concretização desta tarefa formarão o Backlog da ronto. Sprint (figura 4). Ao efetuar o planejamento da Sprint e estabelecer as metas da mesma, a . equipe deverá levar em conta a Meta da Versão para Entrega. Figura 4 – Formação do Backlog da Sprint Fonte: KNIBERG, 2007, p. 22. Ao término de cada Sprint, o Time Scrum deverá reunir-se para a Revisão da Sprint. reunir se Nesta reunião a equipe deve fornecer feedback, discutir sobre sucessos problemas quipe sucessos, enfrentados, como foram solucionados no decorrer da Sprint, com o objetivo de identificar e Sprint corrigir deficiências e/ou imped impedimentos no processo de desenvolvimento. A equipe deve vimento. demonstrar o trabalho pronto, e o Product Owner deve identificar os itens do Backlog da Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do
    • 27 Produto será efetuado, fazendo projeções de prováveis datas de entrega com base na velocidade estimada da equipe. O Scrum estabelece que após a revisão da Sprint e antes do planejamento da próxima Sprint, o Time Scrum deve realizar uma reunião com o tempo fixo de três horas para Retrospectiva da Sprint. Nesta reunião o ScrumMaster deve encorajar o Time a revisar o processo de desenvolvimento, inspecionando quais mudanças podem torná-lo mais eficaz e gratificante para a próxima Sprint (SCHWABER, 2009). Durante as Sprints a equipe deve realizar uma Reunião Diária de quinze minutos, que deve ser sempre no mesmo horário e local. No Guia do Scrum2 ela é relatada como fundamental ao processo empírico do Scrum. Nessa reunião, o ScrumMaster deve garantir que a reunião aconteça e ajudar para que o Time seja o responsável pela condução da mesma, obedecendo ao tempo estabelecido. Nela cada membro deve explicar: O que ele realizou desde a última reunião diária; O que ele vai fazer antes da próxima reunião diária; E quais os obstáculos estão em seu caminho. O objetivo da Reunião Diária é inspecionar o progresso da Meta da Sprint e ajudar o time a alcança-lá. 3.2.3 Artefatos O framework também emprega os seguintes Artefatos: Backlog do Produto, que consiste em uma lista de todos os requisitos necessários ao produto; O Backlog da Sprint, que é a lista de itens do Backlog do Produto que, em uma Sprint, serão transformados em Software Pronto; O Burndown de Versão para Entrega, que mede o Backlog do Produto em relação ao tempo estimado para entrega do produto; E o Burndown de Sprint, que mostra os itens do Backlog da Sprint em relação ao tempo da Sprint. O burndown é um gráfico que mostra o backlog a ser desenvolvido pelo tempo estimado de desenvolvimento. Schwaber (2009) indica o Backlog do Produto como uma lista de todos os requisitos necessários ao produto que está sendo desenvolvido, ele deve estar disponível e priorizado pelo Product Owner, que desempenha o papel responsável pelo conteúdo deste Backlog, 2 Detalhes sobre o Guia do Scrum em SCHWABER, 2009.
    • 28 cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos conhecidos e melhor entendidos. À medida que o Produto evolui, o Backlog também caminha endidos. neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que é o mais apropriado, competitivo e útil ao Produto. O Backlog do Produto deve ser uma lista com todas as características, funções, todas tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como: descrição, prioridade e estimativa. Ele deve estar ordenado por prioridade (f prioridade (figura 5). Quanto maior a prioridade do item, maior deverá ser o seu nível de detalhamento e com mais urgência deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos de maneira a poderem ser realizados dentro da duração de uma Sprint. Figura 5 – Exemplo de Product Backlog Fonte: inspirada em SCHWABER, 2004. : Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time. Com a soma das estimativas de esforço necessário para o término do Backlog do término Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade do Time, podendo-se traçar uma linha de tendência que mostrará uma estimativa do progresso se do desenvolvimento do Produto. Este gráfico é chamado de Burndown da Versão para chamado Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve estar em qualquer unidade de medida de trabalho adotada pelo Time Scrum. Schwaber (2009) também explica que o Backlog da Sprint é todo o trabalho que o Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas necessárias para transformar os itens do Backlog do Produto em Software Pronto. Os itens do Pronto
    • 29 Backlog da Sprint devem ser decompostos ao ponto que possam ser entendidos na Reunião ser Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma, atualizando também as estimativas de trabalho restante. Assim como o Burndown da Versão para entrega, é possível usar a soma das estimativas de esforço necessárias para o término do Backlog da Sprint e registrá-las ao longo sforço registrá do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que mostre o trabalho restante ao longo do tempo (figura 6 go 6). Figura 6 – Burndown da Sprint Fonte: inspirada em SCHWABER, 2004. pirada 2004 3.2.4 Software Pronto O framework Scrum tem como regra que se deve ter como resultado incrementos de funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de “Pronto” deve incluir toda a análise, projeto, refatoramento, programação, documentação e análise, testes. 3.3 Fluxo do Scrum Isotton Neto (2008), com base no artigo “The Scrum Development Process”, de “The Process Schwaber (1996), define que Scrum é formado pelos seguintes grupos de fases: ),
    • 30 Pregame: • Planejamento – Definição de um novo release baseado no Backlog do Produto (BP) e estimativa de cronograma e custo. Se for o início de um novo projeto, essa fase consiste em conceitualização e análise do produto. Se for um projeto em andamento, esta fase é limitada à análise. Os passos dessa fase são: o Desenvolvimento claro e objetivo do BP; o Definição da data de entrega e funcionalidades de uma ou mais Sprints; o Definição do release mais apropriado para o início do desenvolvimento; o Mapeamento e estimativa das atividades a serem incluídas no Backlog do Produto; o Definição do Time Scrum (TS); o Avaliação e controle de riscos envolvidos no projeto; o Avaliação das ferramentas de desenvolvimento e infra-estrutura do projeto; o Estimativa de custos. • Arquitetura – Definição de como os itens do BP serão implementados. Modificações na arquitetura do sistema e design de alto nível também são realizadas nessa fase. Os passos desta fase: o Revisão e ajustes ao BP; o Identificação das mudanças necessárias para a implementação do BP; o Realizar a análise do domínio; o Refinar a arquitetura do sistema; o Identificação de possíveis problemas ou impedimentos na implementação dos requisitos; o Reunião de revisão do design, onde são apresentadas as propostas de melhoria e mudanças na implementação de cada item do BP. Game: • Sprints – Desenvolvimento das funcionalidades do novo release, respeitando- se as variáveis tempo, requisitos, qualidade e custo. Normalmente, serão utilizadas múltiplas Sprints para a evolução incremental do sistema. Os passos dessa fase:
    • 31 o Reunião de Planejamento da Sprint a fim de definir as atividades a serem incluídas na iteração corrente. o Reuniões Diárias com o TS para revisar o andamento do projeto; o Revisão e ajustes nos requisitos do projeto; o Sprints iterativos até que se tenha “Software Pronto”. “Sof Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2 Eventos” desse capítulo, sejam plenamente seguidas pelo TS. e Postgame: • Fechamento – Entrega e empacotamento do “Software Pronto”. Preparação do produto desenvolvido para a entrega. Documentações, testes, materiais de desenvolvido treinamento e marketing são artefatos típicos dessa fase. A figura 7 mostra de o fluxo Scrum de maneira ilustrativa. Figura 7 – Fluxo do Scrum Fonte: inspirada em KNIBERG, 2007
    • 32 O framework foi concebido de maneira simples e aberto, permitindo que características sejam adicionadas sem que a filosofia básica do Scrum seja alterada. Nesse capítulo, buscou-se apresentar uma visão para o entendimento do assunto abordado, porém dificilmente seria possível esgotar o assunto, diante das mais diversas possibilidades da aplicação da metodologia. É possível concluir que Scrum é uma abordagem baseada na flexibilidade, adaptabilidade e produtividade, com ênfase no gerenciamento do projeto.
    • 33 4 MODELO MPS.BR As atividades das empresas ocorrem através de processos. Conforme Pádua (2007), processos são um conjunto de ações e atividades inter-relacionadas, realizadas para obter um conjunto especificado de produtos, resultados ou serviços. Baseados em boas práticas de execução, surgiram diversos modelos de processos, todos visando o aumento da eficiência e eficácia nas atividades das organizações. O Modelo de Melhoria do Processo de Software Brasileiro – MPS.BR, é um exemplo, e por ser uma importante iniciativa brasileira na área de qualidade do desenvolvimento de software, é objeto de estudo desse trabalho. 4.1 Introdução ao Modelo MPS.BR O modelo MPS.BR é uma proposta brasileira, para micro, pequenas e médias empresas, de um modelo de maturidade de processos de desenvolvimento do software Brasileiro (Associação para Promoção da Excelência do Software Brasileiro – SOFTEX, 2009a). O viés do MPS.BR são os processos, a qualificação desses reflete na qualidade do produto, além disso proporciona: diminuição de retrabalho, maior produtividade, redução do tempo para atender às necessidades de negócio, maior competitividade, maior precisão nas estimativas, entre outros. O MPS.BR é um programa coordenado pela Associação para Promoção da Excelência do Software Brasileiro – SOFTEX que tem apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). O modelo está documentado através de guias, que auxiliam no entendimento e implementação do mesmo. Além do Guia Geral, que expõe uma descrição do modelo e detalha o Modelo de Referência MR-MPS, há também os guias de Avaliação, Aquisição e os guias de Implementação, que divididos por níveis, formam o conjunto de documentos do modelo MPS. Os componentes do modelo podem ser observados na figura 8.
    • 34 Figura 8 – Modelo MPS.BR Fonte: SOFTEX, 2009. O Modelo de Referência MR-MPS refere-se aos requisitos que devem ser atendidos MR pelas organizações que se submeterão a avaliação ou desejam desenvolver boas-práticas. Nele bo são indicados os níveis de maturidade, processos e seus atributos. O MR-MPS tem sua base MR MPS técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI-DEV. CMMI 4.2 Base técnica do Modelo MPS.BR A ISO/IEC 12207 (International Organization for Standardization/International ( nization Electrotechnical Commission estabelece uma arquitetura comum para o ciclo de vida de Commission) processos. A norma contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação, manutenção de produtos de software. As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade, quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de base para diversas normas e modelos que surgiram posteriormente. A organização da ISO12207 permite que processos de apoio possam ser combinados e executados junto a outros, a qualquer momento (SOFTEX, 2009a, p.14; International Organization for SOFTEX, Standardization – ISO, 2010a) ). Já a ISO/IEC 15504, também conhecida por SPICE (Software Process Improvement (Software and Capability Etermination), presta se à realização de avaliações de processos de software ), presta-se com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de
    • 35 uma unidade organizacional. Um dos importantes conceitos introduzido por essa norma foi o de “capacidades”. Tal capacidade tem a finalidade de indicar como um processo atende determinada classe de requisitos. Quanto à dimensão dos processos, estes são agrupados em cinco categorias: cliente-fornecedor (impactam na relação cliente-fornecedor), engenharia (implementam ou mantém um sistema ou produto e sua documentação), suporte (processos que podem ser empregados por outros), gerência (práticas genéricas usadas por quem gerenciam projetos ou processos), empresa (objetivos do negócio). Assim, pode ocorrer de uma empresa possuir maiores capacidades em algumas categorias ante outras, permitido que a empresa possa buscar por sua certificação enquanto aprimoram outros processos que precisam de melhorias (SOFTEX, 2009a, p. 14-15; ISO, 2010b). E o CMMI-DEV (Software Capability Maturity Model for Development) é a versão do CMMI dirigido à melhoria do processo de desenvolvimento de produtos e serviços. Foi criado pelo SEI (Software Engineering Institute) da CMU (Carnegie Mellon University). O CMMI é um modelo de referência com as melhores práticas para a maturidade dos processos das organizações. Koscianski (2006) comenta que o objetivo do CMMI é: servir de guia para melhoria de processos na organização e das habilidades dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços. Desta maneira, espera-se que a organização construa software com mais qualidade de maneira eficiente. No modelo CMMI quatro áreas de conhecimento estão presentes: Engenharia de Sistemas, Engenharia de Software, Desenvolvimento e Integração de Produtos e Processos e Fontes de Aquisição. O modelo apresenta-se através de duas representações: • Representação por Estágios: Organiza as áreas de processo em níveis de maturidade, de 1 a 5. • Representação Contínua: Apresenta níveis de capacitação, de 0 a 5. As áreas de processo são agrupadas por categorias afins. O modelo CMMI é complexo e caro, e a idéia de tê-lo como base no MPS.BR é trazer para o modelo brasileiro, as boas práticas de gerenciamento de processos, tornando-os mais fáceis e baratos.
    • 36 4.3 Estrutura do MR-MPS.BR MPS.BR O Modelo de Referência do MPS.BR (MR-MPS.BR) define a maturidade dos (MR MPS.BR) processos de desenvolvimento de software através de níveis de maturidade, que por sua vez to são formados por conjuntos de processos, sendo que há um propósito e um conjunto de resultados esperados para cada um dos 21 processos do MR-MPS.BR (SOFTEX, 2009a) MR 2009a). Para cada conjunto de processos, novas capacidades de processos são exigidas da processos, organização (seguindo a proposta da ISO 15504), sendo estas capacidades mensuradas através 15504), de atributos de processos (AP) e resultados esperados de atributos de processo (RAP). A (RAP) figura 9 mostra a estrutura do Modelo de Referência. tura Figura 9 – Estrutura do MR-MPS.BR Fonte: SOFTEX, 2009a 4.3.1 Níveis de maturidade Os níveis de maturidade foram definidos de maneira que haja um amadurecimento gradual dos processos, eles caracterizam estágios de melhoria da implementação de processos melhoria na organização. São sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A divisão em sete estágios tem como objetivo permitir uma implementação e avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios. A escala de maturidade inicia no nível G e progride até o nível A, conforme tabela 2. 2
    • 37 Tabela 2 – Níveis de Maturidade e Processos do Modelo de Referência do MPS.BR Nível Processo A - Em Otimização B - Gerenciamento Quantitativo Gerência de Projetos – GPR (evolução) Gerência de Riscos – GRI C – Definido Desenvolvimento para Reutilização – DRU Gerência de Decisões – GDE Verificação – VER Validação – VAL D - Largamente Definido Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE Gerência de Projetos – GPR (evolução) Gerência de Reutilização – GRU E - Parcialmente Definido Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP Medição – MED Garantia da Qualidade – GQA F – Gerenciado Gerência de Portfólio de Projetos – GPP Gerência de Configuração – GCO Aquisição – AQU Gerência de Requisitos – GRE G - Parcialmente Gerenciado Gerência de Projetos – GPR Fonte: SOFTEX, 2009a 4.3.1.1 Processos Para cada um dos sete níveis foram atribuídos perfis de processos que serão o foco de melhoria da organização. Atinge-se um determinado nível de maturidade quando o propósito e os resultados esperados dos processos do nível são atendidos. Segundo Diniz (2009a) alguns processos do MPS.BR afetam o desenvolvimento, no sentido de dar-lhe transparência, outros afetam a gerenciabilidade do desenvolvimento. Por consequência, reduzem-se os riscos e aumenta-se a produtividade. Ao passo que os níveis de maturidade são alcançados, os processos implementados em cada nível também amadurecem (conforme tabela 2).
    • 38 No modelo descrito no Guia Geral do MPS.BR (2009a, p. 16), os processos são formados por propósitos e resultados. Os propósitos descrevem os objetivos gerais da execução dos processos, enquanto que os resultados esperados dos processos determinam os resultados que devem ser obtidos com a implementação do processo, ou seja, o efetivo alcance dos propósitos. 4.3.1.2 Capacidades de processos A implementação do conjunto de processos de cada um dos níveis de maturidade do modelo é comprovada através da aquisição de determinadas capacidades. A capacidade do processo caracteriza a habilidade do processo de atingir os objetivos de negócio, assim indica o grau de refinamento com que os atributos de processos (AP) são executados e a comprovação do sucesso da implementação destas capacidades é feita através da demonstração de resultados esperados destes atributos. A tabela 3 mostra os níveis de capacidade do MPS.BR: Tabela 3 - Atributos de Processo do MPS.BR Código Descrição AP 1.1 O processo é executado AP 2.1 O processo é gerenciado AP 2.2 Os produtos de trabalho do processo são gerenciados AP 3.1 O processo é definido AP 3.2 O processo é implementado AP 4.1 O processo é medido AP 4.2 O processo é controlado AP 5.1 O processo é objeto de melhorias e inovações AP 5.2 O processo é otimizado continuamente Fonte: SOFTEX, 2010a, 17-21. Ao longo deste trabalho os processos de Gerência e Desenvolvimento de Requisitos serão descritos, assim como seus propósitos e resultados esperados. O processo de Gerência de Requisitos está incluso no nível G, enquanto que o processo de Desenvolvimento de Requisitos está no nível D.
    • 39 Os níveis, além de graduais, são acumulativos, e isto implica que a organização, ao evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de processo (RAP), sendo que destes, dois estão presentes no nível G e cinco no nível D de cinco maturidade do MPS.BR. A figura 10 mostra a evolução dos AP em relação aos níveis, do nível G ao nível D (SOFTEX, 2009a, p. 16-17). 16 Figura 10 – Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR Fonte: SOFTEX, 2009a, p. 22. O detalhamento de cada AP dos níveis G ao D está descrito nos Anexos C D, E, F e G C, deste trabalho. 4.4 Processo de Gerência de Requisitos O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do que é “projeto” para a organização são implantados e caracterizam um grande desafio para a organização, o que pode determinar o sucesso ou insucesso da implementação do modelo determinar (SOFTEX, 2009b, p. 6). Para esse processo os Atributos de Processos (capacidades) esperados são: e • O processo é executado (RAP 1) e;
    • 40 • O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP 8, RAP 9 e RAP 10). 4.4.1 Processo GRE – Propósito O processo GRE tem por objetivo o gerenciamento dos requisitos do produto e dos componentes do produto do projeto, além da identificação de inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009a, p. 28). O principal objetivo deste processo é o controle da evolução de todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais, não funcionais e os requisitos impostos ao projeto pela organização (SOFTEX, 2009b, p. 18). Neste processo, passos são definidos para assegurar que o conjunto de requisitos acordados (1) é gerenciado e (2) fornece apoio às necessidades de planejamento e execução do projeto. Estabelece que quando requisitos são recebidos, antes de serem incorporados ao escopo do projeto, devem ser revisados e um compromisso entre as partes interessadas é firmado. Documentar todas as mudanças nos requisitos, garantir a rastreabilidade bidirecional entre os requisitos e os produtos, além de identificar inconsistências entre requisitos, planos do projeto e produtos de trabalho do projeto também fazem parte das atribuições do Processo de Gerência de Requisitos. 4.4.2 Processo GRE – Resultados Esperados Segundo a SOFTEX (2009b, p. 20), esperam-se cinco resultados da implementação do processo GRE, a saber: GRE 1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores responsáveis de requisitos, utilizando critérios objetivos. Ou seja, é preciso garantir que os requisitos estejam claramente definidos, comprovados através de um documento de requisitos – que pode ter o formato que melhor atender as necessidades da organização. Após a
    • 41 identificação dos requisitos, eles precisam ser avaliados, tanto pela equipe técnica da organização quanto pelo cliente, com base em critérios que garantam que os requisitos propostos atendem às necessidades e expectativas do cliente e dos usuários. Um registro de aceite dos requisitos aprovados, obtido pelos fornecedores de requisitos será um marco do projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e registro de aceite da mudança aprovada. GRE 2 – O Comprometimento da equipe técnica com os requisitos aprovados é obtido. Os requisitos aprovados pelos critérios estabelecido no GRE1 deverão obter o comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tem conhecimento e aprovam os requisitos, um documento deve ser registrado, por exemplo, uma ata de reunião, e-mail ou algum outro mecanismo. A cada mudança registrada nos requisitos, um novo comprometimento da equipe deve ser obtido (SOFTEX, 2009b, p. 21). GRE 3 – A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por exemplo, nas estimativas, nos produtos ou tarefas do projeto (SOFTEX, 2009b, p. 21). GRE 4 – Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. O que resulta no estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos e os demais elementos do projeto. Todas as inconsistências identificadas devem ser registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações deverão ser acompanhadas até que as inconsistências sejam resolvidas (SOFTEX, 2009b, p. 21-22). GRE 5 – Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização realize o gerenciamento das mudanças que venham a ocorrer. As mudanças devem ser
    • 42 registradas, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com base na análise do impacto da mudança no projeto (SOFTEX, 2009b, p. 22). Estes são os cinco resultados esperados do propósito do processo de Gerência de Requisitos, que juntamente com o processo de Desenvolvimento de Requisitos são os processos que atuam na gestão dos requisitos no MPS.BR, A seguir, faz-se uma análise do processo Desenvolvimento de Requisitos, seu propósito e resultados esperados. 4.5 Processo de Desenvolvimento de Requisitos O processo de Desenvolvimento de Requisitos (DRE) está presente no nível D de maturidade do MPS.BR. Evoluir para o nível D implica na definição de processos geralmente mencionados como sendo relacionados à engenharia de requisitos propriamente dita. Neste nível, cinco novos processos são implementados, que incrementam a capacidade de definição dos processos já alcançada no nível E, e que inclui todos os processos que pertencem aos níveis G e F do MPS.BR. A SOFTEX (2009c, p.6-7) indica que os processos do nível D sejam implementados de forma iterativa e alinhados ao ciclo de vida definido do produto, indicando inclusive uma possível sequência de execução dentro do processo de desenvolvimento, sendo: Desenvolvimento de Requisitos (DRE), Projeto e Construção do Produto (PCP), Integração do Produto (ITP), Verificação (VER) e Validação (VAR). Detalhes do processo DRE, objeto de estudo deste trabalho, são apresentados a seguir. Para este processo os Atributos de Processos (capacidades) esperados são: • O processo é executado (RAP 1); • O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP 8, RAP 9, RAP 10); • Os produtos de trabalho do processo são gerenciados (RAP 11, RAP 12, RAP13, RAP 14);
    • 43 • O processo é definido (RAP 15, RAP16, RAP 17, RAP 18) e; • O processo está implementado (RAP 19, RAP 20, RAP 21, RAP 22) 4.5.1 Processo DRE – Propósito Ao implementar o processo de Desenvolvimento de Requisitos, a organização terá como propósito definir os requisitos do cliente, do produto e dos componentes do produto (SOFTEX, 2009a, p. 38), atendendo assim a necessidade de todos os envolvidos no projeto. O levantamento de requisitos e seu gerenciamento, além do refinamento dos mesmos, a descrição em termos técnicos, dos cenários e conceitos operacionais requeridos são elaborados em um nível de detalhes que permite a realização de projetos técnicos para a resolução do problema em questão (SOFTEX, 2009c, p.7). 4.5.2 Processo DRE – Resultados Esperados Os requisitos do cliente, do produto e dos componentes do produto deverão ser analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manutenção do produto, o que faz com que os resultados esperados do processo DRE estejam relacionados aos resultados esperados dos processos PCP, GRE, VER e VAL, por serem produtos requeridos para sua execução ou por terem uma interface com o processo propriamente dito (SOFTEX, 2009c, p. 7). O processo DRE possui oito resultados esperados, como segue: DRE 1 – As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas. Segundo a SOFTEX (2009c, p. 10), para se alcançar este resultado, é preciso utilizar algum método adequado para identificar as necessidades, expectativas e restrições do cliente, também comenta algumas técnicas de elicitação de requisitos, como: entrevistas; questionários; construção de cenários operacionais e análise de tarefas do usuário final; protótipos e modelos; técnicas facilitadoras de especificação de aplicações (como, por exemplo, JAD); casos de uso; brainstorming; observação de produtos e ambientes existentes; análise de casos de negócio; estudo de fontes
    • 44 de informação como documentos, padrões ou especificações; etnografia; QFD (Quality Function Deployment) e engenharia reversa (para sistemas legados); e estórias de usuários (Metodologias ágeis); DRE 2 – Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas. As necessidades, expectativas e restrições identificadas, deverão ser transformadas em requisitos do cliente (SOFTEX, 2009c, p. 11); DRE 3 – Um conjunto de requisitos funcionais e não funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente. Ou seja, o resultado alcançado deve ser a consolidação das necessidades, expectativas e restrições do cliente na forma de requisitos do produto e dos componentes do produto. A SOFTEX (2009c, p. 11-12), destaca que definir os requisitos funcionais envolve analisar os requisitos do cliente, identificando as funções que são necessárias ao produto. Os requisitos funcionais descrevem as funções ou serviços que são esperados do sistema que será gerado. Os requisitos não funcionais são requisitos que impõe condições ou qualidades que são específicas que o produto e/ou seus componentes devem atender. DRE 4 – Os requisitos funcionais e não funcionais de cada componente do produto são refinados, elaborados e alocados. Para se alcançar este resultado implica em derivar requisitos funcionais e não funcionais que resultem de decisões de projeto; alocar requisitos funcionais e não funcionais e restrições para cada um dos componentes do produto; e estabelecer os relacionamentos entre os requisitos do cliente e os requisitos funcionais e não funcionais de cada um dos componentes do produto, de acordo com o processo de Gerência de Requisitos. É necessário comprovar que o conjunto de requisitos funcionais e não funcionais foi refinado, detalhado e documentado durante o ciclo de vida do desenvolvimento do produto e de seus componentes (SOFTEX, 2009c, p. 12); DRE 5 – Interfaces internas e externas do produto e de cada componente do produto são definidas. Isso será útil para projetar e construir os componentes do produto. Geralmente as definições são quanto aos tipos e formatos de dados de entrada e saída entre os
    • 45 componentes, especificações de protocolo de comunicação, entre outros (SOFTEX, 2009c. p. 13); DRE 6 – Conceitos operacionais e cenários são desenvolvidos. Os cenários podem ser modelados por UML (Unified Modeling Language), no qual o cenário é uma seqüência específica de ações que ilustra o comportamento de um caso de uso. Para se alcançar este resultado, é necessário definir o ambiente de operação do produto, seus limites e restrições; também é necessário elaborar um conceito operacional detalhado, do produto e seus componentes, que defina a interação do produto, do usuário final e do ambiente, de maneira a satisfazer as necessidades de operação, manutenção e apoio; e revisar os conceitos operacionais e cenários para refinar e descobrir novos requisitos (SOFTEX, 2009c, p. 13-14); DRE 7 – Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as restrições existentes. Isso determinará se os requisitos, analisados em conjunto com os cenários e conceitos operacionais, são necessários, corretos, testáveis e suficientes para atingir os objetivos e requisitos do cliente (SOFTEX, 2009c, p. 14); DRE 8 – Os requisitos são validados. Este resultado visa garantir que os requisitos sejam validados através de técnicas adequadas, o que garantirá o desempenho do produto no seu ambiente alvo, além de permitir que problemas sejam encontrados, evitando retrabalho e custos (SOFTEX, 2009c, p. 14-15); Modelos para Maturidade de Melhoria do Processo Software, como o MPS.BR, são hoje referências no mercado como boas práticas fornecidas de como o processo, e consequentemente, o produto de software, podem ser melhorados e avaliados. Ao finalizar a descrição dos resultados esperados dos processos relacionados a requisitos, do MPS.BR, em conjunto com as informações adquiridas sobre requisitos (capítulo 02) e Scrum (capítulo 03), possível propor o mapeamento e alinhamento destes, conforme será apresentado no capítulo a seguir.
    • 46 5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Organizações que buscam a melhoria de seus processos através de modelos como o MPS.BR e que acreditam que a introdução de conceitos ágeis, como o Scrum, em seus processos é uma alternativa capaz de promover a melhoria de qualidade dos seus produtos, e consequentemente, aumento da competitividade no mercado (SZIMANZKI, 2009), podem necessitar de orientação que demonstre a possibilidade da aplicação prática conjunta de MPS.BR e Scrum. Para que a organização atinja maturidade e agilidade através do MPS.BR e Scrum, é necessário que ambos modelos possam ser realizados em conjunto e que suas práticas e objetivos sejam satisfeitas. Assim, o presente capítulo apresenta o mapeamento MPS.BR e Scrum. Pretende-se atender os resultados esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR e satisfazer todos os preceitos da prática do Scrum. 5.1 Mapeamento entre os processos GRE e DRE com Scrum Para analisar se as práticas encontradas no Scrum satisfazem cada um dos resultados esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR, foram definidos os critérios apresentados na tabela 4. Os critérios demonstram o quanto uma prática Scrum pode estar presente em um resultado de processo, como: é possível evidenciar (Satisfeito), evidencia-se em parte (Parcialmente Satisfeito) e não é possível evidenciar que a prática Scrum pode atender um resultado de processo. Tabela 4 – Critérios de análise do uso conjunto das metodologias Classificação Critérios Não Satisfeito Não há evidências da prática na metodologia Há evidências da prática na metodologia, embora a Parcialmente Satisfeito prática não esteja plenamente atendida. Satisfeito A prática está totalmente atendida na Metodologia. Fonte: inspirada em SZIMANSKI, 2009.
    • 47 Para cada um dos processos, foi realizada uma análise detalhada dos resultados esperados em relação às práticas encontradas no Scrum, classificando cada resultado esperado de acordo com os critérios estabelecidos na tabela 4. Abordagem similar já foi utilizada e apresentada à comunidade científica, como na obra “Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G”, de Szimanski (2009). No entanto, o foco de pesquisa foram os processos do nível G e o que se propõe é o mapeamento entre os processos GRE e DRE do MPS. As tabelas 5 e 6 ilustram a ordem de mapeamento, o processo MPS e o resultado esperado, a classificação de acordo com os critérios de análise e um resumo das práticas Scrum que podem atender ao resultado esperado. Após o resumo do mapeamento, é apresentada uma descrição para cada alinhamento entre resultado esperado e práticas (MAP). O processo de Gerência de Requisitos é composto por cinco resultados esperados, já detalhados no capítulo 4, de forma correspondente, a tabela a seguir apresenta cinco mapeamentos entre este processo com as práticas Scrum (tabela 5). Tabela 5 – Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum MPS.BR – Nível G Mapea- Scrum mento Gerência de Requisitos (GRE) Abrev. Resultados Classificação Resumo das Práticas Elaboração do Backlog do Produto, Backlog da Os requisitos são entendidos, Versão para Entrega e avaliados e aceitos junto aos MAP 1 GRE 1 SATISFEITO Backlog da Sprint, fornecedores de requisitos, priorizados por Business utilizando critérios objetivos Value e Retorno do Investimento Planejamento da Versão O comprometimento da equipe para Entrega e geração do MAP 2 GRE 2 técnica com os requisitos SATISFEITO Backlog do Produto para aprovados é obtido a Versão A rastreabilidade bidirecional entre os requisitos e os NÃO Prática não MAP 3 GRE 3 produtos de trabalho é SATISFEITO mencionada no Scrum estabelecida e mantida Revisões em planos e produtos de trabalho do projeto são Reunião Diária, MAP 4 GRE 4 realizadas visando a identificar SATISFEITO Revisão e Retrospectiva e corrigir inconsistências em da Sprint relação aos requisitos MAP 5 GRE 5 Mudanças nos requisitos são SATISFEITO Planejamento da Versão
    • 48 gerenciadas ao longo do para Entrega, projeto Reunião Diária, Revisão e Retrospectiva da Sprint Fonte: Autor. O resumo da análise do mapeamento do processo de Desenvolvimento de Requisitos é apresentado na tabela 6. Esse processo é composto por oito mapeamentos, que correspondem aos resultados esperados. Tabela 6 – Resumo do mapeamento entre o processo DRE do MPS.BR e Scrum MPS.BR – Nível D Mapea- Scrum mento Desenvolvimento de Requisitos (DRE) Abrev. Resultados Classificação Resumo das Práticas Elaboração do Backlog As necessidades, expectativas do Produto, e restrições do cliente, tanto do Reunião de Planejamento MAP 6 DRE 1 SATISFEITO produto quanto de suas da Versão para Entrega e interfaces, são identificadas Reunião de Planejamento da Sprint Um conjunto definido de Backlog do Produto, requisitos do cliente é Backlog do Produto para MAP 7 DRE 2 especificado a partir das SATISFEITO a Versão e necessidades, expectativas e Backlog da Sprint restrições identificadas Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a Reunião de MAP 8 DRE 3 SATISFEITO solução do problema a ser Planejamento da Sprint resolvido, é definido e mantido a partir dos requisitos do cliente Os requisitos funcionais e não- funcionais de cada MAP 9 DRE 4 componente do produto são SATISFEITO Backlog da Sprint refinados, elaborados e alocados Interfaces internas e externas Backlog do Produto, do produto e de cada PARCIALMENTE Backlog do Produto para MAP 10 DRE 5 componente do produto são SATISFEITO a Versão e Backlog da definidas Sprint Reuniões de Conceitos operacionais e PARCIALMENTE MAP 11 DRE 6 Planejamento da Versão cenários são desenvolvidos SATISFEITO para Entrega e da Sprint Os requisitos são analisados, Reuniões de usando critérios definidos, MAP 12 DRE 7 SATISFEITO Planejamento da Versão para balancear as necessidades para Entrega e da Sprint dos interessados com as
    • 49 restrições existentes Conceito de MAP 13 DRE 8 Os requisitos são validados SATISFEITO “Software Pronto” Fonte: Autor. Uma descrição detalhada dos mapeamentos gerados entre os processos de Gerência de Requisitos e Desenvolvimento de Requisitos do MPS.BR com a prática da metodologia ágil Scrum é apresentada a seguir, conforme ilustrado nas tabelas 5 e 6: MAP 1 – No Scrum os requisitos são entendidos diretamente com os clientes, cabendo ao Product Owner (PO) identificar tanto os requisitos como os fornecedores de requisitos. O PO deve avaliar os requisitos, obtendo como resultado o Backlog do Produto (BP). O PO deve usar como critério a priorização por Business Value (BV) e Retorno do Investimento (ROI). O mesmo BP é refinado e os requisitos são novamente analisados quando o Time Scrum (TS) define o Backlog do Produto para a Versão (BPV) e o Backlog da Sprint (BS). Para registrar toda a comunicação realizada, artefatos como estórias de usuário, Atas, BP, Plano de Execução do Projeto, podem ser gerados. Cabe ressaltar que o MPS.BR não indica o formato dos artefatos que devem ser gerados, ficando a critério da organização. Portanto o Scrum atende ao resultado esperado GRE 1. MAP 2 – Scrum atende o resultado esperado GRE 2. Através da Reunião de Planejamento da Versão para Entrega (RPVE), PO e ScrumMaster (SM) trabalham para que todo o TS entre em acordo sobre o entendimento dos requisitos, gerando planos e metas que formarão o BPV. Desta forma, a equipe técnica está se comprometendo com requisitos aprovados a partir de critérios estabelecidos conforme GRE 1. MAP 3 – Scrum não atende a GRE 3, a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho não é mencionada na prática Scrum. Uma possível solução será abordada mais adiante, onde se apresentam sugestões para cobrir incompatibilidades com o MPS.BR. Verificar GAP 1, no tópico “5.3 Estendendo o Scrum”, neste capítulo. MAP 4 – O resultado esperado GRE 4 é atendido pelo Scrum. O objetivo deste resultado esperado, a necessidade de revisões em planos e produtos de trabalho do projeto, realizadas visando à identificação e correção de inconsistências em relação aos requisitos é uma das maiores evidências na prática Scrum. As Reuniões Diárias, a Reunião de Revisão da
    • 50 Sprint e a Reunião de Retrospectiva da Sprint, além do fluxo de desenvolvimento do Scrum, o capacitam a abraçar mudanças ao longo do projeto, permitindo que o projeto esteja apto, a partir de constantes revisões, a identificar e corrigir as mudanças de requisitos que ocorrerão ao longo do desenvolvimento do projeto. MAP 5 – Satisfeito pela prática Scrum. Assim como no MAP 4, características elementares do Scrum encaminham para que as mudanças nos requisitos sejam gerenciadas ao longo do projeto. Uma vez que com a RPVE, as Reuniões Diárias, e as Reuniões de Revisão e Retrospectiva da Sprint garantem um gerenciamento das mudanças dos requisitos, ficando a critério do TS a forma de documentar as mudanças, podendo ser através de estórias de usuário, ou alguma outra ferramenta que também seja adequada para este fim. MAP 6 – As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas na fase de elaboração do BP e nas Reuniões de Planejamento da Versão para Entrega e de Planejamento da Sprint, realizadas pelo TS. Os artefatos gerados, BP, BPV e BS devem conter itens que traduzam as necessidades, expectativas e restrições do cliente e do produto que foram identificadas. Cabe ressaltar que tanto MPS.BR como Scrum não determinam qual o método mais adequado para identificar necessidades, expectativas, restrições do cliente, apenas exemplificam técnicas de elicitação de requisitos, como entrevistas, questionários, casos de uso, estórias de usuário, outros. MAP 7 – Scrum satisfaz DRE 2. Ao elaborar o BP, BPV e BS, se obtém como produto de trabalho, conjuntos definidos de requisitos do cliente. Todos os conflitos e questões relevantes a serem verificadas ou validadas deverão ser resolvidos através da elaboração do BP pelo PO e das Reuniões de Planejamento da Versão para Entrega e de Planejamento da Sprint, realizadas pelo TS. MAP 8 – Scrum atende ao DRE 3 através da reunião de Planejamento da Sprint. É com a elaboração do BS que os requisitos funcionais e não-funcionais, do produto e dos componentes do produto, são definidos e mantidos. MAP 9 – O alcance deste resultado é evidenciado pelo Backlog da Sprint. É na elaboração do BS que os requisitos funcionais e não funcionais são refinados, detalhados e documentados. Portanto, Scrum atende ao DRE 4.
    • 51 MAP 10 – Na prática Scrum, não há uma definição explícita quanto à definição de interfaces internas e externas do produto e de cada componente do produto, no entanto, espera-se que estas definições sejam feitas em ou no BP, pelo PO, ou em outras fases como na reunião que define o BP para Versão de Entrega, ou no BS, realizados pelo TS. Desta maneira, o resultado esperado DRE 5 é parcialmente satisfeito pelo Scrum. Verificar GAP 2, no tópico “5.3 Estendendo o Scrum”. MAP 11 – Mais uma vez, Scrum não indica o que deve ser realizado, mas deixa espaço, através das reuniões de Planejamento da Versão para Entrega do Planejamento da Sprint, para que os conceitos operacionais e cenários sejam desenvolvidos pelo TS. Scrum atende parcialmente ao DRE 6. Verificar GAP 3, no tópico “5.3 Estendendo o Scrum”. MAP 12 – Na prática do Scrum, por primar pelo empirismo, espera-se que o TS tenha a experiência necessária para analisar os requisitos, levando em conta os critérios definidos, os cenários, conceitos operacionais e todo o fluxo de desenvolvimento do produto. Não há uma fase específica que satisfaça DRE 7, porém Scrum dispõe dos momentos apropriados para tarefas que satisfaçam o resultado esperado, como as reuniões de Planejamento da Versão para Entrega e da Sprint. Scrum atende DRE 7. MAP 13 – Scrum atende a DRE 8. A prática Scrum, assim como o resultado esperado DRE 7, não determina a melhor forma de validação dos requisitos, porém na metodologia ágil, o TS deve ter definido claramente o que é “Software Pronto”, e isso deve incluir a garantia de que o produto terá o desempenho adequado quando entregue ao cliente. Feitas as análises, segue um resumo dos resultados encontrados do mapeamento entre os modelos. 5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum O mapeamento, alinhamento e comparativo dos processos GRE, DRE e as práticas Scrum tiveram por objetivo verificar a compatibilidade entre os modelos. Com isto, descobriu-se que o Scrum satisfaz boa parte dos resultados esperados dos processos
    • 52 analisados, no entanto, alguns resultados não podem ser atendidos conforme apresentado na atendidos, tabela 7 e no gráfico 2. Tabela 7 – Resultado da avaliação Critérios GRE DRE Satisfeito 80% 75% Parcialmente satisfeito atisfeito 0% 25% Não satisfeito 20% 0% Fonte: Autor. Gráfico 2 – Resultado da avaliação Fonte: Autor. Ao observar os resultados, percebe que há, no Scrum, algumas atividades ausentes percebe-se ou que carecem de atenção por parte da organização para que este esteja totalmente alinhado organização, ao MPS.BR, este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e
    • 53 mantida, (2) Interfaces internas e externas do produto e de cada componente do produto são definidas, (3) Conceitos operacionais e cenários são desenvolvidos. Neste trabalho, são apresentadas sugestões que visam alinhar totalmente o Scrum aos processos GRE e DRE do MPS.BR, sem que haja uma deturpação dos preceitos empregados nas metodologias ágeis. Assim, entende-se que a metodologia ágil Scrum possibilita novas formas para realização da melhoria de processo, principalmente em ambientes de mudanças constantes, como a área de requisitos de software, aproveitando a experiência de cada um dos indivíduos e a agilidade com que cada um dos times tem para se adaptar a uma nova situação. 5.3 Estendendo o Scrum Alterar as características de um framework seria criar um novo framework. Na tentativa de alinhar o Scrum aos processos GRE e DRE do MPS.BR, foram adicionadas características visando não modificar os principais elementos da metodologia ágil, entendendo desta forma, como uma extensão do Scrum. Para cada lacuna (GAP) identificada no alinhamento realizado, serão propostas sugestões que podem contribuir para o completo alinhamento entre os modelos. GAP 1 – A prática Scrum não menciona o rastreamento bidirecional dos requisitos, isso pode ser facilmente resolvido com a geração de um artefato como uma matriz de rastreabilidade. Essa matriz deve possuir a identificação dos requisitos e permitir a rastreabilidade bidirecional horizontal e vertical dos mesmos, estabelecendo as dependências entre os requisitos, os produtos de trabalho em um mesmo nível (horizontal) ou em níveis diferentes (vertical). Esta sugestão é embasada no relato de Campos (2008), que indica que esta prática já é adotada por algumas organizações. GAP 2 – Scrum não define em que momento interfaces internas externas do produto e de cada componente do produto devem ser definidas, apenas fornece eventos onde esta definição pode ocorrer. Para que o método ágil satisfaça a esta necessidade do MPS, a
    • 54 sugestão é que a organização determine junto ao Time Scrum em que etapa do ciclo de desenvolvimento ocorrerão estas definições. GAP 3 – Assim como em GAP 2, Scrum apenas fornece eventos onde a ação pode ocorrer, mas não determina quais ações o Time Scrum deve realizar, pois a metodologia ágil defende que o Time Scrum deve ser auto-suficiente e maduro para tomar as decisões necessárias ao desenvolvimento. Cabe então a organização, juntamente com o Time Scrum, determinar como, e quando ocorrerá o desenvolvimento do cenário operacional do produto. Cabe ressaltar que, para que a organização esteja alinhada com a correta filosofia do desenvolvimento ágil, qualquer característica adicionada ou modificada no ciclo de desenvolvimento Scrum, deve levar em conta as definições e regras que envolvem cada papel e evento do framework Scrum.
    • 55 6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Neste capítulo, os temas abordados serão revistos com um enfoque prático, no intuito de compilar informações sobre problemas que podem ocorrer na prática dos processos GRE e DRE, do Scrum e problemas relacionados a requisitos de software, como eles podem se complementar, contribuindo para que organizações possam minimizar estes problemas. A validação prática da aplicação de Scrum aos processos GRE e DRE diretamente em uma organização se mostra uma tarefa complexa, no caso da implantação do nível G do MPS.BR, algumas empresas podem levar de 12 a 18 meses para atingirem este nível, como no caso da empresa Prodabel (SOUZA, 2007), que realizou um projeto de implantação com previsão de 15 meses para alcançar este nível do MPS. Travassos (2009), em “iMPS 2009: Caracterização e Validação de Desempenho de Organizações que Adotaram o Modelo MPS”, aponta que empresas no estágio inicial do modelo MPS tiveram uma redução da produtividade, um aumento no custo médio dos projetos e um percentual significativo de empresas em que não houve alteração na satisfação do cliente. Gráfico 3 – Variação de desempenho de 22 empresas com MPS – Níveis G Fonte: TRAVASSOS, 2009. O gráfico 3 mostra o resultado da variação 2008-2009 de desempenho de 22 empresas com MPS nível G, onde cada indicador sinaliza cada um dos itens avaliados e o nível de
    • 56 confiança3, que tenta sugerir o quanto o comportamento descrito pelo indicador poderia estar representando o comportamento das empresas considerando o grupo específico sob análise (TRAVASSOS, 2009). O mesmo trabalho mostra que as empresas, ao alcançarem níveis maiores de maturidade, conseguem mudar positivamente este cenário. A seguir, são apresentados alguns problemas práticos encontrados na implementação do processo GRE e como a aderência as práticas Scrum pode contribuir para maximizar os resultados, contrastando com os resultados apresentados no gráfico 3. 6.1 Dificuldades práticas na implantação do processo GRE Estando o processo GRE presente no nível inicial do MPS, algumas das dificuldades encontradas na sua implementação têm forte relação com as mudanças na cultura organizacional necessárias para o emprego do MPS.BR. A tabela 8 mostra alguns exemplos de dificuldades relatadas e como as práticas ágeis podem contribuir para minimizar estes problemas. Tabela 8 – Dificuldades encontradas no MPS.BR e possíveis soluções pelo Scrum Dificuldades no uso inicial do MPS.BR Possíveis soluções com Scrum Membros do projeto não compreendem os Scrum possui um fluxo simples, de fácil processos como um todo, o que gera resistências na compreensão; O ScrumMaster tem a adequação ao modelo; responsabilidade em fazer com que todos os envolvidos compreendam o fluxo de desenvolvimento e o emprego dos princípios e Membros do projeto não compreendem os motivos valores ágeis, o que traz para todos os envolvidos da necessidade de confecção de artefatos que um maior conhecimento do processo de evidenciam os resultados esperados; desenvolvimento como um todo; Mudanças são abraçadas por equipes ágeis; As metodologias ágeis formam frameworks que Mudanças necessárias ao projeto são descartadas permitem que as mudanças sejam avaliadas e devido a etapas burocráticas; incorporadas com facilidade; Scrum permite a formação de equipes confortáveis às mudanças; Mudanças necessárias ao projeto somente são Métodos ágeis prevêem que as mudanças devem incorporadas ao processo após o término do ocorrer dentro do próprio projeto de projeto; desenvolvimento, entre as Sprints, quando 3 Indicador calculado considerando-se a população como sendo o número total de questionários válidos para cada grupo e a amostra do número de respostas válidas para cada questão (TRAVASSOS, 2009).
    • 57 identificadas nas Reuniões de Revisão e Retrospectiva das Sprints; Em implementações falhas do MPS, os colaboradores envolvidos podem achar que, por culpa do MPS, a organização passa a dar mais valor aos processos do que as pessoas. Isso é uma Foco nos processos e não nas pessoas; inverdade com relação ao MPS e Scrum pode auxiliar a evitar este tipo de problema por ter grande foco no entendimento e experiência do Time Scrum; Na implementação dos processos iniciais do MPS o Faltam referências quanto a design, codificação, enfoque inicial é do ponto de vista da organização ferramentas, testes automatizados, etc. gerencial, deixando para os próximos níveis questões como design, codificação, ferramentas, testes automatizados, etc. Porém ao empregar Scrum em conjunto com estes Faltam referências quanto ao gerenciamento de processos, a equipe terá como referência os valores riscos. e princípios ágeis, que incorporam estas questões dentro do ciclo de desenvolvimento ágil; MPS.BR não obriga a geração de documentos específicos, porém formalizações são necessárias para comprovar os resultados esperados. Os artefatos gerados na prática Scrum podem ser Obrigação de gerar documentos sem explicar utilizados para evidenciar os resultados esperados detalhes de como fazê-los. dos processos MPS, eles foram criados para serem simples, de fácil assimilação e para que seu uso maximize o entendimento do Time Scrum sobre o processo de desenvolvimento; Fonte: BERNABÓ, 2007; RIBEIRO, 2007; Autor. 6.2 Dificuldades práticas relacionadas a requisitos de software Por GRE e DRE tratarem sobre requisitos de software, alguns problemas práticos relacionados a requisitos de software acabam por dificultar a implementação dos processos do MPS. A tabela 9 mostra alguns problemas e como as práticas ágeis podem contribuir para minimizá-los. Tabela 9 – Dificuldades encontradas em Requisitos e possíveis soluções pelo Scrum Dificuldades relacionadas a Requisitos Possíveis soluções com Scrum O levantamento dos requisitos é responsabilidade Envolvimento interessados inapropriados na do Product Owner, cabendo a ele focar quem são os elicitação dos requisitos; stakeholders; No caso de mudanças, como a troca do responsável Problemas políticos na organização, resultando em pelo Backlog do Produto, Scrum permite que, reestruturação de papéis e a mudança de visão do através de iterações curtas e incrementais, a equipe negócio, com impacto na mudança de escopo; possa adaptar-se a mudanças, portanto no caso de uma mudança na visão do negócio, os métodos
    • 58 ágeis levam vantagem por adaptarem-se mais rapidamente as mudanças que os métodos tradicionais; Isso tem impacto em todo o planejamento do projeto; Um dos princípios das Metodologias ágeis é a Detalhamento técnico desnecessário durante a simplicidade, que pode colaborar para evitar especificação funcional do sistema; informações desnecessárias nas especificações; Complexidade no detalhamento dos casos de uso Metodologias ágeis introduzem as estórias de para definição da solução; usuário (user stories), que são descrições textuais sucintas sobre as funcionalidades do sistema, Dificuldades para validação de casos de uso por escritas pela equipe técnica em conjunto com o parte do usuário; cliente. Isso intensifica o envolvimento com o cliente, gera requisitos menos complexos, não Falta de conhecimento dos analistas de requisitos deixando de serem informativos a respeito do em um domínio específico do problema. requisito a ser desenvolvido. Apesar de Scrum abraçar mudanças, após o Time Scrum selecionar quais itens do Backlog do Alteração constante dos requisitos, causando Produto farão parte da Sprint, estes itens não retrabalho; deverão sofrer alterações; Cabe ao Product Owner gerenciar as mudanças necessárias aos itens do Backlog do Produto; Fonte: NASCIMENTO, 2009; Autor. 6.3 Dificuldades práticas relacionadas ao Scrum A implantação de metodologias ágeis também se mostra complexa, por exigir uma mudança na cultura e na forma de realizar os processos. A tabela 10 mostra algumas das dificuldades encontradas na implementação de Scrum e como MPS.BR pode contribuir para minimizá-las. Tabela 10 – Dificuldades encontradas em Scrum e possíveis soluções pelo MPS.BR Dificuldades relacionadas ao Scrum Possíveis soluções com o MPS.BR Por valorizar o Software Pronto mais que documentações abrangentes, muitas organizações interpretam que métodos ágeis, como o Scrum, não há documentação dos produtos desenvolvidos, o Neste caso, MPS.BR pode fazer com que equipes que é uma inverdade. Scrum defende que se deve ágeis tenham documentos mais abrangentes do que ter a documentação suficiente para o entendimento talvez teriam caso não tivessem a necessidade de de todos os envolvidos, ao invés de uma evidenciar os resultados esperados; documentação gigantesca que toma grande tempo para a confecção e desestimula os usuários do produto a lerem; O suporte a equipes distribuídas por acarretar O uso de uma documentação formal pode ser vários problemas que inexistem quando os necessário; MPS pode contribuir por formalizar integrantes da equipe de desenvolvimento e do processos e por ter documentações mais cliente se encontram próximos; abrangentes;
    • 59 O tamanho do projeto pode ser considerado uma limitação ao Scrum; Quanto maior a equipe, mais complexa é a comunicação, o que torna o processo menos ágil; A necessidade da comprovação da rastreabilidade bidirecional, exigida pelo MPS, contribui para que o método ágil também tenha esta avaliação, que Rastreabilidade bidirecional dos requisitos; permite uma análise mais confiável do impacto das mudanças nos requisitos, com relação ao produto de trabalho; Pelos princípios ágeis, as decisões do time têm Através de processos bem elaborados e mais prioridade que as decisões da organização. documentados, Times Scrum podem ter uma base Isso resulta na falta de definição de um padrão de para tomar as suas decisões; processo; Em uma organização que será avaliada em MPS, os processos estabelecidos precisam ser seguidos, O time de desenvolvimento não segue todos os logo, se os preceitos do Scrum estiverem preceitos da prática Scrum; determinados dentro dos processos, a equipe terá de desempenhá-los, sob o risco de não estarem cumprindo com o determinado pelo processo; Fonte: Autor. E estas foram apenas algumas das dificuldades no desenvolvimento de software, que tem relação com os temas abordados no trabalho. Como qualquer processo, o desenvolvimento de software tem entradas, processamentos e saídas que precisam estar bem claros e bem definidos para todos os envolvidos. 6.4 Além das limitações de MPS e Scrum Dada as especificidades, as soluções adotadas pelas organizações podem variar, até porque não há uma solução completa para todos os processos envolvidos. Modelos de qualidade poderão auxiliar na organização dos processos; Frameworks para desenvolvimento poderão impor uma cultura relacionada ao desenvolvimento, mas serão necessárias outras soluções que complementem dificuldades que MPS.BR e Scrum não atendem ou atendem parcialmente, como algumas respostas sobre “como fazer” determinados artefatos ou produtos de trabalho ou quais as melhores práticas de engenharia de requisitos. Ainda há os problemas relacionados com contratos de trabalho, como os relacionados com a pós-entrega do produto, sua manutenção e o auxílio aos usuários. As organizações acabam por montar o seu próprio conjunto de soluções que atendem as suas necessidades e assim, construindo o seu próprio framework de trabalho.
    • 60 7 CONCLUSÃO Diante de problemas cada vez mais complexos, o ser humano sente a necessidade de administrar, gerenciar, tornar as coisas mais simples para o seu próprio entendimento. Na indústria do software, os requisitos são apenas uma das questões que envolvem o desenvolvimento de software. Por mais que se passe a utilizar técnicas que melhorem a elicitação dos requisitos, ainda assim há, dentre outras, a questão de como gerenciar estas informações, como gerenciar os recursos disponíveis ou como gerenciar o projeto como um todo. Não há a resposta correta para todas as perguntas, mas há várias direções que podem ser escolhidas pela organização. Scrum é uma delas. Os métodos ágeis vêm tomando espaço, sendo tema de trabalhos e estudos, recebendo críticas e elogios. E dessa forma vem moldando o nosso presente e futuro na maneira de fazer software. Ao mesmo tempo, modelos como o MPS.BR, apresentam-se como uma possível solução para as questões que atordoam as organizações, como a qualidade do processo. Estes modelos também vêm sendo abordados em trabalhos e pesquisas, possibilitando que as organizações tenham um bom embasamento no momento de tomar decisões. Diferentes correntes nos levam a melhoria. Seja através de um MPS ou através de uma metodologia ágil, o objetivo é o mesmo, o que muda são as formas de se obterem os resultados e o que se busca são maiores possibilidades de atender aos requisitos do cliente. Em realidade, o que se pode afirmar é que existe uma sinergia muito grande entre os modelos, ou seja, um pode complementar o outro. O mapeamento entre os processos de Gerência e Desenvolvimento de Requisitos com o método ágil Scrum, busca um entendimento de como conciliar o Modelo MPS com o método ágil, tirando o melhor proveito de ambos. Com certeza, os temas abordados neste trabalho, jamais serão discutidos ao esgotamento. Com certeza, jamais haverá um consenso sobre a melhor forma de trabalho para uma organização. O que foi exposto aqui são apenas alternativas para as organizações que
    • 61 desejam melhorar, não apenas seus produtos, mas também seus processos e comunicações internas. De fato, o que se espera é que esse trabalho contribua para que as organizações reflitam sobre como seus processos são executados e como é possível melhorá-los adotando boas práticas. 7.1 Trabalhos futuros Como sugestão para trabalhos futuros, indica-se: • Aplicar o mapeamento proposto diretamente em uma organização. • Apurar melhor os artefatos gerados resultantes do mapeamento. • Validar se os artefatos indicados evidenciam os resultados esperados. • Verificar se há necessidade de adaptações, ou até mesmo, se novos artefatos serão necessários para o alinhamento preterido.
    • 62 8 REFERÊNCIAS AGILE MANIFESTO. Manifesto for Agile Software Development. 2001. Disponível em <http://agilemanifesto.org >. Acesso em: mar. 2010. ANDRADE, C. et al. Projeto de Software Orientado a Objetos com UML 2.0. Revista SQL Magazine. Edição 45, Ano 4, Ed. DevMedia, 2007. p. 24-31. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. NBR ISO 9000:2000 – Sistema de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2000. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR Guia Geral: 2009, 2009a. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009. ______ Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS, 2009b. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009. ______ Guia de Implementação – Parte 4: Fundamentação para Implementação do Nível D do MR-MPS, 2009c. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009. ÁVILA, A. L.; SPÍNOLA, R. O. Introdução à Engenharia de Requisitos. Revista Engenharia de Software. Edição especial, Ano 1, 1ª ed, Ed. DevMedia, 2007. p. 46-51. BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001. BERNABÓ, Juran; NOVELLO, Alexandre; TELES, Vinícius Manhães. Improvecast 3 - CMM? MPS.BR? ISO? Não, tô fora! Disponível em <http://improveit.com.br/podcast/improvecast-3-cmm-mpsbr-iso-nao-to-fora>. Acesso em: maio de 2010. Publicado em 22 jun. 2007. CAMPOS, A. C. C., et al. Apoiando a implementação do modelo de maturidade MPS Nível G. Revista Engenharia de Software. Ano 1, 7ª ed, Ed. DevMedia, 2008. p. 50-57. CHIAVENATO, Idalberto. Introdução à Teoria Geral da Administração. 6ª ed. ver. E atualizada. Rio de Janeiro: Campus, 2000. p. 1-4.
    • 63 ______, Idalberto. Introdução à Teoria Geral da Administração. Vol. II. 6ª ed. ver. e atualizada. Rio de Janeiro: Campus, 2002. DIAS, Marisa Villas Boas. Métodos Ágeis de Desenvolvimento de Software. Revista Engenharia de Software Magazine. Edição 20, Ano 2, Ed. DevMedia, 2010. p. 05-21. DINIZ, Samuel. Desmistificando o MPS.BR – Gerência de Requisitos (GRE). Blog do Samuel Diniz. 2009a. Disponível em <http://blogdosamueldiniz.blogspot.com>. Acesso em: mar. 2010. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION – ISO. ISO/IEC 12207:2008 – Systems and software engineering -- Software life cycle processes. 2008. Disponível em < http://www.iso.org/>. Acesso em: abr. 2010a. ______. ISO/IEC 15504 – Information technology -- Process assessment. 2008. Disponível em < http://www.iso.org/>. Acesso em: abr. 2010b. ISOTTON NETO, Erasmo. Scrumming: Ferramenta Educacional para Ensino de Práticas do Scrum. Pontifícia Universidade Católica do Rio Grande do Sul. Porto Alegre, 2008. KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum. InfoQ. 2007. KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: aprenda as metodologias mais modernas para o desenvolvimento de software. 1ª ed. São Paulo. Novatec Editora, 2006. p. 95-115. MACHADO, M.; MEDINA, S. G. SCRUM – Método Ágil: uma mudança cultural na Gestão de Projetos de Desenvolvimento de Software. Revista Científica Intr@ciência. São Paulo: UNIESP, 2009. NASCIMENTO, M. C.; KALINOWSKI, M.; SPÍNOLA, R. O. Soluções Concretas para Problemas Práticos da Engenharia de Requisitos. Revista Engenharia de Software. Ano 2, 13ª ed, Ed. DevMedia, 2009. p.8-15. PÁDUA P. F. Wilson. Alguns Elementos de Engenharia de Software. Revista Engenharia de Software. Edição especial, Ano 1, 1ª ed, Ed. DevMedia, 2007. p. 4-8. PARZIANELLO, Luiz Cláudio. Apostila do Curso Requisitos de Software: Conceitos e Práticas para Equipes Ágeis. Porto Alegre: [S.n.], 2009.
    • 64 PRIKLADNICKI, Rafael. Apostila do Curso Gerenciamento de Projetos com Scrum: Uma nova forma de pensar projetos. Porto Alegre: [S.n.], 2009. RIBEIRO, A. F. MPS.BR – Mitos e Verdades a Respeito de Um Modelo de Maturidade. Revista Engenharia de Software. Ano 1, 2ª ed, Ed. DevMedia, p. 32-35, 2007. SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press, [S. I.] 2004. ______, Ken. Guia do Scrum, maio de 2009. Disponível em <http://www.scrumalliance.org>. Acesso em: dez. 2009. ______, Ken. The SCRUM Development Process. Burlington, MA, USA, 1996. SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. Tradução Maurício de Andrade. São Paulo: Ed. Pearson Addison Wesley, 2003. p. 79-123. SOUZA J. P.; PINTO, M. V. “Prodabel: diagnóstico da implantação do nível G do MPS.BR”. I Workshop de Empresas (W6-MPS.BR). Belo Horizonte. 30 nov. 2007. SPÍNOLA, Rodrigo Oliveira. Engenharia de Requisitos. Revista SQL Magazine. Edição 71, Ano 5, Ed. DevMedia, 2009. p. 64-66. 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. TRAVASSOS, G. H.; KALINOWSKI, M. “iMPS 2009: Caracterização e Validação de Desempenho de Organizações que Adotaram o Modelo MPS”. 1 ª ed. Campinas, SP: SOFTEX, 2009. VERSIONONE. State of Agile Development Survey 2009. Disponível em <http://www.versionone.com>. Acesso em: mai. 2010. WAZLAWICK, Raul S. Análise e Projeto de Sistemas de Informação Orientado a Objetos. 1ª ed. São Paulo: Ed. Campus, 2004.
    • 65 ANEXO A – MANIFESTO ÁGIL - VALORES Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: AGILE MANIFESTO, 2001.
    • 66 ANEXO B – MANIFESTO ÁGIL - PRINCÍPIOS Nós seguimos os seguintes princípios: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção a excelência técnica e bom design aumentam a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitor e designs emergem de times auto-organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Fonte: AGILE MANIFESTO, 2001.
    • 67 ANEXO C – ATRIBUTOS DE PROCESSO - AP 1.1 Atributo de Processo (AP) AP 1.1 - O processo é executado Descrição: Medida do quanto o processo atinge o seu propósito Resultado Esperado (RAP): RAP 1 - O processo atinge seus resultados definidos. Fonte: SOFTEX, 2009a, p. 17.
    • 68 ANEXO D – ATRIBUTOS DE PROCESSO - AP 2.1 Atributo de Processo (AP) AP 2.1 - O processo é gerenciado Descrição: Medida do quanto à execução do processo é gerenciada Resultado Esperado (RAP): RAP 2 - Existe uma política organizacional estabelecida e mantida para o processo; RAP 3 - A execução do processo é planejada; RAP 4 - (A partir do nível F). Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados; RAP 4 - (Para o nível G) A execução do processo é monitorada e ajustes são realizados; RAP 5 - (Até o nível F) As informações e os recursos necessários para a execução do processo são identificados e disponibilizados; RAP 5 - (A partir do nível E) Os recursos e informações necessários para executar o processo definido são disponibilizados, alocados e utilizados; RAP 6 - (Até o nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas; RAP 6 - (A partir do nível E) Os papéis requeridos, responsabilidades e autoridade para execução do processo definido são atribuídos e comunicados; RAP 7 - (Até o nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP 7 - (A partir do nível E) As pessoas que executam o processo definido são competentes em termos de formação, treinamento e experiência; RAP 8 - A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento; RAP 9 - (Até o nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização; RAP 9 - (A partir do nível E) Métodos adequados para monitorar a eficácia e adequação do processo são determinados e os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização; RAP 10 - (Para o nível G) O processo planejado para o projeto é executado; RAP 10 - (A partir do nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades; Fonte: SOFTEX, 2009a, p. 17-18.
    • 69 ANEXO E – ATRIBUTOS DE PROCESSO - AP 2.2 Atributo de Processo (AP) AP 2.2 - Os produtos de trabalho do processo são gerenciados Medida do quanto os produtos de trabalho produzidos pelo processo são Descrição: gerenciados apropriadamente Resultado Esperado (RAP): RAP 11 - Os requisitos dos produtos de trabalho do processo são identificados; RAP 12 - Requisitos para documentação e controle dos produtos de trabalho são estabelecidos; RAP 13 - Os produtos de trabalho são colocados em níveis apropriados de controle; RAP 14 - Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades. Fonte: SOFTEX, 2009a, p. 18-19.
    • 70 ANEXO F – ATRIBUTOS DE PROCESSO - AP 3.1 Atributo de Processo (AP) AP 3.1 - O processo é definido Medida do quanto o processo padrão é mantido para apoiar a Descrição: implementação do processo definido Resultado Esperado (RAP): RAP 15 - Um processo padrão é descrito, incluindo diretrizes para sua adaptação para o processo definido para um projeto; RAP 16 - A seqüência e interação do processo padrão com outros processos são determinadas; RAP 17 - Os papéis e competências requeridos para executar o processo são identificados como parte do processo padrão; RAP 18 - A infra-estrutura e o ambiente de trabalho requeridos para executar o processo são identificados como parte do processo padrão. Fonte: SOFTEX, 2009a, p. 19.
    • 71 ANEXO G – ATRIBUTOS DE PROCESSO - AP 3.2 Atributo de Processo (AP) AP 3.2 - O processo está implementado Medida do quanto o processo padrão é efetivamente implementado como Descrição: um processo definido para atingir seus resultados Resultado Esperado (RAP): RAP 19 - Um processo definido é implementado para o projeto baseado nas diretrizes para seleção e/ou adaptação do processo padrão; RAP 20 - A infra-estrutura e o ambiente de trabalho requeridos para executar o processo definido são disponibilizados, gerenciados e mantidos; RAP 21 - Dados apropriados são coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo; RAP 22 - Produtos de trabalho e lições aprendidas são coletados e armazenados na biblioteca de ativos de processo, para uso futuro e apoio à melhoria contínua do processo. Fonte: SOFTEX, 2009a, p. 19.