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

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).

Fonte: PARZIANELLO, 2009.

Entender os requisitos é descobrir o que o cliente quer com o sistema

2004, p. 24). Logo, por requisitos abrangerem todas as características importantes do software

que será produzido, a elaboração destes torna

projeto de software.

É na análise de requisitos

apresentado na tabela 1 por Á

requisitos podem aumentar consideravelmente

contrário, a correção, ainda ne

tabela 1).

Tabela 1

% do custo de

desenvolvimento

Análise de Requisitos

Projeto

Codificação teste de unidade

Teste

Validação e Documentação

Manutenção

Fonte: ÁVILA, 2007.

Figura 1 – O Contexto dos Requisitos

ntender os requisitos é descobrir o que o cliente quer com o sistema (

requisitos abrangerem todas as características importantes do software

que será produzido, a elaboração destes torna-se uma das fases mais importan

É na análise de requisitos que boa parte dos erros são introduzidos.

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

Tabela 1 – Cenário Atual de Desenvolvimento

% do custo de esenvolvimento

% dos erros introduzidos

% dos erros encontrados

05 55 18

25 30 10

50

10 10 50

10

05 22

12

(WAZLAWICK,

requisitos abrangerem todas as características importantes do software

se uma das fases mais importantes de todo o

boa parte dos erros são introduzidos. Cenários, como

, mostram que defeitos não tratados ainda na fase de

o custo do desenvolvimento do projeto. Ao

conforme primeira linha da

Custo relativo de correção

1

1 - 1.5

1 - 5

10 - 100

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:

• O software deve ser compatível com o

Firefox (1.0 ou superior);

• O software deve garantir que o tempo de retorno das c

do que cinco segundos.

Os diferentes tipos de requisitos não funcionais estão representados na figura

classificados por Sommerville (2003) conforme a sua procedência

Figura 2

Fonte: SOMMERVILLE, 2003

Os requisitos de produto são procedentes do comportamento do produto, como o

desempenho, o espaço requerido

procedimentos do cliente e do

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.

O software deve ser compatível com o browser IE (versão 5.0 ou superior) e

Firefox (1.0 ou superior);

e deve garantir que o tempo de retorno das consultas não seja maior

segundos.

Os diferentes tipos de requisitos não funcionais estão representados na figura

classificados por Sommerville (2003) conforme a sua procedência:

Figura 2 – Tipos de Requisitos Não Funcionais


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



los requisitos externos.

15

IE (versão 5.0 ou superior) e

onsultas não seja maior

Os diferentes tipos de requisitos não funcionais estão representados na figura 2,


. Requisitos organizacionais especificam políticas e

desenvolvedor, como questões relacionadas aos padrões que



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.

Figura

Fonte: SOMMERVILLE, 2003.

2.3.1 Estudo de viabilidade

Autores como Sommerville (2003), recome

sistema, o processo de engenharia de requisitos

viabilidade que indicará se vale a pena ou não seguir adiante no projeto.

Ele explica que o estudo de viabilidade deve responder as

• 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

software e usuários finais do sistema e através do relatório de estudo de viabilidade

recomendar se o desenvolvimento do sistema deve

mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento

disponível ou o cronograma de desenvolvimento.

Figura 3 – Processo de Engenharia de Requisitos

Autores como Sommerville (2003), recomendam que ao iniciar o projeto de um novo

genharia de requisitos deve ser iniciado com um estudo de

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?

se buscar informação através dos gerentes de departamentos, engenheiros de


recomendar se o desenvolvimento do sistema deve iniciar/continuar ou não, podendo sugeri


disponível ou o cronograma de desenvolvimento.

17

ndam que ao iniciar o projeto de um novo

deve ser iniciado com um estudo de

seguintes perguntas:

O sistema pode ser implementado com a utilização de tecnologia atual dentro

O sistema pode ser integrado com outros sistemas já em operação?

se buscar informação através dos gerentes de departamentos, engenheiros de


continuar ou não, podendo sugerir


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.

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ê

desenvolvimento ágil de softwares é, para muito

série de profissionais, de todas as partes do mundo,

metodologias ágeis, divulgando e aprimorando

aceitabilidade dentro das empres

Dentre os principais métodos ágeis de desenvolvimento de software podem ser

citados: Scrum, Extreme Programming, Lean Software Development, entre outros.

1 corrobora a afirmação inicial

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

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

MPS.BR.


paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê

oftwares é, para muitos, algo intangível, que não existe. Mas uma

de todas as partes do mundo, dedicam-se a aplicar os conceitos das

metodologias ágeis, divulgando e aprimorando esses conceitos que ganham,

dentro das empresas de tecnologia da informação.


citados: Scrum, Extreme Programming, Lean Software Development, entre outros.

inicial, mostrando a pesquisa apresentada pela VersionOne (2009),


alguma variação deste, é utilizado por mais de 70 % dos participantes.

Gráfico 1 – Utilização de metodologias ágeis


Scrum e que permitirão uma avaliação do uso deste framework juntamente com o modelo

22


paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê-la. O

, algo intangível, que não existe. Mas uma

se a aplicar os conceitos das

cada vez mais a


citados: Scrum, Extreme Programming, Lean Software Development, entre outros. O gráfico

rando a pesquisa apresentada pela VersionOne (2009),



juntamente com o modelo

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.)

do projeto perca a validade pelas mudanças que podem ocorrer em um plan

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 ho

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

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á

possível produzir dentro da Sprint.

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

Sprint (figura 4). Ao efetuar o planejamento da Sprint e estabelecer

equipe deverá levar em conta a Meta da Versão para Entrega.

Figura 4

Fonte: KNIBERG, 2007, p. 22.

Ao término de cada Sprint, o Time Scrum deverá reunir

Nesta reunião a equipe deve

enfrentados, como foram solucionados no decorrer da Sprint

corrigir deficiências e/ou imped

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

do projeto perca a validade pelas mudanças que podem ocorrer em um plan


compreendido por cada Sprint.


Schwaber (2004), recomenda uma duração de oito horas para Sprints de um mês e no caso de



discutir quais itens do Backlog do Produto serão produzidos na Sprint. O time poderá dar


ime definir, baseado em sua experiência, qual a quantidade de itens será

entro da Sprint.


ronto. As tarefas para a concretização desta tarefa formarão o Backlog da

. 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

Ao término de cada Sprint, o Time Scrum deverá reunir-se para a Revisão da Sprint.

quipe deve fornecer feedback, discutir sobre sucessos

enfrentados, como foram solucionados no decorrer da Sprint, com o objetivo de identificar e

corrigir deficiências e/ou impedimentos no processo de desenvolvimento.

trabalho pronto, e o Product Owner deve identificar os itens do Backlog da


26

do projeto perca a validade pelas mudanças que podem ocorrer em um planejamento muito



ras para Sprints de um mês e no caso de



do Produto serão produzidos na Sprint. O time poderá dar


ime definir, baseado em sua experiência, qual a quantidade de itens será


ronto. As tarefas para a concretização desta tarefa formarão o Backlog da

as metas da mesma, a

se para a Revisão da Sprint.

sucessos, problemas

com o objetivo de identificar e

vimento. A equipe deve

trabalho pronto, e o Product Owner deve identificar os itens do Backlog da


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.

cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos

conhecidos e melhor entendidos.

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 to

tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como:

descrição, prioridade e estimativa. Ele deve estar ordenado por pri

maior a prioridade do item, maior deverá

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

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é

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

do desenvolvimento do Produto. Este gráfico é cham

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

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


endidos. À medida que o Produto evolui, o Backlog também caminha


é o mais apropriado, competitivo e útil ao Produto.

O Backlog do Produto deve ser uma lista com todas as características, funções,


descrição, prioridade e estimativa. Ele deve estar ordenado por prioridade (f

maior a prioridade do item, maior deverá ser o seu nível de detalhamento e com mais urgência


de maneira a poderem ser realizados dentro da duração de uma Sprint.

Figura 5 – Exemplo de Product Backlog

: inspirada em SCHWABER, 2004.



Com a soma das estimativas de esforço necessário para o término do Backlog do


se traçar uma linha de tendência que mostrará uma estimativa do progresso

do desenvolvimento do Produto. Este gráfico é chamado de Burndown da Versão para


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


necessárias para transformar os itens do Backlog do Produto em Software Pronto

28


medida que o Produto evolui, o Backlog também caminha


das as características, funções,


oridade (figura 5). Quanto

ser o seu nível de detalhamento e com mais urgência




rmino do Backlog do


se traçar uma linha de tendência que mostrará uma estimativa do progresso

ado de Burndown da Versão para


o trabalho que o


Software Pronto. Os itens do

Backlog da Sprint devem ser decompostos ao ponto que possam s

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á

do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que

trabalho restante ao longo do tempo (figura 6

Fonte: inspirada em SCHWABER, 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áli

testes.

3.3 Fluxo do Scrum

Isotton Neto (2008), com base no artigo “

Schwaber (1996), define que Scrum é formado pelos seguintes grupos de fases:

Backlog da Sprint devem ser decompostos ao ponto que possam ser entendidos na Reunião


atualizando também as estimativas de trabalho restante.


sforço necessárias para o término do Backlog da Sprint e registrá

do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que

go do tempo (figura 6).

Figura 6 – Burndown da Sprint

pirada em SCHWABER, 2004.

Scrum tem como regra que se deve ter como resultado incrementos de


“Pronto” deve incluir toda a análise, projeto, refatoramento, programação, documentação e

Isotton Neto (2008), com base no artigo “The Scrum Development Process

), define que Scrum é formado pelos seguintes grupos de fases:

29

er entendidos na Reunião



sforço necessárias para o término do Backlog da Sprint e registrá-las ao longo

do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que mostre o

Scrum tem como regra que se deve ter como resultado incrementos de


se, projeto, refatoramento, programação, documentação e

The Scrum Development Process”, de

), 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:

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 “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.

Postgame:

• Fechamento – Entrega e empacotamento do “Software Pronto”. Preparação do

produto desenvol

treinamento e marketing são

A figura 7 mostra de o fluxo Scrum de maneira

Fonte: inspirada em KNIBERG, 2007

Reunião de Planejamento da Sprint a fim de definir as atividades a

serem incluídas na iteração corrente.

Reuniões Diárias com o TS para revisar o andamento do projeto;

Revisão e ajustes nos requisitos do projeto;

Sprints iterativos até que se tenha “Software Pronto”.


e capítulo, sejam plenamente seguidas pelo TS.

Entrega e empacotamento do “Software Pronto”. Preparação do

produto desenvolvido para a entrega. Documentações, testes, materiais de

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

KNIBERG, 2007

31

Reunião de Planejamento da Sprint a fim de definir as atividades a

Reuniões Diárias com o TS para revisar o andamento do projeto;


Entrega e empacotamento do “Software Pronto”. Preparação do

vido para a entrega. Documentações, testes, materiais de

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.

Fonte: SOFTEX, 2009.

O Modelo de Referência MR

pelas organizações que se submeterão

são indicados os níveis de maturidade, processos e seus atributos. O MR

técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI

4.2 Base técnica do Modelo MPS.BR

A ISO/IEC 12207 (

Electrotechnical Commission

processos. A norma contém

fornecimento, aquisição, desenvolvimento,

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

ISO12207 permite que processos de apoio possam ser combinados e executados junto a

outros, a qualquer momento

Standardization – ISO, 2010a)

Já a ISO/IEC 15504, também conhecida por SPICE (

and Capability Etermination), presta

com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de

Figura 8 – Modelo MPS.BR

O Modelo de Referência MR-MPS refere-se aos requisitos que devem ser atendidos

pelas organizações que se submeterão a avaliação ou desejam desenvolver bo

são indicados os níveis de maturidade, processos e seus atributos. O MR-MPS tem sua base

técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI

4.2 Base técnica do Modelo MPS.BR

A ISO/IEC 12207 (International Organization for Standardization/International

Electrotechnical Commission) estabelece uma arquitetura comum para o ciclo de vida de

processos, atividades e tarefas a serem aplicadas durante o

fornecimento, aquisição, desenvolvimento, operação, manutenção de produtos de software.



base para diversas normas e modelos que surgiram posteriormente. A organização da


outros, a qualquer momento (SOFTEX, 2009a, p.14; International Organization for

).

ISO/IEC 15504, também conhecida por SPICE (Software Process Improvement

), presta-se à realização de avaliações de processos de software


34

requisitos que devem ser atendidos

a avaliação ou desejam desenvolver boas-práticas. Nele

MPS tem sua base

técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI-DEV.

nization for Standardization/International

o ciclo de vida de

processos, atividades e tarefas a serem aplicadas durante o

operação, manutenção de produtos de software.



e modelos que surgiram posteriormente. A organização da


SOFTEX, 2009a, p.14; International Organization for

Software Process Improvement

se à realização de avaliações de processos de software


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.

4.3 Estrutura do MR-MPS.BR

O Modelo de Referência do MPS.BR (MR

processos de desenvolvimento de software através de níveis de maturidade, que por sua vez

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

Para cada conjunto de proc

organização (seguindo a proposta da ISO 15504)

de atributos de processos (AP) e resultados esperados de atributos de processo (RAP)

figura 9 mostra a estrutura do Modelo de Referência.

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 melhori

na organização. São sete níveis de maturidade:

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

MPS.BR

O Modelo de Referência do MPS.BR (MR-MPS.BR) define a maturidade dos

to de software através de níveis de maturidade, que por sua vez


resultados esperados para cada um dos 21 processos do MR-MPS.BR (SOFTEX, 2009a)

Para cada conjunto de processos, novas capacidades de processos são exigidas da

(seguindo a proposta da ISO 15504), sendo estas capacidades mensuradas através

de atributos de processos (AP) e resultados esperados de atributos de processo (RAP)

tura do Modelo de Referência.

Figura 9 – Estrutura do MR-MPS.BR


gradual dos processos, eles caracterizam estágios de melhoria da implementação de processos

na organização. São sete níveis de maturidade: A (Em Otimização), B (Gerenciado


(Gerenciado) e G (Parcialmente Gerenciado).

em sete estágios tem como objetivo permitir uma implementação e


A escala de maturidade inicia no nível G e progride até o nível A, conforme tabela 2

36

MPS.BR) define a maturidade dos

to de software através de níveis de maturidade, que por sua vez


(SOFTEX, 2009a).

essos, novas capacidades de processos são exigidas da

, sendo estas capacidades mensuradas através

de atributos de processos (AP) e resultados esperados de atributos de processo (RAP). A


a da implementação de processos

A (Em Otimização), B (Gerenciado


em sete estágios tem como objetivo permitir uma implementação e


até o nível A, conforme tabela 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)

C – Definido

Gerência de Riscos – GRI

Desenvolvimento para Reutilização – DRU

Gerência de Decisões – GDE

D - Largamente Definido

Verificação – VER

Validação – VAL

Projeto e Construção do Produto – PCP

Integração do Produto – ITP

Desenvolvimento de Requisitos – DRE

E - Parcialmente Definido

Gerência de Projetos – GPR (evolução)

Gerência de Reutilização – GRU

Gerência de Recursos Humanos – GRH

Definição do Processo Organizacional – DFP

Avaliação e Melhoria do Processo Organizacional – AMP

F – Gerenciado

Medição – MED

Garantia da Qualidade – GQA

Gerência de Portfólio de Projetos – GPP

Gerência de Configuração – GCO

Aquisição – AQU

G - Parcialmente Gerenciado Gerência de Requisitos – GRE

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.

Os níveis, além de graduais, são acumulativos, e isto implica que a organização,

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 ci

maturidade do MPS.BR. A figura 10

nível G ao nível D (SOFTEX, 2009a, p. 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

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

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 dete

(SOFTEX, 2009b, p. 6).

Para esse processo os Atributos de Processos (capacidades) esperados são:

• O processo é executado (RAP

Os níveis, além de graduais, são acumulativos, e isto implica que a organização,



processo (RAP), sendo que destes, dois estão presentes no nível G e cinco no nível D de

maturidade do MPS.BR. A figura 10 mostra a evolução dos AP em relação aos níveis, do

(SOFTEX, 2009a, p. 16-17).

Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR

detalhamento de cada AP dos níveis G ao D está descrito nos Anexos C

4.4 Processo de Gerência de Requisitos


MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a



que pode determinar o sucesso ou insucesso da implementação do modelo

e processo os Atributos de Processos (capacidades) esperados são:

O processo é executado (RAP 1) e;

39

Os níveis, além de graduais, são acumulativos, e isto implica que a organização, ao



nco no nível D de

mostra a evolução dos AP em relação aos níveis, do

Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR

ao D está descrito nos Anexos C, D, E, F e G


modelo e por isso, tem um grande impacto para a



rminar o sucesso ou insucesso da implementação do modelo

e processo os Atributos de Processos (capacidades) esperados são:

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

Parcialmente Satisfeito Há evidências da prática na metodologia, embora a 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

Map

ea-

men

to MPS.BR – Nível G

Gerência de Requisitos (GRE) Scrum

Abrev. Resultados Classificação Resumo das Práticas

MAP 1 GRE 1

Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos

SATISFEITO

Elaboração do Backlog do Produto, Backlog da Versão para Entrega e

Backlog da Sprint, priorizados por Business

Value e Retorno do Investimento

MAP 2 GRE 2 O comprometimento da equipe técnica com os requisitos aprovados é obtido

SATISFEITO

Planejamento da Versão para Entrega e geração do Backlog do Produto para

a Versão

MAP 3 GRE 3

A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida

NÃO SATISFEITO

Prática não mencionada no Scrum

MAP 4 GRE 4

Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos

SATISFEITO Reunião Diária,

Revisão e Retrospectiva da Sprint

MAP 5 GRE 5 Mudanças nos requisitos são SATISFEITO Planejamento da Versão

48

gerenciadas ao longo do projeto

para Entrega, 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

Map

ea-

men

to MPS.BR – Nível D

Desenvolvimento de Requisitos (DRE) Scrum

Abrev. Resultados Classificação Resumo das Práticas

MAP 6 DRE 1

As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas

SATISFEITO

Elaboração do Backlog do Produto,

Reunião de Planejamento da Versão para Entrega e

Reunião de Planejamento da Sprint

MAP 7 DRE 2

Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas

SATISFEITO

Backlog do Produto, Backlog do Produto para

a Versão e Backlog da Sprint

MAP 8 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

SATISFEITO Reunião de

Planejamento da Sprint

MAP 9 DRE 4

Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados

SATISFEITO Backlog da Sprint

MAP 10 DRE 5

Interfaces internas e externas do produto e de cada componente do produto são definidas

PARCIALMENTE SATISFEITO

Backlog do Produto, Backlog do Produto para

a Versão e Backlog da Sprint

MAP 11 DRE 6 Conceitos operacionais e cenários são desenvolvidos

PARCIALMENTE SATISFEITO

Reuniões de Planejamento da Versão para Entrega e da Sprint

MAP 12 DRE 7

Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as

SATISFEITO Reuniões de

Planejamento da Versão para Entrega e da Sprint

49

restrições existentes

MAP 13 DRE 8 Os requisitos são validados SATISFEITO Conceito de

“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

analisados, no entanto, alguns resultados não podem ser atendidos

tabela 7 e no gráfico 2.

Critérios

Satisfeito

Parcialmente satisfeito

Não satisfeito

Fonte: Autor.

Fonte: Autor.

Ao observar os resultados, percebe

ou que carecem de atenção por parte da 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

analisados, no entanto, alguns resultados não podem ser atendidos, conforme apresentado na

Tabela 7 – Resultado da avaliação

GRE DRE

80% 75%

atisfeito 0% 25%

20% 0%

Gráfico 2 – Resultado da avaliação

Ao observar os resultados, percebe-se que há, no Scrum, algumas atividades ausentes

ou que carecem de atenção por parte da organização, para que este esteja totalmente alinhado

este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a


52

conforme apresentado na

algumas atividades ausentes

totalmente alinhado

este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a


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 processos como um todo, o que gera resistências na adequação ao modelo;

Scrum possui um fluxo simples, de fácil compreensão; O ScrumMaster tem a responsabilidade em fazer com que todos os envolvidos compreendam o fluxo de desenvolvimento e o emprego dos princípios e valores ágeis, o que traz para todos os envolvidos um maior conhecimento do processo de desenvolvimento como um todo;

Membros do projeto não compreendem os motivos da necessidade de confecção de artefatos que evidenciam os resultados esperados;

Mudanças necessárias ao projeto são descartadas devido a etapas burocráticas;

Mudanças são abraçadas por equipes ágeis; As metodologias ágeis formam frameworks que permitem que as mudanças sejam avaliadas e incorporadas com facilidade; Scrum permite a formação de equipes confortáveis às mudanças;

Mudanças necessárias ao projeto somente são incorporadas ao processo após o término do projeto;

Métodos ágeis prevêem que as mudanças devem ocorrer dentro do próprio projeto de 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;

Foco nos processos e não nas pessoas;

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 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;

Faltam referências quanto a design, codificação, ferramentas, testes automatizados, etc.

Na implementação dos processos iniciais do MPS o enfoque inicial é do ponto de vista da organização 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 processos, a equipe terá como referência os valores e princípios ágeis, que incorporam estas questões dentro do ciclo de desenvolvimento ágil;

Faltam referências quanto ao gerenciamento de riscos.

Obrigação de gerar documentos sem explicar detalhes de como fazê-los.

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 utilizados para evidenciar os resultados esperados 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

Envolvimento interessados inapropriados na elicitação dos requisitos;

O levantamento dos requisitos é responsabilidade do Product Owner, cabendo a ele focar quem são os stakeholders;

Problemas políticos na organização, resultando em reestruturação de papéis e a mudança de visão do negócio, com impacto na mudança de escopo;

No caso de mudanças, como a troca do responsável pelo Backlog do Produto, Scrum permite que, através de iterações curtas e incrementais, a equipe 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;

Detalhamento técnico desnecessário durante a especificação funcional do sistema;

Um dos princípios das Metodologias ágeis é a simplicidade, que pode colaborar para evitar informações desnecessárias nas especificações;

Complexidade no detalhamento dos casos de uso para definição da solução;

Metodologias ágeis introduzem as estórias de usuário (user stories), que são descrições textuais sucintas sobre as funcionalidades do sistema, escritas pela equipe técnica em conjunto com o cliente. Isso intensifica o envolvimento com o cliente, gera requisitos menos complexos, não deixando de serem informativos a respeito do requisito a ser desenvolvido.

Dificuldades para validação de casos de uso por parte do usuário;

Falta de conhecimento dos analistas de requisitos em um domínio específico do problema.

Alteração constante dos requisitos, causando retrabalho;

Apesar de Scrum abraçar mudanças, após o Time Scrum selecionar quais itens do Backlog do Produto farão parte da Sprint, estes itens não 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 que é uma inverdade. Scrum defende que se deve ter a documentação suficiente para o entendimento de todos os envolvidos, ao invés de uma documentação gigantesca que toma grande tempo para a confecção e desestimula os usuários do produto a lerem;

Neste caso, MPS.BR pode fazer com que equipes ágeis tenham documentos mais abrangentes do que talvez teriam caso não tivessem a necessidade de evidenciar os resultados esperados;

O suporte a equipes distribuídas por acarretar vários problemas que inexistem quando os integrantes da equipe de desenvolvimento e do cliente se encontram próximos;

O uso de uma documentação formal pode ser necessário; MPS pode contribuir por formalizar processos e por ter documentações mais 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;

Rastreabilidade bidirecional dos requisitos;

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 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 mais prioridade que as decisões da organização. Isso resulta na falta de definição de um padrão de processo;

Através de processos bem elaborados e documentados, Times Scrum podem ter uma base para tomar as suas decisões;

O time de desenvolvimento não segue todos os preceitos da prática Scrum;

Em uma organização que será avaliada em MPS, os processos estabelecidos precisam ser seguidos, logo, se os preceitos do Scrum estiverem 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.


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


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

Descrição: Medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente


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

Descrição: Medida do quanto o processo padrão é mantido para apoiar a implementação do processo definido


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.


71

ANEXO G – ATRIBUTOS DE PROCESSO - AP 3.2

Atributo de Processo (AP) AP 3.2 - O processo está implementado

Descrição: Medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados


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.


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

Technology

Transcript of TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO...