Embed Size (px)
Citation preview
Faculdade de Informática e Administração Paulista – FIAP
Curso de Gestão da Qualidade com ênfase em CMMI e MPS. Br
A utilização das práticas do SCRUM para implantação das áreas de REQM e RD do CMMI
Paulo Victor Gama Gross de Souza
Orientador: Ivanir Costa
São Paulo 2009
Prof. Gutenberg de Araújo Silveira Diretor Acadêmico da Pós Gradiação da Faculdade de Informática e Administração
Paulista
Prof. Nilson Salvetti Coordenador do MBA em Gestão da Qualidade em Software com ênfase em CMMI®
e MPS.BR
Prof. Ivanir Costa Orientado do Trabalho de Conclusão de Curso
3
Paulo Victor Gama Gross de Souza
A utilização das práticas do SCRUM para implantação das
áreas de REQM e RD do CMMI
Trabalho de Conclusão de Curso apresentado como requisito à obtenção do grau de pós graduação Lato Sensu, pelo curso de Gestão da Qualidade com ênfase em CMMI e MPS. Br pela Faculdade de Informática e Administração Paulista - FIAP. Orientador: Prof. Dr. Ivanir Costa.
São Paulo 2009
Trabalho de Conclusão de Curso aprovado no Curso de Gestão da Qualidade em Software com ênfase em CMMI® da Faculdade de Informática e Administração Paulista, por:
Prof. Dr. Ivanir Costa
Prof. Ms. Nilson Salvetti
Gross de Souza, Paulo Victor Gama A utilização das práticas do SCRUM para implantação das áreas de REQM e RD do CMMI / Paulo Victor Gama Gross de Souza – São Paulo, 2009. 56 f.
Monografia (Pós Graduação) – Faculdade de Informática e Administração Paulista, 2009 Bibliografia.
1. Processos de Software 2. Engenharia de Requisitos 3. Qualidade de Software I. Faculdade de Informática e Administração Paulista. Curso de Gestão da Qualidade com ênfase em CMMI® e MPS.BR II. A utilização das práticas do SCRUM para implantação das áreas de REQM e RD do CMMI
CDD–
AGRADECIMENTOS
Aos familiares e amigos pelo incentivo e confiança.
Aos colegas de classe pelas críticas e sugestões.
A FIAP pela infra-estrutura de ponta oferecida aos alunos.
"Uma das principais características do ser humano é a curiosidade, a necessidade de descobrir os segredos da natureza. Para alcançar esse objetivo, nem sempre a simples observação é suficiente. Por isso, há séculos o homem vem criando experimentos que simulam os fenômenos naturais. A interpretação lógica e criativa dos resultados desses experimentos tem sido um dos pilares do conhecimento científico" (Usberco & Salvador, 1996).
RESUMO
Com a globalização e terceirização de diversos serviços do mundo atual, as empresas cada vez mais estão criando parcerias com fornecedores e em especial as empresas que utilizam dos serviços de desenvolvimento de sistemas de software.
Para apoiar essas questões com qualidade e produtividade, existem diversos modelos no mercado, como o CMMI, por exemplo, que foi criado com o intuito de categorizar as empresas em níveis de maturidade na capacidade de desenvolvimento de software
Com isso, para as consultorias se destacarem e terem um diferencial competitivo necessitam dos níveis de maturidade para comprovar sua eficácia e qualidade em especial quanto ao entendimento dos desejos do cliente e como expressar esses desejos em requisitos.
A falta de eficácia nesse entendimento causa erros que segundo estudos chegam a ser de 50% a 70% dos erros totais do desenvolvimento de software. Este trabalho propõe o uso de uma metodologia ágil dada à necessidade de entregas cada vez mais rápidas e processos cada vez mais dinâmicos aderindo às duas áreas de requisitos do CMMI, a Gerência de Requisitos, conhecida como Requirements Management (REQM) e Desenvolvimento de Requisitos conhecida como Requirements Development (RD).
A metodologia ágil estudada será o Scrum, dada sua flexibilidade e compatibilidade, além da preocupação com documentação o que pode não ser tão evidente em outras metodologias ágeis.
Palavras-Chaves: Scrum, REQM, RD, CMMI, Software, ágil, qualidade.
ABSTRACT
With globalization and outsourcing of various services in the world today, companies increasingly are creating partnerships with suppliers and in particular companies that use the services of developing software systems.
To support these issues with quality and productivity, there are several models on the market, such as CMMI, for example, which was created in order to categorize the companies in levels of maturity in the ability of software development
With this, the consultancy is to deploy and have a competitive need for the level of maturity to prove their efficiency and quality in particular about the understanding of the wishes of the client and how to express these wishes in requirements.
The lacks of effectiveness in understanding cause errors that are up to the second study of 50% to 70% of total errors of software development. This paper proposes the use of an agile methodology given the need for deliveries ever faster and more dynamic processes adhering to the two areas of the CMMI requirements, the Requirements Management, known as REQM and the Development of requirements known RD.
The methodology will be the Scrum agile studied, given its flexibility and compatibility, in addition to concern about the documentation that may not be so evident in other agile methodologies.
Keywords: Scrum, REQM, RD, CMMI, Software, agile, quality.
SUMÁRIO
RESUMO
ABSTRACT
LISTA DE FIGURAS
LISTA DE TABELAS
1 INTRODUÇÃO 11
1.1 DELIMITAÇÃO DO TEMA 12
1.2 OBJETIVO 12
1.3 JUSTIFICATIVA 12
1.4 METODOLOGIA DE TRABALHO 13
2 REVISÃO BIBLIOGRÁFICA 15
2.1 PROCESSOS DE SOFTWARE 15
2.2 ENGENHARIA DE REQUISITOS 19
2.3 A METODOLOGIA SCRUM 22
2.4 QUALIDADE DE SOFTWARE 30
2.4.1 TESTE DE SOFTWARE 31
2.5 O MODELO DE QUALIDADE CMMI 32
2.5.1 REQM 35
2.5.2 RD 38
3 O USO DAS PRÁTICAS DO SCRUM NO MODELO CMMI 44
3.1 ANÁLISE DA ADERÊNCIA SCRUM X CMMI 44
3.2 RESULTADOS FINAIS DA ANÁLISE REALIZADA NAS ÁREAS DE PROCESSO REQM E RD 50
4 CONSIDERAÇÕES FINAIS 51
GLOSSÁRIO 53
LISTA DE FIGURAS
FIGURA 1: ESTRUTURA DA NORMA ISO/IEC 12207 18
FIGURA 2: VISÃO GERAL DO PROCESSO SCRUM 24
FIGURA 3: QUADRO DAILY SCRUM 26
FIGURA 4: CARTAS DE PLANNING POKER 27
FIGURA 5: BURNDOWN CHARTER 28
FIGURA 6: ESCALA DE CLASSIFICAÇÃO DA ADERÊNCIA DO SCRUM EM RELAÇÃO ÀS PRÁTICAS ESPECÍFICAS DA ÁREA DE REQM DO CMMI 50
FIGURA 7: ESCALA DE CLASSIFICAÇÃO DA ADERÊNCIA DO SCRUM EM RELAÇÃO ÀS PRÁTICAS ESPECÍFICAS DA ÁREA DE RD DO CMMI 50
LISTA DE TABELAS
TABELA 1: ESTRATÉGIAS DE PESQUISA 13
TABELA 2: ADERÊNCIA DO MODELO SCRUM ÀS PRÁTICAS ESPECÍFICAS DO REQM 46
TABELA 3: ADERÊNCIA DO MODELO SCRUM ÀS PRÁTICAS ESPECÍFICAS DO RD 49
TABELA 4: SOLUÇÃO ÀS PRÁTICAS DO CMMI NÃO ATENDIDAS PELA METODOLOGIA SCRUM 52
1 INTRODUÇÃO
Com a globalização e terceirização de diversos serviços do mundo atual, as
empresas cada vez mais estão criando parcerias com fornecedores e em especial as
empresas que utilizam dos serviços de desenvolvimento e Tecnologia da Informação
(TI), cada vez mais com consultorias especializadas.
Para ajudar nessas questões, existem diversos modelos no mercado, como o
Capability Maturity Model Integration (CMMI), por exemplo, que foi criado a partir de
uma parceria do Department Of Defense (DOD) com a universidade Carnegie
Mellon, justamente com o intuito de criar boas práticas e padrões que definissem
processos para melhoria da qualidade no desenvolvimento de software como um
todo. Esse processo foi categorizado em níveis de maturidade que uma unidade ou
área da empresa poderá ter.
Dado esse cenário, esta pesquisa propõe a aplicação das práticas inerentes a
requisitos da metodologia ágil Scrum para implantação de duas áreas de
conhecimento do CMMI, a de gerência de requisitos (REQM) e desenvolvimento de
requisitos (RD) do Capability Maturity Model (CMMI). Os métodos ágeis visam
aumentar a interação entre cliente e equipe de desenvolvimento de softwares, de
forma a antecipar possíveis problemas no decorrer do projeto.
Segundo Manifesto (2008), o manifesto ágil foi apresentado em 2001 em Utah por
Kent Beck e outros 16 conhecedores da área de software com a seguinte proposta:
• Indivíduos e interações sobre processos e ferramentas;
• Software funcionando sobre documentação detalhada;
• Colaboração do cliente sobre negociação de contrato;
• Responder a mudanças sobre seguir um plano.
Com isso, a idéia de unir a metodologia Scrum ao modelo CMMI visa melhorar a
comunicação entre cliente e equipe de desenvolvimento de software e com isso
antecipar defeitos que de acordo com Myers (1979) ficam mais caros numa escala
de 10X a cada fase do processo de desenvolvimento em que o mesmo é corrigido.
12
Essa proposta será embasada através de pesquisas bibliográficas em livros, artigos
e publicações dos autores do CMMI e Scrum.
1.1 Delimitação do tema
Para abordar os benefícios trazidos pela junção de práticas do Scrum às áreas de
REQM e RD do CMMI, a presente pesquisa se organizou em torno de seis capítulos.
O primeiro capítulo trata do processo de software, abordando a estrutura de software
e alguns modelos existentes, o capítulo 2, trata da área de engenharia de requisitos.
O capítulo 3 fala sobre a metodologia Scrum. Após isto, são apresentados os
capítulos de qualidade de software, contendo uma breve descrição sobre testes de
software e o modelo CMMI falando sobre REQM e RD. O último capítulo explana
sobre como as práticas do Scrum podem auxiliar uma empresa que busca aderir às
áreas de conhecimento do CMMI citadas acima.
1.2 Objetivo
O objetivo deste trabalho é mostrar como as práticas do Scrum podem se encaixar
no framework de duas áreas de processo do CMMI.
Essa pesquisa bibliográfica pretende:
Analisar as práticas do Scrum e mostrar como adaptar essas práticas para aderir ao
CMMI nas áreas de REQM e RD.
1.3 Justificativa
Os estudos das práticas oriundas dos modelos ágeis em projetos de software
justificam-se pela crescente demanda da sociedade contemporânea pela informação
que tem agravado uma série de problemas relacionados ao processo de
desenvolvimento de software.
A proposta do trabalho é mostrar como essas práticas ágeis do Scrum podem ajudar
a suprimir problemas enfrentados pela área de engenharia de requisitos e com isso
13
como essa junção pode beneficiar a implantação de duas áreas de processo do
CMMI.
1.4 Metodologia de Trabalho
Dentre os vários tipos de pesquisa optou-se neste trabalho, pela exploratória
descritiva, pesquisa bibliográfica.
Segundo Yin (2005, p.23), são três as condições para determinar uma pesquisa, (a)
o tipo de questão da pesquisa proposta, (b) a extensão de controle que o
pesquisador tem sobre eventos comportamentais atuais e (c) o grau de enfoque em
acontecimentos contemporâneos em oposição a acontecimentos históricos.
Estas se inter-relacionam com as cinco principais estratégias de pesquisa utilizadas
nas ciências sociais: experimentos, levantamentos, análise de arquivos, pesquisas
históricas e estudo de caso. O quadro 1 mostra estas estratégias.
Tabela 1: Estratégias de pesquisa
FONTE: YIN (2005, p.24)
Sendo propostas questões do tipo “qual” no trabalho, excluem-se as estratégias de
‘experimento’, ‘pesquisa histórica’ e ‘estudo de caso’, restando ‘levantamento’ e
‘análise de arquivos’. As propostas restantes são as que mais se enquadram no tipo
de pesquisa adotado, a exploratória descritiva.
14
Dessa forma, nossos objetos de estudo serão livros sobre Scrum, publicados pelo
autor da metodologia, Ken Schwaber e trabalhos publicados contrastando com uma
visão contemporânea no que tange a coerência com o modelo CMMI; o CMMI-dev,
artigos sobre CMMI e outros artigos acadêmicos e normas como IEEE e ISO/IEC.
15
2 REVISÃO BIBLIOGRÁFICA
2.1 Processos de Software
Antes da explanação sobre processos de software é importante salientar e expor os
termos software e Engenharia de Software.
Segundo Sommerville (2003, p.5), software consiste de uma série de arquivos
separados, arquivos de configuração e toda uma documentação que explica como o
sistema funciona, ou seja, muito mais do que linhas de código sem contexto; e
Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os
aspectos da produção respectivamente, desde estágios iniciais de especificação do
sistema até sua manutenção pós-implantação.
Segundo Pressman (2006, p.4), software são instruções que quando executadas
fornecem as características, função e desempenho desejados.
Segundo a ABNT (1997) em sua norma ISO/IEC 12207, software é uma parte
fundamental da tecnologia de informação. Essa norma estabelece as seguintes
estruturas:
• Estrutura comum e fundamental para os processos de ciclo de vida de
software:
� Processo de Aquisição: inicia-se com a definição da necessidade de
adquirir um sistema, um produto de software ou um serviço de software;
� Processo de Fornecimento: este processo pode ser iniciado tanto por uma
decisão de preparar uma proposta para responder a um pedido de
proposta de um adquirente quanto pela assinatura e celebração de um
contrato com o adquirente para fornecer o sistema;
� Processo de Desenvolvimento: este processo contém as atividades para
análise de requisitos, projeto, codificação, integração, testes, e instalação
e aceitação relacionada aos produtos de software;
� Processo de Operação: este processo cobre a operação do produto de
software e o suporte operacional aos usuários;
16
� Processo de Manutenção: este processo é ativado quando o produto de
software é submetido a modificações no código e na documentação
associada devido a um problema, ou à necessidade de melhoria ou
adaptação.
• Estrutura de apoio:
� Processo de Documentação: o processo de documentação é um processo
para registrar informações produzidas por um processo ou atividade do
ciclo de vida;
� Processo de Gerência de Configuração: o processo de gerência de
Configuração é um processo de aplicação de procedimentos
administrativos e técnicos, por todo o ciclo de vida de software, destinado
a identificar e definir os itens de software em um sistema, e estabelecer
suas linhas básicas; controlar as modificações e liberações dos itens;
registrar e apresentar a situação dos itens e dos pedidos de modificação;
garantir a completeza, a consistência e a correção dos itens e controlar o
armazenamento, a manipulação e a distribuição dos itens;
� Processo de Garantia da Qualidade: as atividades adicionais de gerência
da qualidade devem ser garantidas de acordo com as cláusulas da NBR
ISO 90011;
� Processo de Verificação: verificação é um processo para determinar se os
produtos de software de uma atividade atendem completamente os
requisitos ou condições impostas a eles nas atividades anteriores;
� Processo de Validação: validação é um processo para determinar se os
requisitos e o produto final, sistema ou produto de software construído,
atendem ao uso específico pretendido;
� Processo de Revisão Conjunta: revisão conjunta é um processo para
avaliar a situação e produtos de uma atividade de um projeto, se
apropriado;
1 A expressão ISO 9000 designa um grupo de normas técnicas que estabelecem um modelo de gestão da qualidade para organizações em geral, qualquer que seja o seu tipo ou dimensão. A sigla "ISO" refere-se à International Organization for Standardization, organização não-governamental fundada em 1947, em Genebra e hoje presente em cerca de 157 países. A ISO 9001 tem a garantia da qualidade como base da certificação.
17
� Processo de Auditoria: auditoria é um processo para determinar
adequação aos requisitos, planos e contrato, quando apropriado;
� Processo de Resolução de Problema: quando problemas forem
detectados num produto de software ou numa atividade, um relatório de
problema deve ser preparado para descrever cada problema detectado.
• Estrutura Organizacional:
� Processo de Gerência: o processo de Gerência contém as atividades e
tarefas genéricas que podem ser empregadas por quaisquer das partes
que tem que gerenciar seus respectivos processos;
� Processo de Infra-estrutura: é um processo para estabelecer e manter a
infra-estrutura necessária para qualquer outro processo. A infra-estrutura
pode incluir hardware, software, ferramentas, técnicas, padrões e recursos
para o desenvolvimento, operação ou manutenção;
� Processo de Melhoria: melhoria é um processo para estabelecer, avaliar,
medir, controlar e melhorar um processo de ciclo de vida de software;
� Processo de Treinamento: a aquisição, o fornecimento, o
desenvolvimento, a operação ou a manutenção de produtos de software é
extremamente dependente de pessoal com conhecimento e qualificação.
18
A figura 1 ilustra a estrutura completa da norma.
Figura 1: Estrutura da norma ISO/IEC 12207
Fonte: Norma ABNT ISO/IEC 12207
Sommerville (2003, p.36) cita algumas atividades e modelos fundamentais para o
processo de desenvolvimento de software:
• Atividades:
� Especificação de Software: atividade de definir a funcionalidade do
sistema tais como suas restrições;
� Projeto e Implementação de Software: trata-se da produção do sistema de
modo a cumprir as especificações;
� Validação de Software: é a garantia de que o que foi construído atende o
que o cliente deseja;
� Evolução de Software: é a mutação do produto para atender às
necessidades do cliente.
19
• Modelos:
� Modelo Cascata (waterfall): considera as atividades fundamentais citadas
acima e as representa como fases separadas do processo;
� Modelo Evolucionário: essa abordagem intercala as atividades de
especificação, desenvolvimento e validação;
� Modelo Formal: essa abordagem baseia-se na produção de uma
especificação formal matemática do sistema e na transformação dessa
especificação, utilizando métodos matemáticos, para construir um
programa;
� Modelo Orientado a Reuso: essa abordagem tem como base a existência
de um número significativo de componentes reutilizáveis. O processo de
desenvolvimento de sistemas se concentra na integração desses
componentes em um sistema, em vez de proceder ao desenvolvimento a
partir do zero.
Dessa forma pode-e dizer que a proposta deste trabalho atende aos processos de
desenvolvimento, documentação e verificação da norma ISO/IEC12207 e a atividade
de especificação de software citada por Sommerville (2003).
2.2 Engenharia de Requisitos
Abordando a atividade de especificação dentro do contexto de fases de um software
e ao processo de desenvolvimento dentro do ciclo de vida do mesmo, entra-se na
área de engenharia de requisitos, o pilar principal do tema REQM e RD que será
abordado dentro do tema qualidade.
Segundo Sommerville (2003, p.103), a engenharia de requisitos é um processo que
envolve todas as atividades exigidas para criar e manter o documento de requisitos
do sistema.
Sommerville (2003, p.103) cita quatro atividades genéricas como sendo atividades
centrais da engenharia de requisitos, sendo elas: estudo de viabilidade, obtenção e
análise de requisitos, especificação de requisitos e validação de requisitos.
20
O SEI (2006) propõe em seu framework as seguintes atividades como práticas da
área de gerência de requisitos: obter uma compreensão dos requisitos, obter
comprometimento em relação aos requisitos, gerenciar mudanças dos requisitos,
manter a rastreabilidade bidirecional dos requisitos e identificar inconsistências entre
os produtos de trabalho e os requisitos.
Requisito pode ser definido como uma condição ou capacidade necessária para um
usuário resolver um problema ou alcançar um objetivo, IEEE-830 (1998). A norma
descreve um documento para cobrir as atividades, denominado Software
Requirement Specification (SRS) que deve conter como pontos base:
• Funcionalidade: o que deve fazer o software?
• Interfaces externas: como interage o software com as pessoas, com o
hardware do sistema, com outro hardware e com outro software?
• Desempenho: qual é a velocidade, disponibilidade, tempo de resposta, tempo
de recuperação das várias funções do software dentre outros?
• Atributos: quais as considerações relativas à portabilidade, correção,
manutenibilidade, segurança dentre outros?
• Restrições de desenho impostas numa implementação: existem exigências
padrão, linguagem de implementação, políticas para integridade da base de
dados, limites de recursos, ambientes operacionais, dentre outros?
Segundo a norma IEEE-830 (1998), como o documento de SRS tem um papel
específico no processo de desenvolvimento de software, quem escreve o documento
de SRS deve ter cuidado para não passar os limites desse papel. Isto quer dizer que
o documento de SRS deve definir corretamente todas as exigências do software.
Uma exigência do software segundo IEEE-830 (1998) pode existir devido à natureza
da tarefa a ser resolvida ou devido a uma característica particular do projeto. O
documento de SRS não deve descrever nenhum detalhe de desenho ou
implementação. Estes devem ser descritos na fase de design do projeto.
O documento de SRS não deve impor restrições adicionais ao software. Estas estão
devidamente especificadas em outros documentos tais como o plano de garantia de
qualidade do software, por exemplo.
21
Além do que, segundo a norma IEEE-830 (1998), um documento de SRS deve ser:
• Correto: se e só se, todas as exigências expressas nele serão correspondidas
pelo software;
• Não ambíguo: se e só se todas as exigências expressas nele têm apenas
uma única interpretação. Como mínimo isto requer que cada característica do
produto final seja descrita usando termos simples e únicos;
• Completo: se, e só se, inclui os seguintes elementos: toda a exigência
significante como desempenho, restrições de design, atributos, ou interfaces
externas estão reconhecidas e tratadas, estão definidas as respostas do
software a todas as classes realizáveis de entradas de dados em todas as
classes de situações, legendas e referências completas para todas as figuras,
tabelas e diagramas do documento;
• Consistente: se, e só se, nenhum subconjunto individual de exigências
descrito nele entra em conflito;
• Classificável por importância e/ou estabilidade: se cada exigência nele contido
tem associado um identificador de estabilidade e/ou importância. Algumas
exigências podem ser essenciais, especialmente para aplicações críticas,
enquanto que outras podem ser apenas desejáveis;
• Verificável: se cada exigência especificada é verificável. Uma exigência é
verificável, se e só se, existe um processo finito e de custo aceitável através
do qual uma pessoa ou uma máquina pode verificar que o produto de
software cumpre essa exigência. Em geral uma exigência ambígua não é
verificável;
• Modificável: se a sua estrutura e estilo são tais que mudanças a exigências
podem ser efetuadas de forma fácil, completa e consistente, preservando
simultaneamente estrutura e estilo;
• Rastreável: se cada uma das suas exigências é clara e facilitadora da
identificação da mesma exigência em versões futuras do desenvolvimento ou
da documentação.
Para atender aos requisitos salientados pela norma IEEE-830 (1998) ao explanar
sobre o documento de SRS é necessária muitas vezes uma cultura ou método de
trabalho definido e seguido durante o ciclo de desenvolvimento. Para aderir às
22
práticas propostas pelo CMMI para implantar as áreas de processo de REQM e RD,
este trabalho propõe utilizar práticas da metodologia ágil Scrum, que será exposta
no tópico abaixo.
2.3 A metodologia Scrum
O modelo Scrum é uma metodologia ágil, assim como Extreme Programming (XP) e
visa um desenvolvimento mais enxuto utilizando equipes pequenas e
autogerenciáveis; que segundo Pressman (2006) apud Cockburn (2002) argumenta
como sendo uma das deficiências dos modelos prescritivos o fato de se esquecer
das fragilidades das pessoas, dado que os engenheiros não são robôs, ou seja,
exibem grande variedade de estilos de trabalho.
Pressman (2006) apud Jacobson (2002) complementa dizendo que uma equipe ágil
reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e
que as especialidades dessas pessoas e sua capacidade de colaborar estão no
âmago do sucesso do projeto.
O Scrum surgiu da indústria de automóvel e produtos de consumo, por Takeuchi e
Nonaka. Segundo Wikipédia (2008), os autores notaram que projetos usando
equipes pequenas e multidisciplinares produziam os melhores resultados; e
associaram estas equipes altamente eficazes à formação do Scrum no Rugby.
De acordo com as regras do Rugby, o Scrum é usado para reiniciar o jogo após
alguns casos de paralisação como faltas ou impedimentos acidentais, dentre outros.
Só oito jogadores de cada time podem participar. Eles são, quase sempre, os oito
atacantes da equipe (Guia do Rugby, 2008).
Wikipédia (2008) diz que Jeff Sutherland, John Scumniotales e Jeff McKenna
documentaram, conceberam e implementaram o Scrum na empresa Easel
Corporation em 1993, incorporando estilos de gerenciamento observados por
Takeuchi e Nonaka e em 1995, Ken Schwaber formalizou a definição de Scrum e
ajudou a implantá-lo em desenvolvimento de software, disseminando-o em todo o
mundo, dada a necessidade de desenvolvimentos mais ágeis em que o cliente
pudesse avaliar a evolução do trabalho e não o todo no final.
23
Schwaber (2002. p.1) diz que o Scrum é um termo que segundo Takeuchi e Nonaka
descreve um tipo de processo para desenvolvimento de produtos, inicialmente
utilizados no Japão; e primeiramente em larga escala em 1987.
A metodologia nasceu oficialmente ao ser implantada na empresa Easel em 1995
dando continuidade em 1996, após aquisição pela VMARK (SCHWABER, 2002,
p.11).
Em 2000, Ken Schwaber implantou a metodologia na empresa Patient Keeper e nos
anos seguintes lançou três livros, sendo o primeiro deles, o Agile Software
Development with Scrum, juntamente com Mike Beedle, em 2002.
Segundo Martins (2007, p.253), o Scrum é uma metodologia ágil que segue a
filosofia iterativa e incremental. Martins afirma que o Scrum se concentra no que é
realmente importante, gerenciar o projeto e criar um produto que acrescente valor
para o negócio.
Segundo Martins (2007), uma característica importante do Scrum é ser flexível e
adaptável diferente de métodos e técnicas de gerenciamento de projetos mais
prescritivos, como o PMBOK que, por exemplo, força as pessoas a seguirem uma
seqüência de passos predefinida, com pouca flexibilidade para mudança.
De acordo Sommerville (2003), os projetos de construção de softwares seguem um
ciclo envolvendo captura de requisitos, design, desenvolvimento, testes e
implantação, com cada estágio sendo completado antes que o próximo seja iniciado,
caracterizando-se no modelo cascata.
A abordagem do Scrum visa o oposto ao modelo em cascata, iniciando-se na
análise, assim que alguns requisitos estiverem disponíveis.
Martins (2007, p.253) diz que o projeto Scrum começa com uma visão, composta por
requisitos e funcionalidades que concretizam uma lista de tarefas, denominada
product backlog de produto.
As prioridades dos itens desse documento determinam o quanto de valor cada item
gera para o negócio. Depois de priorizados os itens, antes de cada iteração,
24
chamada de sprint, a equipe se reúne para dizer quantos itens é possível entregar
em um sprint, que segundo Schwaber deve durar cerca de 30 dias, como boa
prática.
Figura 2: Visão Geral do Processo Scrum
Fonte: Agile Project Management with Scrum (2004)
Ao final da iteração, conforme ilustra a figura 2, o que foi desenvolvido é
apresentado ao cliente em uma reunião e antes do início da próxima iteração é feita
uma reunião de retrospectiva, onde é possível extrair lições aprendidas.
Papéis do Scrum segundo Schwaber e Beedle (2002, cap.3):
• Product Owner: pode ser definido como o sponsor do projeto, é o responsável
por definir e priorizar as funcionalidades do produto. Segundo Martins (2007,
p.255) o dono do produto provavelmente será um gerente de projeto, ou um
patrocinador do projeto, um membro da equipe de marketing ou um cliente
interno;
• Scrum Master: é o responsável por forçar os valores e práticas do Scrum,
remover os obstáculos e ensinar o processo a todas as pessoas, garantindo
também que todas elas sigam o processo. O Scrum Master é um líder e tem
como papel remover barreiras, melhorar o relacionamento entre a equipe e
25
manter as informações sobre o progresso da equipe e do projeto sempre
atualizado. O mestre do Scrum segundo Martins (2007, p.255) ocupa uma
posição similar à ocupada pelo gerente de projeto;
• Scrum Team: equipe responsável por desenvolver o produto, esse time está
ligado diretamente ao trabalho e suas características são: ser multifuncional,
ser composta por grupos pequenos, de 7 a 10 pessoas, ser auto-organizável
e definir o que será feito dentro do sprint.
Fases do Scrum segundo Schwaber e Beedle (2002, cap.3):
• Sprint Planning: é uma reunião com duração de 4 horas antes do início de um
sprint, para alinhar com o Product Owner o que será feito dentro do próximo
sprint;
• Sprint: é o tempo estimado pelo time para produzir, testar e homologar
determinadas funcionalidades, que serão priorizadas pelo product owner no
Sprint Planning2. De acordo com as práticas adotadas por Schwaber, um
sprint deve durar 30 dias;
• Daily Scrum: são reuniões diárias, com duração de 15 minutos, onde cada
membro do time coloca em um quadro o que fez no dia anterior, o que fará
para o dia seguinte e as barreiras, que terão de ser desimpedidas pelo Scrum
Master. Essas tarefas devem ser colocadas em um quadro que fique visível
para o time, em forma de post its, como mostra a figura 3;
2 Para o próximo sprint começar, o sprint anterior tem de estar finalizado e aprovado pelo product owner em uma reunião de
validação citada por Zanatta (2004) como Post Sprint Demonstration and Meeting.
26
Figura 3: Quadro Daily Scrum
Fonte: Entendendo Scrum para Gerenciar Projetos de Forma Ágil (2007)
• Retrospective ou Sprint Review: é uma reunião de lições aprendidas que
ocorre após a entrega de um sprint e tem como objetivo analisar se o que foi
feito está bom e o que pode ser melhorado.
Para definição do que será entregue ao final de um sprint, é de responsabilidade do
time estimar quantas funcionalidades poderá entregar testadas e prontas para uso
no prazo de 30 dias.
Scrum Alliance (2008) propõe listar os casos de teste e efetuar uma análise de custo
e riscos entre efetuar testes automatizados e manuais e com isso definir um ponto
de equilíbrio entre os testes. “Um projeto utilizando Scrum fica mais difícil de ser
desenvolvido sem o uso de automação”. (SCRUM ALLIANCE, 2008).
Para estimar o número de funcionalidades por sprint, Schwaber propõe um método
chamado poker game, onde cada membro do time dá uma nota, que equivale a um
peso.
27
Os pesos são denominados de acordo com uma Progressão Aritmética, ou seja, 1,
2, 3, 5, 8, 13 e 21, como ilustra a figura 4.
Figura 4: Cartas de Planning Poker
Fonte: Entendendo Scrum para Gerenciar Projetos de Forma Ágil (2007)
O peso que se repetir mais vezes pelos membros do time é o peso que valerá para a
funcionalidade. Ao total de funcionalidades, os pesos são somados e essa é a
estimativa de entrega em um sprint.
O primeiro sprint, de acordo com Schwaber é destinado à definição da arquitetura do
sistema e é o ciclo que baliza a velocidade do time. Caso o time estime quatro
funcionalidades em 40 pontos e entregue no prazo de 30 dias, essa será a
velocidade de entrega do time, ou seja, seu time-box; de forma que no poker game
dos próximos sprints, o time poderá estimar para desenvolvimento o número de
funcionalidades que não ultrapasse 40 pontos.
De acordo com Martins (2007, p.261), cada sprint consiste de uma ou mais equipes
executando as seguintes atividades:
• Desenvolvimento, onde é definido o que precisa ser feito para implementar os
itens de backlog que o time prometeu entregar;
• Empacotamento do produto que implica na criação dos executáveis de
software;
28
• Revisão, onde todas as equipes se reúnem para apresentar e discutir o
trabalho feito, revisar o processo, analisar os pontos fortes e fracos e
adicionar novos itens de backlog;
• Ajustes, onde as informações obtidas na reunião de revisão são consolidadas
para que as mudanças sejam executadas e um planejamento de mudanças
ocorra.
Schwaber propõe também o controle de volume de trabalho pendente, chamado
também de burn down charter, onde após cada reunião diária é acrescido em um
gráfico o que foi feito em horas e o quanto falta para o término, no prazo de 30 dias,
como ilustra a figura 5.
Figura 5: Burndown Charter
Fonte: Entendendo Scrum para Gerenciar Projetos de Forma Ágil (2007)
Schwaber (2002. p.1) diz que o Scrum é baseado em um controle simples, porém
duro, onde requer disciplina (“Scrum is very simple but very hard”). Esse processo é
empírico e introduz flexibilidade, adaptabilidade e produtividade ao desenvolvimento
dos sistemas.
29
Schwaber (2002. p.20) em seu primeiro livro disserta sobre seu envolvimento em
projetos utilizando CMM e RUP, com práticas similares as da metodologia Scrum.
Ele disserta também sobre a importância do ambiente e de ferramentas para
viabilizar o desenvolvimento do sprint.
Schwaber (2002. p.65) diz que durante o primeiro sprint, o time gasta mais tempo
com a configuração do ambiente. Segundo ele, durante o segundo sprint o time já
tem definido ferramentas necessárias para ganho de agilidade no desenvolvimento.
A idéia é que a cada novo sprint o time fique mais alinhado e com o ambiente e
ferramentas cada vez mais bem definidas para execução do desenvolvimento de
forma que a velocidade do time tenda a aumentar a cada novo ciclo, dado o conceito
de lições aprendidas e melhoria contínua.
Isto feito, o papel do Scrum Master é fundamental como agente de mudanças e
desimpedimentos, dado que esse é o papel que vai viabilizar as mudanças e
melhorias definidas nas reuniões de lições aprendidas, as retrospectives meetings.
Para tal Schwaber (2007. p.6) diz que todos os dias o time estará exposto a
impedimentos e as seguintes mudanças tendem a ocorrer no primeiro ano de
implantação:
• Rotatividade do pessoal;
• O nono mês da mudança será particularmente difícil;
• Conflitos irão ocorrer;
• O produto de gestão do trabalho vai mudar e será mais difícil;
• A Engenharia será objetivada por qualidade;
• Políticas e procedimentos irão mudar;
• A forma de trabalho irá mudar.
Segundo Schwaber (2007. p.63), outro ponto do Scrum é sua implantação com
sistemas integrados, dado que muitos produtos são construídos com o conceito de
componentização, principalmente se tratando de sistemas web. Schwaber propõe
dois critérios, sendo eles o conhecimento do projeto e a incrementação sempre que
30
possível, de forma que ao final os componentes possam ser integrados em um sprint
de integração entre os componentes.
Schwaber (2007. p.66) explana também sobre a integração entre times utilizando
Scrum e times utilizando o método waterfall (cascata) em um mesmo projeto, onde
os entregáveis dos sprints de Scrum podem ser marcos no cronograma gerenciado
pelo método waterfall.
2.4 Qualidade de Software
Dado o cenário onde os clientes não sabem ao certo o que necessitam os
desenvolvedores de software normalmente encontram dificuldades ao especificar as
necessidades dos clientes, para transformá-las em linhas de código. Dessa forma é
papel fundamental do analista de requisitos ou do analista de negócios conseguir
extrair através de técnicas de levantamento, o maior número de informações
possíveis junto a seus stakeholders3. Porém não basta uma especificação bem feita,
o processo de desenvolvimento e o produto final tem de ter qualidade de fato, que
segundo Quality Assurance Institute (QAI, 2006) em seu modelo CBOK é dividida
em duas visões:
• Estar pronto para o uso, visão do cliente;
• Estar de acordo com os requisitos e fazer certo da primeira vez, visão da
fábrica de software.
Para isso, as empresas podem utilizar de modelos como V&V, ISO 9001, MPS.Br,
Six Sigma, CMMI que será abordados adiante, dentre outros, a fim de garantir a
qualidade dos produtos desenvolvidos, juntamente com testes.
A ISO 9001, assim como a ISO 15504, são as normas que mais se assemelham ao
modelo CMMI que será abordado no próximo capítulo. De acordo com Wikipédia
(2008), a ISO 9001 teve sua primeira norma em 1994 com a garantia da qualidade
como base da certificação. A norma possuía 20 requisitos. Em 2001 a nova versão
exigia o envolvimento da gestão para promover a integração da qualidade
3 Stakeholder: pode ser denominado como parte interessada ou interveniente, ou seja, todas as partes interessado-
envolvida em um processo/projeto.
31
internamente na própria organização, além da introdução da visão de foco no
cliente. Em 2008 foi lançada a nova versão, elaborada para apresentar maior
compatibilidade com a família da ISO 14000.
2.4.1 Teste de Software
Ainda dentro do conceito de Qualidade, o teste de software é o processo de
executar o software de uma maneira controlada com o objetivo de avaliar se o
mesmo se comporta conforme o especificado.
Segundo Sommerville (2003, p.377), a finalidade dos testes é expor defeitos latentes
em um sistema de software antes de o sistema ser entregue.
Todo teste de software visa atender a uma demanda; e o teste não é uma tarefa
trivial, pelo fato de que o software é complexo, intangível e altamente modificável.
Sendo assim o teste de software exige:
• Conhecimento;
• Planejamento;
• Projeto;
• Execução / Acompanhamento;
• Integração com outras áreas;
• Recursos como equipe, processo, treinamento, ferramenta, dentre outros.
Com isso, a norma IEEE-829 (1998) descreve um conjunto de oito documentos
básicos para as atividades de teste de software, cobrindo a preparação e registro
dos resultados do teste. A norma define o propósito, a estrutura e o conteúdo de
cada um dos documentos abaixo:
• Plano de Teste;
• Especificação de Projeto de Teste;
• Especificação de Casos de Teste;
• Especificação de Procedimento de Teste;
• Relatório de Encaminhamento de Item de Teste;
32
• Diário de Teste;
• Relatório de Incidentes de Teste;
• Relatório-Resumo de Teste.
Para aprofundar o tema, será utilizado o modelo de qualidade CMMI no âmbito da
área de requisitos para melhoria de qualidade na especificação de software,
utilizando como meio a metodologia Scrum.
2.5 O modelo de Qualidade CMMI
O CMMI é uma abordagem de melhores práticas e elementos essenciais de
processos eficazes. O CMMI é uma evolução do CMM lançado em 1991, tendo sua
versão 1.1 vigente de 1993 até 2005 quando foi descontinuado. Já o CMMI surgiu
em 2002 e teve um trecho de sua existência em paralelo com o CMM. Desde 2006
até os dias de hoje o CMMI encontra-se em sua versão 1.2.
O CMMI é dividido em 5 níveis de maturidade sendo elas inicial, gerenciado,
definido, gerenciado quantitativamente e otimizado.
Para cada nível de maturidade existem áreas de processos que devem ser
implantadas de acordo com suas práticas e subpráticas, que são denominadas como
componentes, que de acordo com o SEI (2006), em seu modelo CMMI-dev 1.2
podem ser:
• Área de processo: um conjunto de práticas relacionadas em uma área que
quando executadas coletivamente satisfazem um conjunto de objetivos;
• Áreas de processos relacionadas: são descritos quais relacionamentos
existem entre a área de processo que se trata e as outras áreas;
• Objetivos específicos: são características que devem ser realizadas para
satisfazer uma área do processo;
• Objetivos genéricos: são objetivos aplicados a várias áreas de processos
dentro de um nível de maturidade;
• Práticas específicas: são práticas que devem ser seguidas para atingir o
objetivo de uma determinada área de processo;
33
• Práticas genéricas: prática que visa permitir a obtenção do objetivo genérico a
que ela está associada;
• Produtos de trabalhos: são exemplos de saídas das práticas específicas ou
genéricas descritas no modelo, ou seja, artefatos; dados de saída do
processo;
• Subpráticas: são descrições detalhadas que fornecem um guia para
interpretação e implementação das práticas específicas.
De acordo com o SEI (2006), em seu modelo CMMI-dev 1.2 as práticas e
subpráticas citadas acima podem ser categorizadas em:
• Componentes exigidos: são obrigatórios e descrevem o que a organização
deve alcançar para satisfazer uma área de processo;
• Componentes esperados: não são obrigatórios, porém importantes o
suficientes para inviabilizar a implantação caso não sejam seguidos;
descrevem o que a organização pode implementar para alcançar um
componente exigido;
• Componentes informativos: não são obrigatórios, porém fornecem detalhes
que auxiliam as organizações em abordagens dos componentes exigidos e
esperados do modelo.
De acordo com o SEI (2006), o modelo CMMI possui duas representações distintas,
sendo elas por estágio ou contínua:
Representação por estágio: o objetivo desta representação é a maturidade
organizacional. A maturidade organizacional fornece uma maneira de mostrar o
desempenho da organização em um conjunto de áreas de processos que segundo
SEI (2006) são:
• No Nível2:
� REQM - Gerência de requisitos;
� PP - Planejamento de projeto;
� PMC - Monitoramento e controle de projeto;
� SAM - Gerência de acordo com fornecedores;
34
� MA - Medições e análises;
� PPQA - Garantia da qualidade do processo e do produto;
� CM - Gerência de configuração.
• No Nível3:
� RD - Desenvolvimento de Requisitos;
� TS - Solução Técnica;
� IP - Integração de Produto;
� VER - Verificação;
� VAL - Validação;
� OPF - Foco no Processo Organizacional;
� OPD - Definição do Processo Organizacional + IPPD4;
� OT - Treinamento Organizacional;
� IPM - Gestão Integrada de Projeto + IPPD;
� RSKM - Gestão de Risco;
� DAR - Análise de Decisão.
• No Nível4:
� OPP - Desempenho do Processo Organizacional;
� QPM - Gestão Quantitativa de Projeto.
• No Nível5
� OID - Inovação Organizacional;
� CAR - Análise de Causa e Solução de Problemas.
Representação contínua: o objetivo desta representação é focar na capacidade dos
processos de áreas específicas das organizações. Essa representação é dividida em
4 módulos:
4 Integrated Product and Process Development (Produto e processo de desenvolvimento integrado).
Essa atividade é completada com o envolvimento dos stakeholders relevantes. Esses stakeholders representam tanto as funções técnicas e de negócio como o desenvolvimento paralelo do produto e dos processos do ciclo de vida relacionados ao produto (ex: manufatura, suporte, treinamento, verificação e descarte). Dessa forma, problemas importantes aparecem mais cedo no desenvolvimento do produto do que no desenvolvimento tradicional em série e podem ser tratados antes que se tornem erros com alto custo de correção.
35
• Gerência de processos: esse módulo é composto pelas áreas de OPF, OPD e
OT do nível 3, OPP do nível 4 e OID do nível 5;
• Gerência de projetos: esse módulo é composto pelas áreas de PP, PMC e
SAM do nível 2, IPM e RSKM do nível 3 e GPM do nível 4;
• Engenharia: esse módulo é composto pela área de REQM do nível 2 e RD,
TS, VER, VAL e IP do nível 3;
• Apoio: esse módulo é composto pelas áreas de PPQA, CM e MA do nível 2,
DAR do nível 4 e CAR do nível 5.
A área de processo do modelo representa o que deve ser feito e o nível de
capacidade da área implantada identifica quão bem as práticas estão sendo
executadas. Os níveis de capacidade das áreas de processo variam de 0 e 5.
2.5.1 REQM
A área de gerência de requisitos é uma das duas áreas em que o CMMI aborda os
requisitos do que será desenvolvido e é implantada no nível 2 de maturidade.
Segundo SEI (2006) em seu modelo CMMI-dev 1.2:
a) O propósito dessa área de processo é gerenciar os requisitos do projeto e de
seus componentes e identificar inconsistências entre os requisitos, os
produtos de trabalho e planos do projeto;
b) Todos os projetos de desenvolvimento têm requisitos. No caso de projetos de
manutenção, as mudanças nos produtos ou componentes de produtos são
baseadas nas mudanças dos requisitos, design e implementações existentes;
c) As mudanças dos requisitos podem ser documentadas em requisições de
mudanças vindas diretamente dos clientes ou usuários, ou do próprio
processo de desenvolvimento de requisitos;
d) A área de processo gerência de requisitos contém um objetivo específico,
gerenciar requisitos, onde os requisitos são gerenciados e as inconsistências
com os planos de projeto e produtos de trabalho são identificados. Este
objetivo específico contém as seguintes práticas:
36
• SP 1.1 - Obter Entendimento dos Requisitos.
Essa prática específica propõe desenvolver um entendimento com os
fornecedores dos requisitos sobre o significado dos mesmos, para isso conta
com quatro subpráticas:
1. Estabelecer critérios para distinguir os fornecedores apropriados de
requisitos;
2. Estabelecer critérios objetivos para aceitação de requisitos.
3. Analisar os requisitos para assegurar que os critérios estabelecidos
estão sendo atendidos;
4. Chegar a um entendimento dos requisitos com o fornecedor dos
requisitos, de forma que os participantes do projeto possam
estabelecer compromissos com relação a eles.
• SP 1.2 - Obter Compromissos com os Requisitos.
Essa prática específica propõe obter compromissos com os requisitos, para
isso conta com duas subpráticas:
1. Analisar o impacto dos requisitos nos compromissos existentes;
2. Negociar e registrar compromissos.
• SP 1.3 - Gerenciar as Mudanças de Requisitos.
Essa prática específica propõe gerenciar as mudanças de requisitos, para
isso conta com cinco subpráticas:
1. Capturar todos os requisitos e mudanças de requisitos que foram
recebidos ou gerados pelo projeto;
2. Manter o histórico das mudanças nos requisitos juntamente com a
justificativa para as mudanças;
3. Manter o histórico de mudanças; auxilia a rastrear a volatilidade dos
requisitos;
4. Avaliar o impacto das mudanças nos requisitos a partir do ponto de
vista dos stakeholders relevantes;
37
5. Tornar disponíveis para o projeto os dados de requisitos e de
mudanças.
• SP 1.4 - Manter a Rastreabilidade Bidirecional de Requisitos.
Essa prática específica propõe manter uma rastreabilidade bidirecional entre
os requisitos e os planos do projeto e produtos de trabalho, para isso conta
com quatro subpráticas:
1. Manter a rastreabilidade dos requisitos para assegurar que a fonte dos
requisitos de mais baixo nível está documentada;
2. Manter a rastreabilidade dos requisitos até seu requisito derivado, bem
como a sua alocação de funções, objetos, pessoas, processos e
produtos de trabalho;
3. Manter a rastreabilidade horizontal de função para função e entre
interfaces;
4. Gerar a matriz de rastreabilidade de requisitos.
• SP 1.5 - Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos.
Essa prática específica propõe identificar inconsistências entre os planos de
projeto e produtos de trabalho do projeto e os requisitos, para isso conta com
quatro subpráticas:
1. Revisar os planos do projeto, atividades e produtos de trabalho com
relação à consistência com os requisitos e com as mudanças que
forem feitas;
2. Identificar a fonte da inconsistência e sua justificativa;
3. Identificar as mudanças que precisam ser feitas nos planos e produtos
de trabalho resultantes das mudanças na baseline de requisitos;
4. Iniciar as ações corretivas.
38
2.5.2 RD
A área de desenvolvimento de requisitos é a segunda área do CMMI a falar sobre
requisitos e implantada no nível 3 de maturidade. Como citado pelo SEI (2006) em
seu modelo CMMI-dev 1.2, o propósito da área de processo de Desenvolvimento de
Requisitos é produzir e analisar os requisitos de cliente, de produto e de
componente de produto.
Esta área de processo descreve três tipos de requisitos: requisitos de cliente,
requisitos de produto e requisitos de componente de produto.
De acordo com SEI (2006) em seu modelo CMMI-dev 1.2, todos os projetos de
desenvolvimento possuem requisitos. No caso de um projeto com foco em atividades
de manutenção, as alterações no produto ou nos componentes de produto são
baseadas nas mudanças dos requisitos, do projeto, ou da implementação existentes.
As alterações de requisitos, se existirem, deveriam ser documentadas em
solicitações de mudança que partissem do usuário ou do cliente, ou poderiam ser
tomados na forma de novos requisitos recebidos do processo de desenvolvimento
de requisitos. Segundo SEI (2006) em seu modelo CMMI-dev 1.2, os requisitos são
a base para o design.
A área de processo desenvolvimento de requisitos contém 3 objetivos específicos,
segundo SEI (2006) em seu modelo CMMI-dev 1.2.
2.5.2.1 Desenvolver os Requisitos de Cliente
As necessidades, expectativas, restrições e interfaces dos stakeholders são
coletadas e traduzidas em requisitos do cliente, contendo as seguintes práticas:
• SP 1.1 Levantar os Requisitos.
Essa prática específica propõe levantar as necessidades, expectativas, restrições e
interfaces dos stakeholders para todas as fases do ciclo de vida do produto.
39
O levantamento vai além da coleta de requisitos, incluindo a identificação adicional e
pró-ativa de requisitos não fornecidos explicitamente pelos clientes.
Requisitos adicionais deveriam endereçar as várias atividades do ciclo de vida do
produto e seus impactos no produto, para isso conta com uma subprática:
1. Envolver os stakeholders relevantes usando métodos para levantamento de
necessidades, expectativas, restrições e interfaces externas.
• SP 1.2 Desenvolver os Requisitos de Cliente.
Essa prática específica propõe transformar as necessidades, expectativas, restrições
e interfaces dos stakeholders em requisitos do cliente, para isso conta com duas
subpráticas:
1. Traduzir as necessidades, expectativas, restrições e interfaces dos
stakeholders em requisitos do cliente documentados;
2. Definir restrições de verificação e validação.
2.5.2.2 Desenvolver Requisitos de Produto
Os requisitos do cliente são refinados e elaborados para desenvolver os requisitos
do produto e dos componentes de produto, contendo as seguintes práticas:
• SP 2.1 Estabelecer os Requisitos de Produto e de Componentes de
Produto.
Essa prática específica propõe estabelecer e manter os requisitos do produto e dos
componentes de produto, que são baseados nos requisitos do cliente, para isso
conta com duas subpráticas:
40
1. Desenvolver os requisitos em termos técnicos, necessários ao design do
produto e dos componentes de produto. Desenvolver os requisitos de
arquitetura endereçando qualidades e desempenho críticos do produto
necessários ao design da arquitetura do produto;
2. Derivar os requisitos que resultam das decisões de design.
• SP 2.2 Alocar os Requisitos de Componentes de Produto.
Essa prática específica propõe alocar os requisitos de cada componente do produto,
para isso conta com três subpráticas:
1. Alocar requisitos a funções;
2. Alocar requisitos a componentes de produto;
3. Alocar restrições de design a componentes de produto.
• SP 2.3 Identificar os Requisitos de Interface.
Essa prática específica propõe Identificar os requisitos de interface. As Interfaces
entre funções ou entre objetos são identificadas. As interfaces funcionais podem
orientar o desenvolvimento de soluções alternativas descritas na área de processo,
para isso conta com duas subpráticas:
1. Identificar as interfaces externas e internas do produto. À medida que o
design evolui, a arquitetura do produto será alterada pelos processos da
solução técnica, criando novas interfaces entre os componentes de produto e
os componentes externos do produto;
2. Desenvolver os requisitos para as interfaces identificadas. Os requisitos de
interfaces são definidos em termos de aspectos tais como origem, destino,
estímulo, características de dados para software e hardware.
2.5.2.3 Analisar e Validar Requisitos
Os requisitos são analisados e validados, e uma definição das funcionalidades
requeridas é realizada, contendo as seguintes práticas:
41
• SP 3.1 Estabelecer Conceitos e Cenários Operacionais.
Essa prática específica propõe estabelecer e manter conceitos operacionais e
cenários associados. Um cenário é tipicamente uma seqüência de eventos que
poderia ocorrer no uso do produto, que são usados para tornar explícita alguma
necessidade dos stakeholders, para isso conta com quatro subpráticas:
1. Elaborar conceitos operacionais e cenários que incluam funcionalidade,
desempenho, manutenção, suporte e descarte quando apropriado;
2. Definir o ambiente no qual o produto ou o componente de produto irá operar,
incluindo fronteiras e restrições;
3. Revisar os conceitos e cenários operacionais para descobrir e refinar
requisitos;
4. Desenvolver um conceito operacional detalhado, quando o produto e os
componentes de produto são selecionados, para satisfazer às necessidades
operacionais, de manutenção, de suporte e de descarte.
• SP 3.2 Estabelecer uma Definição da Funcionalidade Requerida.
Essa prática específica propõe a definição de funcionalidade, também chamada de
“análise funcional”, é a descrição do que o produto pretende fazer.
A definição de funcionalidades pode incluir ações, seqüências, entradas, saídas ou
outras informações que comunicam à maneira que o produto será usado, para isso
conta com seis subpráticas:
1. Analisar e quantificar as funcionalidades requeridas pelos usuários finais;
2. Analisar os requisitos para identificar as partições lógicas ou funcionais;
3. Particionar os requisitos em grupos, com base nos critérios estabelecidos,
para facilitar ou dar foco à análise de requisitos;
4. Considerar a seqüência das funções de tempo-crítico, no início e durante o
desenvolvimento dos componentes de produto;
5. Alocar os requisitos do cliente às partições funcionais, objetos, pessoas ou a
elementos de suporte para dar suporte à síntese de soluções;
6. Alocar requisitos funcionais e de desempenho às funções e subfunções.
42
• SP 3.3 Analisar os Requisitos.
Essa prática específica propõe que os requisitos sejam analisados para determinar
se eles são necessários e suficientes para atender aos objetivos dos níveis mais
altos da hierarquia do produto. Então, os requisitos analisados fornecem uma base
de requisitos mais detalhada e precisa para os níveis mais baixos da hierarquia do
produto, para isso conta com seis subpráticas:
1. Analisar as necessidades, expectativas, restrições e interfaces externas dos
stakeholders para remover conflitos e organizá-los em assuntos relacionados;
2. Analisar os requisitos para determinar se eles satisfazem aos objetivos dos
requisitos dos níveis mais altos;
3. Analisar os requisitos para garantir que eles sejam completos,
economicamente viáveis, implementáveis e verificáveis. Enquanto o design
determina a viabilidade de uma solução particular;
4. Identificar os requisitos-chave que têm uma forte influência nos custos,
cronograma, funcionalidades, riscos ou desempenho;
5. Identificar medidas de desempenho técnico que serão acompanhados durante
o esforço de desenvolvimento;
6. Analisar os conceitos e cenários operacionais para refinar as necessidades,
restrições e interfaces do cliente, e descobrir novos requisitos.
• SP 3.4 Analisar os Requisitos Visando Equilíbrio.
Essa prática específica diz que as necessidades e restrições dos stakeholders
possam endereçar custos, cronograma, desempenho, funcionalidade, componentes
reusáveis e manutenibilidade ou risco, para isso conta com três subpráticas:
1. Usar modelos comprovados, simulações e prototipagem para analisar o
equilíbrio de necessidades e restrições dos stakeholders;
2. Realizar uma avaliação de risco nos requisitos e na arquitetura funcional;
3. Examinar os conceitos ciclo de vida do produto para identificar os impactos
dos requisitos nos riscos.
43
• SP 3.5 Validar os Requisitos com Métodos Detalhados.
Essa prática específica propõe que a validação dos requisitos seja realizada
precocemente no esforço de desenvolvimento com os usuários finais para obter
confiança de que os requisitos são capazes de guiar um desenvolvimento que
resulte em validação final bem sucedida, para isso conta com três subpráticas:
1. Analisar os requisitos para determinar o risco do produto resultante não
funcionar apropriadamente em seu ambiente de uso pretendido;
2. Explorar a adequação e completitude dos requisitos por meio do
desenvolvimento de representações do produto; como protótipos, simulações,
modelos, cenários e roteiros; e de obtenção de feedbacks dos stakeholders
relevantes a respeito dessas representações;
3. Avaliar o design à medida que ele amadurece no contexto do ambiente de
validação dos requisitos para identificar problemas de validação e expor
necessidades e requisitos do cliente não declarados.
44
3 O USO DAS PRÁTICAS DO SCRUM NO MODELO CMMI
A Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os
aspectos da produção respectivamente, desde estágios iniciais de especificação do
sistema até sua manutenção pós-implantação. O QAI (2006) em seu modelo CBOK
diz que 50% a 70% dos defeitos se originam na fase de especificação de requisitos.
Segundo Crosby (1979), qualidade significa conformidade com os requisitos,
portanto para que haja conformidade com os requisitos e o cliente fique satisfeito, os
requisitos precisam espelhar de forma fiel o desejo do mesmo.
Este trabalho propõe o uso do Scrum para auxiliar a implantação das áreas de
REQM e RD do CMMI, com o intuito de prevenir defeitos o mais cedo possível no
ciclo de vida de software.
3.1 Análise da aderência SCRUM X CMMI
Segundo Zanatta (2004), as metodologias ágeis mostram que certos valores
relacionados com a área de engenharia de requisitos continuam sendo importantes,
como o entendimento dos requisitos. Porém essas metodologias preocupam-se em
não gerar muita documentação com a justificativa de nunca ser lida.
Dessa forma o método ágil Scrum foi avaliado segundo as perspectivas do modelo
CMMI nas áreas de REQM e RD e divididos em três categorias denominadas por
Zanatta (2004) como:
• NA - Não atendido, onde há pouca evidência de que a prática específica do
CMMI esteja presente no Scrum;
• PA - Parcialmente atendido, onde existem evidências de que a prática
específica do CMMI esteja presente no Scrum;
• A – Atendido, onde há evidências significativas de que a prática específica do
CMMI esteja presente no Scrum.
Assim sendo, no objetivo específico de gerenciar requisitos da área de REQM, onde
os requisitos são gerenciados e as inconsistências com os planos de projeto e
45
produtos de trabalho são identificados, o Scrum adere às práticas específicas da
seguinte maneira:
SP 1.1 - Obter Entendimento dos Requisitos.
No modelo Scrum, os requisitos são levantados diretamente com o cliente em uma
reunião de Sprint Planning, onde o produto dessa reunião é uma lista de requisitos
priorizada, separada por fornecedores e com os requisitos aceitos pelo cliente e pelo
Scrum Team, chamada Product Backlog. Com essa prática é possível aderir aos
produtos de trabalho que são:
• Lista de critérios para distinguir fornecedores de requisitos;
• Critério para avaliação e aceitação dos requisitos;
• Análise dos resultados conforme lista de critérios estabelecidos;
• Elaboração de um conjunto de requisitos aceitos.
SP 1.2 - Obter Compromissos com os Requisitos.
Esse compromisso é obtido entre o Product Owner, Scrum Master e o Scrum Team
sobre o Product Backlog, inclusive no momento das estimativas.
SP 1.3 - Gerenciar as Mudanças de Requisitos.
No Scrum o andamento do projeto é acompanhado diariamente através das
reuniões de Daily Scrum, caso haja uma mudança de requisitos, os mesmos serão
inclusos no Product Backlog e estimados e inseridos nos próximos sprints de acordo
com a prioridade dos mesmos, que é estabelecida pelo Product Owner. O modelo
Scrum não deixa clara a existência de um banco de dados para manter as
mudanças registradas.
SP 1.4 - Manter a Rastreabilidade Bidirecional de Requisitos.
No Scrum esta prática não é seguida, pois a metodologia se preocupa com o
produto final e não no como se chegará a ele, dessa forma a rastreabilidade é feita
caso o Scrum Team considere necessário.
46
SP 1.5 - Identificar Inconsistências entre o Trabalho do Projeto e os Requisitos.
No modelo Scrum as inconsistências são analisadas e as ações tomadas nas
reuniões de Daily Scrum e ao final do sprint após o aceito do cliente sobre o que foi
produzido há uma reunião de lições aprendidas onde as inconsistências são
documentadas e ações de melhoria tomadas para o próximo sprint. Dessa forma
tem-se:
Objetivo Genérico do REQM - Gerenciar Requisitos
Prática Específica NA PA A
SP 1.1 - Obter Entendimento dos Requisitos. X
SP 1.2 - Obter Compromissos com os Requisitos. X
SP 1.3 - Gerenciar as Mudanças de Requisitos. X
SP 1.4 - Manter a Rastreabilidade Bidirecional de Requisitos. X
SP 1.5 - Identificar Inconsistências entre o Trabalho do Projeto e os
Requisitos. X
Tabela 2: Aderência do modelo Scrum às práticas específicas do REQM
FONTE: primária Legenda: NA - Não Atendido PA - Parcialmente Atendido A - Atendido
No objetivo de desenvolver os requisitos de cliente da área de RD, onde diz que as
necessidades, expectativas, restrições e interfaces dos stakeholders são coletadas e
traduzidas em requisitos do cliente, o Scrum adere às práticas específicas da
seguinte maneira:
SP 1.1 Levantar os Requisitos.
No Scrum, o levantamento dos requisitos é feito junto ao Product Owner na reunião
de Sprint Planning, onde os requisitos são levantados e acordados, a reunião pode
ser do tipo Joint Application Development (JAD) ou com o uso de prototipação.
SP 1.2 Desenvolver os Requisitos de Cliente.
No Scrum os requisitos são desenvolvidos juntamente ao cliente na reunião de
Sprint Planning, onde o produto final será o Product Backlog. Nessa reunião os
requisitos serão verificados e validados com o Product Owner, Scrum Master e
Scrum Team e a estimativa será feita pelo Scrum Team, após a priorização dos
requisitos do Product Backlog e desmembrados em sprints de acordo com o Time
47
Box do Scrum Team que irá executar o sprint. Dessa forma é possível aderir aos
produtos de trabalho que são:
• Requisitos dos clientes;
• Restrições dos clientes na condução da verificação;
• Restrições dos clientes na condução da validação.
No objetivo específico de desenvolver requisitos de produto, os requisitos do cliente
são refinados e elaborados para desenvolver os requisitos do produto e dos
componentes de produto e o Scrum adere às práticas específicas da seguinte
maneira:
SP 2.1 Estabelecer os Requisitos de Produto e de Componentes de Produto;
Segundo Zanatta (2004), o estabelecimento dos requisitos dos produtos e dos
componentes é realizado no Scrum através do Product Backlog, onde são
detalhadas todas as funcionalidades, características, infra-estrutura, arquitetura e
tecnologia que o produto deverá possuir.
SP 2.2 Alocar os Requisitos de Componentes de Produto;
De acordo com SEI (2006) em seu modelo CMMI-dev 1.2, os produtos de trabalho
para essa prática específica são:
• Planilhas com alocação dos requisitos;
• Alocação dos requisitos temporários;
• Projeto das restrições;
• Requisitos derivados;
• Relacionamentos entre os requisitos derivados.
O modelo Scrum não descreve a alocação de requisitos como uma prática dentro do
sprint, portanto ela pode ocorrer caso haja a necessidade, porém o modelo não
define técnicas para essa prática.
48
SP 2.3 Identificar os Requisitos de Interface.
Segundo Zanatta (2004), no Scrum, os requisitos de interface com outros sistemas
não são detalhados, seja durante a elaboração do Product Backlog ou na execução
do sprint, descrevendo superficialmente a ligação com outros sistemas. Porém
Segundo Schwaber (2007. p.63), muitos produtos são construídos com o conceito
de componentização, principalmente se tratando de sistemas web, sendo assim
Schwaber propõe dois critérios, sendo eles o conhecimento do projeto e a
incrementação sempre que possível, de forma que ao final os componentes possam
ser integrados em um sprint de integração entre os componentes.
No objetivo específico de analisar e validar requisitos. Os requisitos são analisados e
validados, e uma definição das funcionalidades requeridas é realizada e o Scrum
adere às práticas específicas da seguinte maneira:
SP 3.1 Estabelecer Conceitos e Cenários Operacionais.
Os conceitos operacionais, instalações e operações são atendidas pelo Product
Backlog e colocadas pelo Scrum Master a disposição dos Stakeholders. Os cenários
são construídos através de User Stories.
SP 3.2 Estabelecer uma Definição da Funcionalidade Requerida.
O Scrum tem como ponto inicial o Product Backlog para estabelecer as
funcionalidades requeridas. Segundo Schwaber (2002, p.33) a definição do Product
Backlog e o Sprint são considerados as fases mais importantes do Scrum. A
arquitetura funcional é definida no primeiro sprint, porém o modelo não exige
diagramas como diagrama de atividades e casos de uso, apenas o que for
necessário para a entrega do sprint.
SP 3.3 Analisar os Requisitos.
O CMMI define como produtos de trabalho desta prática:
• Relatórios dos defeitos dos requisitos;
• Propor mudanças nos requisitos para resolver defeitos;
49
• Apresentar os requisitos chaves;
• Elaborar medidas técnicas de desempenho.
Dessa forma o Scrum cobre as mudanças e resolução de defeitos junto aos
stakeholders através do Product Backlog, porém não deixa clara a existência de
relatório de defeitos de requisitos e medidas técnicas de desempenho.
SP 3.4 Analisar os Requisitos Visando Equilíbrio.
O Scrum não define modelos ou protótipos para analisar o risco das necessidades
dos stakeholders e suas restrições. Não há análise de riscos formal neste caso.
SP 3.5 Validar os Requisitos com Métodos Detalhados.
Segundo Zanatta (2004), a reunião conhecida como Post Sprint Demonstration and Meeting é um método que o Scrum utiliza para validar os requisitos. Dessa forma tem-se:
Objetivo Genérico do RD - Desenvolver os Requisitos de Cliente
Prática Específica NA PA A
SP 1.1 Levantar os Requisitos. X
SP 1.2 Desenvolver os Requisitos de Cliente. X
Objetivo Genérico do RD - Desenvolver Requisitos de Produto
Prática Específica NA PA A
SP 2.1 Estabelecer os Requisitos de Produto e de Componentes de Produto. X
SP 2.2 Alocar os Requisitos de Componentes de Produto. X
SP 2.3 Identificar os Requisitos de Interface. X
Objetivo Genérico do RD - Analisar e Validar Requisitos
Prática Específica NA PA A
SP 3.1 Estabelecer Conceitos e Cenários Operacionais. X
SP 3.2 Estabelecer uma Definição da Funcionalidade Requerida. X
SP 3.3 Analisar os Requisitos. X
SP 3.4 Analisar os Requisitos Visando Equilíbrio. X
SP 3.5 Validar os Requisitos com Métodos Detalhados. X Tabela 3: Aderência do modelo Scrum às práticas específicas do RD
FONTE: primária Legenda: NA - Não Atendido PA - Parcialmente Atendido A – Atendido
50
3.2 RESULTADOS FINAIS DA ANÁLISE REALIZADA NAS
ÁREAS DE PROCESSO REQM E RD
Analisando as áreas de REQM e RD do CMMI, conforme proposto, precebe-se que
das 15 práticas específicas avaliadas, 3 Não são atendidas pelo modelo Scrum,
sendo 1 da área de REQM e 2 da área de RD. 4 práticas específicas são atendidas
parcialmente pelo Scrum, sendo 3 da área de RD e 1 da área de REQM e 8 práticas
são atendidas completamente sendo 3 da área de REQM e 5 da área de RD,
conforme ilustram as figuras 6 e 7.
Figura 6: Escala de classificação da aderência do Scrum em relação às práticas específicas da área
de REQM do CMMI
FONTE: primária
Figura 7: Escala de classificação da aderência do Scrum em relação às práticas específicas da área
de RD do CMMI
FONTE: primária
51
4 CONSIDERAÇÕES FINAIS
Considerando a análise realizada a partir das referências bibliográficas é possível
concluir que com o uso do modelo Scrum tem-se uma aderência de 60% das
práticas de REQM e 50% das práticas de RD do CMMI.
Das práticas de REQM, 20% são atendidas parcialmente, dessa forma nota-se que
apenas 20% das práticas de REQM não são atendidas pelo modelo Scrum. Quanto
às práticas de RD, 30% são atendidas parcialmente e 20% não são atendidas.
Nota-se que o grande pilar do modelo para aderência às práticas do CMMI é o
artefato produzido junto ao cliente chamado Product Backlog.
Para maior aderência do modelo às práticas do CMMI, algumas medidas podem ser
adotadas dada a flexibilidade da metodologia ágil:
Descrição das práticas não atendidas
– REQM
Solução
SP 1.4 - Manter a Rastreabilidade
Bidirecional de Requisitos.
Desenvolver uma matriz de
rastreabilidade.
Descrição das práticas atendidas
parcialmente - REQM
Solução
SP 1.3 - Gerenciar as Mudanças de
Requisitos.
Criar um novo módulo no Product
Backlog, de forma que as mudanças
fiquem registradas.
Descrição das práticas não atendidas
– RD
Solução
SP 2.2 Alocar os Requisitos de
Componentes de Produto.
Agregar ao Product Backlog um anexo
para registrar os requisitos, as
alocações, requisitos temporários e suas
variações.
SP 3.4 Analisar os Requisitos Visando
Equilíbrio.
Desenvolver um documento de análise
de riscos.
52
Descrição das práticas atendidas
parcialmente – RD
Solução
SP 2.3 Identificar os Requisitos de
Interface.
Agregar ao Product Backlog, as
restrições dos requisitos, interfaces e
relacionamentos com protótipos.
SP 3.2 Estabelecer uma Definição da
Funcionalidade Requerida.
Adicionar os diagramas necessários no
primeiro Sprint, sendo ele destinado à
definição da arquitetura do sistema.
SP 3.3 Analisar os Requisitos. Agregar a análise dos riscos ao
documento de análise de riscos proposto
como solução para a SP 3.4.
Tabela 4: Solução às práticas do CMMI não atendidas pela metodologia Scrum
FONTE: primária
Com isso é possível considerar que pela flexibilidade da metodologia ágil Scrum, a
sua adoção facilita e auxilia na implantação de áreas de requisitos do CMMI.
Como trabalho futuro pretende-se aplicar a proposta de trabalho e aprofundar em
técnicas de Gestão do Conhecimento para diminuir defeitos causados pela fase de
especificação de requisitos de software.
53
GLOSSÁRIO
ABNT: Associação Brasileira de Normas Técnicas.
CMM: Capability Maturity Model.
CMMI: Capability Maturity Model Integration.
DOD: Department Of Defense.
IEEE: Institute of Electrical and Electronics Engineers.
ISO: International Organization for Standardization.
QAI: Quality Assurance Institute.
REQM: Requirements Management.
RD: Requirements Development.
SRS: Software Requirement Specification.
XP: Extreme Programming.
54
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (Brasil). Processos
de Ciclo de Vida de Software: NBR ISO/IEC 12207. 19. ed. Rio De Janeiro:
Comitê Brasileiro de Informática, 1997. 42 p.
AGILE MANIFESTO. <http://agilemanifesto.org>. Disponível em:
<http://agilemanifesto.org>. Acesso em 15 jun. 2008.
CROSBY, P. Quality is Free. Mcgraw-hill, 1979.
Guia do Rugby. http://pt.wikibooks.org. Disponível em:
<http://pt.wikibooks.org/wiki/Guia_do_Rugby/Leis/O_Scrum>. Acesso em: 08
ago. 2008 às 23h41min.
IEEE Std830- INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS
(United States Of America). Recomended Practice of Software
Requirements Specifications. New York, 1998. 37 p.
IEEE Std829 - INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS
(United States Of America). Standard for Software Test Documentation.
New York, 1998. 59 p.
MARTINS, José. Técnicas para gerenciamento de projetos de software. Rio de
Janeiro: Brasport, 2007.
MYERS, Glendford. The Art Of Software Testing. Estados Unidos da América: Wiley
Interscience Publication,1979.
PEREIRA, Paulo; TORREÃO, Paula; MARCAL, Ana Sofia. Entendendo Scrum para
Gerenciar Projetos de Forma Ágil. Mundo Pm, CESAR - Recife, n. , p.01-11,
06 mar. 2007.
55
PRESSMAN, Roger S. Engenharia de Software. 6. ed. São Paulo: Mcgraw-hill,
2006. 720 p.
QAI (Org.). Guide to the CSTE COMMON BODY OF KNOWLEFGE. 2006. V6.1
SCHWABER, Ken. Agile Project Management with Scrum. Redmond, Washington:
Microsoft Press, 2004.
SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum. New
Jersey: Prentice Hall, 2002.
SCHWABER, Ken. The Enterprise and SCRUM. Redmond: Microsoft, 2007.
SCRUM ALLIANCE. http://www.scrumalliance.org. Disponível em:
<http://www.scrumalliance.org/articles/86-reducing-the-test-automation-
deficit>. Acesso em: 06 abr.2008.
Software Engineering Institute (2006) CMMI–DEV: CMMI for development, V1.2
model, CMU/SEI-2006-TR-008, http://www.sei.cmu.edu/cmmi/general/
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Prentice-hall,
2003. 606 p.
Wikipédia. ISO9001. Disponível em: <
http://pt.wikipedia.org/wiki/ISO_9000#ISO_9001:1994 >. Acesso em: 19 dez.
2008 às 21:04.
Wikipédia. Scrum. Disponível em: < http://pt.wikipedia.org/wiki/Scrum >. Acesso em:
08 ago. 2008 às 23:18.
YIN, R.K.. Estudo de Caso: Planejamento e Métodos. São Paulo: Bookman, 2005.
ZANATTA Lazaretti, Alexandre. xScrum: uma proposta de extensão de um Método
Ágil para Gerência e Desenvolvimento de Requisitos visando adequação ao
CMMI Florianópolis, 2004. 180 páginas. Dissertação (Mestrado em Ciência da
56
Computação) - Curso de Pós-Graduação em Ciência da Computação,
Universidade Federal de Santa Catarina
