1
Universidade de Pernambuco
Faculdade de Ciência e Tecnologia de Caruaru
Bacharelado em Sistemas de Informação
UMA PROPOSTA DE BUG TRACKER ORIENTADA A PROCESSOS
COM ÊNFASE EM REQUISITOS PARA APOIAR DESENVOLVIMENTO DE
SOFTWARE ÁGIL
Trabalho de Graduação
Sistemas de Informação
Tarcísio Ferreira De Souza Cavalcanti
Orientador: Prof. Msc. Rômulo César Dias de Andrade
2
TARCÍSIO FERREIRA DE SOUZA CAVALCANTI
UMA PROPOSTA DE BUG TRACKER ORIENTADA A PROCESSOS
COM ÊNFASE EM REQUISITOS PARA APOIAR DESENVOLVIMENTO DE
SOFTWARE ÁGIL
Monografia apresentada como requisito
parcial para obtenção do diploma de
Bacharel em Sistemas de Informação pela
Faculdade de Ciência e Tecnologia de
Caruaru – Universidade de Pernambuco.
Caruaru, dezembro, 2014
3
Dedico este trabalho ao meu pai Luiz e
minha mãe Tereza, e minhas a irmãs Taiza,
Tassia, Tacira e Tais por todo o carinho amor
e dedicação.
4
Agradecimentos.
A Deus causa primeira e razão de todas a coisas. Razão pela qual hoje estamos,
aqui e pela qual tive a oportunidade poder concluir este trabalho. A Lei de Causa e
Efeito, lei natural e universal, não existe efeito sem causa, nem causa sem efeito.
A meu pai Luiz minha mãe Tereza a minhas irmãs Taiza, Tassia, Tacira e Tais
por todo amor incentivo, e dedicação e ensinamentos.
Aos meus Avós José (in memoriam) Antônia (in memoriam), Augusto (in
memoriam), Neposiana (mãe branca) (in memoriam), pelos ensinamentos passados aos
meus pais, e carinho que pude desfrutar enquanto estavam no plano terrestre.
Aos meus tios Avos (in memoriam) pelas palavras de sabedoria, em especial aos
meus tios Jacinto e “Pradin Sé”. A minha família, aos meus tios e tias paternos a minha
Tia materna Dona Cicera, a minha madrinha Socorro ao meu padrinho Assis, aos meus
primos Antônio(Quirino), Camyla (Amarela) demais primos.
A Pitadoras, Isaac newton, Abert Einstein a este e outros cientistas que não estão
citados, se não ia terminar a página e ainda ia ter nomes por citar, por tudo que fizeram
pela matemática e pela física, suas descobertas teoremas, conhecimento.
Aos filósofos, Platão, Friedrich Nietzsche aos iluministas e aos que estiveram na
revolução francesa, por toda revolução intelectual que poderão trazer a humanidade.
A Napoleão Bonaparte por ter ido ir invadir Portugal e assim fazer com que a corte
portuguesa mudasse para o Brasil e o resultou na independência.
A democracia tão linda ao qual vivemos
A Pernambuco esse estado lindo de cultura sem igual, terra dos altos coqueiros
do melhor carnaval do mundo, do Recife a Petrolina meu coração se enche de alegria e
amor, o paraíso na terra é Pernambuco, ser pernambucano é uma honraria.
Ao todos os poetas que tive oportunidade ler por todos que ainda ei ler, por cada
verso que me encantou e inspirou e inspirara os meus dias.
A Eduardo Campos (in memoriam) por ter assinado a gratuidade da Upe.
A Dilma, Aécio Neves, Marina silva, Lucina Genro e Eduardo Jorge pastor Everaldo
por terem feitos a pior campanha que já vi em toda minha vida.
5
Ao politicamente correto por ter criado tantos juízes em nossa sociedade, Se dizem
defensores da liberdade. E no fim das contas pregam o discurso da via única, quando
podem atiram a primeira pedra, mesmo cometendo as mesmas atitudes que condenam.
A Reginaldo Rossi, Luiz Gonzaga , Raul Seixas, The Beatles, Elvis, Volver, Mamonas,
Azeitonas, Pedro Abrunhosa , ao Sonata Ártica Nightwish ao Epica, Pablo do arrocha e
pelas músicas que fizeram parte da trilha sonora deste trabalho.
Aos meus professores por todo conhecimento que poderão me passar, ao professor
Rômulo por toda paciência que teve em me orientar.
Aos amigos meus de faculdade, aos meus companheiros de Rotaract Cassio, Caio,
Daniel, Daniel Siqueira, Karina, João, Mari, Marcinha Marcella, Thiago, Stefanie,
Rebeka, Joyce, Vânia pela oportunidade de presidi-lo em momento tão especial de
minha vida, às pessoas que através dele tive a oportunidade conhecer e colaboram para
o meu amadurecimento, James, Wyama, Bia, Sildemberg, a paraibana Hyalle, Dalila,
Diego, Demais companheiros do distrito 4500, o Rotaract para mim foi a maior
oportunidade de aprendizado que puder ter nesses últimos tempos, Amo vocês.
Ao Esde, que por tantas quartas feiras foi meu refúgio onde tive oportunidade de
Compreender melhor a vida, e poder despertar e mim a vontade ser melhor a cada dia.
Aos meus amigos de internet e leitores do recanto das letras que leem meus simples
textos e desabafos e pela paciência. Samatha por ter me ajudado com os slides.
A Diego, Nerd, Raul Hallyson, Laercio, Elton, Cleyllton, Rik, Leticia, Polliana
Francisco, minhas vizinhas e atuais moradores do AP 102 por todos momentos e
resenhas, Ozair, Saulo e Nayara pelos resumos que fizeram e que tanto me ajudaram.
A Deksa por todos os aperreios e apoio, e carinho.
A todos que vocês de algum modo estiveram presentes nessa minha trajetória por
caruaru meu muito obrigado.
6
Resumo
A busca pela excelência e êxito no desenvolvimento de software, fez com que ao longo
do tempo surgissem métodos para não somente produzi-los mas garantir também a
qualidade do software. Com métodos ágeis a engenharia passou a valorizar as interações
que ocorrem no processo de desenvolvimento, Entre as interações está presente a
volatilidade dos requisitos exigidos pelo cliente, os requisitos evoluem e se modificam
com próprio processo de desenvolvimento, para apoiar o esse processo em metodologias
como Scrum existem uma série de ferramentas para apoiar os desenvolvedores, elas têm
foco em fornecer base de histórica e detalhamento dos requisitos a serem implementados.
Nesse cenário surge Business Process Management (BPM) paradigma da computação
empresarial para incrementar agilidade nas organizações. Nesse contexto este trabalho
tem como proposta o desenvolvimento de uma ferramenta de que use Bug tracker BPM
como forma de gestão alinhada com as práticas ágeis e assim facilitando a adaptação dos
processos internos das organizações ao processo de desenvolvimento de software e com
isso gerar indicadores de produtividade, gargalos e melhorias, possibilitando tomada de
decisão da alta gestão para apoiar o desenvolvimento de software ágil com ênfase nos
requisitos, através da automação de processos de numa metodologia ágil.
Palavras-chave: Engenharia de software; Requisitos; Métodos ágeis; Scrum; BPM; Bug
tracker;
7
Abstract
The search for excellence and success in software development, has made over time arose
methods to not only produce them but also ensure the quality of software. With agile
engineering came to value the interactions that occur in the development process, Among
the interactions is present volatility of the requirements required by the customer, the
requirements evolve and change with the development process itself, to support this
process in methodologies such as Scrum there are a number of tools to support developers,
they have focused on providing historical base and detailing requirements to be
implemented. In this scenario arises Business Process Management (BPM) paradigm of
enterprise computing to increase agility in organizations. In this context, this paper aims
to develop a tool that uses Bug tracker BPM as a way to line management with agile
practices and facilitating the adaptation of internal processes of organizations to the
software development process and thus generate productivity indicators , bottlenecks and
improvement, allowing for making senior management's decision to support the agile
software development with emphasis on the requirements through the automation of
processes in an agile methodology.
Keywords: Software engineering; Requirements; Agile methods; Scrum; BPM; Bug
tracker
8
LISTA DE FIGURAS
Figura 1. Ciclo de vida modelo cascata.
Figura 2. O ciclo de vida Scrum.
Figura 3. Elementos de um processo.
Figura 4. Modelo do processo do Bug tracker baseado na metodologia Scrum na
notação BPMN.
Figura 5. Cadastrar Backlog.
Figura 6. Analisar Backlog.
Figura 7. Sprint Backlog.
Figura 8. Desenvolver Requisito.
Figura 9. Realizar Testes.
Figura 10. Revisão da Sprint.
Figura 11. Realizar Implantação.
Figura 12:Grafíco de analise carga.
Figura 13: Gráficos dos trabalhos em andamento.
Figura 14: Tempo de Ciclo.
Figura 15: Histograma de duração.
Figura 16: Atividade do processo.
Figura 17. Classificação de Atividades.
9
Sumário
1 INTRODUÇÃO ......................................................................................................... 10
1.1 CARACTERIZAÇÃO DO PROBLEMA ......................................................... 10
1.2 OBJETIVOS E METAS ..................................................................................... 10
1.3 METODOLOGIA E ESTRATÉGIA DE AÇÃO ............................................. 11
1.4 RESULTADOS E IMPACTOS ESPERADOS ................................................ 12
2. REVISÃO DE LITERATURA ................................................................................ 13
2.1 ENGENHARIA DE SOFTWARE .................................................................... 13
2.1.1 ENGENHARIA DE REQUISITOS ............................................................ 16
2.1.2 DEFEITO DE SOFTWARE ....................................................................... 18
2.2 METODOS AGEÍS............................................................................................. 19
2.2.1 SCRUM ......................................................................................................... 21
2.3 BPM...................................................................................................................... 24
2.3.1 MODELAGEM DE PROCESSOS ............................................................. 26
2.3.3 BPMS ............................................................................................................. 27
3. PROPOSTA DE BUG TRACKER ORIENTADO PROCESSOS ....................... 30
4 CONCLUSÕES.......................................................................................................... 40
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 42
10
1 INTRODUÇÃO
1.1 CARACTERIZAÇÃO DO PROBLEMA
Os processos de negócios têm que oferecer vantagens competitivas, logo, para
serem efetivadas, as organizações devem ser capazes de definir, analisar, melhorar, medir
e controlar os seus processos (ANDRADE et al, 2013). Uma das abordagens crescentes
no mercado com este objetivo é o gerenciamento de processos de negócio.
De acordo com Korhonen (2007), Business Process Management (BPM) é
um paradigma chave da computação empresarial para incrementar agilidade nas
organizações.
Segundo Kaplan & Norton (1997), tradicionalmente as corporações têm
tratado suas unidades de serviço de TI como centros de despesas distintos, o que pouco
contribui para alinhá-las, de modo à melhor servir às unidades de negócio e à corporação.
Nesse contexto surge à necessidade de desenvolver uma ferramenta orientada
a processos que apoie as empresas de desenvolvimento software que utilizam
metodologia ágil como forma de gestão, resultando assim em um melhor controle,
aumentando a visibilidade e gerando indicadores de produtividade dentro dos processos
ágeis.
1.2 OBJETIVOS E METAS
Desenvolver uma ferramenta de Bug tracker que seja alinhada com as práticas
ágeis e assim facilitando a adaptação dos processos internos das organizações ao processo
de desenvolvimento de software e com isso gerar indicadores de produtividade, gargalos
e melhorias, possibilitando tomada de decisão da alta gestão.
São objetivos deste trabalho:
 Revisão da literatura dos assuntos abordados;
 Pesquisar ferramentas de Bug tracker.
 Desenvolver uma ferramenta que consolide a proposta do trabalho
