modelo de monografia -...
TRANSCRIPT
Curso de Engenharia de Computação
GARANTIA DE QUALIDADE DE SOFTWARE EM
PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR
NÍVEL F
Michelle Scarassati
Campinas – São Paulo – Brasil
Dezembro de 2009
Curso de Engenharia de Computação
GARANTIA DE QUALIDADE DE SOFTWARE EM
PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR
NÍVEL F
Michelle Scarassati
Monografia apresentada à disciplina de Trabalho de
Conclusão do Curso de Engenharia de Computação da
Universidade São Francisco, sob a orientação do Prof.
Esp. Ricardo Cesar Boaretto, como exigência parcial para
conclusão do curso de graduação.
Orientador: Prof. Esp. Ricardo Cesar Boaretto
Campinas – São Paulo – Brasil
Dezembro de 2009
GARANTIA DE QUALIDADE DE SOFTWARE EM
PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR
NÍVEL F
Michelle Scarassati
Monografia defendida e aprovada em 17 de Dezembro de 2009 pela Banca
Examinadora assim constituída:
Prof. Esp. Ricardo Cesar Boaretto (Orientador)
USF – Universidade São Francisco – Itatiba – SP.
Bel. em Análise de Sistemas Lilian de Oliveira Campos (membro externo)
___________________________________________________________________________
Prof. Ms. José Aparecido Carrilho
USF – Universidade São Francisco – Campinas – SP.
Dedico esse trabalho aos meus pais, ao meu namorado
e a minha família que muito me apoiaram e me
ajudaram nessa longa caminhada.
v
.Agradecimentos
Agradeço primeiramente a Deus por ter me dado forças para chegar ao final do curso e
ter me iluminado todos os dias dessa longa caminhada.
Agradeço aos professores da Universidade São Francisco de Campinas por terem me
passado todo o conhecimento e por terem sido importantes para a minha formação acadêmica.
Agradeço também ao Prof. Esp. Ricardo Cesar Boaretto por ter me orientado no
trabalho de conclusão de curso e ter me ajudado nessa etapa final e muito importante para
minha formação. Pelos seus conselhos, dedicação e paciência.
Agradeço ao coordenador do curso André Leon por ter me ajudado durante toda essa
caminhada, apoiando e ajudando sempre que foi preciso.
Agradeço a todas as pessoas da Dextra Sistemas, empresa onde faço estágio, pela
oportunidade que me forneceram e por toda a ajuda para tornar real esse estudo feito por mim.
Agradeço também aos meus pais, meu namorado e toda minha família pela paciência
que tiveram comigo, nos meus momentos de stress, no nervosismo das vésperas de provas, na
ansiedade da espera da divulgação das notas, e nesse final pelo entendimento dos meus nãos
para poder me dedicar a esse trabalho de conclusão de curso.
vi
O ENGENHEIRO planeja, ensaia, testa e projeta,
calcula, faz e constrói, estuda, ensina e arquiteta,
acompanha, fiscaliza, coordena, realiza.
Sua Missão e Intuito consistem em melhorar a
qualidade dos sistemas produtivos, criando
oportunidade, para o desenvolvimento, aumentando o
rendimento, a luz, a prosperidade para cada um.
Seu ideal é exercer a profissão, com cuidado,
entusiasmo, com fé e convicção, com ética, dignidade,
transparência, lealdade, com amor e devoção.
vii
Sumário
Lista de Siglas .......................................................................................................................... ix
Lista de Figuras ....................................................................................................................... xi
Lista de Tabela ....................................................................................................................... xiii
Resumo ................................................................................................................................... xiv
Abstract ................................................................................................................................... xv
1 INTRODUÇÃO .................................................................................................................. 1 1.1 Contextualização ........................................................................................................... 1 1.2 Definição do problema a ser tratado ............................................................................. 2
1.3 Estrutura do Texto ......................................................................................................... 3
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 3 2.1 Conceitos fundamentais ................................................................................................ 3
2.1.1 Processo .................................................................................................................. 3 2.1.2 Processo de Desenvolvimento de Software ............................................................ 7
2.1.2.1 Modelo Cascata ................................................................................................ 8
2.1.2.2 Modelo Iterativo e Incremental .............................................................................. 9 2.1.3 RUP (Rational Unified Process) ........................................................................... 10 2.1.4 Qualidade .............................................................................................................. 13
2.1.4.1 Qualidade de Software .......................................................................................... 16 2.1.4.1.1 Qualidade de Produto ..................................................................................... 17
2.1.4.1.2 Qualidade de Processo ................................................................................... 17 2.1.4.2 Modelo de Qualidade de Software ....................................................................... 18
2.1.4.2.1 MPS.Br (Melhoria do Processo de Software Brasileiro) ............................... 19 2.1.5 Metodologia ágil de desenvolvimento de software – SCRUM ............................. 23 2.1.5.1 O Manifesto Ágil .................................................................................................. 23
2.1.5.2 O esqueleto do SCRUM ........................................................................................ 25 2.1.5.3 Atividades e Fluxo do SCRUM ............................................................................ 28
2.2 Estudo de Caso ............................................................................................................ 31
2.2.1 O processo SCRUM da empresa PowerLogic ...................................................... 31
3 ELABORAÇÃO DA SOLUÇÃO ................................................................................... 40 3.1 Histórico da Dextra Sistemas ............................................................................... 40 3.2 Motivação para a elaboração de um processo para projetos SCRUM na Dextra . 42
3.3 Processo SCRUM da Dextra Sistemas ........................................................................ 43 3.4 SCRUM Dextra – Atividades de Garantia da Qualidade............................................. 50
3.4.1 Atividade Realizar Auditoria de Processo .................................................................. 50 3.4.2 Atividade Realizar Auditoria de Produto .................................................................... 51 3.4.3 Atividade Disponibilizar Relatório de Auditoria ........................................................ 52
3.4.4 Atividade Acompanhar as Não Conformidades (NC)................................................. 53 3.4.5 Atividade Consolidar todas as Auditorias Realizadas................................................. 53
viii
3.5 SCRUM Dextra – Produtos de Trabalho de Garantia da Qualidade ........................... 54
4 CONCLUSÃO .................................................................................................................. 62 4.1 Contribuições .............................................................................................................. 64 4.2 Trabalhos futuros......................................................................................................... 65
Apêndice 1 – Ferramentas ..................................................................................................... 66
1.1 EPF Composer ................................................................................................................. 66
1.2 TRAC ................................................................................................................................ 67
Referências Bibliográficas ..................................................................................................... 69
Bibliografias Consultadas ...................................................................................................... 70
ix
Lista de Siglas
ABNT
AP
AQU
BID
CD
CMM
CMMI
CPU
DVD
EPF
FINEP
GCO
GPR
GQA
GRE
IBM
IEC
IEEE
ISO
MA
MCT
MED
MN
MPS.Br
Associação Brasileira de Normas Técnicas
Atributos de Processo
Aquisição
Banco Interamericano de Desenvolvimento
Compact Disc (Disco Compacto)
Capability Maturity Model (Modelo de Maturidade de
Capacidade)
Capability Maturity Model Integration (Integração do Modelo de
Maturidade de Capacidade)
Central Processing Unit (Unidade Central de Processamento)
Digital Video Disc (Disco Digital de Vídeo)
Eclipse Process Framework (Estrutura de Processo Eclipse)
Financiadora de Estudos e Projetos
Gerência de Configuração
Gerência de Projetos
Garantia da Qualidade
Gerência de Requisitos
International Business Machines (Máquinas Comerciais
Internacionais)
International Eletrotechnical Commission (Comissão
Internacional de Eletrotécnica)
Institute of Electrical and Electronics Engineers (Instituto de
Engenheiros Elétricos e Eletrônicos)
International Organization for Standardization (Organização
Internacional para Normalização)
Método de Avaliação
Ministério da Ciência e Tecnologia
Medição
Modelo de Negócio
Melhoria de Processo do Software Brasileiro
x
MR
NC
PDCA
ProUD
PSP
QA
RAP
ROI
RUP
SEPG
SOFTEX
SPICE
TI
TQC
Modelo de Referência
Não Conformidade
Plan, Do, Check, Action (Planejar, Executar, Verificar e Atuar
corretivamente)
Processo Unificado Dextra
Personal Software Process (Processo de Software Pessoal)
Quality Assurance (Garantia da Qualidade)
Resultados dos Atributos de Processo
Retorno do Investimento
Rational Unified Process (Processo Unificado da Rational)
Software Engineering Process Group (Grupo de Processos de
Engenharia de Software)
Associação para Promoção da Excelência do Software Brasileiro
Software Process Improvement and Capability dEtermination
(Melhoria e Capacidade de Determinação do Processo de
Software)
Tecnologia da Informação
Total Control Quality (Controle da Qualidade Total)
UML Unified Modeling Language (Linguagem de Modelagem
Unificada)
xi
Lista de Figuras
FIGURA 2-1: CICLO PDCA DE CONTROLE DE PROCESSOS [3]. ...................................................... 6
FIGURA 2-2: DETALHAMENTO DO CICLO PDCA NOS CICLOS DE MANUTENÇÃO E MELHORIAS [3].
............................................................................................................................................ 7
FIGURA 2-3: MODELO CASCATA DE DESENVOLVIMENTO DE SOFTWARE. (FONTE: SITE -
HTTP://W3.UALG.PT/~PVENTURA/EP/AULAS_TP/T1_G13.PDF) .............................................. 9
FIGURA 2-4: MODELO ITERATIVO E INCREMENTAL DE DESENVOLVIMENTO DE SOFTWARE.
(FONTE: SITE -
HTTP://WWW.CEFETRN.BR/~PLACIDO/DISCIPLINA/MOSSORO/ANALISE/MATERIAL/AULA5.PD
F) ....................................................................................................................................... 10
FIGURA 2-5: PROCESSO RUP [4]. .............................................................................................. 11
FIGURA 2-6: ESTRUTURA DE NÍVEIS DO MPS.BR E COMPARAÇÃO COM OS NÍVEIS DO CMMI.
(FONTE: SITE - HTTP://WWW.WEBPACK.COM.BR/TEMPLATES/95/ ...................................... 21
FIGURA 2-7: ESTRUTURA DO MR-MPS DO MODELO DE QUALIDADE MPS.BR [17]. .................. 22
FIGURA 2-8: FLUXO DE UM PROJETO SCRUM. (FONTE: SITE -
HTTP://WWW.B2ML.COM.BR/B2ML/PAGINA.DO?IDSECAO=54) .......................................... 31
FIGURA 2-9: CICLO DE VIDA DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE – ÁREA DE
PRODUTOS [14]. ................................................................................................................. 35
FIGURA 3-1: PROCESSO DEXTRA PARA DESENVOLVIMENTO EM SCRUM [19]. .......................... 44
FIGURA 3-2: CICLO DE VIDA DO PROCESSO SCRUM DA DEXTRA. ............................................ 44
FIGURA 3-3: PAPÉIS DO PROCESSO SCRUM DA DEXTRA. ......................................................... 45
FIGURA 3-4: DISCIPLINAS DO PROCESSO SCRUM DA DEXTRA. ................................................. 45
FIGURA 3-5: PRODUTOS DE TRABALHO DO PROCESSO SCRUM DA DEXTRA. ............................ 46
FIGURA 3-6: DIAGRAMA DO SPRINT 0. ....................................................................................... 47
FIGURA 3-7: DIAGRAMA DA FASE DE EXECUÇÃO. ..................................................................... 48
FIGURA 3-8: DIAGRAMA DO SUBPROCESSO ACOMPANHAMENTO E CONTROLE.......................... 49
FIGURA 3-9: DIAGRAMA DA FASE DE ENCERRAMENTO. ............................................................ 49
FIGURA 3-10: DIAGRAMA DA DISCIPLINA GARANTIA DA QUALIDADE. ...................................... 50
FIGURA 3-11: PLANO DE QA. .................................................................................................... 54
FIGURA 3-12: LISTA DE VERIFICAÇÃO DE QA SCRUM. ............................................................ 55
FIGURA 3-13: LISTA DE VERIFICAÇÃO DE QA DE STATUS REPORT PARA CLIENTE. ................... 56
xii
FIGURA 3-14: LISTA DE VERIFICAÇÃO DE QA DE STATUS REPORT INTERNO. ........................... 56
FIGURA 3-15: PLANILHA DE ACOMPANHAMENTO DE AUDITORIAS DA QUALIDADE. ................. 57
FIGURA 3-16: REGISTRO DE NÃO CONFORMIDADES NO TRAC. ................................................ 58
FIGURA 3-17: RELATÓRIO DE AUDITORIA DA QUALIDADE. ....................................................... 59
FIGURA 3-18: RELATÓRIO DE PRODUTO. ................................................................................... 60
FIGURA 4-1: GRÁFICO GERADO A PARTIR DOS DADOS REGISTRADOS NA PLANILHA DE
ADERÊNCIA. ....................................................................................................................... 64
FIGURA 4-2: TELA DA FERRAMENTA EPF COMPOSER. ............................................................... 66
FIGURA 4-3: PÁGINA INICIAL DO TRAC [16]. ............................................................................ 67
FIGURA 4-4: TELA INICIAL DO TRAC DE UM PROJETO DA DEXTRA. .......................................... 68
xiii
Lista de Tabela
TABELA 2-1: FATORES BÁSICOS PARA O CICLO DE MANUTENÇÃO DO CONTROLE DA QUALIDADE
[3]. .................................................................................................................................... 15
xiv
Resumo
Quando se fala em qualidade de software, logo vem à mente auditorias e cobranças,
algo desagradável e que incomoda muitas pessoas. Quando o assunto são os modelos de
qualidade de software, as pessoas logo se lembram de processos de desenvolvimento de
software pesados, longos, detalhistas, com uma quantidade enorme de documentos a serem
gerados. Até recentemente a realidade era essa: as empresas que queriam qualidade no
software produzido tinham que colocar em prática processos totalmente complicados, onde se
gastava muito tempo gerando documentos e por isso o produto final acabava se tornando mais
caro. Porém, atualmente, com as exigências do mercado em relação a custo e prazo, as
empresas começaram a implantar metodologias ágeis de desenvolvimento de software. Este
trabalho de conclusão de curso apresenta uma forma de continuar com a qualidade nos
softwares produzidos utilizando essas novas metodologias, em específico utilizando a
metodologia SCRUM. Apresenta também como o conceito de Garantia da Qualidade pode ser
executado dentro de um processo SCRUM de desenvolvimento de software, sem que as
exigências do modelo de qualidade de software brasileiro, o MPS.Br (Melhoria de Processo
do Software Brasileiro), nível F, sejam comprometidas.
PALAVRAS-CHAVE: Qualidade de Software, Modelos de Qualidade de Software, Processo
de Desenvolvimento de Software, Metodologias Ágeis, SCRUM, MPS.Br.
xv
Abstract
When software quality is mentioned, words like audits and collections quickly come to
mind, these are something unpleasant that bothers many people. Regarding the models of
software quality, sometimes people remember heavy, long and detailed software development
process, with a huge amount of documents to be generated. Until recently that was the
scenario: the companies which want quality in software produced have to practice much
complicated processes, and spent much time creating documents, such that the final product
becomes too expensive. Nowadays, with the market requirements for cost and time,
companies began to implement agile software development methodologies. This dissertation
provides means to keep software quality using these news methodologies, in particular using
the SCRUM methodology. It also shows how the concept of Quality Assurance can be
maintained within a SCRUM process of software development, without the demands of the
Brazilian quality of software model, MPS.Br (Melhoria de Processo do Software Brasileiro –
Brazilian Process Improvement of Software), level F, are compromised.
KEY WORDS: Software Quality, Software Quality Models, Software Development Process,
Agile Methodologies, SCRUM, MPS.Br.
1
1 INTRODUÇÃO
1.1 Contextualização
No início da era da computação, os sistemas baseados em computadores eram
desenvolvidos com foco no hardware, isso porque naquela época o hardware era o item mais
caro dentro do desenvolvimento de um sistema computacional. Haviam controles formais e
padrões técnicos para acompanhar os custos de hardware. A engenharia de hardware era a
responsável por aplicar controles, métodos e ferramentas para implementar melhorias no
hardware, e o software era visto como uma simples reflexão posterior.
A programação não era considerada muito importante, poucas pessoas sabiam
programar, e quem sabia, havia aprendido por tentativa e erro. O mundo do software era
considerado menos importante que o do hardware. Porém, com o passar dos anos, esse
pensamento foi mudando e várias perguntas foram surgindo, como por exemplo: Por que os
programas demoravam a ser concluídos? Por que os custos eram elevados? Por que os erros
não eram todos descobertos antes de o software ser entregue aos clientes? Essas e outras
perguntas levaram a adoção de práticas de engenharia de software, que atualmente é a parte
mais importante e cara dentro de um sistema computacional.
Atualmente, a grande preocupação das pessoas envolvidas no desenvolvimento de um
sistema baseado em computador é em relação ao software, pois o hardware passou a ser mais
barato e menos importante do que a programação de software. O maior desafio dos
profissionais de informática de hoje é conseguir desenvolver software com prazo e custo
mínimos e de alta qualidade. Com isso a engenharia de software passou a ser considerada uma
área essencial dentro do mundo da computação.
O software, por ser um elemento lógico, deve ser desenvolvido ou projetado por
engenharia, e não por manufatura como qualquer produto físico, por isso os custos do
software estão concentrados no trabalho do engenheiro de software. O software também tem
custo maior do que o hardware na manutenção, isso porque a manutenção do software é mais
complexa, por envolver erro de projeto ou de processo, ou seja, não envolve uma simples
reposição de peça como acontece com o hardware.
Em suma, pode-se dizer que os custos da engenharia de software estão distribuídos ao
longo do processo de software. Para determinar qual parte do processo tem custo maior, deve-
se levar em conta o tipo de processo utilizado e o tipo de software a ser desenvolvido. De uma
forma geral, pode-se dizer que teste de sistema, no caso de desenvolvimento de produto, e
2
evolução de sistema, no caso de alteração após o software ter sido colocado em uso, são as
duas atividades que possuem o maior custo dentro de um processo de software.
Além do desafio de desenvolver software com prazo e custos mínimos e de alta
qualidade, como dito anteriormente, a engenharia de software, no século XXI, ainda enfrenta
outros três principais desafios. O primeiro deles é o desafio do legado, que envolve a
manutenção e atualização de softwares antigos, para evitar custos excessivos e para dar
continuidade à prestação de serviços corporativos essenciais.
O segundo é o desafio da heterogeneidade, que visa desenvolver softwares confiáveis
e flexíveis, que suportem sistemas distribuídos em redes que possuam diferentes tipos de
computadores. E por último, o desafio do fornecimento que se refere à redução do tempo de
fornecimento de sistemas grandes e complexos sem comprometer a sua qualidade.
Por fim pode-se concluir que para um software ser considerado de boa qualidade, ele
deve possuir os seguintes atributos: fácil manutenção, como atualmente o ambiente de
negócios está em constante mutação, o software deve ser capaz de evoluir e ser modificado
para atender as necessidades dos clientes; nível de confiabilidade, que envolve confiabilidade,
proteção e segurança, isto é, em caso de defeito o software não deve ocasionar danos físicos
e/ou econômicos para o usuário; eficiência, que inclui rapidez de resposta, tempo de
processamento, além de evitar desperdício de recursos do sistema, como a memória, por
exemplo; e por último, facilidade de uso, isto é, o software deve possuir uma interface
apropriada com o usuário, além de uma documentação adequada.
1.2 Definição do problema a ser tratado
As empresas de software estão buscando cada vez mais ter um produto final de maior
qualidade, através de certificações como MPS.Br e CMMI (Capability Maturity Model
Integration - Integração do Modelo de Maturidade de Capacidade), visando atrair mais
clientes e manter os que já possui. Porém esses modelos de qualidade de software até
recentemente levaram a elaboração e utilização de processos de desenvolvimento de software
muito extensos e pesados, sendo os mesmos melhor aplicados apenas em projetos grandes e
longos, caso contrário, torna-se muito custoso e trabalhoso para a empresa implantá-los.
Por esse motivo, algumas empresas começaram a adotar o desenvolvimento ágil de
software, muitas vezes utilizando a metodologia SCRUM, que ao contrário do que muitos
pensam, não significa ausência de documentação, mas sim, apenas a documentação necessária
e no momento oportuno.
3
O grande desafio atualmente é como garantir a qualidade de processo dos projetos que
utilizam um processo ágil de desenvolvimento de software. Como conseguir uma certificação
MPS.Br em projetos SCRUM, através da elaboração de um processo mais leve, é o objetivo
desse trabalho, que tem foco apenas na disciplina Garantia de Qualidade do MPS.Br nível F.
1.3 Estrutura do Texto
Esse trabalho está divido em quatro seções, onde a Seção 1 contém a introdução, a qual
está dividida em dois itens, que são contextualização e definição do problema a ser tratado. A
Seção 2 aborda toda a fundamentação teórica e está dividida em dois itens, onde o primeiro
descreve todos os conceitos fundamentais que foram a base deste trabalho (processo, processo
de desenvolvimento de software, RUP (Rational Unified Process - Processo Unificado da
Rational), qualidade, qualidade de software, modelo de qualidade de software, MPS.Br e
SCRUM).
O segundo item trata do estudo de caso feito para este trabalho, contemplando o
processo SCRUM da empresa PowerLogic, que foi tomado como base do estudo, o histórico
da empresa Dextra Sistemas, onde esse trabalho está sendo aplicado na prática e a motivação
que levou ao desenvolvimento desse trabalho. A Seção 3 aborda a elaboração da solução, ou
seja, o desenvolvimento do trabalho proposto, com a explicação detalhada de cada atividade
presente na disciplina Garantia da Qualidade do Processo SCRUM da Dextra.
Por fim, a última seção finaliza com as conclusões deste trabalho, as suas contribuições
para a empresa onde está sendo aplicado e para quem desenvolveu, e algumas sugestões para
trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
2.1 Conceitos fundamentais
2.1.1 Processo
Há várias definições para processo, tais como: “Uma ação regular e contínua realizada
de forma bem definida, levando a um resultado”, segundo Oxford English Dictionary; “Um
conjunto parcialmente ordenado de atividades para se atingir um objetivo”, segundo Feiler &
Humphrev [1]; “Define quem está fazendo o quê, quando e como para atingir um certo
4
objetivo”, segundo Jacobson, Booch, Rumbaugh [2]; “Processo é um conjunto de causas que
provoca um ou mais efeitos” , segundo Falconi [3].
Conceitualmente, processo é todo conjunto de atividades bem definidas, que possuem
responsáveis e artefatos de entrada e saída, atividades com dependências entre as mesmas,
ordem de execução e modelo de ciclo de vida. Resumindo, pode-se dizer que processo é
qualquer atividade que recebe uma entrada, realiza uma transformação agregando-lhe valor e
gera uma saída para um cliente externo ou interno, fazendo uso de recursos para gerar
resultados concretos.
Os processos possuem a seguinte hierarquia:
1. Macroprocessos: são considerados um centro autônomo de resultados com
autonomia decisória e recursos plenos (a organização em si). Melhor dizendo,
macroprocessos designam um conjunto de atividades necessárias e suficientes
para atender aos pedidos dentro do requisito especificado, a elaboração e a
disponibilidade no prazo e local prometido ao cliente.
2. Subprocessos: são divisões do macroprocesso com objetivos específicos.
Recebem entradas e geram saídas em um único departamento.
3. Atividades: são divisões que compõem um subprocesso.
4. Tarefas: são as atividades em um nível mais detalhado.
Processos também podem ser divididos de acordo com suas finalidades, isto é,
processos de fabricação geram produtos ou serviços. Os processos de negócios apóiam
processos de fabricação pelos meios operacionais (operações finalísticas) ou administrativos
(gestões de recursos (suporte) e operações).
Hoje em dia é muito comum a padronização de processos, o que ajuda a reduzir
problemas de treinamento, revisões e ferramentas de apoio. Na visão da computação e da
engenharia de software, se forem utilizados métodos padrões, cada nova experiência de
projeto pode ajudar na melhoria do processo como um todo. Além disso, processos
padronizados podem fornecer uma base sólida para se fazer medições de qualidade entre
projetos que utilizam o mesmo processo.
Existe também o modelo de processo, que é uma representação de um processo e
envolve as atividades que serão realizadas, os agentes que realizarão as atividades, os
artefatos (produtos) gerados e os recursos necessários para a realização das atividades. Um
modelo de processo deve ser descrito de forma completa e formal, utilizando-se diagramas de
estados, técnicas de análise e projeto estruturados, UML (Unified Modeling Language -
Linguagem de Modelagem Unificada), entre outros formalismos diagramáticos. Esse modelo
5
deve ser usado pela organização para o entendimento e comunicação do processo, e deve
servir como base para a análise, execução, gerência e melhoria do processo como um todo.
Para que um processo seja institucionalizado com sucesso dentro de uma organização,
precisa haver um comprometimento da diretoria da empresa, envolvimento de todos,
treinamento e orientação das pessoas envolvidas nos padrões e técnicas, infra-estrutura
necessária disponível, disciplina e motivação. Para que um processo acompanhe a constante
modificação do ambiente de negócios, ele deve ser revisado periodicamente e deve ter
melhoria contínua. É importante deixar claro que todo processo deve ajudar e não burocratizar
a organização, por isso é importante se ter procedimentos adequados e ferramentas que
facilitam o trabalho dentro da empresa.
Como um processo pode ter um ou mais resultados, para que se possa realizar o
gerenciamento do mesmo é preciso fazer medições desses resultados. Isso pode ser feito
através dos itens de controle do processo, os quais medem a qualidade, custo, entrega, moral e
segurança dos resultados. É importante ressaltar que “não se deve estabelecer um item de
controle sobre algo de que não se possa exercer o controle, ou seja, atuar na causa do desvio”
[3].
O método gerencial para controle de processo mais utilizado é o ciclo PDCA (plan, do,
check e action – planejar, executar, verificar e atuar corretivamente), como mostra a Figura 2-
1. O planejamento consiste em estabelecer metas sobre os itens de controle e a maneira para
atingir essas metas. A execução consiste na realização das tarefas exatamente como previstas
no planejamento e na coleta de dados para uma futura verificação do processo. Nessa etapa
também se deve ter um treinamento no trabalho que foi definido no planejamento.
Na fase de verificação se compara o resultado alcançado com as metas planejadas
inicialmente. Essa comparação é feita utilizando-se os dados coletados na fase de execução.
Por último, existe a fase de atuação corretiva, onde o usuário atuará nos desvios detectados,
realizando correções definitivas, de modo que o problema não ocorra novamente.
6
O ciclo PDCA pode ser utilizado para quatro objetivos diferentes: manutenção do
nível de controle, melhoria do nível de controle, manutenção dos resultados e melhoria dos
resultados. Para manutenção do nível de controle, o mesmo é utilizado “quando o processo é
repetitivo e o plano consta de uma meta que é uma faixa aceitável de valores e de um método
que compreende os procedimentos padrões de operação” [3].
Nas melhorias do nível de controle, o ciclo PDCA é utilizado quando “o processo não
é repetitivo e o plano consta de uma meta que é um valor definido e de um método, que
compreende aqueles procedimentos próprios necessários para se atingir a meta” [3]. Na
manutenção dos resultados “as diretrizes de controle são mantidas pelo cumprimento dos
procedimentos de operação” [3], que pode ser visto no seqüenciamento do PDCA, que é o
ciclo de manutenção.
E por fim, na melhoria dos resultados se tem que “a utilização de ciclo PDCA para
melhorar as diretrizes de controle é a grande responsabilidade de todas as chefias, desde o
presidente até o nível de supervisor” [3]. Constitui um método para a solução de problemas, o
Figura 2-1: Ciclo PDCA de controle de processos [3].
7
qual deve ser dominado por todas as pessoas da empresa. O detalhamento do ciclo PDCA
pode ser visto na Figura 2-2.
2.1.2 Processo de Desenvolvimento de Software
Existem várias definições para Processo de Desenvolvimento de Software. Segundo
Sommerville [5] “Processo de Software é um conjunto de atividades e resultados associados
que produzem um produto de software”. Conforme Pressman [6] “definimos um processo de
software como um framework para as tarefas que são necessárias para a construção de
software de alta qualidade”.
Um processo de desenvolvimento de software é dividido em atividades genéricas, que
englobam: Especificação dos Requisitos, atividade onde são feitas as funcionalidades e
restrições do sistema; Desenvolvimento, atividade que envolve a construção do software em
si; Verificação, atividade de análise de correção, validação entre outros aspectos relacionados
com qualidade; Manutenção, atividade que visa analisar e realizar mudanças no software.
Dividido também em papéis e artefatos. Essas divisões possuem a seguinte relação: os
artefatos são documentos, modelos e códigos produzidos por uma atividade, onde cada
Figura 2-2: Detalhamento do ciclo PDCA nos ciclos de manutenção e melhorias
[3].
8
atividade é executada por um papel (que pode ser uma equipe ou uma única pessoa)
específico.
Hoje em dia, muitas pessoas ainda não sabem definir o que é método e o que é
processo. De modo geral, pode-se dizer que método é teórico, ele define o que, como e porque
fazer, já o processo é prático, ele define quem e quando fazer, é a junção de método com
planejamento.
Método define papéis. Processo define quem desempenhará cada papel. No método, as
atividades que serão realizadas são denominadas disciplinas. No processo as atividades são
alocadas aos papéis, e determinam-se o fluxo de trabalho, as dependências e os marcos. Em
um método, disciplinas e papéis produzem e consomem artefatos. Em um processo define
quem produz e consome os artefatos e quando os mesmos serão produzidos.
Estabelecer um processo de desenvolvimento de software dentro de uma empresa é
importante para se diminuir a dependência da empresa em relação às pessoas, reduz
problemas de treinamento e ferramentas de apoio, fornece a base para medições de qualidade
entre projetos, além de facilitar a disseminação de melhores práticas, conhecimento e
documentos. Para que se tenha sucesso é importante que o processo seja bem definido,
padronizado, divulgado e utilizado de forma correta por todos da empresa.
Utiliza-se um modelo de processo para que haja o entendimento e a comunicação do
processo, além de prover a sua melhoria. Um modelo de processo deve ser descrito de
maneira formal e padronizada. Existem vários modelos de processo de desenvolvimento de
software, dentre os quais os mais conhecidos e utilizados são o Modelo Cascata e o Modelo
Iterativo Incremental.
2.1.2.1 Modelo Cascata
O modelo Cascata, também conhecido como modelo ciclo de vida Clássico, é o mais
antigo de todos. Ele descreve o desenvolvimento de software de forma linear e seqüencial,
isto é, uma vez que uma fase é completada ela não retorna mais, e o desenvolvimento
prossegue para a próxima fase. Outra característica importante é que uma fase não pode
iniciar enquanto a anterior não estiver finalizada, como pode ser observado na Figura 2-3.
9
No modelo cascata são contempladas as fases: Requerimento, onde é elaborado um
conjunto de requisitos do software; Projeto, que é a fase que se encarrega de transformar o
conjunto de requisitos em um documento (desenho ou plano) que será seguido pelos
desenvolvedores na implementação desses requisitos.
2.1.2.2 Modelo Iterativo e Incremental
Dizer que um processo é iterativo, significa que o mesmo possui várias iterações no
tempo, isto é, significa que o processo possui vários ciclos de desenvolvimento onde em cada
ciclo são identificadas as fases de levantamento e análise de requisitos, projeto,
implementação, testes e implantação. Dizer que ele é incremental significa que ele gera novas
versões incrementadas a cada ciclo, como mostra a Figura 2-4. Atualmente, o modelo
iterativo incremental de desenvolvimento de software é um dos mais utilizados nas empresas
de fábrica de software.
Figura 2-3: Modelo Cascata de
desenvolvimento de software. (Fonte: Site -
http://w3.ualg.pt/~pventura/ep/aulas_tp/t1_g1
3.pdf)
10
Isso ocorre porque neste modelo existem inúmeras vantagens, como por exemplo, a
possibilidade de avaliar logo no início os riscos e pontos críticos do projeto, identificar
medidas para eliminar ou controlar os riscos avaliados, definir a melhor arquitetura a ser
usada, redução do risco de a entrega do projeto atrasar, contato freqüente com o cliente (o que
permite manter o entendimento dos requisitos alinhados), a equipe visualiza o software
funcionando mais cedo (o que é extremamente motivador).
2.1.3 RUP (Rational Unified Process)
O RUP foi criado pela Rational Software Corporation e posteriormente foi adquirido
pela IBM (International Business Machines - Máquinas Comerciais Internacionais). É o
processo de desenvolvimento de software baseado no modelo iterativo incremental mais
utilizado atualmente pelas empresas. Por ser considerado um processo pesado, é aplicado em
Figura 2-4: Modelo Iterativo e Incremental de
desenvolvimento de software. (Fonte: Site -
http://www.cefetrn.br/~placido/disciplina/mosso
ro/analise/material/aula5.pdf)
11
grandes projetos, com grandes equipes de desenvolvimento. Apesar disso, por ser um
framework de processo, o RUP pode ser adaptado a realidade de pequenas e médias empresas
de desenvolvimento de software.
Devido utilizar a orientação a objetos como paradigma de desenvolvimento de
software, o RUP lança mão da UML como linguagem de modelagem e documentação de
projetos. Além disso, o RUP é guiado por casos de uso e centrado na arquitetura. Como já foi
dito anteriormente, o ciclo de vida do RUP é iterativo e incremental, isto é, ele se repete
através de uma série de ciclos, onde em cada ciclo que se encerra é gerado uma nova release
(produto acabado) incrementada.
O ciclo de vida é dividido em quatro fases, onde cada fase pode ser subdividida em
iterações. As fases são: concepção, elaboração, construção e transição. Elas serão explicadas
na seqüência e podem ser observadas através da Figura 2-5.
A fase concepção é a primeira fase do ciclo de vida do RUP. Nela são definidos o
escopo do projeto, suas fronteiras e os principais casos de uso do projeto. Essa fase tem ênfase
no planejamento, por isso é nessa fase que se faz as estimativas de prazo e custo, de forma
global para o projeto todo e mais detalhada para a fase seguinte. As idéias são exploradas até
alcançarem o ponto em que se possa iniciar a elaboração do sistema.
A segunda fase é a elaboração, onde o levantamento inicial dos casos de uso é
revisado e, se necessário, complementado. Nessa fase são desenvolvidas a arquitetura do
sistema e a versão inicial do manual do usuário, também é feita a revisão da modelagem de
negócio do projeto. Resumidamente, pode-se dizer que a fase de elaboração é constituída da
análise e projeto.
Figura 2-5: Processo RUP [4].
12
A fase construção é a terceira fase do ciclo de vida e é nela que são feitos a
implementação e os testes. Nessa fase o sistema é desenvolvido, códigos são gerados e testes
são realizados.
A quarta e última fase é a transição, a qual ocorre após o último ciclo iterativo da fase
de construção. Concentra-se na realização de testes, visando garantir que o sistema possui um
nível de qualidade aceitável. Nessa fase o sistema é entregue ao cliente, é feito o plano de
implantação, acompanhamento e qualidade de software de modo a obter a satisfação do
cliente. Essa fase também contempla a construção de novas versões para permitir ajustes do
sistema, corrigir problemas ou construir algumas características que foram postergadas, que
surgem após o sistema ter sido colocado em uso pelo cliente.
Os elementos pertencentes ao processo RUP são: papéis, atividades, artefatos, fluxos
de trabalhos e disciplinas. O elemento papel define as responsabilidades de cada indivíduo da
equipe no projeto. Um indivíduo pode assumir vários papéis dentro do mesmo projeto. A
atividade é uma tarefa realizada por um papel e que produz um resultado importante para o
projeto. Cada atividade pode ser dividida em etapas, para facilitar a execução da mesma por
um determinado papel.
O artefato é uma parte de uma informação que é produzida, modificada ou utilizada no
processo. É o produto de um projeto, que é utilizado como entrada de atividades ou produzido
como saída das mesmas. Templates (modelos), documentos, código fonte, executáveis são
exemplos de artefatos em um processo. Fluxo de trabalho é uma seqüência de atividades que
são executadas para a produção de um resultado importante para o projeto. Essa seqüência é
semi-ordenada para o melhor entendimento do processo, podendo quebrá-lo em menores
áreas de conhecimento. Um fluxo de trabalho é representado na forma de diagrama de
seqüência.
Por fim tem-se o elemento disciplina, que é uma coleção de tarefas relacionadas a uma
área de conhecimento de todo o projeto. Dividir as atividades em disciplinas diferentes é uma
forma de organizar o conteúdo de modo a facilitar a compreensão. O RUP é dividido em nove
disciplinas, que são: modelagem de negócios, requisitos, análise e design, implementação,
teste, distribuição, configuração e gerenciamento de mudanças, gerenciamento de projeto e
ambiente.
13
2.1.4 Qualidade
A idéia de qualidade surgiu há aproximadamente 4 (quatro) mil anos atrás no Egito,
quando os egípcios criaram um padrão de medida de comprimento chamada cúbito, que
correspondia ao comprimento do braço do faraó que estava no reinado. Ou seja, a cada troca
de faraó, a medida mudava, de acordo com o tamanho do braço do novo faraó. Eram cortados
bastões com o comprimento do braço do faraó e este era utilizado para fazer as construções.
A partir daí a história da qualidade prosseguiu com os templos construídos na Grécia e
Roma antigas, os feitos das grandes navegações, as catedrais medievais. Porém, o grande
marco da história da qualidade foi a Revolução Industrial, devido às profundas mudanças
econômicas e sociais e, conseqüentemente, o surgimento da concorrência entre as grandes
empresas que surgiram nessa época.
Segundo a ISO 9000 (International Organization for Standardization - Organização
Internacional para Normalização) [7] “Qualidade é a adequação ao uso. É a conformidade às
exigências.” Existem vários pontos de vista sobre o que é qualidade. Para alguns, qualidade é
a aparência do produto, para outros é de qual material o produto foi feito, outros que avaliam
a qualidade de um produto pelo preço que ele custa.
Falconi [3] acredita que “um produto ou serviço de qualidade é aquele que atende
perfeitamente, de forma confiável, de forma acessível, de forma segura e no tempo certo as
necessidades do cliente.” Em outros termos, pode-se dizer que:
“a. que atende perfeitamente = projeto perfeito;
b. de forma confiável = sem defeitos;
c. de forma acessível = baixo custo;
d. de forma segura = segurança do cliente;
e. no tempo certo = entrega no prazo certo, no local certo e na quantidade certa” [3].
Na verdade a qualidade é subjetiva e está totalmente ligada as necessidades internas de
cada pessoa. O aspecto objetivo, que é mensurável da Qualidade, é o processo. É através do
processo que se pode implantar sistemas de qualidade.
O primeiro sistema padronizado de qualidade surgiu na indústria de produção seriada e
é conhecido e utilizado por muitas empresas até os dias de hoje, esse sistema é o ISO. Ele
surgiu como uma forma de se manter a perfeita padronização das peças e produtos fabricados,
evitando o retrabalho e maiores custos de produção.
14
Com o surgimento das certificações que comprovam a qualidade dos produtos gerados
por uma empresa o conceito de qualidade evoluiu e deixou de ser apenas a conformidade de
determinado produto com o processo estabelecido na empresa, cumprindo todas as etapas do
processo de forma homogênea e padronizada. Agora qualidade é vista como sendo um
enfoque na satisfação plena das necessidades do cliente.
Outro conceito muito utilizado atualmente é o de Qualidade Total. Esse termo busca a
satisfação não só do cliente, mas de todas as pessoas que influenciam na existência da
empresa e no seu modelo organizacional. Resumindo pode-se dizer que o conceito qualidade
total possui seis atributos básicos, que são: qualidade intrínseca (capacidade do produto de
cumprir o objetivo ao qual se destina), custo (para empresa e preço para o cliente),
atendimento (local, prazo e quantidade), moral (treinamento, motivação), segurança (dos
clientes internos e externos) e ética (valores e regras de conduta).
A qualidade total valoriza o ser humano no âmbito das empresas e pode ser entendida
como uma nova maneira de pensar, antes de agir e produzir. Ela tem como pontos básicos:
foco no cliente; trabalho em equipe; decisões baseadas em fatos e dados; e a busca constante
da solução de problemas e da diminuição de erros. Por isso, pode-se dizer que a sobrevivência
das empresas que precisam garantir aos seus clientes a total satisfação com os produtos
produzidos depende da qualidade total, a qual também influencia a competitividade entre
empresas.
A prática de controle da qualidade é o objetivo principal do Controle da Qualidade
Total (TQC – Total Control Quality - Controle da Qualidade Total) e é de obrigação de todos.
“O controle da qualidade total é um novo modelo gerencial centrado no controle de processo,
tendo como meta a satisfação das necessidades das pessoas” [3].
Os três principais objetivos abordados pelo controle da qualidade, segundo Falconi
[3], são:
1. “planejar a qualidade desejada pelos clientes; isto implica um esforço de localizar
o cliente, saber de suas necessidades (muitas vezes ele não as conhece e você deve
colocar-se em seu lugar), traduzir estas necessidades em características
mensuráveis, de tal forma que seja possível gerenciar o processo de atingi-las.”
2. “manter a qualidade desejada pelo cliente, cumprindo padrões e atuando na causa
dos desvios. O processo para manter a qualidade desejada pelo cliente está
mostrado na Tabela 2-1. Nesse caso o controle (PDCA) é exercido para manter os
resultados.”
15
3. “melhorar a qualidade desejada pelo cliente; neste caso é preciso localizar os
resultados indesejáveis (problemas) e utilizar o método de solução de problemas
para melhorá-los.”
Dentro da Qualidade Total ainda existe o conceito de Garantia da Qualidade, que tem
como finalidade confirmar se todas as atividades da qualidade estão sendo realizadas da
maneira como é requerida pela empresa. Segundo Falconi [3], “a garantia da qualidade é a
embaixatriz do cliente na empresa, é a função que visa a confirmar que todas as ações
necessárias para o atendimento das necessidades dos clientes estão sendo conduzidas de
forma completa e melhor que o concorrente.”
Consegue-se a garantia da qualidade em uma empresa através do gerenciamento
correto, que é feito via ciclo PDCA descrito anteriormente, de todas as atividades da área da
qualidade em cada projeto e em cada processo existente na empresa. A mesma busca eliminar
completamente as falhas através da constante preocupação com a total satisfação dos clientes
e pela participação e responsabilidade de todos os membros da empresa. Pode-se dizer que, na
qualidade total, a garantia da qualidade busca o defeito zero.
Existem três estágios da garantia da qualidade, os quais foram evoluindo com o passar
dos anos, são eles: a garantia da qualidade orientada pela inspeção, a orientada pelo controle
Tabela 2-1: Fatores básicos para o ciclo de manutenção do controle da qualidade [3].
16
de processos e a com ênfase no desenvolvimento de novos produtos. É importante ressaltar
que esses estágios não se excluem, a diferença entre os mesmos está na ênfase que cada
empresa tem no momento, se é na inspeção, no controle de processos ou no desenvolvimento
de novos produtos.
Resumidamente, tem-se que a garantia da qualidade orientada pela inspeção é
realizada por um grupo independente da produção. O problema é que esse estágio é muito
custoso, uma vez que os inspetores aumentam os custos e não produzem nenhum produto, e
também não melhora a qualidade do produto se aplicada isoladamente, visto que a inspeção
não elimina as causas fundamentais dos defeitos, apenas evita que eles apareçam para o
cliente.
Já a garantia da qualidade orientada pelo controle de processo é de responsabilidade de
todos na empresa. Nesse estágio se garante que os processos da empresa estão perfeitos,
fazendo produtos sem defeitos, porém não garante que esses produtos possuem especificações
que satisfazem as necessidades dos clientes. Assim, surgiu o terceiro e último estágio da
garantia da qualidade, o com ênfase no desenvolvimento de novos produtos, onde a qualidade
deve ser construída de acordo com cada projeto e em cada processo. “Portanto, neste estágio,
além de se ter o controle de processos e a inspeção (ainda que com menor ênfase), procura-se
conduzir severamente as avaliações e garantir a qualidade em cada passo do desenvolvimento
de um novo produto, desde o seu planejamento até a fase posterior à assistência técnica
(serviço)” [3].
2.1.4.1 Qualidade de Software
Uma famosa definição de qualidade de software foi dada por Crosby [8] que diz que
“A qualidade é conformidade aos requisitos”. Ela é interessante pelo fato de deixar explícito
que é preciso um ponto de referência para julgar um produto, e no que diz respeito a software
essa referência são os seus requisitos. Além disso, também traz embutida a idéia de como todo
o processo pode ser documentado, analisado e os resultados transmitidos a outras pessoas.
A qualidade de software está focada em dois aspectos diferentes, mas que são
necessários e complementares: a qualidade de produto e a qualidade de processo. Ambos os
aspectos garantem a qualidade do software final, interferem no processo de desenvolvimento,
realimentando-o com os resultados obtidos durante a verificação e tem um propósito comum,
que é o de satisfazer o cliente.
17
2.1.4.1.1 Qualidade de Produto
A qualidade de produto refere-se aos testes realizados no software por uma equipe
específica de testes, são as chamadas verificações e validações. Avaliar a qualidade de
produto significa verificar, através de técnicas e atividades operacionais o quanto os requisitos
são atendidos. A qualidade de produto não se atinge de forma espontânea, ela depende
fortemente da qualidade de processo. A finalidade da qualidade de produto é a verificação
(verifica se a saída está de acordo com a entrada do processo) e a validação (verifica se a
saída está de acordo com a especificação inicial).
Quando se fala em qualidade de produto de software, ou melhor dizendo, em testes de
software, surge uma dúvida em relação a três termos que parecem ser muito semelhantes:
engano, defeito, erro e falha. Apesar de parecerem iguais, eles possuem significados
diferentes. “Engano é uma ação humana que introduz um defeito no software. Defeito é um
conjunto de instruções no software que, ao ser executado, pode causar uma falha. Erro é um
estado incorreto de execução do software que pode produzir um resultado incorreto, isto é,
pode levar a uma falha no software. Falha é a ocorrência de uma diferença entre o resultado
observado do software e o resultado especificado pelos requisitos.” [9]
Resumindo os termos engano, defeito, erro e falha, pode-se dizer que “um engano
introduz um defeito no software que, quando ativado, pode produzir um erro que, se
propagado até a saída do software, constitui uma falha.” [9]
2.1.4.1.2 Qualidade de Processo
Um processo bem escrito e estruturado não garante que os produtos produzidos serão
de boa qualidade, mas é um indicativo de que a empresa tem a capacidade de produzir bons
produtos. Quando aplicada de forma correta, a qualidade de processo proporciona muitos
benefícios para a empresa, tais como: aumento da qualidade do produto final, diminuição do
retrabalho, maior produtividade, redução de custos, maior competitividade, maior precisão
nas estimativas.
A qualidade de processo de software é uma atividade da subárea garantia da qualidade,
que faz parte da área de gerência dentro de um processo de desenvolvimento de software. Ela
tem como propósito assegurar que os objetivos planejados no início do projeto serão
cumpridos ao longo do projeto, até o seu final. Fazem parte da qualidade de processo as
auditorias de qualidade, as quais são realizadas por pessoas externas ao projeto que será
auditado. A equipe de qualidade não faz parte da equipe do projeto, diferente da equipe de
18
testes, que faz parte do projeto para garantir a qualidade de produto de software. A qualidade
de processo tem por finalidade realizar auditorias (que verificam a adequação e a
conformidade ao processo).
A qualidade de um software está vinculada a atributos essenciais que devem ser
levados em consideração no projeto de software, para que possam ser aferidos antes, durante e
após o desenvolvimento do mesmo. Esses atributos são: funcionalidade (o software deve
atender às especificações para as quais foi desenvolvido), facilidade de uso (a operação do
software deve ser a mais direta e simples possível, não devendo existir falhas e/ou defeitos),
confiabilidade (tempo durante o qual o software atende aos objetivos para os quais foi
desenvolvido), desempenho (tempo de resposta, consumo de memória e/ou CPU (Central
Processing Unit - Unidade Central de Processamento), capacidade de resolução de
problemas), suportabilidade (facilidade de manutenção, apoio técnico adequado).
Um assunto muito discutido na área da qualidade de software é a relação entre valor e
custo, que conforme Koscianski [10] “abrange os prejuízos causados pela falta de qualidade
de um produto e os custos com que é preciso arcar para garantir um determinado nível de
exigência quanto ao funcionamento do software“. A subárea Garantia da Qualidade é a
responsável por isso, além de assegurar que os objetivos planejados no início do projeto serão
cumpridos ao longo do projeto inteiro, até o seu final.
Segundo Koscianski [10], “o propósito da garantia da qualidade é estabelecer sistemas
para controlar tudo o que ocorre durante o ciclo de vida, com o objetivo de garantir que o
programa que será fabricado fará aquilo que se espera dele”.
2.1.4.2 Modelo de Qualidade de Software
Os modelos de qualidade de software, as normas e os organismos normativos surgiram
para ajudar na definição de um processo de software. “A criação das normas é baseada na
experiência e no trabalho de especialistas de todo o mundo. Elas são a base para especificar
produtos, organizar fornecimento de serviços e para elaborar leis de diversos países. As
normas definem padrões, os quais podem mudar com o passar o tempo. Esses padrões podem
ser de dois tipos, são eles: padrões de facto, que são padrões conhecidos e aplicados na prática
sem precisar se formalizarem como um regulamento ou como uma lei; padrões de jure, que
são padrões escritos seguindo uma regulamentação, transformam-se em leis, e são aprovados
19
por instituições reconhecidas mundialmente e que possuem capacidade para realizar essa
aprovação” [10].
Os organismos normativos são as empresas que escrevem os padrões de jure, as
normas regulamentadas. Dentre os organismos mais conhecidos estão o IEEE (Institute of
Electrical and Electronics Engineers - Instituto de Engenheiros Elétricos e Eletrônicos), a
ISO, a IEC (International Eletrotechnical Commission - Comissão Internacional de
Eletrotécnica) e a ABNT (Associação Brasileira de Normas Técnicas).
Já os modelos de qualidade de software são parecidos com os modelos de processo de
desenvolvimento de software. Eles avaliam a qualidade dos processos de software aplicados
em uma empresa. São considerados padrões de processo. Atualmente, existem vários modelos
de qualidade de software, dos quais o CMMI e o MPS.Br são os mais utilizados e conhecidos,
sendo que o último é de conhecimento apenas do Brasil. Além desses dois modelos também
existem o SPICE (Software Process Improvement and Capability dEtermination - Melhoria e
Capacidade de Determinação do Processo de Software), o CMM (Capability Maturity Model -
Modelo de Maturidade de Capacidade) - que deu origem ao CMMI -, a ISO 9000-3 e o PSP
(Personal Software Process - Processo de Software Pessoal).
Resumidamente pode-se dizer que os modelos de qualidade definem os requisitos a
que o processo deve atender, e tem a possibilidade de se escolher como irá atendê-los, os
modelos possuem flexibilidade em relação a como atender esses requisitos. Além disso, os
modelos, principalmente os estruturados por etapas, definem um caminho evolucionário para
a melhoria do processo.
Uma empresa, ao optar por fazer um processo seguindo um modelo de qualidade, faz
com que esse processo se transforme em um repositório de melhores práticas que vêm sendo
utilizadas ao longo de vários anos com sucesso. Também permite avaliações do processo de
forma objetiva e a detecção de pontos fortes e fracos.
2.1.4.2.1 MPS.Br (Melhoria do Processo de Software Brasileiro)
O MPS.Br é um modelo de qualidade de software brasileiro criado e coordenado pela
SOFTEX (Associação para Promoção da Excelência do Software Brasileiro) em Dezembro de
2003, com o apoio do MCT (Ministério da Ciência e Tecnologia), da FINEP (Financiadora de
Estudos e Projetos) e do BID (Banco Interamericano de Desenvolvimento). Foi criado com o
objetivo de definir um modelo de referência acessível às micros, pequenas e médias empresas
brasileiras, aumentando a competitividade entre elas.
20
Foi criada com base no modelo americano CMMI, adequando-se a realidade
socioeconômica e cultural das empresas brasileiras. Apesar de ter herdado os conceitos do
CMMI, o MPS.Br também se baseia nas normas internacionais ISO/IEC 12207 (de
desenvolvimento de software) e ISO/IEC 15504 - SPICE (de avaliação de processos de
software).
O foco do MPS.Br está na qualidade de processo, uma vez que se acredita que
problemas no processo é que geram defeitos no produtos. Com isso, focando-se na qualidade
do processo uma empresa consegue aumentar a qualidade do produto, diminuir retrabalho,
aumentar a produtividade, reduzir o tempo para atender o mercado, aumentar a
competitividade e melhorar a precisão nas estimativas.
Uma empresa com processo imaturo tem como conseqüências pouca produtividade,
qualidade somente na realização de testes, alto custo de manutenção do produto e riscos na
adoção de novas tecnologias. Já uma empresa que possui um processo maduro tem papéis e
responsabilidades claramente definidos, acompanhamento da qualidade do produto e da
satisfação do cliente, estimativas iniciais para custos, prazo, funcionalidades e qualidade do
produto são, quase sempre, alcançadas com sucesso. Assim, pode-se definir, resumidamente,
que um processo maduro é aquele processo conhecido por toda a empresa, visivelmente
apoiado pela alta administração, possui medidas de produto e de processo, as auditorias são
fiéis ao processo e pode-se adotar de forma disciplinada novas tecnologias.
O MPS.Br está dividido em três componentes, que são: modelo de referência (MR-
MPS), método de avaliação (MA-MPS) e modelo de negócio (MN-MPS). O modelo de
referência está descrito de forma detalhada no guia geral MPS.Br, o qual se encontra
disponível no site da SOFTEX. O modelo de qualidade de software MPS.Br possui sete níveis
de maturidade, que são:
- nível A: Em otimização
- nível B: Gerenciado quantitativamente
- nível C: Definido
- nível D: Largamente definido
- nível E: Parcialmente definido
- nível F: Gerenciado
- nível G: Parcialmente gerenciado.
Esses níveis de maturidade podem ser atingidos por uma empresa gradativamente, por
etapas, começando do nível G e chegando ao nível A, o qual é compatível com o CMMI nível
5. A comparação dos níveis do MPS.Br com os do CMMI pode ser observada através da
21
Figura 2-6. “Defini-se nível de maturidade como sendo o grau de melhoria de processo para
um pré-determinado conjunto de processos no qual todos os objetivos dentro do conjunto são
atendidos” (ISO/IEC 15504-1, 2004).
A estrutura do MR-MPS.Br, conforme descrito pela SOFTEX, é mostrada abaixo, na
Figura 2-7.
Figura 2-6: Estrutura de níveis do MPS.Br e
comparação com os níveis do CMMI. (Fonte: Site -
http://www.webpack.com.br/templates/95/
22
A definição de nível de maturidade já foi dada anteriormente. Processo, nesse
contexto, é “um conjunto de atividades inter-relacionadas, que transforma entradas em saídas”
(ABNT, 1998). A SOFTEX define que cada processo é composto de propósito, que é o
principal objetivo da execução do processo e os prováveis resultados obtidos com a
implementação do mesmo, e de resultado, que é “o resultado observável do sucesso do
alcance do propósito do processo” (ISO/IEC 12207:1995). Em suma, se os resultados
esperados atingem o propósito do processo, o mesmo é considerado implementado.
Define-se capacidade do processo como sendo uma habilidade da empresa para gerir o
processo e atingir seu objetivo, é “uma caracterização da habilidade do processo atingir os
objetivos de negócio atuais ou futuros” (ISO/IEC 15504-1, 2004). A SOFTEX define que
cada capacidade do processo é composta de atributo de processo, que é “uma característica
mensurável da capacidade do processo aplicável a qualquer processo” (ISO/IEC 15504-
Figura 2-7: Estrutura do MR-MPS do modelo de qualidade MPS.Br [17].
23
1,2004), e de resultado, que é o “resultado observável do sucesso do alcance do atributo do
processo” (ISO/IEC 12207:1995).
Cada nível de maturidade envolve um conjunto de processos, capacidades do processo
e resultados esperados. Os níveis de maturidade, como já vistos anteriormente, vão do G ao A.
As capacidades do processo (na verdade, os atributos de processo) vão do AP (Atributo de
Processo) 1.1 ao AP 5.2. Os resultados esperados vão do RAP (Resultados dos Atributos de
Processo) 1 ao RAP 36. E por último, existem vários processos, que são avaliados de acordo
com o nível de maturidade desejado pela empresa. Como esse trabalho está focado no nível F
do MPS.Br (nível almejado pela Dextra Sistemas inicialmente para projetos SCRUM), serão
citados os processos que fazer parte desse nível, que são: gerência de projetos (GPR),
gerência de requisitos (GRE), aquisição (AQU – esse processo é avaliado apenas para
empresas que compram serviços de terceiros, no caso de empresas como fábricas de software
esse processo não é avaliado), gerência de configuração (GCO), garantia da qualidade (GQA)
e medição (MED).
Resumidamente, pode-se dizer que um processo implementado mais uma capacidade
implementada resultam em um nível de maturidade referente ao modelo de referência. Um
processo é considerado implementado se todas as capacidades do processo e resultados
esperados, referente a esse processo, forem considerados totalmente satisfeitos. Se todos os
processos, referentes ao nível de maturidade escolhido pela empresa, estiverem totalmente
satisfeitos, então a empresa será considerada certificada no MPS.Br no nível em que foi
avaliada.
2.1.5 Metodologia ágil de desenvolvimento de software – SCRUM
2.1.5.1 O Manifesto Ágil
O início dos métodos ágeis de desenvolvimento de software está fundamentado nos
princípios descritos no Manifesto Ágil, ocorrido em Fevereiro de 2001. Esse manifesto
aconteceu nos Estados Unidos, quando um grupo de dezessete profissionais, veteranos na área
de desenvolvimento de software se reuniram em uma estação de esqui para discutir maneiras
de melhorar o desempenho de seus projetos. Mesmo cada participante tendo suas próprias
práticas e teorias sobre como fazer um projeto de software de sucesso, todos concordaram
que, em suas experiências anteriores, um pequeno conjunto de princípios sempre era
respeitado quando os projetos davam certo. Kent Beck, Martin Fowler e Ken Schwaber, os
24
três maiores defensores das metodologias ágeis estavam nesse grupo de profissionais que
participaram do manifesto.
Desse manifesto surgiram os doze princípios para desenvolvimento de software de
forma ágil, os quais devem ser seguidos sempre que se utilizar uma metodologia ágil. São eles
[11]:
“1- nossa maior prioridade é satisfazer o cliente através da entrega inicial e contínua
de software suscetível de avaliação;
2- mudanças de requisitos são bem-vindas, mesmo que tardia em desenvolvimento
(isto porque projetos SCRUM são considerados projetos de escopo aberto, diferente
dos projetos que seguem a metodologia tradicional, que são de escopo fechado);
3- entregar software funcionando freqüentemente, de algumas semanas a alguns
meses, com preferência para o curto prazo;
4- empresários e desenvolvedores devem trabalhar juntos diariamente durante o
projeto;
5- construa projetos em torno de indivíduos motivados, dê-lhes o meio ambiente e
suporte que eles precisam e confie neles para fazer o trabalho;
6- o método mais eficiente e eficaz de transmitir informações para e dentro de uma
equipe de desenvolvimento é a conversa face-a-face;
7- software funcionando é a primeira medida de progresso;
8- processos ágeis promovem o desenvolvimento sustentável, patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente;
9- atenção contínua a excelência técnica e bom design melhoram a agilidade;
10- simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é
essencial;
11- as melhores arquiteturas, requisitos e designs emergem de equipes auto-
organizáveis;
12- em intervalos regulares, a equipe reflete sobre como tornar-se mais eficaz, depois
sintoniza e ajusta seu comportamento em conformidade.”
O manifesto ágil também declarou quatro valores essenciais para o desenvolvimento
de software ágil, são eles [11]:
“1- indivíduos e interação entre eles mais que processos e ferramentas;
2- software em funcionamento mais que documentação abrangente;
3- colaboração com o cliente mais que negociação de contratos;
25
4- responder a mudanças mais que seguir um plano.”
O manifesto ágil descreve a essência de um conjunto de abordagens para
desenvolvimento de software criadas ao longo da última década, dentre as quais se destaca o
SCRUM, uma abordagem atualmente muito conhecida e utilizada por muitas empresas de
desenvolvimento de software. Conforme Ken Schwaber [12], criador do SCRUM: "SCRUM é
um processo ágil ou framework para gerenciamento de projetos ágeis. Ele é enquadrado como
um processo para gerenciamento de projetos e certamente não é uma metodologia, se o fosse,
seria muito pesado". Isso porque o SCRUM é um processo imprevisível que possibilita
adaptações de forma a entregar algo de valor ao final e também por ter uma equipe auto-
gerenciável, ao contrário das metodologias tradicionais que possuem uma estrutura de
comando e controle com um futuro previsível. Assim faz com que parte de seus problemas
possam ser identificados mais rapidamente.
2.1.5.2 O esqueleto do SCRUM
Em seu livro, "Agile Project Management with SCRUM" (Gerenciamento ágil de
projetos com SCRUM), Ken Schwaber [12] diz que "o SCRUM trava todas as suas práticas em
um esqueleto iterativo e processo incremental" representado pela Figura 2-8, onde "o círculo
inferior representa uma iteração de atividades de desenvolvimento que ocorrem uma após a
outra. A saída de cada iteração é um incremento do produto. O círculo superior representa a
inspeção diária que acontece durante a iteração, na qual os membros da equipe se reúnem para
inspecionar as atividades e fazer as adaptações apropriadas. A condução da iteração é uma
lista de exigências. Este ciclo se repete até que o projeto não seja mais dividido" [12].
Schwaber [12] considera que "o esqueleto funciona desta forma: no começo e uma
iteração, a equipe revê o que deve ser feito. Em seguida, escolhe o que ela acha que pode se
transformar em um incremento de funcionalidade potencialmente pronto para o uso, até o
final da iteração. A equipe é então deixada sozinha para fazer o seu melhor esforço para o
resto da iteração.”
“No final da iteração, a equipe apresenta o incremento de funcionalidade desenvolvido
para que os stakeholders (membros externos à equipe) possam inspecionar a funcionalidade e
oportunidades de adaptação para que o projeto seja feito" [12]. No SCRUM, a iteração é
chamada de sprint (ciclo). A explicação dada por Schwaber a respeito do que ele chamou de
esqueleto do SCRUM é exatamente tudo o que deve ser feito dentro de um sprint de um
projeto SCRUM.
26
Todo gerenciamento e responsabilidades em um projeto SCRUM são divididos entre
os três papéis existentes no SCRUM, que são o product owner (dono do produto), o team
(equipe) e o SCRUM master (mestre do SCRUM). Ken Schwaber [12] classifica o product
owner como o "responsável por representar os interesses de todos, com uma participação no
projeto e no seu sistema resultante". É ele quem consegue financiamento inicial contínuo do
projeto, através da criação de requisitos globais e objetivos de retorno do investimento (ROI).
A lista de requisitos de um projeto, em SCRUM, chama-se product backlog (lista de itens
pendentes), e o product owner também é o responsável por priorizar os itens que compõem
essa lista, assegurando que a funcionalidade mais valiosa, mais importante, será desenvolvida
em primeiro lugar.
A equipe é responsável por desenvolver as funcionalidades requisitadas pelo product
owner e por descobrir como transformar um item do product backlog em um incremento de
funcionalidade dentro de uma iteração. Uma equipe SCRUM tem que ser auto-gerenciável,
auto-organizada e multifuncional, isto é, todos os integrantes da equipe devem realizar todas
as atividades do projeto, não existem papéis de desenvolvedor, testador, arquiteto, entre
outros. Os membros da equipe são coletivamente responsáveis pelo sucesso de cada sprint e
do projeto como um todo.
E por fim, o SCRUM master, que é quem trabalha para e com a equipe. É o
responsável por auxiliar a equipe e garantir que a mesma está seguindo as práticas do SCRUM
corretamente. Além disso, é também da responsabilidade do SCRUM master remover
qualquer impedimento que a equipe encontra, identificar e auxiliar na resolução de conflitos,
tentar tornar as metas claras para a equipe, garantir que a reuniões diárias ocorrem no mesmo
horário e com duração máxima de 15 (quinze) minutos e assegurar que a equipe está
totalmente funcional e produtiva.
De maneira geral, todos os papéis do SCRUM devem estar comprometidos com o
projeto. As pessoas não devem ser apenas interessadas pelo projeto, senão não estarão
engajadas com o mesmo. Uma história muito conhecida do SCRUM é a do porco e da galinha,
a qual é descrita por Ken Schwaber [12] em seu livro "Agile Project Management with
SCRUM". A história é a seguinte: "uma galinha e um porco estão andando pela estrada. A
galinha diz para o porco, "Você quer abrir um restaurante comigo?"O porco considera a
questão e responde: "Sim, eu gostaria. Como você quer chamar o restaurante?"A galinha
responde: "Presunto e ovo!"O porco para, pensa e responde: "Pensando bem, acho que não
quero abrir um restaurante com você. Eu serei prático e você apenas envolvida". Essa
27
distinção é importante no SCRUM e relevante para insistir sobre a total visibilidade do
SCRUM".
O SCRUM possui alguns novos artefatos que são usados do começo ao fim de um
projeto SCRUM. São eles: a user story (história de usuário), o product backlog, o sprint
backlog (itens pendentes do sprint), o incremento de potencialidade pronto para ser usado no
produto funcional, o release burndown chart (gráfico de manejo do projeto), o sprint
burndown chart (gráfico de manejo do ciclo) e o task board (quadro de tarefas). A user story
é a descrição da funcionalidade do ponto de vista do product owner, são descritas por item de
backlog (itens pendentes) e incluem os critérios de validação de cada item.
O product backlog é a lista principal com todas as funcionalidades (requisitos)
desejadas pelo product owner no produto final, pode-se dizer que o product backlog é uma
lista de requisitos funcionais e não funcionais. O product owner também é responsável por
priorizar os itens do product backlog. Ele é dinâmico e evolui na medida em que o produto e o
ambiente em que será utilizado evoluem, por isso o product backlog inicial é uma mera
estimativa do projeto como um todo.
O sprint backlog é a lista de tarefas que a equipe se comprometeu a concluir no sprint
corrente. Itens do sprint backlog são retirados do product backlog se baseando na prioridade
definida pelo product owner. A definição dos itens que farão parte do sprint backlog do sprint
corrente são definidos durante a reunião de planejamento. Depois de definidos os itens, a
equipe divide igualmente as tarefas. No final do sprint as tarefas realizadas pela equipe se
tornarão um incremento de funcionalidade potencialmente pronto para ser colocado no
produto ou até mesmo pronto para ser usado.
O incremento de potencialidade pronto para ser usado é o incremento construído
durante todo o sprint, o qual pode ser implementado imediatamente depois da entrega, caso o
product owner deseje. Isso faz com que o incremento tenha um código perfeitamente testado,
bem estruturado e bem escrito, que tenha sido construído dentro de um executável e onde a
funcionalidade da operação do usuário é totalmente documentada.
O release burndown chart é um gráfico onde a equipe acompanha seu progresso
comparado com o planejado no início do projeto. É um gráfico 2D (duas dimensões) onde o
eixo horizontal representa os sprints do projeto e o eixo vertical apresenta o total de trabalho
restante no início de cada sprint, normalmente representado por pontos. O release burndown
chart funciona muito bem em vários projetos e equipes diferentes, porém se o projeto
apresenta muitas mudanças de requisitos, ele não funciona muito bem, por isso nem é
indicado para projetos com esse perfil.
28
O sprint burndown chart é a representação gráfica do trabalho restante no sprint
corrente, o qual é calculado diariamente. O eixo vertical do gráfico representa as horas de
esforço restantes no sprint. O eixo horizontal representa os dias do sprint. O gráfico do
burndown (manejo) deve ser representado por uma linha saindo do início do sprint com as
horas iniciais, descendo até o último dia do sprint, sem deixar horas sobrando e, de
preferência, sem faltar horas, ou seja, o esperado é chegar ao último dia do sprint com zero
hora. Resumindo, o ideal é que o gráfico de burndown do sprint seja uma linha reta
decrescente.
O task board é um quadro de tarefas que mostra todo o trabalho que a equipe está
desenvolvendo durante um sprint. Esse quadro é atualizado diariamente. Usualmente o task
board é um quadro branco, o qual é preenchido manualmente com os itens de backlog escritos
em post-it (papéis com cola na parte superior). Cada linha do quadro é um item do product
backlog. Cada coluna é o estado de cada item de backlog. Normalmente, o quadro possui as
seguintes colunas:
- User Story: nessa coluna são colocadas as user stories;
- To do (a fazer): nessa coluna ficam todos os itens do sprint backlog que deverão ser feitos
durante o sprint;
- In process (Em processo): post-it do item do sprint backlog que está em andamento (quando
alguém da equipe decide por fazer um item do sprint backlog, ela tira o post-it referente a esse
item da coluna "to do" e coloca na coluna "in process";
- To verify (Para verificar): quando o item do sprint backlog já foi desenvolvido e falta testar;
- Done (Feito): quando o item do sprint backlog já foi desenvolvido, testado e não foi
identificado mais nenhum defeito, ele é colocado na coluna "done", que significa que o item
já está concluído e pronto para ser entregue ao product owner. Os itens que ficam nessa
coluna são removidos no final de cada sprint.
2.1.5.3 Atividades e Fluxo do SCRUM
O SCRUM possui cinco atividades bem definidas, são elas: estimation meeting
(reunião de estimativas), sprint planning (planejamento do sprint), daily SCRUM (reunião
diária), sprint review (revisão do sprint) e sprint retrospective (retrospectiva do sprint). A
estimation meeting, que é a reunião de estimativas, é a primeira atividade que acontece dentro
do ciclo do SCRUM. Nela, o tamanho dos itens de product backlog é estimado pela equipe e
posteriormente são priorizados pelo product owner. Todos os membros da equipe fazem uma
estimativa por pontos de cada user story.
29
É importante deixar claro que, em SCRUM, as estimativas são baseadas na
complexidade de cada item de backlog e não pelo tempo que pode ser gasto para desenvolvê-
lo. A forma mais comum de se fazer estimativa em SCRUM é através do planning poker
(planejamento com baralho SCRUM). O planning poker funciona da seguinte maneira:
- um baralho é fornecido a cada membro da equipe e cada carta tem um valor de
estimativa válido. Esse baralho não é um baralho comum, mas sim um baralho
específico para a prática SCRUM, o qual possui cartas com os seguintes valores: ?
(quando a pessoa não sabe quantos pontos vale determinada user story), 0 (quando não
requer nenhum esforço), 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, esses números representam
o esforço em pontos;
- cada user story é lida e discutida rapidamente pela equipe;
- cada membro da equipe escolhe uma carta representando sua estimativa;
- quando todos da equipe já tiverem escolhido sua estimativa, eles mostram sua
estimativa ao mesmo tempo;
- as diferenças das estimativas são discutidas (principalmente os valores discrepantes);
- faz-se reestimativas até que toda a equipe chegue a um consenso.
A sprint planning, que é a reunião de planejamento do sprint, é a segunda atividade
executada no fluxo de atividades do SCRUM. Ela é dividida em duas partes, a sprint planning
1, que é onde se define o objetivo do sprint e onde são selecionados os itens do product
backlog. Na verdade essa parte da reunião acontece apenas no início do projeto, pois nela
também são definidas a quantidade de sprints que terá o projeto, os dias das sprint review e
retrospectivas e também é feito o agendamento das reuniões diárias (local e hora).
A segunda parte da reunião de planejamento ocorre todo início de sprint, nela são
definidas as tarefas de cada user story para criar o sprint backlog. O ideal é que a tarefa dure
apenas um dia, caso a tarefa seja maior que um dia, deve-se quebrar a tarefa em duas tarefas
menores. A reunião como um todo não deve ultrapassar oito horas, sendo de quatro horas a
duração máxima de cada parte da sprint planning.
A daily SCRUM é a reunião diária que deve ser realizada seguindo as exigências do
SCRUM. Ela deve ser realizada em pé, com todos os membros da equipe juntos, deve ter
duração de no máximo quinze minutos e deve ser sempre no mesmo local e horário. O ideal é
que a reunião seja realizada logo pela manhã (no início do dia), uma vez que ela apóia a
determinar as atividades do dia, ou então no final do dia, pois os membros da equipe falarão o
que foi feito durante o dia e o que farão no dia seguinte. O objetivo dessa reunião é atualizar e
inspecionar o progresso da equipe. Todos os impedimentos devem ser apontados, porém
30
soluções de problemas maiores ou dúvidas ocorridas durante o dia devem ser discutidas fora
da reunião diária.
Durante essa reunião todos os membros da equipe, um de cada vez, devem responder a
três questões básicas: O que fez ontem? O que vai fazer hoje? Existe algum impedimento?
Assim, ao final da reunião a equipe tem uma melhor visão do trabalho que foi concluído e o
que ainda falta fazer.
A sprint review é a reunião de revisão do sprint. Ela é realizada todo final de sprint,
onde a equipe apresenta para o product owner os resultados obtidos durante o sprint e
demonstra as funcionalidades e arquiteturas desenvolvidas. Essa reunião é informal, isto é,
não precisam ser geradas ata nem apresentação em slides e deve ser feita em, no máximo,
duas horas.
Durante a reunião o projeto também é avaliado, tendo como base o objetivo do sprint
definido na reunião de planejamento, isto é, espera-se que a equipe tenha concluído todos os
itens do sprint backlog. Nessa reunião também pode ser solicitado pelo product owner a
inclusão de uma nova funcionalidade ou mesmo uma alteração da funcionalidade feita, essa
nova solicitação deve ser adicionada como um novo item de backlog.
Por fim, temos a última atividade a ser realizada dentro de um ciclo SCRUM, que é a
sprint retrospective, a reunião de retrospectiva. Essa reunião também é realizada no final do
sprint, preferencialmente depois da sprint review. O objetivo da retrospectiva é aprender com
a experiência anterior, melhorando a produtividade da equipe. É obrigatória a presença de
todos os membros da equipe na reunião.
A retrospectiva também é uma oportunidade para a equipe discutir o que está dando
certo e o que não está, e consentir em ações para mudança. Por isso, é comum que na reunião
sejam abordadas e discutidas as seguintes questões: O que aconteceu?, O que funcionou bem?
e O que precisa ser melhorado?
O fluxo de um projeto SCRUM, o qual pode ser visto na Figura 2-8, inicia-se com uma
visão do sistema a ser desenvolvido, a qual é fornecida pelo product owner, que também é
responsável pelo financiamento do projeto e por entregar a equipe um product backlog. O
product owner também é responsável por priorizar os itens do product backlog, para que os
itens com maior probabilidade de gerar altos valores sejam desenvolvidos primeiro. Todas
essas atividades são realizadas no início do projeto, na chamada estimation meeting.
31
A seguir, iniciam-se os ciclos do SCRUM, que são os sprints. Todo o trabalho é feito
nos sprints. Cada sprint deve ter duração de 2 (duas) ou 4 (quatro) semanas, no máximo,
sendo que todos os sprints de um mesmo projeto devem ter a mesma duração.
Cada sprint é iniciado com uma sprint planning, onde product owner, SCRUM master
e equipe se juntam para decidir o que será feito no sprint. Selecionando a partir do product
backlog priorizado, o product owner diz à equipe o que é desejado e a equipe responde para o
product owner o quanto do desejado ela consegue desenvolver no sprint.
Seguindo o fluxo do SCRUM, vêm as daily SCRUM, que devem ser realizadas,
rigorosamente, todos os dias no mesmo horário e no mesmo local, com duração máxima de
quinze minutos. Por fim, no último dia do sprint, são realizadas as reuniões de sprint review e
logo em seguida a sprint retrospective.
Assim, estará terminado o primeiro ciclo do SCRUM, isto é, o primeiro sprint do
projeto. Todas essas atividades se repetem nos demais sprints, até chegar ao último sprint do
projeto, que é quando o projeto se encerra.
2.2 Estudo de Caso
2.2.1 O processo SCRUM da empresa PowerLogic
Figura 2-8: Fluxo de um projeto SCRUM. (Fonte: Site -
http://www.b2ml.com.br/b2ml/Pagina.do?idSecao=54)
32
Para o desenvolvimento do estudo de caso da Dextra Sistemas, detalhado na próxima
subseção, foram realizadas várias pesquisas, a fim de encontrar algum material sobre caso de
sucesso de empresas que conseguiram conquistar o MPS.Br, principalmente o nível F,
utilizando processo para projetos SCRUM em desenvolvimento ágil de software. Foi muito
difícil encontrar material sobre esse assunto.
Somente a empresa PowerLogic conseguiu o MPS.Br nível F de um processo SCRUM.
Sendo assim, foi utilizado o processo desenvolvido por essa empresa como base deste
trabalho, uma vez que o objetivo do mesmo é bem semelhante ao ocorrido com a empresa
PowerLogic.
Conforme publicado pela SOFTEX [13], “a PowerLogic Consultoria e Sistemas é uma
empresa brasileira, com sede em Belo Horizonte, com 12 anos de existência atuando no
segmento de desenvolvimento de produtos e soluções e de serviços de fábrica de software" e
seu objetivo era combinar a agilidade natural dos métodos ágeis e a maturidade adquirida por
meio do MPS.Br, constituindo uma experiência concreta na busca de resultados positivos para
processos de TI (tecnologia da informação) e para o programa de Melhoria Contínua de
Processos MPS.Br Pioneira em métodos ágeis.
A PowerLogic já era certificada pelo MPS.Br nível F para o processo que segue o
RUP, o qual já era utilizado há um certo tempo pela empresa. A utilização de SCRUM na
empresa passou a ser maior uma vez que começaram a surgir problemas com
imprevisibilidade, ruídos de comunicação, documentações extensas que pouco ajudavam no
processo, que precisavam ser encarados de forma diferente e que exigiam que não seguisse
passos semelhantes entre os diversos projetos existentes, que possuem peculiaridades que
apenas com a implementação afloram.
"Além disso, tarefas do processo de desenvolvimento de software fazem parte de um
processo criativo, não linear e não palpável, fazendo com que modelos incrementais e
iterativos se apresentem como a melhor solução diante da realidade dos projetos
PowerLogic." [13]. Isso fez a empresa buscar a certificação MPS.Br para esse novo processo.
Buscando associar os conceitos do MPS.Br com os conceitos do SCRUM, "os
princípios e valores de métodos ágeis foram relacionados e mapeados em todo o ciclo de vida
do software a um ou mais de um princípio do Manifesto da Agilidade verificando sua
aplicabilidade. Estes princípios abordam aspectos do desenvolvimento como análise, projeto,
implementação, testes, além de outros, como gerenciamento de projetos e de métricas de
satisfação do produto final entregue” [13].
33
“As áreas de processo do MPS.BR foram cuidadosamente relacionadas com as
características dos métodos ágeis. Desse modo, foram discutidos gerência de requisitos,
planejamento e acompanhamento de projetos, gerência de configuração, garantia de qualidade
de software e medição e análise, presentes no nível F do MPS.BR e sua aplicabilidade ao
SCRUM" [13].
A adoção de modelos de qualidade de software, como o MPS.Br, traz para a empresa
mais formalismo ao processo por ela utilizado, agregando valor com a qualidade do software
desenvolvido. Assim, pode-se dizer que, apesar dos modelos de qualidade e metodologias
ágeis possuírem fundamentos inicialmente divergentes, eles puderam complementar um ao
outro e estabelecer o equilíbrio no processo de desenvolvimento implantado na empresa.
Para desenvolver um processo para projetos SCRUM compatível com o MPS.Br nível
F sem aferir os princípios ágeis, a PowerLogic contratou uma empresa de consultoria para
auxiliá-los nesse desenvolvimento. Inicialmente, foi feito um levantamento e desenho do
processo já existente, o qual é aprimorado a cada dia e aplicado em projetos para verificar a
adequação do mesmo. Essas melhorias só são percebidas quando o processo está inteiramente
institucionalizado e funcionando em um fluxo contínuo.
Analisado inicialmente, o MPS.Br parecia muito formal e pouco aderente à nova
realidade da empresa, mas era necessário por causa de seus resultados comprovados e da
grande aceitação por todos os clientes. Era difícil para as pessoas envolvidas nesse processo
entender como fazer um processo que continuasse com os benefícios do SCRUM e que
conseguisse atingir um nível de maturidade do MPS.Br. Mas a empresa chegou à conclusão
de que essa fusão não era tão impossível, uma vez que a mesma entende que o MPS.Br diz "o
que fazer" mas não impõe o "como fazer" enquanto que as metodologias ágeis contém
informações específicas de "como fazer".
Ao comparar as metodologias ágeis com os modelos de qualidade, a PowerLogic
listou os cinco maiores desafios, que são:
- GPR (gerenciamento de projeto): Como gerenciar com base em "planejamento
contínuo" em lugar do "grande plano inicial"?
- GPR: Como "abraçar" a mudança e "controlá-la" ao mesmo tempo?
- GRE (gerenciamento de requisitos): Como estimar requisitos que são parcialmente
conhecidos?
- GQA (gerenciamento da qualidade): Como averiguar qualidade de produto em um
processo "iterativo" com time-boxed (tempo fechado)?
- MED (medição e análise): O que são indicadores importantes em um processo ágil?
34
Para iniciar o desenvolvimento do processo ágil, a PowerLogic partiu da idéia de que
"formalidade não é sinônimo de conformidade" e que "informalidade não é sinônimo de
agilidade". Com isso, a empresa pensou na seguinte forma de desenvolvimento do processo:
inserir em cada disciplina do nível F do MPS.Br (GPR, GRE, GCO, GQA e MED) os
princípios do manifesto ágil com ênfase no SCRUM. A PowerLogic também se baseou nas
lições aprendidas em processo de desenvolvimento de software unificado e as lições
aprendidas em processos ágeis de desenvolvimento de software. Essas lições são descritas, de
forma resumida, a seguir.
No final, o resultado foi positivo, e a PowerLogic conquistou o nível F do MPS.Br
para um processo ágil. Ainda nesse capítulo será descrito, de forma resumida, o processo ágil
desenvolvido pela PowerLogic.
PowerLogic - Lições aprendidas em Processo de Desenvolvimento de Software
Unificado (experiência da empresa nas décadas de 80 e 90):
“1- Processos em cascata não são adequados para o desenvolvimento de
softwares complexos, porém, atualmente, a maior parte dos projetos
corporativos caem nessa categoria;
2- Projetos complexos são melhor gerenciados por Processos Empíricos e
Iterativos;
3- O RUP foi o primeiro Processo Iterativo a se popularizar, no entanto, sua
extensão e complexidade usualmente distraem a atenção sobre seu caráter
iterativo. A grande maioria das implementações de processos unificados
terminam como bisnetos UML dos processos em cascata;
4- Contratos 'escopo fechado' x Necessidades técnicas: o modelo de Fábrica de
Software pressupõe a separação física de especialidades, dificultando ou
impossibilitando uma abordagem verdadeiramente iterativa;
5- Software é 50% introspecção e 50% comunicação. A comunicação por
escrito é boa para a criação de memória, mas é o canal menos eficaz para
obtenção de entendimento;
6- Documentação realmente útil em desenvolvimento de software é obtida por
conseqüência de atividades produtivas e não como um esforço à parte.
Atividades meramente documentacionais tendem ao desperdício” [14].
PowerLogic - Lições aprendidas em Processos Ágeis (experiência da empresa em
2001-2008):
35
“1- O Manifesto Ágil sumariza de forma sensata a experiência de seus
dezessete autores em projetos reais, sendo consistente com a experiência da
grande maioria das empresas, como a PowerLogic, que atuam com
metodologia aplicada, focada em resultados;
2- O caráter sensato de ênfase do Manifesto Ágil tem sido ignorado em
algumas posturas radicais que, precipitadas, chegam a confundir agilidade com
mera informalidade;
3- Duas pequenas revisões de um dos princípios do Manifesto Ágil foram
realizadas, através da experiência adquirida: indivíduos e interações continuam
mais valiosos do que processos e ferramentas, mas muitas ferramentas se
mostraram fundamentais para práticas de metodologias ágeis; e não espere
auto-organização e soluções técnicas com alta conformidade de equipes
frágeis, de perfil mediano. A ênfase em indivíduos e interações exige ênfase na
boa formação de equipes e na preservação de talentos;
4- Processos ágeis são mais leves (possuem menos práticas) porém exigem alto
índice de disciplina. Suas motivações são mais difíceis de explicar e, por
conseqüência, de se compreender” [13].
O processo ágil desenvolvido pela PowerLogic está dividido em quatro fases bem
definidas, que são: pre-game (pré-jogo), development (desenvolvimento), monitoramento e
controle e post-game (pós-jogo). Na Figura 2-9 a seguir, pode ser observada uma ilustração
do ciclo de vida do processo elaborado.
No pre-game é feita a concepção arquitetural e organização inicial de um novo release
(projeto) de um produto baseado na lista de product backlog elaborado para o mesmo, seguido
de uma estimativa inicial de prazo e custo. Nessa fase também são levantados e identificados
os riscos e as ações para minimizar o impacto dos mesmos. Também se defini nessa fase a
Figura 2-9: Ciclo de vida dos projetos de desenvolvimento de software – área de
produtos [14].
36
equipe do projeto (SCRUM team – equipe SCRUM). O pre-game é como a fase de concepção
do RUP, porém é mais curta e com duração fixa de 7 a 15 dias.
A fase development tem o objetivo de colocar em prática o que foi planejado no pre-
game. É nessa fase que o principal acontece. É realizada de forma iterativa, através de ciclos
de time-boxed chamados de sprints que, no caso do processo da PowerLogic, tem duração de
trinta dias corridos. Em cada sprint são executadas atividades de refinamento dos itens do
product backlog, análise, projeto, desenvolvimento e testes, cujo resultado final deve ser um
incremento do produto funcionando, o qual será apresentado para o product owner na reunião
de sprint review que acontece em todo final de sprint. Durante os sprints também são
realizadas as reuniões de daily SCRUM que ocorrem diariamente, onde são discutidas as
tarefas que já foram realizadas e que ainda serão feitas.
A fase de Monitoramento e Controle compreende as atividades de medição e análise e
de gestão, que verificam se as atividades estão sendo produtivas. Ela garante o bom
andamento do projeto em relação ao planejado nas reuniões de planejamento, que ocorrem
todo início de sprint. Esse acompanhamento é feito através das reuniões de daily SCRUM,
sprint review, release review (revisão do projeto - que acontece no encerramento do projeto) e
retrospective meeting (que também ocorre no final de cada sprint, após a sprint review).
Diversas medidas são coletadas diariamente ao longo do projeto. Informações do tipo
"previsto x realizado" são disponibilizadas para o SCRUM master e para o product owner. Os
quadros brancos também são uma forma de monitoramento, uma vez que eles "mantêm as
informações mais importantes disponíveis, afixados em local visível para toda a organização"
[13].
E por último vem a fase post-game, que é onde ocorre a entrega final do produto
(embalagem, documentação, liberação para o mercado). Nessa fase também é feita a avaliação
do projeto como um todo, refletindo sobre as práticas empregadas, indicadores finais e lições
aprendidas de uma forma geral. É nessa fase que ocorre a reunião de release review, que
consiste em uma demonstração do produto final do ponto de vista do cliente, discussões e
levantamento de lições aprendidas. O resultado final dessa fase é a documentação final, que é
um CD com o produto e funcionalidades já testadas.
Em relação às disciplinas contempladas no MPS.Br nível F (GPR, GRE, GCO, GQA e
MED), as alterações feitas pela PowerLogic, para adaptá-las ao processo ágil que estava
sendo desenvolvido, serão apresentadas a seguir. Na disciplina de gerência de projetos (GPR)
foram adotados os conceitos de release e release plan (plano do projeto).
37
O planejamento será realizado via release planning (reunião de planejamento realizada
no início do projeto, para definição dos itens do product backlog, equipe, quantidade de
sprints) e sprint planning (reunião de planejamento de sprint, realizada todo início de sprint,
onde são definidos e estimados os itens que sairão do product backlog e farão parte do sprint
backlog), sendo que esse último está dividido em sprint planning 1 (definição e priorização) e
sprint planning 2 (estimativas).
O acompanhamento contínuo é feito através de inspeção direta do SCRUM master, o
acompanhamento formal diário é feito através das reuniões diárias e o acompanhamento
mensal via sprint review e release review. O quadro branco, na PowerLogic chamado de agile
radiator (radiador ágil), também é uma forma de acompanhamento diário do projeto.
É feita também uma reserva de tempo no planejamento de cada sprint para que os
impedimentos possam ser discutidos e solucionados. Algumas outras práticas específicas da
PowerLogic são: apropriação de horas diárias, medição de produtividade individual, matriz de
competências.
A disciplina de gerência de requisitos (GRE) possui como pontos chaves a utilização
de pocker planning (planejamento com baralho) para realizar as estimativas dos itens de
backlog, a quebra de um item do product backlog em atividades que possam ser completadas
por cada membro da equipe em um dia, captura contínua de product backlog. Um ponto
importante é em relação à forma como o processo ágil da PowerLogic trata as solicitações de
mudança.
As mudanças ao final ou dentro do sprint que não afetam o objetivo do sprint são
consideradas solicitações de mudança leve, isto é, não requerem uma solicitação de mudança
propriamente dita. Solicitações de mudança somente são requeridas em situações críticas, por
exemplo, quando a equipe não vai conseguir cumprir o objetivo do sprint, ou para mudanças
de configuração, por exemplo, em alteração de versão de framework (estrutura). A
PowerLogic adota como prática adicional a rastreabilidade do requisito ao código, através de
uma matriz de rastreabilidade.
Em relação à disciplina de garantia da qualidade (GQA) foi introduzido o conceito de
post-sprint (pós-ciclo) de QA, que são iterações de quinze dias (time-boxed) de QA, após cada
sprint. São realizados testes funcionais automatizados. Os erros encontrados pelo QA contam
pontos contra a equipe, já os erros capturados pelo cliente contam pontos contra o QA. Isso
tudo em relação à qualidade de produto. Já as práticas de qualidade de processo devem auditar
o desempenho do processo, os produtos de trabalho e atividades previstas em todas as fases. A
equipe de QA deve ser compartilhada para todos os projetos, deve garantir que os quadros
38
brancos (agile radiators) estão sendo usados e deve fornecer um relatório à Diretoria Técnica
da PowerLogic contendo os resultados das auditorias.
Na disciplina gerência de configuração (GCO) são utilizados a integração contínua e o
controle de código fonte, componente, executável, release plan, documentação e mídia
CD/DVD dos produtos. As práticas de gerência de configuração devem ser rigorosas e
completas, por se tratarem de produtos de mercado também exigem especial controle de
versão. Os itens de configuração são definidos em nível de produto e não de projeto, caso o
produto tenha um projeto subseqüente, deve-se definir somente alterações em versões de itens
anteriores, evitando assim a redundância. É importante ressaltar que as alterações de versões
de itens de configuração devem ser feitas formalmente, através de uma solicitação de
mudança que deverá ser aprovada, para evitar a falta de sincronismo e integridade provocada
pelas modificações não controladas.
Por fim, a disciplina de medição e análise, onde foram definidos indicadores ágeis, que
são assiduidade de daily SCRUM, remoção de impedimentos, freqüência de integração e
inspeção, e indicadores clássicos, que são produtividade (velocidade x qualidade), metas e
previsto x realizado. Os resultados tangíveis obtidos pela medição devem contemplar o
desempenho da equipe como um todo e não somente indicadores individuais e devem ser
divulgados durante as reuniões de retrospectiva e analisados pela equipe, coletivamente. A
PowerLogic também criou a figura do Gerente de Processo que, como apoio ao SCRUM
master ajuda no incentivo e catequese de práticas ágeis, e como apoio ao assessor da diretoria,
ajuda na garantia de resultados da implantação do processo.
Após a implantação e utilização contínua do processo ágil desenvolvido pela
PowerLogic, conseguindo resultado positivo na avaliação MPS.Br nível F, foi possível
observar melhorias significativas em relação ao desempenho da equipe e na qualidade do
produto final. Na fase de pre-game se destacaram as seguintes melhorias: planejamento
antecipado da disponibilidade da equipe, levando em consideração impedimentos como horas
de trabalho, férias, horas gastas em reuniões; garante a participação real de cada membro
envolvido; alinhamento das metas, planejamento e definição do objetivo de cada sprint com o
consenso de todos os envolvidos promove o comprometimento e a visibilidade; a definição de
indicadores da equipe e individuais estimula o alcance de melhores resultados; e a
identificação e categorização dos riscos anteciparam possíveis problemas.
"Os indicadores criados para as áreas de processo Gerência de Projetos e Gerência de
Requisitos, principalmente, proveram importante feedback (retorno) para a equipe e criou
metas a serem alcançadas por cada um. Indicadores de Gerência de Configuração asseguraram
39
que as práticas determinadas foram seguidas provendo maior controle das versões geradas e
integração contínua. As práticas de Gerência de Qualidade para Processo garantem a
institucionalização e desempenho do processo e produtos de trabalho, através das auditorias
nas áreas envolvidas" [13].
As melhorias que merecem destaque na fase de development são: gestão a vista através
do quadro branco (Agile Radiator), promovendo o feedback real e imediato; realização de
reuniões de inspeção contínua (daily SCRUM); integração contínua trouxe resultados
importantes e informações essenciais para o planejamento e acompanhamento do projeto;
rastreablidade entre requisito e código fonte, gerando uma matriz de rastreabilidade facilita a
análise de impacto das mudanças; integração da equipe, estimulando a troca de conhecimento
e a utilização de pair programming (programação em par) entre os membros da equipe;
conceito de código compartilhado é importante, uma vez que o mesmo poderá ser modificado
ou revisado por diferentes membros da equipe; definição de um objetivo, tanto de cada sprint
como do projeto como um todo, possibilita melhor visibilidade e norteia o caminho a ser
seguido por cada membro da equipe.
No post-game a melhoria mais importante observada foi a realização da reunião de
retrospectiva, que acontece no final de cada sprint e onde ocorre a coleta das lições
aprendidas do projeto, avalia-se o que deu certo e o que deu errado, alimentando o projeto e o
processo e avalia também se algo está sendo feito em relação ao que foi levantado na reunião
de retrospectiva anterior. Podem-se observar também melhorias organizacionais nas áreas de
gerência da qualidade de processo e de produto e de gerência de configuração. A nova área
gerência da qualidade de processo criou um desconforto saudável, "fazendo com que as
pessoas dêem o melhor de si e concretize ações para o objetivo maior organizacional" [13].
Essa área "provê apoio total à condução dos projetos, executa a manutenção do
processo, aceitando sugestões e inserindo melhorias necessárias e executa auditorias para
garantia da execução do processo" [13]. Já a área de gerência da qualidade de produto "provê
suporte à qualidade dos produtos com testes automatizados, manuais e de integração" [13]. E
por último a área de gerência de configuração que garante a integridade dos itens de
configuração do release, apóia a geração de baselines (pacote) e a integração contínua.
A experiência positiva vivida pela empresa PowerLogic, tanto em relação ao processo de
implantação do modelo de qualidade MPS.Br nível F quanto aos bons resultados obtidos com
essa fusão (MPS.Br com SCRUM), fez com que a empresa colocasse como próximo objetivo
a melhoria do processo ágil desenvolvido com foco na avaliação para obtenção do nível C do
MPS.Br.
40
3 ELABORAÇÃO DA SOLUÇÃO
3.1 Histórico da Dextra Sistemas
A empresa onde foi desenvolvido esse trabalho de conclusão de curso é a Dextra
Sistemas. A Dextra está presente no mercado de TI desde 1995. Foi fundada como uma
empresa especializada em consultoria nas áreas de integração de sistemas corporativos.
Atualmente, a mesma possui três linhas de atuação, que são: integração e desenvolvimento de
sistemas sob medida, treinamento em TI e consultoria em TI.
A excelência dos serviços prestados pela Dextra está apoiada em profissionais
especializados, processos estabelecidos e uma larga experiência em projetos. O capital
humano é um elemento chave na estratégia de atuação da empresa, que investe continuamente
na atualização e capacitação de seus profissionais, propiciando um ambiente encorajador para
serem os melhores naquilo que realizam.
A alta qualidade dos serviços prestados aliada ao compromisso em gerar resultados e
proporcionar maior vantagem competitiva a seus clientes tem propiciado a Dextra
relacionamentos duradouros e bem sucedidos com empresas de diversos segmentos de
mercado.
A Dextra teve um crescimento muito expressivo nos anos de 2006 e 2007 e com isso
surgiu a necessidade da definição e implantação de um processo mais formal. A empresa já
contava com o ProUD (Processo Unificado Dextra) que se baseava fortemente no RUP. A
versão 1.0 do ProUD era bastante enxuta e se aplicava muito bem ao tamanho e características
da empresa e de suas equipes de trabalho até então.
O objetivo da evolução e melhoria do processo da Dextra era ter um nível maior de
formalização das atividades e papéis, bem como coletar e analisar indicadores de projeto que
dessem a visibilidade necessária em relação à qualidade do produto, pontualidade nas entregas
e previsibilidade de custo.
O resultado de um ano de trabalho foi o ProUD 2.0, o qual foi lançado oficialmente na
Dextra em Setembro de 2008. Essa nova versão do processo possui quatro grandes fases, que
são: planejamento, refinamento da solução, execução e encerramento.
Um dos objetivos do projeto de melhoria e evolução do ProUD, era a de implementar
também um modelo de qualidade reconhecido no mercado de software. A empresa escolheu o
41
MPS.BR por ser um programa brasileiro, voltado para a realidade do mercado de pequenas e
médias empresas de desenvolvimento de software.
A Dextra obteve o certificado de qualidade de software MPS.BR nível F, ratificando
assim todo seu processo de desenvolvimento de sistemas. Teve como principais pontos fortes:
a) o conjunto de ferramentas adotado, que automatiza as atividades e traz maior controle e
ganho de produtividade da equipe;
b) o envolvimento das equipes dos projetos com o processo.
Ambos eram as grandes preocupações da Dextra desde o início do desenvolvimento do
processo.
No início de 2008 a Dextra teve o primeiro contato com metodologias ágeis, iniciando
um projeto totalmente SCRUM. Com a disseminação das metodologias ágeis no mercado,
diversos clientes começaram a procurar por essas metodologias para realização de seus
projetos. Por esse motivo e com a experiência positiva do projeto em SCRUM que já estava
em andamento, a Dextra resolveu implantar a metodologia ágil SCRUM.
Atualmente quase todos os projetos desenvolvidos na Dextra são em SCRUM. O
sucesso dessa metodologia se deve, principalmente, ao fato dos projetos serem de escopo
aberto, aceitarem tranqüilamente mudanças solicitadas pelo cliente e terem pelo menos uma
funcionalidade pronta a cada duas semanas (no caso da Dextra, adotou-se que o ideal é os
sprints terem duração de duas semanas).
Com esse novo cenário de projetos da Dextra, se tornou importante pensar a respeito
de uma padronização para a aplicação do SCRUM nos projetos da empresa, uma vez que até
os dias de hoje cada equipe, cada projeto aplica o SCRUM de uma forma diferente, mas
sempre respeitando os princípios definidos para essa metodologia. Assim surgiu a idéia de se
criar um processo para projetos SCRUM, uma vez que o processo de desenvolvimento de
software já existente na empresa, e já avaliado no MPS.Br nível F, é baseado no RUP e não se
encaixa para projetos SCRUM.
Em meados de Abril de 2009 iniciaram-se estudos sobre SCRUM, como criar um
processo para essa metodologia e como conseguir um processo SCRUM que também possa
ser, futuramente, avaliado no MPS.Br nível F. Juntos, o SEPG (Software Engineering Process
Group – Grupo de Processos de Engenharia de Software), a área de qualidade e profissionais
qualificados em SCRUM, em meados de Agosto de 2009, deram início ao desenvolvimento do
processo para projetos SCRUM da Dextra.
O objetivo era criar um processo simples, que não afete a agilidade do SCRUM mas
também que não comprometem as exigências impostas pelo MPS.Br nível F. A idéia de se
42
criar um processo é que todos os projetos gerem documentos com templates padrões, sigam
realmente todos os princípios do SCRUM e trabalhem de maneira similar, para não haver
divergências entre os projetos em relação a forma de se aplicar SCRUM dentro da Dextra.
O objetivo da Dextra agora é gerar uma primeira versão desse processo que, como
aconteceu com o processo baseado no RUP, será atualizado, incrementado e melhorado com o
passar do tempo e à medida que o processo for sendo utilizado pelos projetos, realizando as
adaptações necessárias. Em um futuro não muito distante, quando o processo para projetos
SCRUM já estiver bem consolidado, a expectativa da Dextra é conquistar o MPS.Br nível F
também para esse processo, garantindo assim uma maior qualidade dos projetos SCRUM para
seus clientes e podendo também conquistar novos clientes.
3.2 Motivação para a elaboração de um processo para projetos SCRUM na
Dextra
A grande motivação que levou a Dextra a querer implantar um processo também para
os projetos em SCRUM foi o sucesso conquistado com o processo de desenvolvimento
ProUD, que segue o modelo RUP. Depois do mesmo ter sido avaliado no MPS.Br nível F,
novos clientes começaram a procurar e a se interessar pelos softwares produzidos pela
empresa. Ter um processo que foi avaliado por um modelo de qualidade traz muita
credibilidade para a empresa, os clientes ficam mais seguros em relação ao produto que estão
comprando e têm garantia de que estão adquirindo um software com qualidade.
Além disso, a necessidade de todos os projetos seguirem um padrão para o
desenvolvimento de software seguindo SCRUM também é fundamental para ter um produto
final com qualidade igual para todos os clientes. Quando o processo segue um padrão único
na empresa, é mais fácil avaliar o que está seguindo as normas, garantindo dessa forma a
qualidade de processo e do produto final gerado.
É de extrema importância que todos os projetos SCRUM da empresa gerem todos os
documentos necessários, de acordo com um template padrão estabelecido pela mesma e com
todas as informações que são essenciais para uma futura evolução do projeto, caso venha
ocorrer. Também é preciso que todos os projetos sigam os princípios básicos do SCRUM, para
que essa metodologia ágil seja aplicada de forma correta. E por fim, é preciso um processo de
desenvolvimento padronizado, que seja seguido por todos os projetos que utilizam
determinada metodologia, para que se possa aplicar a garantia da qualidade de processo e de
43
produto nos mesmos. Sem um padrão e sem um processo é impossível verificar se um projeto
está seguindo as normas exigidas pela empresa ou não.
3.3 Processo SCRUM da Dextra Sistemas
Para atingir o objetivo proposto por esse trabalho de conclusão de curso (aplicar
atividades da Garantia da Qualidade de Software para projetos SCRUM), primeiramente foi
necessário pensar em conjunto com o SEPG da Dextra Sistemas (empresa onde esse projeto
será aplicado) na elaboração de um processo de desenvolvimento de software ágil, que possa
ser seguido por todos os projetos SCRUM da empresa. Após isso, foi realizada uma análise
sobre o estudo de caso realizado nesse trabalho, a respeito da experiência positiva da empresa
PowerLogic com processo ágil e MPS.Br nível F.
Várias dúvidas surgiram e pesquisas e discussões em reuniões foram realizadas para
que essas dúvidas fossem solucionadas. As dúvidas foram as seguintes:
1- Como é feita a qualidade de processo em SCRUM?
2- Quais indicadores são coletados em SCRUM?
3- Que alterações devem ser realizadas na ferramenta TRAC (vide Apêndice 1.2)
utilizada na Dextra, para contemplar user stories, product backlog, sprint?
4- Como é feito o acompanhamento do projeto? Existe registro formal da reunião
diária?
5- Como são guardadas as informações do quadro de tarefas? Como são formalizadas as
reuniões?
6- Como será o ciclo de vida do processo ágil?
Após vários estudos e reuniões as respostas para as dúvidas surgidas foram aos poucos
esclarecidas e foi possível dar início ao desenvolvimento do processo, que está demonstrado
na Figura 3-1. As dúvidas que ainda não ficaram definitivamente resolvidas serão discutidas
novamente em outras reuniões até se atingir uma resposta final.
44
Um dos primeiros aspectos a serem definidos foi o ciclo de vida do processo. Ficou
decidido que o ciclo de vida será formado pelas fases: Sprint 0, Execução (onde serão
executados os sprints) e Encerramento, as quais podem ser observadas através da Figura 3-2.
Figura 3-1: Processo Dextra para desenvolvimento em SCRUM [19].
Figura 3-2: Ciclo de vida do Processo SCRUM da Dextra.
45
Os papéis presentes no processo são mostrados na Figura 3-3, sendo: time, product
owner, SCRUM master, gerente de projeto, auditor de qualidade e auditor de baseline. As
disciplinas, nessa primeira versão do processo (mostradas na Figura 3-4) estão divididas em
três: implementação, garantia da qualidade e gestão de configuração.
Figura 3-3: Papéis do Processo SCRUM da Dextra.
Figura 3-4: Disciplinas do Processo SCRUM da Dextra.
46
Inicialmente existem os seguintes produtos de trabalho, que são mostrados na Figura
3-5: user story, gráfico de burndown do projeto, incremento do produto, aceite de sprint,
apresentação dos compromissos com cliente, apresentação de kickoff (inicial) interno, lista de
verificação de QA SCRUM, release notes (notas do projeto), team planning (planejamento da
equipe), quadro de tarefas, gráfico de sprint burndown, sprint backlog, product backlog,
relatório de status (estado) para cliente, relatório de status interno, relatório de auditoria de
produto e relatório de auditoria da qualidade. Para a primeira versão do processo, a única
ferramenta disponível será o TRAC (ferramenta de acompanhamento de alterações), que
deverá ser adaptado para o SCRUM. Essa adaptação será realizada futuramente.
As atividades envolvidas nessa primeira versão do processo, no Sprint 0,
demonstradas na Figura 3-6, são: organizar o ambiente do projeto, preparar equipe, reunião
inicial com o cliente, reunião inicial com o time, estimar product backlog e as atividades
relacionadas a disciplina de Garantia da Qualidade (vide).
Figura 3-5: Produtos de trabalho do Processo SCRUM da Dextra.
47
Na fase de Execução (em cada sprint do projeto) as atividades, mostradas na Figura 3-
7 são: reunião de planejamento do sprint, manter backlog, validar itens de backlog em
desenvolvimento, implementar o sprint backlog, reunião de revisão do sprint, retrospectiva do
sprint e atividades da qualidade.
Figura 3-6: Diagrama do Sprint 0.
48
Ainda dentro da fase de execução existe um subprocesso chamado Acompanhamento e
Controle, o qual envolve as seguintes atividades: monitorar e controlar, manter registros de
ação gerencial. Essas atividades estão relacionadas com o acompanhamento formal do projeto
durante todos os sprints do mesmo e podem ser observadas na Figura 3-8. O gerente de
projeto é o responsável por esse acompanhamento.
Figura 3-7: Diagrama da Fase de Execução.
49
Na fase de Encerramento as atividades, demonstradas pela Figura 3-9 são: obter aceite
do cliente, encerrar projeto, fornecer resultados das medições, liberar baseline, auditar
baseline, auditar configuração e todas as atividades da disciplina garantia da qualidade.
Figura 3-8: Diagrama do subprocesso
Acompanhamento e Controle.
Figura 3-9: Diagrama da Fase de Encerramento.
50
3.4 SCRUM Dextra – Atividades de Garantia da Qualidade
Dentro da disciplina de Garantia da Qualidade, que está presente em todas as fases do
ciclo de vida do processo SCRUM da Dextra, estão as seguintes atividades: realizar auditoria
de processo, realizar auditoria de produto, disponibilizar relatório de auditoria, acompanhar as
não conformidades e consolidar todas as auditorias realizadas. Em todas as atividades dessa
disciplina, que podem ser observadas através da Figura 3-10, o executor principal e único é o
auditor da qualidade.
Como o foco desse trabalho não é o processo SCRUM completo, e sim apenas a
disciplina de garantia da qualidade, as outras disciplinas e atividades relacionadas não serão
descritas em detalhes nesse trabalho, podendo ser tema para um trabalho futuro. Só serão
tratadas nesse trabalho as atividades e produtos de trabalho relacionados à disciplina Garantia
da Qualidade.
3.4.1 Atividade Realizar Auditoria de Processo
A atividade realizar auditoria de processo tem como objetivo realizar auditorias para
avaliação do processo e dos produtos de trabalho do projeto e para verificar se os mesmos
estão seguindo o que foi definido no processo SCRUM. A entrada obrigatória para essa
Figura 3-10: Diagrama da disciplina Garantia da Qualidade.
51
atividade é o plano de QA, e tem como saídas a lista de verificação de QA SCRUM, a planilha
de acompanhamento de auditorias da qualidade e o registro de não conformidades.
As etapas envolvidas nessa atividade são:
1. Avisar o gerente de projeto da auditoria a ser realizada: uma semana antes,
enviar um e-mail (correio eletrônico) ao gerente de projeto informando a data em que será
realizada a auditoria e que os artefatos do projeto devem estar atualizados e disponíveis no
repositório durante o período da auditoria;
2. Avaliar a aderência ao processo: nas datas previstas para auditoria o auditor
da qualidade deve utilizar a lista de verificação de QA SCRUM e preencher as seguintes
informações: data da auditoria, nome do projeto, sprint em que o projeto se encontra e o nome
do gerente do projeto;
3. Identificar os itens conformes e não conformes: os itens conformes e não
conformes identificados pela auditoria devem ser registrados na lista de verificação de QA
SCRUM. O auditor da qualidade deve registrar se o item em questão está conforme ou não, e
para isso deverá marcar com a letra “S” o item de verificação que estiver conforme, “N” o
item de verificação que não estiver conforme ou “N/A” o item de verificação que não foi
avaliado. Devem-se registrar os comentários quando necessário;
4. Registrar as não conformidades encontradas: o auditor da qualidade deve
registrar as não conformidades encontradas durante a auditoria do projeto na ferramenta
TRAC, abrindo um ticket do tipo NC (não conformidade) para o projeto. Nesse ticket devem
ser registrados o sumário da NC, a descrição da NC, a criticidade (alta, média ou baixa), a
fase que o projeto está, a data limite para resposta/avaliação da NC pelo gerente de projeto, a
data limite para a resolução da NC (que varia de acordo com a criticidade, sendo 2 dias para
alta, 1 semana para média e 2 semanas para baixa) e a data final colocada pelo gerente de
projeto para a resolução da NC;
5. Finalizar auditoria: o auditor da qualidade deve utilizar a planilha de
acompanhamento de auditorias da qualidade e registrar o resultado na aba acompanhamento
de auditorias (onde é colocado o resultado geral da auditoria) e na aba consolidação por
processo (onde é colocado o resultado por processo – gerência de projeto, gestão de
configuração, validação).
3.4.2 Atividade Realizar Auditoria de Produto
A próxima atividade da disciplina garantia da qualidade é a de realizar auditoria de
produto, que tem como entrada obrigatória o plano de QA e como saídas a lista de verificação
52
de QA de status report (relatório de estado) interno, a lista de verificação de QA de status
report para o cliente, o registro de não conformidades e a planilha de acompanhamento de
auditorias da qualidade.
As etapas envolvidas são parecidas com as etapas da atividade de realizar auditoria de
processo, são elas:
1. Avaliar aderência ao produto: avaliar a aderência dos seguintes produtos de
trabalho a serem auditados: Aprovação dos compromissos com o cliente: nessa auditoria
devem ser verificados o plano do projeto, o plano de gestão de configuração e a apresentação
dos compromissos com o cliente; utilizar a aba produto aprovar compromissos com cliente da
lista de verificação de QA SCRUM; Status Report Interno: nessa auditoria deve ser verificado
se todas as medidas foram coletadas e analisadas corretamente e se o status report foi gerado
conforme definido no processo; utilizar a lista de verificação de QA de status report interno;
Status Report para Cliente: nessa auditoria deve ser verificado se o status report do cliente foi
gerado conforme definido no processo; utilizar a lista de verificação de QA de status report
para o cliente; o Auditor da Qualidade deve executar a auditoria utilizando a lista de
verificação correspondente a cada auditoria e conforme planejado, através de observações
diretas, acesso a base de dados, ferramentas e exame dos produtos de trabalho;
2. Identificar os itens conformes e não conformes: a descrição dessa atividade
é idêntica a da atividade realizar auditoria de processo, por esse motivo não irei repetí-la aqui;
3. Registrar as não conformidades encontradas: a descrição dessa atividade
também é idêntica a da atividade realizar auditoria de processo;
4. Finalizar auditoria: o auditor da qualidade deve utilizar a planilha de
acompanhamento de auditorias da qualidade e registrar o resultado na aba referente a cada
auditoria de produto realizada.
3.4.3 Atividade Disponibilizar Relatório de Auditoria
Outra atividade da qualidade é a disponibilizar relatório de auditoria, onde as entradas
obrigatórias são a lista de verificação de QA SCRUM, lista de verificação de QA de status
report interno, lista de verificação de QA de status report para o cliente, planilha de
acompanhamento de auditorias da qualidade e o registro de não conformidades. As saídas são
o e-mail de divulgação do relatório de auditoria da qualidade, o relatório de auditoria da
qualidade e o relatório de auditoria de produto.
As etapas dessa atividade estão descritas a seguir:
53
1. Disponibilizar o relatório de auditoria: ao final de cada auditoria de produto
referente a status report interno ou status report para o cliente, gerar o relatório de auditoria
de produto; ao final de cada auditoria de processo ou produto a ser entregue para o cliente,
gerar o relatório de auditoria da qualidade;
2. Disponibilizar as não conformidades para tratamento: a ferramenta TRAC
comunica automaticamente, por e-mail, o gerente de projeto que será responsável por tratar a
NC;
3. Notificar a equipe sobre o resultado da auditoria: o auditor da qualidade
deve enviar um e-mail para a equipe do projeto e para o gerente da fábrica, informando o
término da auditoria e indicando o local onde o relatório de auditoria da qualidade tanto de
produto quanto de processo pode ser consultado.
3.4.4 Atividade Acompanhar as Não Conformidades (NC)
A atividade acompanhar as não conformidades deve ocorrer diariamente, pois tem
como objetivo acompanhar o tratamento das NCs encontradas no projeto durante as
auditorias. Tem como entrada obrigatória o registro de não conformidades, que também é a
saída da atividade.
Suas etapas são:
1. Tratar as NCs rejeitadas: o auditor da qualidade deverá tratar as NCs que
foram rejeitadas pelo gerente de projeto; deverá verificar o motivo pelo qual o mesmo não
concorda com a NC e decidir por cancelar ou abri-la novamente esclarecendo os pontos que
causaram a rejeição;
2. Tratar as NCs resolvidas: o auditor da qualidade deverá validar as NCs que
foram corrigidas pelo gerente de projeto; deverá verificar a solução dada e avaliar se o
tratamento foi adequado; em caso positivo a NC deverá ser fechada no estado validada, caso
contrário a NC deverá voltar ao estado inicial de aberta para que o tratamento correto seja
dado para a mesma.
3.4.5 Atividade Consolidar todas as Auditorias Realizadas
Por último tem a atividade de consolidar todas as auditorias realizadas, que deve ser
realizada no último dia do mês, de preferência. Tem como objetivo consolidar todas as
auditorias realizadas no projeto, tanto de processo quanto de produto, periodicamente a cada
30 dias. A planilha de acompanhamento de auditorias da qualidade é entrada obrigatória e
também a saída da atividade. Essa atividade tem uma única etapa que é a de registrar o
54
resultado da consolidação na planilha de acompanhamento de auditorias da qualidade, onde o
auditor da qualidade deve registrar o resultado consolidado de todas as auditorias realizadas
em cada projeto, mensalmente, na planilha de acompanhamento de auditorias da qualidade,
aba consolidação.
3.5 SCRUM Dextra – Produtos de Trabalho de Garantia da Qualidade
Em relação aos produtos de trabalhos, também são todos gerados pelo auditor da
qualidade. O primeiro a ser gerado é o plano de QA (mostrado na Figura 3-11) que é o plano
que define as atividades da qualidade para o projeto. O mesmo deve ser elaborado juntamente
com o plano do projeto, consolidado com o gerente de projeto e aprovado pelo gerente da
fábrica. Nesse plano deve conter informações das datas das auditorias a ser realizadas, o tipo,
o esforço previsto e, se necessário, os treinamentos realizados.
Figura 3-11: Plano de QA.
55
Para realizar as auditorias de processo precisa-se gerar a lista de verificação de QA
SCRUM (mostrada na Figura 3-12) que é uma planilha que contém a lista de artefatos e
processos que serão auditados por processo (Gestão de Configuração, Gerência de Projeto,
Validação e Projeto e Construção do Produto) e por sprint. Cada aba da planilha representa
uma fase do projeto (no caso da fase de Execução, tem uma aba para cada sprint do projeto).
Também existe o espaço para se colocar se o item está conforme ou não, a criticidade do
mesmo e algum comentário quando for necessário. Essa lista também calcula a quantidade de
itens conformes e não conformes por processo e no geral.
Para que as auditorias de produto de status report para cliente e interno possam ser
realizadas, devem ser geradas as listas de verificação de QA de status report para cliente
(mostrado na Figura 3-13) que é uma planilha que contém todos os itens a serem observados
que devem existir em um status report que é enviado para o cliente, e de status report interno,
que é uma planilha que contém todos os itens a serem observados que devem existir em um
status report interno que pode ser observado através da Figura 3-14. Ambas as listas seguem
o mesmo estilo da lista de verificação para auditoria de processo descrita acima.
Figura 3-112: Lista de Verificação de QA SCRUM.
56
Figura 3-13: Lista de Verificação de QA de Status Report para Cliente.
Figura 3-14: Lista de Verificação de QA de Status Report Interno.
57
Os registros de todas as auditorias realizadas, tanto de processo quanto de produto, e a
consolidação das mesmas no final do mês, ficam na planilha de acompanhamento de
auditorias da qualidade, mostrada na Figura 3-15. É uma planilha que contém o registro e
acompanhamento das auditorias da qualidade que estão sendo realizadas para o projeto. Nessa
planilha devem ser registrados o acompanhamento de auditorias, a consolidação por processo
e a consolidação final. São registrados também os resultados de cada auditoria de produto
realizada, sendo que cada produto é registrado em uma aba diferente da planilha.
Figura 3-15: Planilha de Acompanhamento de Auditorias da Qualidade.
58
O produto de trabalho registro de não conformidades não gera nenhum documento, o
registro das NCs deve ser feito na ferramenta de acompanhamento de alterações (TRAC) do
projeto, que pode ser visto na Figura 3-16. O e-mail de divulgação do relatório de auditoria da
qualidade também não tem um modelo que precisa ser seguido. É um e-mail comum, que
deve ser enviado para a equipe do projeto e para o gerente da fábrica divulgando o término da
auditoria e disponibilizando o relatório para consulta de todos.
Ao finalizar uma auditoria de processo deve ser elaborado e disponibilizado o relatório
de auditoria da qualidade, o qual faz um resumo sobre a auditoria realizada. Nele devem
conter as seguintes informações: nome do projeto, fase (no caso da fase de execução o
número do sprint) auditada, data em que foi realizada a auditoria, nome do auditor da
qualidade, o número de itens auditados, conformes e não conformes, a lista das não
conformidades encontradas, o percentual de aderência do projeto ao processo e o esforço
gasto na realização da auditoria. O template desse relatório pode ser observado na Figura 3-
17.
Figura 3-16: Registro de Não Conformidades no TRAC.
59
Figura 3-17: Relatório de Auditoria da Qualidade.
60
Ao final de cada auditoria de produto referente a status report interno ou status report
para o cliente, deve ser elaborado e disponibilizado para a equipe do projeto e para o gerente
de fábrica o relatório de produto, o qual faz um resumo sobre a auditoria realizada. Nele
devem conter as seguintes informações: nome do projeto, data da auditoria realizada, o
resultado (número de itens auditados, conformes e percentual de aderência), as não
conformidades abertas (caso existam) e o esforço gasto para a realização da auditoria. O
template desse relatório pode ser visto na Figura 3-18.
A execução das atividades relacionadas com a disciplina garantia da qualidade do
processo em questão ocorre da seguinte maneira: ao iniciar um novo projeto, o gerente da
fábrica comunica ao auditor da qualidade que o projeto deverá ser auditado, em seguida o
auditor solicita ao gerente do projeto as datas de entrega dos sprints que foram combinadas
com o cliente. Com isso o auditor da qualidade tem a base para realizar o plano de QA,
definindo assim as datas das auditorias.
Nessa primeira versão do processo, as auditorias estão sendo marcadas para serem
realizadas antes da entrega do sprint ao cliente e depois da retrospectiva do sprint corrente e o
planejamento do próximo sprint terem sido realizados. Com todas as auditorias marcadas,
uma semana antes de uma auditoria ser realizada, o auditor da qualidade envia um e-mail ao
gerente do projeto avisando o dia que será realizada a auditoria e o conteúdo da mesma, isto é,
a qual sprint a auditoria se refere. No SCRUM não é comum acontecer das auditorias terem
que ser replanejadas, uma vez que os sprints são time-boxed, ou seja, tem um tempo certo
para serem concluídos, no caso da Dextra, os sprints tem duração de 2 semanas (10 dias
úteis).
Figura 3-18: Relatório de Produto.
61
Como o gerente do projeto já foi avisado da auditoria uma semana antes, no dia em
que a mesma for realizada todos os artefatos gerados naquele sprint devem estar disponíveis
para o auditor da qualidade. O auditor realiza a auditoria com a lista de verificação de QA
SCRUM, utilizando a aba referente ao sprint que será auditado. O mesmo deve preencher essa
lista de verificação de acordo com o que for sendo auditado. Se o item estiver conforme,
marcará com “S” na coluna “Conforme?”, caso contrário marcará com “N” e na coluna
“Comentário” irá colocar o motivo pelo qual o item não está conforme e o número da NC
referente ao mesmo, a qual foi aberta no TRAC do projeto. Caso o item não tenha sido
avaliado, marcará com “N/A” e escreverá o motivo pelo qual o mesmo não foi auditado na
coluna “Comentário”.
As não conformidades encontradas pelo auditor ao longo da auditoria são registradas
na ferramenta de alterações (TRAC) do projeto que está sendo auditado. Os procedimentos de
como preencher os campos já foram descritos anteriormente. Ao finalizar a auditoria o auditor
deve preencher a planilha de acompanhamento de auditorias, nas abas referentes à
Acompanhamento das Auditorias e Consolidação por Processo. Deve também gerar o
relatório de auditoria da qualidade, o qual deve ser disponibilizado no TRAC do projeto. O
auditor deve também enviar um e-mail para toda a equipe divulgando o resultado da auditoria
realizada e enviando o link (referência) para visualização do relatório da mesma.
O auditor da qualidade deve acompanhar as não conformidades todos os dias,
verificando se as mesmas estão sendo corrigidas e se estão seguindo o prazo estipulado para
correção. Caso o prazo tenha se esgotado, o auditor deverá escalar a não conformidade para o
gerente da fábrica, que é um nível superior do gerente do projeto.
Para as auditorias de produto de status report interno não precisa ser enviado e-mail
com uma semana de antecedência, elas são realizadas periodicamente a cada quinze dias. Para
a realização das mesmas o auditor deve utilizar a lista de verificação de QA de status report
interno. Deve preenchê-la da mesma forma que foi feito na auditoria de processo. Caso sejam
encontradas não conformidades também são abertas no TRAC do projeto que está sendo
auditado.
Ao final da auditoria de produto de status report interno, o auditor da qualidade
também deve preencher a planilha de acompanhamento de auditorias na aba referente à
auditoria realizada. Deve também gerar o relatório de auditoria de produto, o qual deve ser
disponibilizado no TRAC do projeto. O auditor também envia um e-mail comunicando o
gerente do projeto da realização da auditoria com o resultado da mesma e o link para o
relatório. Depois é enviado um e-mail para o gerente da fábrica e para o gerente de contas
62
encaminhando o resultado da auditoria junto com o status report do projeto, já auditado e de
acordo com as regras da empresa.
As auditorias de produto de status report para cliente seguem os mesmos passos da
auditoria de produto de status report interno, porém a periodicidade com que ocorrem varia
de projeto para projeto. Normalmente também ocorrem a cada quinze dias, uma vez que o
status report geralmente é enviado ao cliente no final do sprint. A única diferença é que no
final da auditoria o auditor envia um e-mail apenas para o gerente de projeto, divulgando o
resultado da auditoria, o link para consulta do relatório e liberando o status report para ser
entregue ao cliente. É responsabilidade do gerente de projeto encaminhar o status report para
o cliente.
Por fim, a cada 30 dias, de preferência no último dia do mês, o auditor da qualidade
deve fazer uma consolidação de todas as auditorias realizadas no mês, de cada projeto
separadamente. Esse registro deve ser feito na planilha de acompanhamento de auditorias de
cada projeto, na aba “Consolidação”. Nela devem ser registradas a data da consolidação, a
quantidade de auditorias realizadas, a quantidade de itens auditados, conformes e não
conformes, a quantidade de não conformidades escaladas e o percentual da aderência do
projeto ao processo, que é o número de itens conformes dividido pelo número de itens
auditados e o resultado é multiplicado por 100.
Essa consolidação faz com que, tanto o auditor da qualidade, como a equipe, o gerente
de projeto, o gerente da fábrica e até a diretoria da empresa, tenham uma visão de como o
projeto está em conformidade com as normas da empresa, com o que o processo exige. Isso
reflete também em como está a qualidade do projeto de um modo geral. Faz com que a
empresa saiba como está a área da qualidade, se está trazendo benefícios para a empresa ou
está sendo apenas um overhead (excesso).
4 CONCLUSÃO
Com a constante utilização de processos de desenvolvimento de software pelas
empresas de desenvolvimento de software observa-se que os mesmos são importantes para a
padronização de todos os documentos gerados pela empresa e do fluxo de atividades
realizadas durante o desenvolvimento de um software. Além disso, torna possível a execução
da garantia da qualidade de produto e de processo e das atividades de medição, que geram
dados que mostram se o projeto está dentro do prazo, custo e qualidade esperada.
63
Ultimamente, com a adoção da qualidade de produto e de processo, juntamente com a
busca por certificações de qualidade de software, houve uma evolução na qualidade dos
softwares produzidos. Isso é fundamental para a empresa conseguir satisfação de seus
clientes, atraindo mais clientes e manter os que já possuem.
A implantação de metodologias ágeis de desenvolvimento de software foi fundamental
para que as empresas se adaptassem as novas exigências do mercado, que querem que os
softwares sejam produzidos no menor tempo possível, com baixo custo e com cada vez mais
qualidade.
Resumidamente, com todo o estudo feito neste trabalho, pode-se concluir que projetos
que são desenvolvidos utilizando a metodologia ágil SCRUM também precisam passar pela
área da qualidade. Todo final de mês é realizada uma coleta dos números de itens auditados e
de itens conformes de todos os projetos juntos, para avaliar a aderência dos projetos ao
processo da empresa.
Essa aderência é calculada dividindo a quantidade de itens conformes pela quantidade
de itens auditados. O resultado é registrado em uma planilha chamada planilha de aderência.
Dessa forma, é possível avaliar a eficiência da área de qualidade da empresa e se a mesma
está trazendo benefícios, uma vez que é possível ver se a aderência está aumentando, o que
demonstra que a qualidade está sendo eficiente, ou se está diminuindo, sendo possível
verificar o que está acontecendo com os projetos, uma vez que a tendência natural é a
aderência aumentar com o passar do tempo demonstrando maturidade das equipes dos
projetos em relação ao processo.
Essa coleta inclui todos os projetos, tanto os que seguem o ProUD como os que
seguem o SCRUM. Até Maio de 2009 eram auditados apenas os projetos que utilizam o
ProUD. Em Junho de 2009 começaram a ser auditados os projetos que utilizam SCRUM,
seguindo o que o processo SCRUM da Dextra exige na disciplina Garantia de Qualidade, que
em Julho já estava pronta.
Observando o gráfico abaixo (mostrado na Figura 4-1), gerado através das coletas
registradas na planilha no período de Abril de 2009 até Outubro de 2009, é possível perceber
uma queda do percentual de aderência em Junho, quando entraram na coleta os projetos
SCRUM, uma vez que foi a primeira vez que os projetos estavam sendo auditados e por isso
vários problemas foram encontrados. Em Julho houve outra queda, pois mais projetos
SCRUM entraram na coleta, porém com o passar do tempo percebe-se o aumento gradativo
desse percentual, demonstrando uma maturidade dos projetos em relação ao novo processo
SCRUM, que ainda está em sua versão inicial.
64
Por fim, é importante destacar que os projetos SCRUM também devem seguir um
processo certificado por um modelo de qualidade de software para conquistar a confiança dos
clientes e com isso prover maior credibilidade à empresa.
4.1 Contribuições
Esse trabalhou contribuiu para que o fluxo das atividades realizadas nos projetos que
utilizam SCRUM na Dextra fosse padronizado e também foi possível a criação de modelos
(templates), de forma que todos os documentos gerados estejam de acordo com as exigências
da empresa.
Contribuiu também para o início da medição da qualidade de processo e de produto
dos projetos SCRUM, de forma a verificar se os mesmos estão seguindo o processo definido.
Com a definição do processo SCRUM também foi possível identificar quais indicadores
devem ser coletados nos projetos que utilizam SCRUM, de forma que os mesmos possam ser
adequadamente monitorados, porém ainda não foi definida uma nova planilha de medidas,
isso será um aprimoramento do processo.
Com a elaboração de um novo checklist (lista de verificação) de QA e definição de
toda a disciplina de qualidade do processo SCRUM (atividades estas realizadas durante a
elaboração desse trabalho), foi possível um maior controle e verificação de todos os
entregáveis antes das entregas serem feitas para o cliente, garantindo uma maior qualidade do
produto entregue.
Figura 4-1: Gráfico gerado a partir dos dados registrados na
planilha de aderência.
65
4.2 Trabalhos futuros
Uma sugestão para trabalhos futuros baseados nesse trabalho de conclusão de curso é
o aprimoramento do processo elaborado nesse trabalho (adicionando mais detalhes, outros
produtos de trabalhos, outras atividades) de forma que o mesmo possa ser certificado no
MPS.Br nível F (esse trabalho seguiu as exigências do MPS.Br nível F apenas na disciplina
de Garantia da Qualidade).
Outra sugestão é o detalhamento das atividades das outras disciplinas existentes no
processo elaborado (por exemplo: Gerência de Projetos, Gestão de Configuração), uma vez
que o foco desse projeto foi em apenas uma disciplina, a Garantia da Qualidade.
A última sugestão seria a adequação do processo descrito nesse trabalho para os outros
níveis do MPS.Br (níveis E, D, C, B ou A), ou ainda, adequá-lo de acordo com as exigências
de algum modelo de qualidade de software internacional, como por exemplo, o CMMI.
66
Apêndice 1 – Ferramentas
1.1 EPF Composer
Para a elaboração do processo SCRUM descrito nesse trabalho foi utilizada a
ferramenta denominada EPF (Eclipse Process Framework - Estrutura de Processo Eclipse)
Composer (compositor). É uma ferramenta livre, isto é, encontra-se disponível gratuitamente.
O EPF define uma linguagem comum para descrever processos, que podem seguir qualquer
metodologia. O local para descrever o processo pode ser visto na Figura 4-2, que mostra a tela
do programa EPF.
Essa ferramenta gera o conteúdo dos métodos, permite definir processos para diversos
tipos de projetos e também permite combinar processos. É muito utilizada para estruturação,
documentação, adaptação e publicação de processos de desenvolvimento de software. “O EPF
visa criar um processo de software totalmente adaptável, com toda a estrutura da engenharia
de software, conteúdos, ferramentas, suportando uma ampla variedade de tipos de projetos e
estilos de desenvolvimento” [15].
Figura 4-2: Tela da ferramenta EPF Composer.
67
1.2 TRAC
O TRAC é uma ferramenta livre (open source), simples e de interface web. Sua
principal função é controlar mudanças em projetos de desenvolvimento de software. Essa
ferramenta ajuda não só o desenvolvedor, mas sim toda a equipe do projeto, a rastrear as
mudanças que ocorreram no projeto, entender o porquê de cada uma delas e qual o impacto no
projeto como um todo. A página principal dessa ferramenta pode ser vista na Figura 4-3, logo
abaixo.
Figura 4-3: Página inicial do TRAC [16].
68
O TRAC tem os seguintes recursos: controle de mudanças, wiki (que é uma página
web que pode ser editada por qualquer pessoa) para documentação colaborativa e referência
cruzada entre os elementos do TRAC, integração com o subversion (subversão - funciona
como um browser do repositório do projeto) e acompanhamento da evolução do projeto. Os
benefícios de se usar essa ferramenta são: melhoria na qualidade do produto e do processo de
desenvolvimento; registro, rastreamento e controle das mudanças sofridas pelo projeto
durante seu ciclo de vida; integração entre o controle de versão e o controle de mudança;
acompanhamento da evolução do projeto; e melhor documentação do projeto através da
equipe de desenvolvimento.
O TRAC é adaptável e pode ser configurado de acordo com as definições da empresa
ou então de acordo com a necessidade dos projetos. No caso dos projetos da Dextra Sistemas
que utilizam o processo ProUD, o TRAC (mostrado através da Figura 4-4), possui recursos
como: requisitos, riscos, não conformidades, defeitos, mudanças de requisitos, solicitações de
mudanças, ações gerenciais, tarefas, sub-tarefas, uma página inicial com o nome e um resumo
do projeto, assim como perfis de acesso (cliente, equipe e gerência), além da integração com o
subversion dos projetos. Para o processo SCRUM ainda não foi configurado nem definido um
novo TRAC.
Figura 4-4: Tela inicial do TRAC de um projeto da Dextra.
69
Referências Bibliográficas
[1] FEILER, P. H.; HUMPHREY, W. S. Software Process Development an
Enactment: Concepts and Definitions. In: International Conference on the
Software Process, 2., 1993, Berlin.
[2] I, Jacobson, G. Booch & J. Rumbaugh. The Unified Software Development Process.
[3] TQC – Controle da Qualidade Total (no estilo japonês). Vicente Falconi
Campos. Nova Lima – MG: INDG Tecnologia e Serviços Ltda., 2004.
[4] Site oficial RUP. Disponível em: http://www.wthreex.com/rup/portugues/index.htm
Acessado em: Setembro de 2009.
[5] SOMMERVILLE, Ian: Engenharia de Software. Tradução: André
Maurício de Andrade Ribeiro. São Paulo: Addison Wesley, 2003.
[6] PRESSMAN, Roger S. Engenharia de Software. Tradução: José Carlos
Barbosa dos Santos. São Paulo: Pearson Education do Brasil, 1995.
[7] ROTHERY, Brian. ISO 9000. São Paulo, Makron Books,1993.p.13.
[8] CROSBY, PB. Quality is Free: the Art of Making Quality Certain. São Paulo, SP: Mentor
Books, 1992.
[9] Crespo, Adalberto; Argollo, Miguel. Apostila de Fundamentos de Teste de Software.
CenPRA. Campinas, 2008.
[10] KOSCIANSKI, André; SOARES, Michel dos Santos: Qualidade de
Software: aprenda as metodologias e técnicas mais modernas para o
desenvolvimento de software. São Paulo: Novatec Editora, 2007.
[11] Manifesto for Agile Software Development. Site oficial do Manifesto Ágil. Disponível
em: http://agilemanifesto.org/. Acessado em: Julho, 2009.
70
[12] SCHWABER, Ken: Agile Project Management with SCRUM.
Washington, 2004.
[13] Oliveira, Ana Cláudia Grossi de.; Guimarães, Fernanda Alves; Fonseca, Isabella de
Araújo. Utilizando Metodologias Ágeis para atingir MPS.Br nível F na PowerLogic.
Disponível em: http://www.softex.br/portal/softexweb/uploadDocuments/_mpsbr/T1-
PowerLogic-WE.pdf. Acessado em: Outubro, 2009.
[14] SCRUM Certificado (MPS.Br F) – A experiência da PowerLogic. Disponível em:
http://imprensa.cesar.org.br/scrum/SPINRecife_Mai08_PowerLogic.pdf. Acessado em:
Outubro de 2009.
[15] Site oficial do EPF. Disponível em:
http://www.eclipse.org/projects/project_summary.php?projectid=technology.epf. Acessado
em: Novembro de 2009.
[16] Site oficial do Trac. Disponível em: http://trac.edgewall.org/. Acessado em: Novembro
de 2009.
Bibliografias Consultadas
[17] SOFTEX, Sociedade: Apostila do Curso Oficial de Introdução ao
Modelo MPS.BR. São Paulo: Campinas, 2007.
[18] 1ª Conferência da Qualidade de Software. Disponível em:
http://www.asrconsultoria.com.br/docs/Conf_0412_06_PowerLogic.pdf. Acessado em:
Maio, 2009.
[19] Dextra Sistemas: Coding your business. Disponível em:
http://www.dextra.com.br/servicos/scrum.htm. Acessado em: Novembro de 2009.
71
[20] Pereira, Ana Paula Valente. Eclipse Process Framework: Uma nova visão da engenharia
de software. IST- Organização e Gestão da Função Informática. Outubro, 2007. Disponível
em:
https://dspace.ist.utl.pt/bitstream/2295/138414/1/Eclipse%20Process%20Framework_IST.pdf.
Acessado em: Outubro, 2009.
[21] Wilson, José. Visão geral sobre Engenharia de Software. CEP – Ceilândia. Disponível
em: http://www.cepceilandia.df.gov.br/sites/200/296/00000482.ppt. Acessado em: Abril de
2009.
[22] Martins, Edite. Implantação de Processo – Os desafios da implantação de um processo de
software. Revista eletrônica Engenharia de Software Magazine. Edição 14.
[23] Figueiredo, Alexandre Magno. Falando sobre SCRUM. Disponível em:
http://www.scribd.com/doc/20007777/Falando-sobre-Scrum. Acessado em: Junho de 2009.
[24] ARTIGOS.COM. Processos – Contextualização. Disponível em:
www.artigos.com/artigos/sociais/administracao/processos-_-contextualizacao-988/artigo/.
Acessado em: Abril de 2009.
[25] PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. Prentice Hall
Brasil, 2004.
[26] BEZERRA, Eduardo. Princípio de Análise e Projeto de Sistemas com UML. Rio de
Janeiro: Campus, 2006.
[27] CARROMEU, Camilo. Qualidade de Software. Disponível em:
http://academy.carromeu.com/images/5/53/2009.qs.aula.01.pdf. Acessado em: Junho de 2009.
[28] ESPINHA, Rafael. Process Institutionalization Tools (PIT) – Ferramentas de apoio à
institucionalização de processos. Previa de Defesa. PUC-RIO, Rio de Janeiro, 2006.
[29] Bartie, Alexandre. Agilidade ou Controle Operacional? Os dois! Revista eletrônica
DevMedia. Edição 1.