aqui pesquisado.
11
1.3 METODOLOGIA E ESTRATÉGIA DE AÇÃO
Ao utilizar modelos de referências de processo juntamente com metodologias
de gestão de projeto, a organização tende a enfrentar uma série de desafios, como a
existência de possíveis sobreposições entre os modelos e metodologias, as quais devem
ser tratadas. Neste sentido, uma forma de abordar as similaridades e diferenças entre eles
é mapear os requisitos de um modelo em relação aos requisitos da gestão. Mesmo que os
requisitos sejam compatíveis ou complementares, as diferenças de rigor podem significar
que os resultados de um modelo podem não atender ao requisito da gestão (PAULK,
2004).
Para que seja possível atender os objetivos deste trabalho, responder as
questões de pesquisa e entender os assuntos que embasaram a ferramenta a ser
desenvolvida, foi utilizada a metodologia de pesquisa revisão da literatura.
Após a revisão da literatura será possível observar a importância de identificar
as interseções do gerenciamento do processo de negócio com as metodologias ágeis, bem
como a relevância de elaborar uma ferramenta de apoio para junção e a realização da
implantação dos conceitos abordados na pesquisa. A visão geral da metodologia de
pesquisa utilizada para realização deste trabalho, foi composta por duas etapas.
A primeira etapa se refere à realização de uma Revisão da Literatura do
assunto de pesquisa para identificar, analisar e selecionar os trabalhados disponíveis
relacionados ao tema. Além da revisão informal, um estudo baseado em revisão
sistemática será conduzido, com o objetivo de reduzir o viés de uma revisão informal e,
também, permitir que a pesquisa bibliográfica possa ser atualizada com novas publicações
(KITCHENHAM, 2004).
A segunda etapa após a identificação dos assuntos abordados na revisão da
literatura, foi desenvolvido uma ferramenta de Bug tracker para apoiar processos de
fabricação do software com ênfase nos requisitos, para que cada etapa do processo possa
ser monitorada e apresente ganhos reais de eficiência, e forneça a equipe dados estáticos
sobre detalhados sobre o processo.
As duas etapas da metodologia de pesquisa têm como objetivo:
1. Identificar os desafios na gestão ágil;
2. Identificar os procedimentos, etapas e processos contidos em uma
documentação ágil;
12
3. Identificar os métodos ágeis e as interações das atividades e dos
procedimentos internos adotados nas organizações;
4. Identificar relacionamento dos assuntos abordados com os a
ferramenta proposta.
5. Desenvolver
uma
ferramenta
Bug
tracker
para
apoiar
o
desenvolvimento de Sofware ágil
1.4 RESULTADOS E IMPACTOS ESPERADOS
O mapeamento dos processos de desenvolvimento software, utilizando
metodologia ágeis visa garantir maior consistência na entrega do produto dando ao cliente
a possibilidade de dispor da ferramenta em um tempo menor, garantindo com que os
esforços para cumprir os requisitos o sejam otimizados.
Quando as etapas do trabalho forem devidamente concluídas será possível
mensurar, o quanto se pode ganhar na eficiência e do cumprimento dos requisitos, e fazer
com que as metodologias ágeis melhorem culturalmente a maneira com que os processos
orientados a requisitos são trabalhados pelas organizações.
O resultado esperando da primeira etapa do trabalho dará as bases para que o
Bugtrack orientado a processos com ênfase em requisitos possa ser construído, atendendo
as intersecções com metodologias ágeis.
A segunda etapa é ter uma ferramenta capaz trazer uma melhor tomada de
decisão e agilizando o cumprimento dos requisitos, fazendo com que cada etapa do
desenvolvimento apresente ganhos reais de eficiência e uma estruturação ampla dos
processos de fabricação do software
13
2. REVISÃO DE LITERATURA
2.1 ENGENHARIA DE SOFTWARE
De acordo com MAFRA (2004), durante os últimos 20 anos, sistemas de
software tem exercido um papel fundamental e crítico em nossa sociedade, estão
presentes em nosso dia a dia, desde aplicações simples de smartfone, editores de texto,
até aplicações mais complexas ERPs softwares para gerenciamento de redes, sistemas de
banco de dados entre outras ferramentas.
Segundo PINTO (2011), na década seguinte, a de 1960, constatou-se que
desenvolver softwares é diferente de desenvolver hardware. O desenvolvimento de
hardware exige uma exaustiva revisão de projeto antes que este possa ser posto na linha
de produção, já o software permite que a medida que ele seja produzido, permite que ele
seja revisado e testado.
Ao longo do tempo, a demanda por softwares aumentou consideravelmente,
aumentou também a complexidade dos softwares. Esses fatores no decorrer do tempo
fizeram com que problemas em relação a produção fossem aparecendo, problemas esses
que foram se repetindo de forma recorrente nos diversos tipos de sistemas, a esses
problemas recorrente damos o nome de crise software.
A crise software abrange problemas relacionados a diversas áreas do software
pautados, desde a maneira ao qual softwares eram projetados pelos gerentes de projetos,
que concentravam suas preocupações nos custos e no tempo de produção, a maneira como
ocorre a implantação das ferramentas de software, a maneira como era feita a manutenção
da mesma. Fatores esse afetam a qualidade e estabilidade, condições que se precisam
garantir para que o usuário possa desfrutar dos recursos presente no software. No processo
de implantação, os usuários devem ter uma fácil adaptação a utilização. A manutenção
precisa ser feita de maneira dinâmica de modo que as atualizações da ferramenta de
software possam atender necessidades de utilização do usuário, necessidades essas como
a adição de funções e revisões do design, e corrigir problemas de funcionamento.
Como reação a essa crise houve, o estabelecimento e uso de sólidos princípios
de engenharia para que se possa obter economicamente software que seja confiável e que
funcione eficientemente em máquinas reais (FRITZ BAUER-1969).
A engenharia de software disciplina tem o objetivo de prover métodos
organizados e boas práticas que visam atender as necessidades de projetos cada vez mais
complexos (BOEHM, 2006).
14
Segundo SOMMERVILLE, (2011) ela engloba todas as etapas de
desenvolvimento do projeto para que seja garantida a solução com qualidade. É a base
para o ciclo de vida da construção do software, desde as fases iniciais, especificações de
requisitos do sistema, até sua implantação e manutenção.
Com estabelecimento da engenharia de software foram surgindo diversos
modelos de processo de software, modelos que visam explicar como o software pode ser
construído. Um modelo de processo de software é uma representação abstrata de um
processo de software. Cada modelo de processo representa um processo a partir de uma
perspectiva particular, de uma maneira que proporciona apenas informações parciais
sobre o processo (SOMMERVILLE, 2007). Cada modelo apresenta como se dá o ciclo
de vida do processo de desenvolvimento, seguem abaixo alguns modelos que são usados
para gerir este processo.
1. O modelo em cascata;
2. Desenvolvimento evolucionário;
3. Desenvolvimento iterative;
4. Modelo de desenvolvimento espiral;
5. Modelo de desenvolvimento incremental;
6. Desenvolvimento baseado em components.
Pressman (2006) cita outros modelos:
1. Modelo Incremental;
2. Modelo RAD;
3. Modelo de Desenvolvimento Concorrente;
4. Modelo de Métodos Formais;
5. Processo Unificado.
Já FALBO (1998), cita em seu trabalho que a escolha de um modelo de ciclo
de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de
desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-atividades
básicas, estabelecendo precedência e dependência entre as mesmas (FALBO, 1998).
O ciclo de vida inclui desde as etapas de construção software até as etapas de
manutenção, segundo PRESSMAN (2006) o modelo clássico de ciclo de vida chamado
15
de modelo cascata, traz uma abordagem sistemática, sequencial ao desenvolvimento do
software, que se inicia no nível do sistema e seus requisitos e avança ao longo da análise
do sistema, projeto, codificação teste e manutenção. A figura 1 apresenta as fases da
modelo cascata:
Figura 1. Ciclo de vida modelo cascata (Fonte: Adaptado Royce 1970 )
De acordo com SOMMERVILLE, (2011) cada uma das seguintes atividades
pode ser resumida da seguinte maneira:
1. Analise e definição dos requisitos: os serviços, restrições do sistema,
serão definidos por consulta aos usuários. Em seguida, são definidos
em detalhes e funcionam como uma especificação do sistema;
2. Projeto de sistema e software. O processo de projeto aloca os requisitos
tanto para hardwares quanto para o sistema, definido assim arquitetura
geral do sistema, definido assim sua descrição fundamental e os
relacionamentos;
3. Implementação e teste unitário. Nesse estágio o projeto do software e
desenvolvido como um conjunto de programas ou unidades de
programas. Essa fase visa verificar também se cada unidade
implementada atendera as suas especificações.
16
4. Integração e teste de sistema. As partes do programa são integradas e
testadas e forma conjunta, visando assim assegurar que os requisitos
do sistema tenham sidos atendidos, após isso ele poderá ser entregue
ao cliente.
5.
Operação e manutenção: nessa fase que é a mais longa do processo, é
onde o software entra em operação, e a partir daí ele será, os bugs que
forem dectados começaram a serem corrigidos, poderá haver
ampliação do sistema havendo assim a adição de novas funcionalidade
e descobertas de novos requisitos.
Este modelo como já dito antes, fala das etapas básicas da construção de
software etapas essas que são semelhantes em diversos modelos, para fins de estudo e
construção da ferramenta nos os tópicos seguintes apresentaremos a técnicas e
metodologias que serão as bases para sua elaboração.
2.1.1 ENGENHARIA DE REQUISITOS
De acordo com BECK (2000) Organizações de desenvolvimento de software
geralmente enfrentam grandes desafios na produção de seus sistemas. Grande parte disso
está relacionado à volatilidade de seus requisitos. O acompanhamento de como os
requisitos, se comportam ao longo do desenvolvimento é importante para se garantir o
produto final atenda às necessidades dos clientes.
Segundo DUARTE (2012) Um requisito pode ser entendido como uma
condição ou funcionalidade à qual o sistema desenvolvido deve corresponder. A análise
de requisitos é o processo de descobrir, refinar, modelar, e especificar os propósitos do
cliente (PRESSMAN, 1997 apud DUARTE 2012).
Durante o levantamento de requisitos cliente e a empresa vão trabalhar juntos
para poder encontrar a melhor maneira para que os requisitos sejam estabelecidos.
Entende-se que o próprio processo de definição de requisitos gera um feedback que acabar
modificando os próprios requisitos (HAZAN, 2003).
A deficiência no tratamento de requisitos tem sido apontada como a principal
causa de fracassos de projetos de software (HOFMANN,2001) Esse processo é
sistemático e abrange diversas atividades, tais como elicitação, análise e negociação,
documentação, validação e gerência de requisitos (KOTONYA,1998).
17
De acordo com NADDEO (2002) cada umas as etapas citadas da engenharia
de requisitos podem ser resumidas do seguinte modo:

Elicitação: nessa fase os requisitos serão descobertos, serão feitas
reuniões com stakeholders, nas quais serão discutidas expectativas
objetivos ao qual aplicação se destina, a equipe de desenvolvimento
vai começar a entender o domino da aplicação para assim encontrar
maneiras de entender e resolver a complexidade do problema em
questão. Se identifica as partes interessadas e papel de cada
stakeholders no sistema e o seu nome, além disso se define também
as técnicas que vai serão usadas para realização desse processo;

Análise e negociação: As atividades conduzidas no contexto de
Análise e Negociação de requisitos destinam-se a resolver problemas
relacionados aos requisitos que envolvam diferentes percepções do
mesmo problema ou necessidade por mais de um stakeholder, bem
como os problemas gerados pela representação do conhecimento
obtido de mais de um stakeholder;

Documentação: Após o identificados os requisitos devém ser
documentos para que possam, servir como base para as etapas
restantes do processo de desenvolvimento;

Validação: nesta etapa a de se verificar a consistência dos requisitos
levantados;

Gerencia de requisitos: etapa de administração dos requisitos ao
longo do projeto, pois possuem volatilidade ou seja podem ser
alterados conforme as necessidades que venha a surgir no decorrer do
processo de desenvolvimento mas essas alterações não deve
comprometer o tempo final de entrega do projeto.
Os requisitos podem ser classificados no geral em funcionais, e não
funcionais:

Funcionais: representam aquilo que o sistema deve fazer. Ou seja tudo
aquilo que acaba sendo transformado em funções do sistema, podem
ser divididos em, essenciais, desejados e supérfluos
18

Não funcionais: representam os atributos do sistema, definem
propriedades e as restrições do sistema, estão relacionados com
segurança,
usabilidade,
confiabilidade
e
manutenibilidade
e
tecnologia envolvida.
2.1.2 DEFEITO DE SOFTWARE
Ao gerenciar um projeto, a gerente ira dispor ferramentas para tornar
simplificar o acompanhamento do ciclo de vida, para que assim ele possa minimizar e até
evitar que ocorram falhas durante o projeto. Com software não poderia ser diferente,
evitar e gerenciar possíveis falhas no produto é essência para que a empresa de software
se manter competitiva no mercado, conceito de Bug tracker sugere uma ferramenta, que
apoia a gestão defeitos para que assim manter a qualidade do software.
Evitar defeitos no software é garantir que o cliente possa dispor dos padrões
de qualidade aos quais ele requisitou é evitar possíveis custos, portanto, descobrir os
defeitos do(s) software(s) da empresa não é suficiente, é essencial adotar o gerenciamento
de defeitos no processo de teste para minimizar, controlar, evidenciar os riscos para que
os seus impactos não sejam grandes (ELIZA; LAGARES, 2011).
O grande objetivo do Teste é garantir qualidade ao sistema, o que não quer
dizer que o mesmo vai ser entregue ao cliente sem nenhum problema. (ELIZA;
LAGARES, 2011). No Scrum diferentemente de outras metodologias as equipes de
desenvolvimento e teste de estão integradas no mesmo time, de modo que a equipe de
teste passe a ser vista como parceira e não adversaria da equipe de desenvolvimento.
De acordo com ELIZA; LAGARES, (2011) muitas pessoas confundem o
significado de defeito, erro e falha, cada conceito pode ser resumido em:

Erro (engano): ação humana que produz resultados incorretos, como
por exemplo, a implementação errada de um algoritmo;

Defeito (bug): falha em um sistema que pode ocasionar uma anomalia
ao tentar desempenhar a função proposta. Por exemplo, omissão de
informações e cálculos incorretos;

Falha: ação inesperada no software. Por exemplo, o sistema apresenta
resultados diferentes do planejado.
19
No mercado existem diversos tipos de ferramentas que visam apoiar as
equipes de teste, no controle e detecção de erros/defeitos que podem vim a resultar em
falhas do sistema. Entre elas podemos citar: o Mantis; BugZilla; Testlink; Salomé TMF.
2.2 METODOS AGEÍS
Os métodos de desenvolvimento ágil, surgiram em respostas aos problemas
percebidos pela indústria, especialmente quanto a taxa de sucesso dos projetos (ROSE
MELO, 2010). A taxa de sucesso dos projetos vinha caindo, segundo JOHNSON, (1995)
em um estudo da Standish Group (1995) com mais de 30 mil projetos de desenvolvimento
de produtos de software desde 1994, revelou que, embora tenha havido melhorias com o
passar do tempo, ainda há um grande problema no setor.
Problemas aos quais foram apontados por esse estudo, estão relacionados a
atraso na entrega de aumento dos custos, e taxa de implementação (projetos que se
tornaram, produtos de software que realmente forma utilizados pelo usuário final). Por
décadas o desenvolvimento de software seguiu o modelo clássico de cascata para
desenvolvimento de produtos (ROSE MELO, 2010). Segundo Pinto, 2011, esse modelo
prega a evolução sequencial dividindo o projeto de forma semelhante ao que se faz na
linha de produção. Esse enrijecimento do modelo de gestão adotado garantiu que as taxas
de sucesso das entregas dos softwares desenvolvidos fossem baixas (ROSE MELO,
2010).
Os métodos ágeis surgem como respostas aos métodos tradicionais, que são
baseados no seguimento de um plano bem definido, excesso de documentação e rigorosa
padronização (NERUR et al., 2005).
As metodologias ágeis, que ganham mais destaque no início do ano de 2001
com a definição do Manifesto Ágil (BECK et al., 2001). O manifesto apresenta um
conjunto de valores e princípios que provem as bases para desenvolvimento ágil. Nele
os autores falam:
“Estamos descobrindo maneiras melhores de desenvolver software, fazendoo nós mesmos e ajudando outros a fazerem o mesmo.”
Segundo Manifesto ágil(2001), os valores são:

Indivíduos e interações mais que processos e ferramentas
20

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens
à esquerda.
No manifesto é apresentado os seguintes princípios:
1. Nossa maior prioridade é satisfazer o cliente através da entrega
contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento.
Processos
ágeis
tiram
vantagem
das
mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a
poucos meses, com preferência à menor escala de tempo.
4. Pessoas
de
negócio
e
desenvolvedores
devem
trabalhar
diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o
ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e
entre uma equipe de desenvolvimento é através de conversa face a
face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de
manter um ritmo constante indefinidamente.
9. Contínua
atenção
à
excelência
técnica
e
bom
design
aumenta 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.
21
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais
eficaz e então refina e ajusta seu comportamento de acordo.
De acordo com Cohen et al, (2004) a partir da divulgação do Manifesto Ágil,
metodologias como Adaptive Software Development (ASD) (Highsmith e Cockburn,
2001), SCRUM (Schwaber e Beedle, 2002) e eXtreme Programming (XP) (Beck e
Andres, 2004) ganharam um grande número de adeptos e se tornaram objeto de pesquisas
acadêmicas .
Enquanto as metodologias tradicionais de desenvolvimento mantêm o foco
na geração de documentação sobre o projeto e no cumprimento rígido de processos, a
proposta ágil é concentrar as atenções no desenvolvimento em si e nas relações entre os
participantes (MUNDIN et al., 2002).
Projetos que seguem métodos ágeis, permitem flexibilidade, visando enxugar
a produção e evitar o desperdício, o cliente participa ativamente do processo de
desenvolvimento, de modo que assim o produto final consegue se aproximar daquilo que
o cliente espera.
2.2.1 SCRUM
De acordo com PRESSMAN, (2006) o framework Scrum é uma metodologia
ágil de desenvolvimento para gestão e planejamento de projetos de software. Foi
elaborada por Jeff Sutherland e por sua equipe, no início da década de 90, e tinha como
base o processo de produção de automóveis de indústrias japonesas.
Segundo CARVALHO E MELO (2009) o nome Scrum surgiu da comparação
entre desenvolvedores e jogadores de Rugby. Scrum é a denominação da rápida reunião
que ocorre quando os jogadores de Rugby irão iniciar um lance.
No Rugby, cada time age em conjunto, como uma unidade integrada, em que
cada membro desempenha um papel específico e todos se ajudam em busca de um
objetivo comum (CARVALHO E MELO 2009).
Assim como no Rugby, no Scrum a cada nova Sprint os desenvolvedores se
reúnem para assim debater e chegar num consenso sobre a fase do projeto que será
iniciada, dessa maneira pode se garantir que haja flexibilidade para observar e discutir
tanto o que foi planejado antes do início do projeto quanto para lidar com os desafios que
surgiram ao longo da execução do projeto.
22
Esta
metodologia
fornece
técnicas
específicas
para
a
fase
de
desenvolvimento, constitui práticas gerenciais que devem ser adotadas para o sucesso de
um projeto.
Segundo SCHWABER, (1995) Scrum baseia-se em seis características
flexibilidade dos resultados; flexibilidade dos prazos; times pequenos; revisões
frequentes; colaboração; orientação a objetos. PEREIRA et al, (2007) ressalta que as
práticas do Scrum podem ser aplicadas em qualquer conjuntura onde pessoas precisem
trabalhar juntas para atingir um objetivo comum. Logo podemos aplicar Scrum a projetos
que não seja essencialmente de desenvolvimento de software.
Segundo CARVALHO E MELO, (2009) temos como praticas gerenciais do
Scrum as seguintes atividades: Product Backlog, Daily Scrum, Sprint, Sprint Planning
Meeting, Sprint Backlog e Sprint Review Meeting.
Product Backlog é a etapa inicial do processo onde é feito uma série de
reuniões com objetivo, de definir os requisitos que serão implementados, reuniões essas
que contam com todos os envolvidos, investidores e parceiros no projeto, são apontados
os itens com todas as necessidades do negócio e os requisitos técnicos a serem
desenvolvidos (CARVALHO E MELO 2009). A lista de funcionalidade fica em
constante adaptação ao longo de todo o projeto com o objetivo de atender as mudanças
que podem surgir no decorrer deste (SCHWABER, 2009).
Sprint Planning Meeting é a reunião em que o time faz o planejamento do
Sprint (CARVALHO E MELO 2009).
Sprint Backlog ANDRADE (2012) fala que esta etapa consiste na análise do
Product Backlog, com a elaboração de um conjunto dos requisitos aceitos, que serão
implementados na Sprint.
Daily Scrum consiste em reunião diária, rápida que possibilita o controle das
atividades que serão feitas durante o dia. Três perguntas devem ser respondidas por cada
membro sobre suas responsabilidades (RISING & JANOFF, 2000): O que foi feito
ontem? O que será feito hoje? Há algum obstáculo à realização de suas atividades?
Sprint Review Meeting Após cada Sprint a equipe se reúne avalia os
resultados erros, acertos, a Sprint dura de duas a quatro semanas com a sua revisão é
possível apontar quais caminhos o desenvolvimento do software seguira até ele esteja
pronto para implantação. Caso nessa revisão surjam novos requisitos eles serão inseridos
no Product Backlog, para serem adicionadas nas Sprints posteriores, dependendo assim
do seu grau de importância pra o projeto.
23
A figura 2, mostra como estão interligadas cada etapa do clico de vida do
Scrum, e também o tempo médio que cada uma delas leva para sua conclusão:
Figura 2. O ciclo de vida Scrum - (THAMIEL, 2009)
No Scrum os diversos stakeholders do projeto são divididos em dois grupos
principais: os envolvidos e os comprometidos. Os envolvidos são os diversos espectadores
do projeto que não têm autoridade direta sobre o processo (SCHWABER, 2004). Pinto 2001
cita que os comprometidos são aqueles que estão diretamente ligados ao projeto e tem papéis
bem definidos, sendo eles: Scrum Master, Product Owner e Time (equipe Scrum).
O Scrum Master deve trabalhar para que o processo Scrum aconteça e para
que não existam impedimentos para que os membros da equipe realizem seu trabalho
(CARVALHO E MELO 2009). O Scrum Master é comparado com gerente projetos
contudo SCHWABER, 2004, ressalta que enquanto o gerente de projetos gerencia
ditando o ritmo do trabalho, o ele gerencia o funcionamento do Scrum. Logo ele é o
responsável por garantir seu funcionamento, fazer com que as práticas do Scrum sejam
efetivamente realizadas.
A reponsabilidade de definir requisitos cabe ao Product Owner, Segundo
CARVALHO E MELO (2009) sendo ele membro do time tem ao qual tem o papel de
representar o cliente interno ou externo. Para PEREIRA et al, (2007) que além disso
decide a data do release e o que deve conter nele, é responsável pelo retorno financeiro
(ROI) do produto, e deve priorizar os requisitos de acordo com o seu valor, ajustá-los
conforme a prioridades para cada Sprint, aceita ou rejeita o resultado de cada Sprint.
24
O time é justamente a equipe de desenvolvimento, cada time é responsável
pelo seu próprio gerenciamento e organização, PINTO, (2011) ressalta que dessa forma,
o Scrum Master trabalha apenas como facilitador no dia-a-dia da equipe. São os membros
classificados nesse papel que decidem como os requisitos vão ser transformados em
funcionalidades (SCHWABER, 2004).
PRESSMAN (2011), cita Beedle e seus Colegas [bee99] expondo que “O
Scrum pressupõe a existência do caos dessa” desse modo o framework Scrum procura
trabalhar num mundo onde a eliminação de incertezas é impossível.
2.3 BPM
Gerenciamento de Processos de Negócio (do original em inglês: Business
Process Management – BPM) é uma abordagem de gestão que vem recebendo interesse
crescente da academia e da indústria na última década (SANTANA et al, 2010).
Segundo mini dicionário AURELIO, processo é uma sucessão de estados ou
de mudanças, de modo que se possa realizar ou executar uma coisa. Em linhas gerais
processo é o conjunto de passos/atividades necessárias para que uma ação seja executada.
BPM refere-se à gestão do ciclo completo de gerenciamento de processos de negócio, o qual
inclui: desenho, análise, implementação, execução e melhoria contínua dos processos de uma
organização (SANTANA et al, 2010).
Assim como os requisitos de uma ferramenta de uma ferramenta de software
os processos evoluem com passar do tempo e precisam ser e ter uma gerencia que permita
o ganho de eficiência e ao mesmo tempo flexibilidade para lidar com mudanças que
podem vim a ocorrer ao longo do tempo. Os princípios de BPM enfatizam a visibilidade,
a reponsabilidade, e a capacidade de adaptação dos processos e constantemente
aperfeiçoar resultados e melhor enfrentar os desafios de um ambiente de negócio
globalmente diversificado(CBOK,2013).
Dentro do contexto da adoção do BPM é de suma importância a análise
minuciosa de como está todo o andamento organizacional com a implantação
da metodologia, pois é preciso mapear o potencial de cada processo, visando o
que cada um pode gerar ou não no ponto de vista da otimização constante
(JOSE et al ,2014).
25
A questão é que em muitas organizações seus diversos departamentos
trabalham de maneiras separadas o que dificulta a adoção de BPM, sua adoção sugere que
a empresa passe a ser enxergada como um todo, sendo ela é composta por diversos sub
processos que se integram.
O BPM possibilita, por exemplo, que um analista de negócios integre os
sistemas de tecnologia da informação (TI) com as metas estratégicas de uma organização
da forma mais viável (JOSE et al ,2014). Os Processos de negócio definem como as
organizações executam o trabalho para entregar valor a seus clientes e aplicar BPM é se
concentrar
nos
processos
interfuncionais
que
agregam
valor
para
esses
clientes(CBOK,2013).
Segundo AMARAL et al (2008) o BPM possibilita as seguintes vantagens:

Melhoria da velocidade do negócio: os tempos de ciclo dos
processos podem ser reduzidos significativamente por meio da sua
automação, realização de atividades paralelas, controle e
monitoramento;

Aumento da satisfação dos clientes: os clientes internos e externos
podem obter informações mais rapidamente e facilmente devido à
melhoria no tempo do ciclo e do monitoramento, já que as
ocorrências não se perdem ao longo do caminho, assim, ações
preventivas e corretivas são gerenciadas com maior agilidade;

Integridade: o BPM, por ser também estratégico para suportar
certificações de qualidade (ex.: ISO) e exigências regulatórias (ex.:
Lei Sarbanes-Oxley), garante a integridade por seguir todos os
passos especificados no processo;

Flexibilidade: a intervenção da área de informática é minimizada,
existindo uma grande flexibilidade para alteração de fluxos e regras
de negócio;

Maximização da melhoria e evolução dos processos: a
disponibilidade de indicadores e métricas sobre custos, tempos de
execução, carga de trabalho e outros aspectos, geram insumos
fundamentais para um trabalho de melhoria.
26
O CBOK, (2013), reforça que Adoção de BPM é uma jornada, não um destino
desse modo podemos entender que ao longo de sua adoção ele reforçara desde as
estratégias da empresa até a operação, dando maior resiliência a organizacional e
operacional, menos intrusiva fazendo com assim se tenha o aumento de produtividade.
2.3.1 MODELAGEM DE PROCESSOS
Ao adotar BPM, precisamos ter noção de como os processos estão
organizados, e como se dão as interações nele, quais são suas etapas? Nesse processo
temos subprocessos? Quais são suas atividades e tarefas? Faz-se necessário que ele seja
mapeado e modelado para que assim possa iniciar de fato a sua gerencia.
De acordo com LOJA (2011), Com a modelagem dos processos é possível
visualizar o funcionamento da organização através dos modelos obtidos. A modelagem
servira para aumentar o nível de compreensão dos processos, nela deverão estar contidos
não só as tarefas e subprocessos, como também os papeis dos atores envolvidos, além os
recursos que estão sendo utilizados. Desse modo a organização passa a desenvolver sua
capacidade de BPM, Segundo o CBOK, (2013) para “ter a capacidade de gerenciar”
processos de negócio, a organização deve possuir métodos otimizados, pessoas
preparadas e tecnologias apropriada para tal. A figura 3 ilustra os elementos básicos de
presentes num processo:
Figura 3. Elementos de um processo (Araujo e Borges, 2001)
A modelagem de processos de negócio deve incluir, a informações atuais do
processo (As Is), o modelo futuro do processo (To Be), Segundo FRANCO, (2014) ela é
27
formada por um conjunto de técnicas que buscam descrever as atividades dentro da
empresa e como elas se relacionam e interagem com os recursos do negócio buscando
alcançar o objetivo do processo.
A partir do momento em que se tem o modelo do processo com todas as suas
atividades e executores definidos, é possível simular a sua execução a partir de
dados coletados no dia-a-dia e, dessa forma, verificar o fluxo de informações,
testar as regras definidas e principalmente medir a eficiência do processo
(PUNTAR et al, 2009).
Modelagens no geral são representadas por diagramas de fluxo de trabalho,
para entender a situação atual (As-Is) e a situação futura desejada (To -Be). Segundo
OLIVEIRA S (2012), o autor fala que diagramas de fluxo servem como uma análise de
eventuais lacunas entre como a organização trabalha e como deve trabalhar no futuro,
sinalizando os pontos que precisam ser melhorados para que possa alcançar efetividade
na melhoria de processos de negócio.
2.3.3 BPMS
De acordo com PUNTAR et al, (2009) [TIC/IDTA/AT, 2008] um BPMS
(Business Process Management System) é um ambiente integrado de componentes de
software que automatizam o ciclo de vida de processos de negócios, desde a sua
concepção e modelagem inicial, passando pela execução e monitoramento, até a
incorporação de melhorias, inclusive com a possibilidade de simulação.
Quando falamos em BPMS estamos falando em automação de processos, em
geral as ferramentas presentes no mercado apresentam um conjunto de instrumentos que
a partir do modelo já otimizado (To-Be), fazem a automação. Segundo PUNTAR et al,
(2009) a automação ocorre através do acompanhamento de atividades por um motor de
execução de processos, que funciona recebendo e enviando as atividades aos agentes
responsáveis pela sua execução.
A automação do processo ocorre com a criação de uma ferramenta a partir do
modelo de processo de negócio na notação BPMN, ela irá gerenciar o fluxo de trabalho
do processo. Um webservice, no qual os subprocessos, as etapas tarefas e atividades
envolvidas, estão devidamente interligados por meio das regras de negócio para a
execução do processo, estará também definido o papel dos atores envolvidos.
28
Um webservice é uma solução utilizada na integração de sistemas e na
comunicação entre aplicações diferentes. Com esta tecnologia é possível que
novas aplicações possam interagir com aquelas que já existem e que sistemas
desenvolvidos em plataformas diferentes sejam compatíveis (SHODJAI, 2006
apud TESSARI, 2008).
De acordo com SORDI e SPELTA (2006) o modelo conceitual do BPMS
valoriza os investimentos já realizados em softwares pelas organizações envolvidas com
o processo de negócio, diferentemente da estratégia da reengenharia de uma década atrás,
que apregoava o descarte e a substituição dos sistemas de informação. Os autores ainda
ressaltam que, no modelo, sistemas de informação legados, hospedados em diferentes
ambientes computacionais, com adoção do BPM pela organização continuam a executar
as operações necessárias aos processos de negócio ao quais estão envolvidas.
De acordo com DUBOULOZ (2004) as ferramentas BPMS deveram ser
compostas por cinco blocos são eles: definição de processos; mecanismo de execução e
controle de processos; modelagem gráfica do processo; Controle de atividades; e interface
do usuário.
Para SANTOS et al (2009) os sistemas BPMS são compostos de um conjunto
de soluções as quais ele cita as seguintes, workflow (automação de processos), EAI –
Enterprise Application Interchange (troca de informações entre sistemas empresariais) e
TICs (Tecnologias de Informação e Comunicação), ferramentas de modelagem dos
processos de negócios (e.g.: UML e BPMN), componentes de integração dos processos
(e.g.: ERP, SCM, GED, CRM, data centers e etc.) e ferramentas de simulação e análise
(e.g.: Business Inteligence - BI).
Funcionalidades essas que estão relacionadas tanto com o conjunto de
ferramenta apresentado por DUBOULOZ conjunto esse que é explicitado por SANTOS
et al, mostrando a maneira a maneira como as ferramentas se integram para dar vida ao
BPMS.
ARAUJO e BORGES, (2001) Explicam que um BPMS apresenta as seguintes
funcionalidades: definição dos processos, controle de execução dos processos, controle
de interações e gerenciamento e acompanhamento de execuções.
29
Em um estudo conceitual realizado por PUNTAR et al, (2009), o autor
explica cada umas dessas funcionalidades mostrando a maneira como elas se relacionam
para geração de melhorias nos processos:

A definição de processos está relacionada com a modelagem, ela deve
apresentar todas informações necessárias para que processo possa
funcionar, é nessa fase em que o processo e suas etapas e ferramentas
tornam-se evidentes, suas condições de início e fim. Nessa etapa
ocorrem também as simulações, que vão permitir observar como o
processo se comporta, e onde o processo pode ser alterado ou não.

O controle de execução dos processos, através da interpretação do
processo implementado no BPMS, ele irá acompanhar e coordenar a
sua execução, ela corresponde à ativação de instâncias, várias
instâncias de um mesmo processo ou de processos distintos podem
estar em execução simultaneamente em um BPMS.

No controle de interações está relacionado a maneira como o BPMS
adiciona itens às listas de trabalho atores do processo, tais listas
contêm atividades de diversas instâncias dos diversos processos em
execução. Os atores, por sua vez, acessam as suas listas de trabalho e
selecionam a tarefa que desejam executar. A execução da tarefa
envolve a manipulação de documentos, tomadas de decisão ou
preenchimento de dados

Gerenciamento e acompanhamento de execuções, modelo do
processo apresentara o status das atividades realizadas, em execução
ou a serem executadas, BPMS pode ter recursos de medida de
desempenho e estatística que auxiliam na projeção de melhorias.
Das várias ferramentas BPMS disponíveis no mercado Bizagi [Bizagi 2010]
e Bonita [Bonita 2010] podem ser citadas como exemplos do estado da prática nesse tipo
de software(OLIVEIRA et al,2011).
30
3. PROPOSTA DE BUG TRACKER ORIENTADO PROCESSOS
Os conceitos apresentados no capítulo anteriores serviram como base para
que a ferramenta proposta pudesse ser elaborada.
A proposta de Bug tracker tem como base e fim mapear e monitorar o
processo de desenvolvimento de um requisito até sua implantação, com base na
metodologia Scrum de gerenciamento de projetos de software. Para que isso fosse
possível de ser realizado, foi feita a modelagem das etapas necessárias para
implementação do requisito, modelagem essa que utiliza a notação BPMN.
A modelagem e automação do processo fosse realizada foi utilizado o
Software Bizagi Studio, posteriormente o modelo gerado serviu como base para
automação do processo, etapa que resultou na criação da ferramenta.
As figuras 4 a 11 apresentam a modelagem do processo e sua automação,
explicando cada tarefa contida no processo e suas respectivas etapas, desde seu início até
o seu fim:
Figura 4. Modelo do processo do Bug tracker baseado na metodologia Scrum na
notação BPMN. (Fonte o autor)
31
O processo inicia com o cadastro do Backlog. Nesta etapa que é cadastrado
na ferramenta o requisito ao qual será desenvolvido no processo, cada requisito
cadastrado é trabalhado em um fluxo de processos na ferramenta fica em um processo.
Figura 5. Cadastrar Backlog. (Fonte o autor)
A etapa de cadastro do Backlog, contém o formulário apresentado na figura
5, dele fazem parte os seguintes campos:

Id do Requisito: código pelo qual o requisito é identificado;

Nome Do Requisito;

Story: descrição do requisito e sua funcionalidade;

Data do Requisito: é data ao o requisito foi cadastrado na ferramenta;

Categoria do requisito: Relatório, código fonte e banco de dados;

Sistema: nesse campo é relatado software ao qual o requisito pertence;

Plataforma: Campo utilizado para que seja informado a plataforma ao
qual o requisito pertence;

Passo para reproduzir: Caminho para que a funcionalidade seja
executada;
32

Anexo: espaço utilizado pra que possa ser carregado e enviado o
documento (ou imagem), para auxiliar o entendimento do requisito;
Ao terminar o preenchimento dos campos, o formulário apresenta os
seguintes botões, Guardar e Próximo: ao Guardar tudo que foi preenchido será salvo no
banco de dados do Bizagi, ao Clicar em Próximo, além de guardar as informações do
processo, ele caminhara para a etapa seguinte.
A análise do Backlog, consiste na análise e votação da prioridade
implementação do Requisito.
Figura 6. Analisar Backlog. (Fonte o autor)
A etapa de Analise Backlog contém as informações inseridas no formulário
anterior ao qual sofre o acréscimo dos seguintes campos:

Pontuação do Cliente: Campo ao qual é informado qual a prioridade
que o cliente aufere para o requisito que foi cadastrado.

Estado do Requisito: Apresenta a situação ao qual o requisito se
encontra, ele pode receber os seguintes atributos: Aberto quando o
requisito ainda não foi iniciado; Em desenvolvimento; Fechado
quando o requisito foi finalizado; e Ignorado.
33

Pontuação da Equipe Técnica: Apresenta a pontuação da prioridade e
do grau de dificuldade avaliado pela equipe técnica para que o
requisito seja implementado.

Ao marcar implementado o usuário tem opção de escolher se o
processo continuará ou não, para que ele continue deve se marcar a
opção sim e clicar no botão próximo, para que ele seja finalizado
clique na opção não e em seguida no botão próximo, desse modo o
requisito que ao qual foi decidido que será implementado é inserido
no Sprint Backlog, passo ao contém os requisitos que serão
desenvolvidos pelo time.
A figura 7 mostra o Sprint Backlog, esta etapa possui um formulário com as
informações sobre o requisito - sendo possível a edição do atributo estado -, o passo tem
a duração de 15 dias, é nesse período ao qual ele deve ser iniciado. Uma vez feito, devese alterar o estado do requisito para Em desenvolvimento e clicar em próximo para que
o processo vá à etapa de desenvolvimento.
Figura 7. Sprint Backlog. (Fonte o autor)
A figura 8 mostra a etapa de Desenvolvimento do requisito, onde o estado
do requisito será alterado para Fechado para que assim possa ser encaminhado para a
fase de teste. Os campos Relatar Comportamento e Aprovar requisito poderão ser
editados na fase seguinte.
34
Figura 8. Desenvolver Requisito. (Fonte o autor)
O formulário da figura 9 está relacionado com a etapa Realizar Testes, traz
neles além das informações das fases anteriores os seguintes campos:

Relatar comportamento: para que o teste faça breve relato de como o
requisito se comportou durante a fase, e que possam ser relatados os
critérios que levaram a sua aprovação ou reprovação.

Aprovar Requisito: ao clicar em sim e no botão próximo o requisito
será enviado para a etapa de Revisão da Sprint, se não ele será
encaminhado novamente a etapa de Desenvolver requisito.

Caso seja aprovado o estado será alterado para fechado, se não for
permanece ele Em desenvolvimento.
35
Figura 9. Realizar Testes. (Fonte o autor)
A figura 10 mostra a etapa de Revisão da Sprint, o requisito aprovado poderá
ser revisto, e consequentemente, ser feito o no campo Relatar Comportamento um relato
de como ele se comportou na revisão, ou seja se surgiram ou não novas informações sobre
ele.
Figura 10. Revisão da Sprint. (Fonte o autor)
A figura 11, mostra Formulário da etapa Realizar Implantação onde são
apresentados os campos:
36

Relato de implantação: destinado ao responsável pela implantação do
requisito aprovado, possibilitando-o fazer um relatório do que ocorreu
durante a implantação.

Requisito implementado: campo para a checagem se o requisito foi
implantado.
Ao final do processo caso seja clicado no botão guardar as informações serão
salvas no banco de dados e processo ainda continuará ativo, ao pressionar próximo ele
será encerrado.
Figura 11. Realizar Implantação. (Fonte o autor)
Além do acompanhamento do fluxo do processo, com a ferramenta resultante
da automação, é possível obter uma serie de relatórios de desempenhos relacionados ao
processo. Gráficos e planilhas que tem como objetivo fornecer a informações detalhadas
sobre o andamento dos processos.
O Gráfico da figura 12, mostra para todos os processos ativos a quantidade
de casos que estão em dia, em risco ou atrasados. Em risco significa que expiram hoje.
37
Figura 12:Grafíco de analise carga. (Fonte o autor)
A figura 13, os gráficos do Trabalho em andamento:

Estado de caso: Este gráfico mostra a porcentagem de casos que estão
em dia ou em rico ou atrasados;

Casos próximos do vencimento: mostra quando os casos em aberto
atingirão suas datas de expiração.
Figura 13: Gráficos dos trabalhos em andamento. (Fonte o autor)
A Figura 14 , os graficos relacionados com o tempo de ciclo.
38

Duração do caso: duração média x duração esperada;Estado de caso:
Este gráfico mostra a porcentagem de casos que estão em dia ou em
rico ou atrasados;

Tabela de Resumo do tempo de clico.
Figura 14: Tempo de Ciclo. (Fonte o autor)
A figura 15 apresenta Histograma de duração, o gráfico mostra quantos dias
forma necessários para concluir os casos encerrados. A linha tracejada vertical separa os
casos em dia dos atrasados.
Figura 15: Histograma de duração. (Fonte o autor)
A figura 16 apresenta os seguintes gráficos: Tendência; Atividade do
processo e a tabela de resumo, os gráficos estão contidos na tela de nome Atividade do
39
processo, onde possível selecionar m intervalo de tempo para que os gráficos sejam
gerados.

Tendência: Tendência ou número de ativações do processo no
intervalo de tempo selecionado;

Atividade do processo: Casos iniciados, casos encerrados casos
abortados no intervalo de tempo selecionado;

Tabela de resumo das atividades do processo.
Figura 16: Atividade do processo. (Fonte o autor)
A Figura 17, mostra denominada Classificação de Atividades o número
ativações do processo, num intervalo de tempo selecionado.
Figura 17. Classificação de Atividades. (Fonte o autor)
40
4 CONCLUSÕES
Produzir software antes do surgimento da engenharia de software era uma
tarefa ao qual era vista com abordagem semelhante as das linhas de produção industriais,
com passar do tempo essa forma de produzir software passou a gerar os problemas aos
quais foram denominados de crise de software. Com estabelecimento da engenharia
tornou-se possível além otimizar o processo de produção de software, estabelecer padrões
de qualidade para atender as demandas dos clientes.
Com o surgimento dos métodos ágeis produzir software tornou-se uma tarefa
dinâmica de modo a valorizar “os indivíduos e as interações mais que processos e
ferramentas” (Manifesto ágil, 2001). Possibilitando aos atores envolvidos no processo de
software, trabalhar de maneira flexível e pratica, para responder de as requisições feitas
pelos clientes. Requisições essas que mudam com passar do tempo.
Ao iniciar o processo de desenvolvimento os requisitos da ferramenta pelo
cliente evoluem, tanto pelo próprio processo de desenvolvimento quanto pela utilização
do software pelo cliente, em metodologias de gestão como o Scrum o cliente tem um
representante dentro da equipe de desenvolvimento Product Owner é o responsável por
fazer com que os requisitos do software desejado pelo cliente possa corresponder ao
esperado.
As equipes de desenvolvimento para auxiliar a gerencia tanto dos requisitos
quanto bugs podem que ocorrem no sistema, utilizam-se de ferramentas para facilitar o
acompanhamento e a evolução que eles sofrem no recorrer do desenvolvimento.
Ferramentas que em sua maioria servem apenas como repositório de informações e
observações sem apresentar dados e estatísticas sobre como o requisito/Bug se comportou
durante o processo de software.
Ao alinhar a metodologia ágil Scrum com BPM, foi possível obter uma
ferramenta capaz de acompanhar a tarefa de desenvolvimento, de modo que os atores
envolvidos possam obter dados estatísticos sobre a duração das fases bem como o nível
de sucesso de cada requisição, e também monitorar e auxiliar os envolvidos a cumprirem
com os prazos para entrega e resolução dos requisitos. Construída com auxílio do BPMS
Bizagi Studio, foi possível observar todo o poder que essa nova tecnologia tem e como
ela é capaz de auxiliar a integração das etapas de um processo. Oferecendo recursos para
que a ferramenta gerada possa ser integrada com ferramenta de Bug tracker.
41
Como proposta de trabalhos de trabalho futuros, seria possível um estudo de
caso sobre o impacto do uso dessa ferramenta, em uma fábrica de software que use a
metodologia Scrum de desenvolvimento.
42
REFERÊNCIAS BIBLIOGRÁFICAS
AMARAL, F.P., et al. O papel das ferramentas para sistematização de processos de
negócio (bpms). In: XXVIII Encontro Nacional de Engenharia de Produção, 2008. Rio
de Janeiro. Anais do XXVIII do Encontro Nacional de Engenharia de Produção –
ENEGEP, 2008.
ANDRADE, Rômulo C. et al. Um Estudo De Caso Sobre Integração De Sistemas Usando
BPM Em Um Escritório De Advocacia. Revista Eletrônica Eng Tech Science ANO I,
Vol. 01, N. Jaboatão dos Guararapes - PE
ARAUJO, R.; BORGES, M.R.S. Sistemas de Workflow. In: Jornadas de Atualização
Em Informática (JAI), Congresso da SBC, 2001, Fortaleza, Ceará, pp. 1 - 17
BPM CBOK. Guia para Gerenciamento de Processos de Negócio Corpo Comum de
Conhecimento 1ª Edição, ABMPM Brasil 2013.
BECK, K. “Extreme programming explained: embrace change.” Addison-Wesley
Longman, Boston, MA, 2000.
BOEHM, B. A view of 20th and 21st Century Software Engineer. ICSE’06 Shanghai,
China, 2006
CARVALHO, B. V. MELLO, C. H. P. Revisão, análise e classificação da literatura sobre
o método de desenvolvimento de produtos ágil scrum. Anais do XII Simpósio de
Administração da Produção, Logística e Operações Internacionais - SIMPOI, São
Paulo/SP, 2009.
COHEN, D., LINDVALL, M., & COSTA, P, “An introduction to agile methods.” In
Advances in Computers (pp. 1-66). New York: Elsevier Science, 2004.
DUBOULOZ, B. Business Process Management Systems (BPMS). Ensures Consulting,
2004.
43
DUARTE, FRANCISCO J. “Engenharia de Software orientada aos processos”
Universidade do Minho Escola de engrenharia Departamento de informática. Braga
2002.
ELIZA, Renata; LAGARES, Vivian. Gestão de Defeitos no Teste de Software Java
Magazine, Grajaú, n.94, p.68 – p.74 ago. 2011
FALBO, R. A. Integração de Conhecimento em um Ambiente de Desenvolvimento de
Software. Tese de Doutorado, COPPE/UFRJ, RJ, Dezembro, 1998.
FALBO, R.A.; NATALI, A.C.C.; MIAN, P.G.; BERTOLLO, G.; RUY, F.B. ODE:
Ontology-based software Development Environment, IX Congreso Argentino de
Ciencias de la Computación, p. 1124-1135, La Plata, Argentina, outubro 2003.
G. KOTONYA, I. SOMMERVILLE. “Requirements Engineering: Process and
Techniques”. 1º Edição. Editora Wiley. 1998.
JOHNSON, J. The Chaos Report. The Standish Group International, Inc. West Yarmouth,
MA, 1995.
JOSE, R ANDRADE, C. R. CARVALHO, F. KELLY, M. Uma Pesquisa Sobre A
Importância Do Gerenciamento De Processos De Negócio Nas Organizações. Revista
Eletrônica Eng Tech Science ANO I, Vol. 01, N. 1 | Jaboatão dos Guararapes - PE | 2014
HAZAN, C., LEITE, J.C.S.P., Indicadores para a Gerência de Requisitos, VI Workshop
em Engenharia de Requisitos – WER03, São Paulo, Brasil, 2003.
HOFMANN, H.F. LEHNER. “Requirements Engineering as a Success Factor in Software
Projects, IEEE Software, July/August 2001.
KAPLAN, R.S.; NORTON, D.P. (1997). “A Estratégia em Ação: Balanced Scorecard”.
22. Edição. Rio de Janeiro: Campus, 1997.
44
KITCHENHAM, B. Procedures for Performing Systematic Reviews. Joint Technical
Report, Keele University TR/SE-0401 and NICTA 0400011T.1, July 2004.
KORHONEN, J. On the Lookout for Organizational Effectiveness: Requisite Control
Structure in BPM Governance. 1st International Workshop on BPM Governance –
WoGo’2007.
LOJA, L. F. B. (2011). Sinfonia: uma abordagem colaborativa e flexível para a
modelagem e execução de processos de negócio. Master’s thesis, Instituto de Informática
Universidade Federal de Goiás.
MANIFESTO ÁGIL, 2001. Disponível em: <http://www.manifestoagil.com.br/>.
Acesso em: Dez 2014
MAFRA, S.N. (2004) “Infra-Estrutura para automatização de processos de software ”,
monografia de projeto final de curso. Rio de Janeiro, RJ , Brasil.
MUNDIM, A.P.F.; ROZENFELD, H.; AMARAL, D.C.; SILVA, S.L.; GUERREIRO,
V.; HORTA, L.C. 2002 Aplicando o cenário de desenvolvimento de produtos em um caso
prático de capacitação profissional. Gestão & Produção. v. 9, nº. 1, p. 1-16, Abril, 2002.
NADDEO, P.S, 2002 Uma Taxonomia na Área de Uma Taxonomia na Área de
Engenharia de Engenharia de Requisitos. Dissertação de Mestrado, Instituto de M
Requisitos atemática e Estatística da Universidade de São Paulo. São Paulo, SP, 2002.
NERUR, S.; MAHAPATRA R.; MANGALARA J,G . Challenges of migrating to agile
methodologies. Communications of the ACM, Maio, 2005.
OLIVEIRA, M. M. Como fazer projetos, relatórios, monografias, dissertações e teses. 4ª
edição. Rio de Janeiro: Elsevier, 2008.
OMG (2009). Bpmn information home. Disponível em: http://www.bpmn.org.
45
PAULK, M.C., 2004. “Surviving the Quagmire of Process Models, Integrated Models,
and Standards. Surviving the quagmire of process models, integrated models, and
standards”. Proceedings of the Annual Quality Congress, May:24–27, 2004.
PINTO, P. 2011. “Uma abordagem para a condução de retrospectivas Scrum baseada nos
conceitos de melhoria contínua e Lean Software Development” CIN Centro de
Informatica UFPE. RECIFE, 2011.
PRESSMAN, Roger S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw-Hill,
2006.
PUNTAR, S.; IENDRIKE, H.; MAGDALENO, A.; BAIÃO. F.; SANTORO, F.; “Estudo
Conceitual sobre BPMS” Relatórios Técnicos do Departamento de Informática Aplicada
da UNIRIO n° 0007/2009. Rio de Janeiro, RJ. 2009
RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams,
IEEE Software, Vol. 17, No. 4, July-August 2000.
ROYCE W. Managing the development of large software systems: Concepst and
Techniques. International Conference on software engieering, california, 1970.
ROSE, TANARA P.R.: MELLO, CARLOS H.P. Proposta de Sistemática para de gestão
de projetos baseada na metodologia ágil Scrum. XXX Encontro Nacional de Engenharia
de Produção - ENEGEP, São Paulo, out 2010
SANTANA, A. F.L; ALVES, C . F.; MOURA, H. P. ; Governança de BPM em Processos
Inter-Organizacionais do Setor Público. Programa de pós-graduação em Ciência da
Computação. Recife – PE, 2010.
SOMMERVILLE, I., Engenharia de Software, 9ª Edição. São Paulo: Pearson –Addison
Wesley, 2011.
SCHWABER,
K.
SCRUM
Development
process.
1995.
Disponível
em:
<http://navegapolis.net/files/Scrum_Development_Process.pdf>. Acesso: Dez. 2014.
46
SCHWABER, K. Agile Project Management With Scrum. Microsoft Press, 2004
THAMIEL, Thiago. Ciclo de Vida do Scrum. Disponível em:
< http://thiagothamiel.files.wordpress.com/2009/07/scrum.jpg?w=595 >. Acesso em: 01
dez. 2014.