Sistema Para Controle de Processos Aplicando Scrum e
ITIL
Rafael L. Passarela, Prof. Me. Guilherme Lacerda, Prof. Daniel Wildt
Faculdade Cenecista Nsa. Senhora dos Anjos (FACENSA)
Av. José Loureiro da Silva, 1991 – 94.010-010 – Gravataí – RS – Brasil
{rafaelpassarela, guilhermeslacerda, dwildt}@gamil.com
Abstract. This article aims to present the benefits achieved by implementing a
system for process control, using the best practices of ITIL in Incident
Management and Problem Management as well as concepts of agile methods
to improve the procurement metrics to control them, using the Pascal
language with CodeGear RAD Studio 2007 and database FireBird 2.1.
Keywords: ITIL, Scrum, XP, Agile Methods, Process Control
Resumo. Este artigo tem como objetivo apresentar os benefícios obtidos com
a implementação de um sistema para o controle de processos, utilizando as
boas práticas do ITIL para a Gestão de Incidentes e a Gestão de Problemas,
bem como conceitos de métodos ágeis para facilitar a obtenção de métricas
para o controle dos mesmos, utilizando a Linguagem Pascal com CodeGear
RAD Studio 2007 e banco de dados FireBird 2.1.
Palavras chave: ITIL, Scrum, XP, Métodos Ágeis, Controle de Processos
1. Introdução
Atualmente as empresas encontram-se em um mercado cada vez mais globalizado, onde
a busca e a captação de clientes são feitas de diversas maneiras, como por exemplo,
oferecendo produtos ou serviços inovadores, algo que os destaque dos demais
concorrentes.
Existem segmentos de mercado onde a personalização e a constante evolução do
produto são considerados pontos cruciais para garantir que a empresa será a escolhida
pelo cliente.
Organizações de TI, principalmente as que se dedicam a construção de software,
têm estes dois fatores como essenciais para a satisfação do cliente. Além de evitar que o
sistema apresente bugs e corrigir os que eventualmente apareçam, é de suma
importância efetuar as personalizações para os clientes, desde um simples ajuste em um
relatório a até mesmo o desenvolvimento de uma nova funcionalidade. Para isto, é
necessário conhecer a real capacidade da equipe de desenvolvimento sabendo quantas
funcionalidades podem ser entregues por interação.
Segundo (DESCHAMPS, 2008), existem quatro necessidades fundamentais que
levam a realização de uma mudança em um software: novas necessidades de mercado,
novas necessidades do cliente, crescimento/diminuição dos negócios, restrições de
orçamento ou cronograma.
Diante de tal fato, muitas software houses realizam estas modificações no
software sem conhecer os reais motivos que levam a tal alteração, outras, sequer não
conhecem a capacidade da equipe em suportar tais demandas. Além disto, não possuem
rastreabilidade sobre as implementações, onde não sabem quem solicitou, quem alterou
e nem para qual motivo o software foi modificado.
Apesar de existirem sistemas capazes de gerenciar tais informações e elevar os
ganhos em ordem de grandeza proporcionada pelas métricas geradas, poucas
organizações se beneficiam destas ferramentas. Esta baixa adoção pode ser explicada
pela complexidade envolvida na utilização das mesmas, ressaltando que, em sistemas
mais simples, existem informações que são ignoradas e nos sistemas mais complexos
sua interface os torna degradantes.
Tal fato serviu como base de toda a motivação necessária para a elaboração deste
projeto, que surgiu da necessidade da criação de uma ferramenta que torne possível
gerenciar de forma simples e eficaz todas as tarefas necessárias para a distribuição de
requisições durante as interações em um projeto de software.
Outro fator motivacional que leva ao desenvolvimento deste trabalho bem como
a definição da ferramenta para controle de requisitos, teve como base a quantidade de
solicitações (bugs, novas implementações e personalizações), existentes em qualquer
empresa de desenvolvimento de software que não possuem o devido controle sobre os
mesmos bem como a possibilidade de gerir uma base de conhecimento sobre os
softwares desenvolvidos conforme as solicitações populam a base de dados do sistema
de controle.
Abaixo segue o modelo sugerido para a entrada de informações no sistema de
controle de requisitos:
Figura 1- Modelo para entrada de informações na base de dados (Fonte: próprio
autor).
Após a entrada dos dados será possível separar as informações entre incidentes e
problemas, bem como consultar registros semelhantes através da base de conhecimento
gerada.
O principal objetivo deste trabalho vem a ser demonstrar como é possível
gerenciar de forma simples e eficaz a distribuição de tarefas durante as interações
presentes no ciclo de desenvolvimento de software bem como obter métricas capazes de
identificar a potencial carga de trabalho suportada pela equipe de desenvolvimento.
Propõe-se então a criação de um sistema para controle de processos com a
capacidade de gerenciar de forma prática os requisitos necessários para a distribuição de
tarefas durante o ciclo de interações.
Espera-se diminuir o tempo necessário para gerencia de processos presentes
durante o ciclo das interações de software, de modo que este tempo seja melhor
aproveitado para projetá-lo, aplicando bons princípios de engenharia de software para a
construção de arquivos fontes com um padrão adotado e conhecido pela maioria dos
desenvolvedores.
Com a entrada dos requisitos em um único sistema, será possível obter uma base
de conhecimento sobre os sistemas desenvolvidos, proporcionando aos demais setores
usufruírem desta ferramenta, como por exemplo, o suporte a clientes.
Como objetivos específicos deste projeto, pode-se citar:
- Estudar sistemas de gerenciamento de projeto;
- Estudar gerencia de incidentes;
- Estudar gerencia de problemas;
- Estudar a linguagem de programação Pascal;
- Estudar o banco de dados FireBird;
- Estudar o CodeGear RAD Studio 2007;
- Definir as funcionalidades do programa;
- Modelar o programa exemplo;
- Implementação e validação do programa proposto.
Além da introdução e considerações finais, este artigo esta dividido em mais três
grandes seções: Referencial Teórico, Estado da Arte e Solução Proposta.
Na primeira seção tem-se o referencial teórico que trará em seu conteúdo
informações para as questões que norteiam a definição de um aplicativo para controle de
processos como princípios básicos para: manutenção de software, ITIL (gerencia de
projetos e gerencia de incidentes), métodos ágeis e a arquitetura necessária para
construção da ferramenta desenvolvida.
Na segunda, o estado da arte, mostra algumas das tecnologias envolvidas para
atingir o objetivo que é a criação de um sistema para controle de processos.
A terceira seção tratará da concepção da solução proposta, o cenário antes da sua
implantação, modelagens, telas e uma abordagem aos resultados preliminares já obtidos.
2. Revisão de Literatura
Nesta seção será feita uma breve abordagem sobre sistemas legados, manutenção de
software, Scrum e ITIL.
2.1. Sistemas Legados
Softwares tornam-se legados quando eles começam a resistir a modificação e a
evolução. No entanto, o conhecimento incorporado nestes sistemas constitui um trunfo
importante nas organizações. Estes sistemas podem ainda proporcionar um importante
valor comercial, tornando-se assim objetos de modernização ou substituição
(SEACORD, 2003).
Sistemas legados em geral, utilizam uma estrutura imperativa e com as seguintes
características:
- Sistemas com difícil manutenção;
- Sistemas sem documentação utilizada;
- Sistemas sem padronizações;
- Foram escritos em linguagens que não existem mais no mercado;
- Foram escritos por programadores que já se aposentaram;
- Sistemas que possuem um alto custo para modernização.
Por falta de documentação e com a mudança do pessoal técnico que participou
originalmente no desenvolvimento dos sistemas legados, os mesmos podem apresentar
problemas tais como:
- Estilos de programação distintos;
- Dificuldade de compreensão das regras de negócio;
- Desconhecimento das razões que levaram a determinadas decisões;
- Impossibilidade de reaproveitamento de equipamentos;
- E mesmo estando em perfeito estado de funcionamento as ferramentas de
desenvolvimento deixaram de ser úteis, devido ao surgimento de produtos
tecnologicamente mais avançados.
Seja pela evolução dos equipamentos ou pelas novas necessidades de negócio,
algumas empresas se deparam com a necessidade de evoluir seus sistemas, sendo estes
talvez os principais motivos para reestruturação e migração de um sistema. Dessa forma,
a reestruturação de um sistema proporciona uma oportunidade para a consideração de
um maior número de variáveis, sejam na atualização de hardware, mas também de
software.
Em contrapartida para certas empresas, o valor mais significante para a
atualização de seus programas de computador é a oportunidade de reorganizar as
operações departamentais, tendo como base um maior ganho de produtividade e a
utilização de softwares modernos.
2.1.1. Manutenção de Software
As razões que levam a manutenção de software se dividem nas seguintes categorias
conforme mostra o quadro abaixo (SWEBOK, 2004):
Correção
Aprimoramento
Pró-ativa
Preventiva
Perfectiva
Reativa
Corretiva
Adaptativa
Quadro 1 - Categorias de Manutenção de Software (Fonte: próprio autor).
Perfectiva: Também chamadas de acessórios, são feitas para melhorar o
produto, como adicionar necessidades dos usuários, ou para melhor o desempenho,
facilitar a utilização, ou agregar outros atributos.
Existem quatro necessidades fundamentais que levam a realização de uma
mudança em um software: novas necessidades de mercado, novas necessidades do
cliente, crescimento/diminuição dos negócios, restrições de orçamento ou cronograma
(DESCHAMPS, 2008).
Adaptativa: São feitas para acompanhar o ritmo das mudanças ambientais, tais
como: novos sistemas operacionais, novas linguagens, banco de dados de sistemas de
gestão comercial e outros componentes.
Corretiva: As mudanças são feitas para reparar defeitos no sistema.
Preventiva: As mudanças são feitas para melhorar o futuro da manutenção e
confiabilidade de um sistema. Ao contrário das últimas três razões para a mudança
reativa, a preventiva age proativamente para mudanças, que visam simplificar a
evolução futura.
Uma vez em funcionamento, defeitos são descobertos, o ambiente de operação
muda e novas necessidades dos usuários são criadas. Os esforços de desenvolvimento de
software resultam na entrega de um produto de software que satisfaça os requisitos dos
usuários, assim o software tem que mudar ou evoluir.
A fase de manutenção no ciclo de vida do software inicia após o período de
garantia ou suporte, após a entrega do software, mas as atividades de manutenção
ocorrem muito mais cedo. Esta manutenção segue definições criadas nas seguintes
normas, conforme o quadro 2 abaixo:
Norma
Definição
IEEE 1219
Define a alteração do software após a entrega, com atividades para:
corrigir falhas, implementar melhorias, criar interface com outros
sistemas, adaptar programas para diferentes hardwares e softwares,
migração de sistemas legados e aposentar o software.
IEEE 12207
Descreve o processo para o ciclo de vida do software e identifica as
principais atividades da manutenção do mesmo.
IEEE 14764
Define a nível internacional, a manutenção de software nas mesmas
condições da norma IEEE 12207.
Quadro 2 - Definições de Manutenção de Software (Fonte: próprio autor).
Lehman e Belady (1985) realizaram a maioria dos trabalhos referentes a
dinâmica de evolução do programa focando nas mudanças do sistema. Com base nestes
estudos propuseram um conjunto de leis referentes as mudanças nos sistemas (Leis de
Lehman).
Durante vinte anos, os estudos de Lehman levaram a formulação de oito leis
conforme mostra a quadro 3, todas relacionadas a manutenção e ciclo de vida de
software (SWEBOK, 2004).
Lei
Descrição
Mudança Contínua
Um programa usado e ambiente de produção deve mudar
necessariamente ou se torna progressivamente menos útil.
Complexidade crescente
A medida que um programa muda, sua estrutura tende a se
tornar mais complexa. Recursos devem ser dedicados para
preservar e simplificar a estrutura.
Evolução de Programa
de Grande Porte
A evolução do programa é um processo auto-regulável.
Atributos de sistemas como tamanho, tempo entre releases e
número de erros reportados são quase invariáveis em cada
versão do sistema.
Estabilidade
Organizacional
Durante o ciclo de vida, sua taxa de desenvolvimento é
quase constante e independente de recursos dedicados ao
desenvolvimento.
Conservação de
Familiaridade
Durante o ciclo de vida de um sistema, mudanças
incrementais em cada versão são quase constantes.
Crescimento Contínuo
As funcionalidades oferecidas pelo sistema devem aumentar
continuamente para manter a satisfação do usuário.
Qualidade em Declínio
A qualidade do sistema entrará em declínio a menos que eles
sejam adaptados a mudanças em seus ambientes
operacionais.
Sistema de Feedback
Os processos de evolução incorporam um sistema de
feedback com vários agentes e loops e você devem tratá-los
para conseguir aprimoramentos significativos de produto.
Quadro 3 - As oito leis de Lehman relacionadas ao ciclo de vida e manutenção
do software (LEHMAN, 1985).
As organizações modificam software, para corrigir erros, ou para melhorar o
desempenho, durabilidade, qualidade ou outros atributos. Isto tudo é de acordo com a
primeira lei da Lehman: “Um grande programa que é usado sofre mudança contínua ou
se torna progressivamente menos útil” (SEACORD, 2003).
O ciclo de vida do software representa as etapas pelas quais o projeto passa por
desenvolvimento e utilização em uma organização. Conforme a figura 2 (SEACORD,
2003) verifica-se a existência de uma atividade continua de desenvolvimento, até que
um novo sistema entre em operação.
Figura 2 - Ciclo de Vida de Manutenção de Software (Fonte: próprio autor)
Construir um novo sistema computadorizado normalmente torna-se uma tarefa
difícil. Visando amenizar esta tarefa, existem métodos de conversão que reduzem o
impacto gerado pela introdução de novas tecnologias (O’ BRIEN, 2006), conforme pode
ser observado na figura 3 abaixo.
Figura 3 - Métodos de Conversão para Redução de Impacto (O’ BRIEN, 2006).
As definições destas quatro formas de conversão podem ser observadas no
quadro quatro.
Conversão
Definição
Paralela
O sistema legado e o sistema novo funcionam em paralelo até que o
a equipe de desenvolvimento e a administração concordem em
utilizar somente o novo. Resultados e desempenhos são avaliados
nesta etapa.
Piloto
Um departamento ou estabelecimento serve como local de teste até
que os desenvolvedores decidam implantar em toda a empresa.
Por Etapas
Parte da nova aplicação ou alguns departamentos são convertidos,
um de cada vez permitindo a implantação de forma gradual.
Direta
Os erros podem ser identificados e corrigidos e o novo sistema passa
a ser o único em uso a partir de determinado momento.
Quadro 4 - Definição de Métodos de Conversão (Fonte: próprio autor)
Segundo SOMMERVILLE (2003), assim que o software é colocado em uso,
novos requisitos emergem, e os requisitos existentes são modificados à medida que a
empresa que executa esse software passa por modificações, tornando impossível
produzir sistemas de qualquer tamanho que não precisem ser modificados.
Mesmo após serem entregues, softwares necessitam ser modificados, seja para
correção de bugs, adição de novas funcionalidades ou aperfeiçoamento das já existentes,
em suma, eles sempre evoluem, em resposta às exigências de mudanças.
2.2. Métodos Ágeis
Segundo TALES (2005), as indústrias de software buscam a décadas técnicas de
desenvolvimento que possam reduzir os riscos em projetos e tornar esta atividade mais
produtiva.
Em 1968, com o surgimento da engenharia de software surgiram inúmeras
propostas para melhorar o desempenho dos projetos, iniciados pelo processo de
desenvolvimento linear e seqüencial (em cascata) até aos atuais processos ágeis de
desenvolvimento. Este novo conceito surge da necessidade de enxergar as de forma
diferente o processo de engenharia de software.
Engenharias tradicionais colocam grande ênfase em projetar antes de construir,
gerando softwares que tendem a evitar mudanças (HILMER, 2004).
A relação entre o custo e o momento em que a alteração é adicionada na
engenharia tradicional pode ser observada na figura 4, deixando evidente que quanto
mais tempo uma alteração ou funcionalidade é postergada, maior será o custo aplicado
sobre tal.
HILMER (2004) define a nova engenharia de software utilizando métodos ágeis,
como a forma que permite constantemente alterar o código sem que a qualidade seja
comprometida. A relação custo e momento em que a alteração é adicionada para este
caso pode ser observado na figura 5.
Figura 4 - Custo de Adição de Funcionalidade na Engenharia Tradicional
Figura 5 - Custo de Adição de Funcionalidade na Nova Engenharia
A introdução dos métodos ágeis na engenharia de software visa reduzir o ciclo
de vida do mesmo, e com isto acelerar seu desenvolvimento disponibilizando versões do
sistema com funcionalidades mínimas, executando exatamente o que foi solicitado. As
demais funcionalidades, bem como aperfeiçoamentos e correções de bugs, são
adicionadas nas versões subseqüentes com base em um processo continuo e interativo.
Métodos ágeis aplicam uma coleção de práticas guiadas por princípios e valores
que podem ser aplicados por desenvolvedores de software diariamente.
Em novembro de 2001, um grupo de dezessete profissionais, com referencias
mundiais em desenvolvimento, reuniu-se para debater as melhores formas de
desenvolvimento de software. Desta reunião surgiu o Manifesto Ágil para
Desenvolvimento de Software.
Os seguintes princípios
(AGILEMANIFESTO, 2010):
foram
definidos
para
o
Manifesto
- Indivíduos e Interações são mais importantes que processos e ferramentas;
Ágil
- Software funcionando é mais importante do que documentação completa e
detalhada;
- Colaboração com o cliente é mais importante do que negociação de contratos;
- Adaptação a mudanças é mais importante do que seguir o plano inicial;
Conforme TALES (2005), graças aos métodos ágeis, o cliente é inteiramente o
piloto do seu projeto e obtém muito rapidamente uma primeira produção do seu
software.
Dentre as principais metodologias ágeis destacam-se as seguintes: RAD, DSDM,
XP, FDD e Scrum.
2.2.1. Scrum
O Scrum é baseado em controle de processos empíricos que visam uma
abordagem interativa e incremental, otimizando assim a previsibilidade e o controle de
riscos. Pode ser encarado como um framework, e não um processo ou uma técnica de
desenvolvimento, onde se pode empregar processos e técnicas.
Seu papel é fazer transparecer a eficácia relativa das suas práticas de
desenvolvimento para que você possa melhorá-las (SCHWABER, 2008).
O Scrum é um processo para construir software incremental em ambientes
complexos, onde os requisitos não são claros ou mudam com muita freqüência
(HILMER, 2004).
Com princípios semelhantes ao XP, possui equipes pequenas, requisitos poucos
estáveis ou desconhecidos e interações curtas para promover a visibilidade do
desenvolvimento.
As equipes trabalham as funcionalidades definidas no inicio de cada sprint,
diariamente é realizada uma reunião de aproximadamente 15 minutos onde a equipe
expõe o que está sendo feito e o que será feito. O tema destas reuniões é focado sobre
três perguntas:
- O que você realizou desde a última reunião?
- Quais problemas você encontrou?
- Em que você trabalhará até a próxima reunião?
2.3. ITIL
Apesar de ser confundida muitas vezes com uma metodologia, ITIL é na verdade um
conjunto de boas práticas. Foi criada pela secretária de comércio do governo inglês
(Office of Government Commerce, OGC) para definir as melhores práticas para a gestão
da área de TI de empresas públicas e privadas, tornou-se recentemente uma norma (BS1500), um anexo da ISO 9000/2000.
Conforme (ITIL, 2010), o foco deste modelo é descrever os processos
necessários para gerenciar a infra-estrutura de TI eficientemente e eficazmente de modo
a garantir os níveis de serviço acordados com os clientes internos e externos.
O ITIL fortalece a idéia de que as organizações estão cada vez mais dependentes
da área de TI, como uma forma de satisfazer e alcançar as necessidades impostas pelas
regras de negócio de pequenas, médias e grandes corporações. (ITIL, 2010).
Para minimizar o desperdício de tempo gasto em implementação, o responsável
pela equipe de desenvolvimento deve alocar o desenvolvedor que mais se encaixe com a
atividade que será desenvolvida, para isto, ele deve conhecer bem sua equipe e como
cada indivíduo trabalha, individualmente e coletivamente dentro da equipe, qual sua real
produtividade, seu nível de qualidade na aplicação de uma implementação.
Para conseguir estas métricas, podem ser utilizados alguns conceitos de
indicadores obtidos no ITIL, onde os principais são: Gestão de Incidentes (Incidents),
Gestão de Problemas (Problem).
2.3.1. Gestão de Incidentes
Segundo ITIL (2010), um incidente é todo evento que não faz parte da rotina do modelo
de gestão de um serviço, podendo gerar uma interrupção ou redução na qualidade do
serviço prestado.
Gerenciar incidentes é garantir que estes eventos atípicos sejam solucionados o
mais breve possível, minimizando o impacto e garantindo que estes atendam aos níveis
de serviços pré-estabelecidos entre TI e cliente (AQUINO, 2008).
Em suma, o gerenciamento de incidentes possui quatro objetivos principais:
- Resolver os incidentes o mais rápido possível, restabelecendo a normalidade do
serviço no prazo acordado no ANS;
- Manter a comunicação dos status dos incidentes aos usuários;
- Definir as prioridades dos incidentes e classificá-los para os grupos de
atendimento para que seja cumprido o prazo de resolução;
- Avaliar os incidentes e as possíveis causas, informando ao Gerenciamento de
Problemas.
Dentre as atividades do gerenciamento de incidentes, cita-se: Detecção de
incidentes e registro; Classificação e suporte inicial; Investigação e diagnóstico;
Resolução e restauração; Fechamento do incidente; Responsabilidade pelo incidente,
monitoração, acompanhamento e comunicação.
O diagrama exibido na figura 6 abaixo mostra as atividades pertencentes ao
gerenciamento de incidentes.
Figura 6 - Diagrama de Atividades na Gerencia de Incidentes (ITIL, 2010)
Quanto à classificação, a Gerência de Incidentes utiliza-se de três fatores:
prioridade, urgência e impacto.
A prioridade é definida em relação ao impacto que o incidente tem sobre o
negócio da organização, pode ser definido na ANS. A urgência é a prioridade com que o
incidente deve ser resolvido e o Impacto é o grau em que a provisão do serviço é
interrompido. No quadro 5, pode-se observar a classificação das prioridades.
Código da Prioridade
Descrição Prazo para Solução
1
Crítico
1 hora
2
Alto
8 horas
3
Médio
24 horas
4
Baixo
48 horas
5
Planejado
Planejado
Quadro 5 - Classificação de Prioridades
Com base na urgência e no impacto, pode ser gerada uma matriz que define sua
relação com os serviços de suporte, como pode ser observado na figura 7 abaixo.
Figura 7 - Matriz de Impacto x Urgência
Outros aspectos pertencentes às atividades de gerencia de incidentes podem ser
definidos como: Detecção de Incidentes e Registros, Classificação e Suporte Inicial,
Investigação e Diagnóstico, Resolução e Recuperação e o Fechamento do Incidente.
2.3.2. Gestão de Problemas
Segundo HALLAIS (2009), a Gestão de Problemas lida com os incidentes que não
puderam ser resolvidos pela Gestão de Incidentes e foram direcionados para identificar a
causa raiz do incidente.
Este processo foca em encontrar a relação entre os incidentes, problemas e erros
conhecidos, onde estes três itens formam a chave para o conhecimento da causa raiz do
incidente.
O principio básico está em começar com muitas possibilidades e estreitar até
encontrar a causa raiz final (BON, 2005).
O gerenciamento de problemas, de acordo com ITIL (2010), possui quatro atividades
primárias, divididas em sub-atividades: Controle de Problemas (Identificar e Registrar,
Classificar, Pesquisar e Diagnosticar), Controle de Erros (Identificar e Registrar,
Avaliar, Registrar a Solução e o Fechamento, Monitorar o Problema), Gerenciamento
Proativo de Problemas (Analisar tendências, Medida de suporte com objetivos
definidos, Proporcionar informações a empresa) e Finalização de revisão dos
problemas graves.
O controle de problemas é responsável por encontrar a solução definitiva para a
causa raiz do incidente. Este possui atividades específicas, conforme pode ser observado
na figura 8 abaixo.
Figura 8 - Atividades do Controle de Problemas (ITIL, 2010)
O controle de erros é o processo onde os erros já conhecidos são pesquisados e
corrigidos. As atividades específicas do controle de erros são apresentadas na figura 9.
Figura 9 - Atividades do Controle de Erros (ITIL, 2010)
HALLAIS (2009) define o erro como sendo uma condição identificada por meio
de um diagnostico bem sucedido da causa raiz de um problema, onde a falha é
confirmada e a solução provisória é identificada.
O processo de identificação de erros pode ser feito de maneira reativa ou próativa. Esta ultima é tida como sendo o modo ideal, pois o cliente não percebe qualquer
alteração em seu sistema.
O modo reativo visa eliminar as origens causadoras de incidentes e minimizar as
conseqüências, soluções de contorno e apresentação de propostas. Neste modo, o cliente
já está ciente do incidente e normalmente já foi afetado.
O modo pró-ativo visa prevenir incidentes e problemas, melhorando a
produtividade, realizando analise de tendências, identificando os pontos vulneráveis e as
fraquezas. Como mencionado anteriormente, neste modo, o cliente não foi afetado e
desconhece a existência do erro.
3. Estado da Arte
Nesta seção serão apresentados estudos feitos em sistema que apresentam
funcionalidades semelhantes as do sistema proposto, são eles: BaseCamp, ToDo List e
ClockingIT.
O BaseCamp é uma ferramenta de colaboração e gerenciamento de projetos
baseada em web, onde é possível distribuir tarefas, verificar prazos e centralizar o
feedback.
Conforme 37SIGNALS (2010), o BaseCamp foi criado em 2004 e desde então
mantido pela 37Signals, ele aborda a gerencia de projetos de um ângulo totalmente
inovador até então, com enfoque na colaboração e na comunicação.
O BaseCamp é um software pago, mas possui uma versão free, capaz de
gerenciar apenas um projeto. Para iniciar o gerenciamento, basta efetuar o cadastro em <
http://basecamphq.com/ >, que será redirecionado para a sua página de Dashboard.
O BaseCamp mostra-se uma ferramenta extremamente útil no gerenciamento de
projetos, permitindo a criação de tarefas com pessoal responsável definido, to-do lists,
controle de estimativa de tempo e compartilhamento de arquivos. Todas suas
funcionalidades são acessadas com poucos cliques, porem, a definição de carga de
trabalho torna-se demorada.
O ToDoList é uma ferramenta open source para gestão de tarefas, mantido pela
AbstractSpoon desde 2004 e funciona apenas em desktop. Apresenta uma interface
altamente intuitiva.
Esta ferramenta permite subdividir uma atividade em partes menores de forma
muito fácil mantendo dentro de um agrupamento criado sobre a tarefa original. Cada
projeto possui seu arquivo de TaskList, o que permite gerenciar inúmeros projetos mas
não todos sobre a mesma visão.
Para executar o programa, basta efetuar o download diretamente do site
(www.abstractspoon.com), não é necessário realizar a instalação, o que permite que o
sistema rode diretamente de um Pen Drive.
O ToDoList surgiu como uma ferramenta para gerenciamento de tarefas, mas
encaixa-se perfeitamente no gerenciamento de projetos (TODOLIST, 2010). Permitindo
a criação de tarefas definindo o responsável, sua estrutura de to-do list permite uma
visualização ampla das atividades em desenvolvimento e em espera, a fácil divisão de
uma atividade em sub-atividades menores é um dos pontos em destaque deste sistema.
Todas suas funcionalidades são acessadas facilmente e estão centralizadas em
uma única janela. O fator negativo para este sistema fica em não ser possível visualizar
as tarefas para projetos distintos em um local centralizado.
O ClockingIT é uma ferramenta web, totalmente free, de gerenciamento de
projetos, colaboração e TimeTracking, que permite total controle sobre as tarefas e sobre
o tempo gasto nas mesmas, com foco em desenvolvimento de software e manipulação
de grandes quantidades de tarefas.
O ClockingIT surgiu em 2003 como uma ferramenta para auxiliar a consultoria
prestada por Erlend e Ellen Simonsen, um casal residente em Oslo, Noruega. Erlend é
responsável por toda a programação, enquanto Ellen é responsável pelo design de
interface, gráficos e cores.
Conforme CLOCKINGIT (2010), o ClockingIT busca gerenciar seus planos de
tarefas e a agenda, permitindo verificar se a entrega de determinado requisito está
atrasada ou adiantada.
O ClockingIT mostra-se uma excelente ferramenta para gerenciamento de
projetos, permitindo a criação de tarefas com pessoal responsável definido, to-do lists
separados por tarefas, controle de estimativa de tempo, indicadores de BurnUp e
BurnDown e compartilhamento de arquivos.
Todas suas funcionalidades são acessadas com poucos cliques. Possui um grande
diferencial em relação às outras ferramentas analisados, o Gráfico de Gantt, que permite
visualizar de forma bastante clara o andamento dos projetos bem como o desempenho
dos elementos da equipe.
4. Solução Implementada
Nesta seção serão apresentadas informações referentes ao sistema que foi
implementado, como uma breve visão do sistema, o cenário existente antes do projeto se
desenvolvido, a modelagem utilizada, telas e a apresentação dos resultados preliminares
já obtidos. O sistema recebeu o nome de CaseSupport.
4.1. Visão
O sistema implementado é capaz de centralizar as informações de incidentes e
problemas, gerar uma base de conhecimento, controlar a distribuição de tarefas,
estimativas de tempo, tempo gasto por atividade e medir a qualidade de
desenvolvimento sobre determinada implementação ou de indivíduo específico.
Como uma das metas deste projeto, esta ferramenta é capaz de agilizar a
distribuição de tarefas de forma funcional e efetiva. Para que tal meta seja atingida, o
sistema se encarregará de gerar os seguintes índices: qualidade e produtividade.
Produtividade: será a quantidade de tarefas que a equipe será capaz de produzir em
determinado período de tempo, que pode ser estabelecido como sendo o período entre as
interações.
Qualidade: será basicamente o índice de sucesso do desenvolvedor em concluir
determinada tarefa, de acordo com seu grau de dificuldade. Muitas vezes ocorre de uma
tarefa ser liberada para homologação e retornar, pois não atingiu a funcionalidade total
esperada ou surgiram outros erros decorrentes da alteração efetuada no código fonte. O
número destas “reincidências” irá afetar a qualidade do trabalho realizado.
4.2. Cenário Existente Antes do Projeto
No cenário existente antes da implantação deste sistema, o controle dos incidentes e
problemas pendentes era feito sem nenhum tipo de controle. Não existia nenhuma forma
de rastrear o histórico das funcionalidades, saber quem solicitou ou quem a
implementou.
O controle era efetuado de maneira manual, sem nenhuma regra ou padrão para
com as informações cadastradas, feito sobre planilha eletrônica, onde o seu modelo pode
ser visto na figura 10.
Figura 10 - Modelo de controle efetuado antes da implantação do sistema
1
(Fonte: adaptação de arquivos IntelliComm Informática LTDA )
Este controle, além de não possuir nenhum recurso que auxilie tratamento das
informações, não apresentava nenhuma garantia de controle sobre prazos e estimativas,
1
Empresa onde o software implementado e utilizado como base para os testes comparativos.
gerando inúmeros transtornos no momento de prever a entrega de determinadas
solicitações.
4.3. Modelagem
Nesta seção, alguns dos principais diagramas deste projeto serão apresentados a fim de
exemplificar a arquitetura utilizada durante sua concepção.
A figura 28 mostra o diagrama de caso de uso para a abertura de um chamado,
através do suporte telefônico, por e-mail ou diretamente pela web.
Figura 11 - Diagrama de Caso de Uso para abertura de chamados
Neste diagrama, o usuário do sistema detecta um erro, comunica o suporte por email ou telefonema, este dará a entrada das informações no banco de dados do sistema
de controle, quando feito via web o cadastro se dará de forma automática. Certos
incidentes tornam-se problemas, estes são tratados pelo desenvolvimento que após a
conclusão da implementação libera para que os testes de aceitação sejam feitos pelo
suporte.
A figura 29 mostra o diagrama conceitual de classes, contendo a relação das
principais encontradas no sistema.
Figura 12 - Diagrama Conceitual de Classes do CaseSupport
No diagrama acima, observa-se a centralização dos processos sobre a classe
TCases, que é responsável pelo registro de tarefas, bem como incidentes e problemas.
Por último, a figura 30 mostra o diagrama de entidade-relacionamento (ER) das
principais tabelas que compões o sistema.
Figura 13 - Diagrama ER do Sistema CaseSupport
Como pode ser observado no ER, basicamente todo sistema gira em torno das
tarefas, representado pela tabela “CASES”.
4.4. O Sistema
Nesta seção serão apresentadas algumas das telas do sistema pertencente a este projeto.
Na figura 14, alguns itens podem ser observados, são eles: histórico do
atendimento (1), lista de tarefas (2), dados do atendimento (3) e histórico de alterações
(4).
Figura 14 - Tela Principal do Sistema de Controle de Processos
Tratando-se da janela principal do sistema, esta foi desenvolvida a fim de reunir
toda a informação necessária para o acompanhamento de atendimentos realizados, bem
como a atual situação de uma implementação que está sendo realizada.
Além da tela principal do sistema, é possível observar na figura 15 a tela para
gerenciamento de arquivos anexos que permite que qualquer informação gerada
externamente seja inserida na base de dados do sistema para consultas posteriores,
mesmo que o arquivo originalmente adicionado não exista mais fisicamente no disco.
Na figura 16 pode-se observar a tela de auxilio e elaboração do plano de teste,
gerada de forma automática pelo sistema, necessitando apenas que o responsável pelo
desenvolvimento da funcionalidade a ser testada informe alguns passos para que se
chegue ao problema relacionado.
A figura 17 mostra o controle de alterações por versão, gerado a partir dos dados
contidos nas ocorrências cadastradas no sistema já concluídas que anteriormente a
correção evoluíram de incidente para problemas necessitando alteração no código da
aplicação, gerando conseqüentemente uma nova versão de sistema.
Figura 15 - Tela para controle de arquivos anexos
Figura 16 - Plano de Teste elaborado com Auxilio do CaseSupport
Figura 17 - Controle de Alterações por Versão
Além das telas apresentadas, o sistema conta com outras de menor irrelevância,
como por exemplo: cadastro de clientes, cadastro de usuários, cadastro de notas, filtros e
gráficos.
Outra janela considerada de extrema importância dentro da sistemática
apresentada pelo sistema é a de DashBoard, que pode ser vista na figura 18 ainda em
fase de planejamento.
Figura 18 - DashBoard gerado para controle de interações no CaseSupport
Nesta última tela, é possível ter a visão geral da interação atualmente em
andamento. Cada tipo de “nota” (status) será representado por uma cor diferente,
facilitando a visualização e compreensão do que está sendo feito no momento. Existirá a
facilidade de atribuição de tarefas para usuários com um simples drag-and-drop das
“notas” entre usuários.
4.5. Resultados Preliminares
Após a implantação do sistema, notou-se um aumento significativo no número de
incidentes e problemas concluídos semanalmente ao longo de dois meses de
acompanhamento, sem aumento no quadro funcional da empresa. Conforme pode ser
visto na figura 19, é apresentada a média de dois meses antes e dois meses depois da
implantação. Nota-se que anteriormente a média semanal era de 11, 14, 15 e 16
respectivamente tendo como média mensal 14 entregas semanais, enquanto a média
semanal obtida após a implantação ficou em 18, 20, 21 e 24 respectivamente, tendo
como média mensal 20,75 entregas semanais.
Figura 19 - Gráfico comparativo entre cenários de entrega
Os valores acima são referentes apenas a solicitações entregues pela equipe de
desenvolvimento, ressaltando que, foi constatado aumento de proporções semelhantes
no setor de suporte, devido a grande parte das informações necessárias para solução de
incidentes estar contida na base de conhecimento gerada gradualmente pelo próprio
sistema.
5. Considerações Finais
Todas as atividades relacionadas ao desenvolvimento de produtos de software sofrem
alterações, motivadas por inúmeros aspectos, como novas necessidades de mercado,
novas necessidades do cliente, crescimento/diminuição dos negócios, restrições de
orçamento ou cronograma.
Para acompanhar estas mudanças e manter o nível de satisfação do usuário final
sem elevar os custos de produção do software, é necessário possuir mecanismos para
controle destas alterações que proporcionem métodos de gerenciar a equipe de
desenvolvimento como: definição de tarefas, controle de estimativa de tempo, controle
do tempo gasto com implementações, capacidade e qualidade de produção.
Fica evidente que ao utilizar um sistema que proporcione as métricas citadas
anteriormente e que este utilize alguns dos conceitos presentes nos métodos ágeis, estes
ganhos podem ser ainda mais elevados. Este tipo de sistema tem se mostrado como
sendo fundamental para empresas que lidam com o desenvolvimento de software, pois
todo o sistema muda, ele necessita ser modificado, seja para correção de bugs, adição de
novas funcionalidades ou aperfeiçoamento das já existentes, em suma, eles sempre
evoluem, em resposta às exigências de mudanças.
O sistema de controle de requisitos não irá sanar todas as necessidades de
negócio envolvidas na produção de software, mas irá proporcionar grande auxilio na
distribuição de tarefas e fechamento de cronogramas, permitindo produzir mais em
menos tempo.
5.1. Limitações
Tendo em vista a vasta gama de informações que pode-se extrair de um controle de
processos devidamente implementado, está evidente que este projeto abrange um
pequeno percentual destas informações. Uma maior captação dos mesmos pode
potencializar os resultados obtidos e com isto elevar os ganhos de qualidade e
produtividade bem como a satisfação do cliente.
Este projeto parte da premissa de que um setor de nível estratégico já definiu
dentre as solicitações quais são de maior prioridade para serem atendidas durante a
próxima interação, o sistema encarrega-se apenas de distribuí-las de modo que o maior
número possível, com as maiores prioridades, seja entregue no prazo esperado. Para este
caso, será extremamente interessante integrar ao sistema a capacidade de definição de
solicitações a serem desenvolvidas, sem a necessidade de interferência de outros níveis
coorporativos.
5.2. Trabalhos Futuros
Além de sanar as limitações encontradas, como pontos passiveis de implementação ou
melhoria, destacam-se alguns pontos, tais como:
- Módulo para controle WEB: Visa permitir que incidentes/problemas sejam
inseridos na base de dados do sistema pelos usuários que utilizam o sistema final
produzido pela empresa.
- Gráficos para controle de tempo: Os gráficos estão entre as melhores formas de
exemplificar/demonstrar dados estatísticos, como sugestões futuras o gráfico de Burning
Down e o modelo de Gantt podem gerar informações interessantes para se agregar ao
sistema.
- Estender o sistema para abordar mais profundamente rotinas de nível
estratégico e design do ITIL v3 a fim de eliminar a interferência de outros setores da
corporação.
6. Conclusão
Uma vez que todos os softwares sofrem alterações, sejam elas motivadas por novas
necessidades de mercado, novas necessidades do cliente, crescimento/diminuição dos
negócios, restrições de orçamento ou cronograma, as empresas que os desenvolve
necessita acompanhar estas mudanças e manter o nível de satisfação do usuário final
sem elevar os custos de produção do software.
Diante deste fato, é necessário possuir mecanismos para controle destas
alterações que proporcionem métodos de gerenciar a equipe de desenvolvimento como:
definição de tarefas, controle de estimativa de tempo, controle do tempo gasto com
implementações, capacidade e qualidade de produção.
Fica evidente que ao utilizar um sistema que proporcione as métricas citadas
anteriormente e que este utilize alguns dos conceitos presentes nos métodos ágeis, estes
ganhos podem ser ainda mais elevados, devido ao aumento dos os lucros obtidos através
da maior entrega de funcionalidades e correções bem como nos atendimentos de suporte
realizados.
Este tipo de sistema tem se mostrado como sendo fundamental para empresas
que lidam com o desenvolvimento de software, pois todo o sistema muda, ele necessita
ser modificado, seja para correção de bugs, adição de novas funcionalidades ou
aperfeiçoamento das já existentes, em suma, eles sempre evoluem, em resposta às
exigências de mudanças.
O sistema de controle de requisitos não irá sanar todas as necessidades de
negócio envolvidas na produção de software, mas irá proporcionar grande auxilio na
distribuição de tarefas e fechamento de cronogramas, permitindo produzir mais em
menos tempo.
Referencias
[37SIGNALS, 2010] 37SIGNALS. Simple small business software, collaboration,
CRM: 37signals. Disponível em: <http://37signals.com/>. Consultado em Junho de
2010.
[AGILEMANIFESTO, 2010] AGILEMANIFESTO, Manifesto for Agile Software
Development. Disponível em: <http://www.agilemanifesto.org>. Consultado em
Julho de 2010.
[AQUINO, 2008] AQUINO, Larissa R. Lira. Gerenciamento de Incidentes, segundo
ITIL. MBA Governança de Tecnologia da Informação. Faculdade Católica de Cuiabá,
2008.
[CLOCKINGIT, 2010] CLOCKINGIT. ClockingIT, Timetracking 2.0. Disponível em:
<http://www.clockingit.com/>. Consultado em Maio de 2010
[DESCHAMPS, 2008] DESCHAMPS, Alexandro. SWAROWAKY, Hugo H.
Gerencia de Configuração – Ápice da Engenharia de Software. 2008.
[HALLAIS, 2009] HALLAIS, Vitor; ALVES, Ramon. Gerencia de Serviços:
Gerenciamento de Problemas baseado no Modelo ITIL. Monografia de Engenharia
de Software, PUC-Minas, 2009.
[HILMER, 2004] HILMER, Gustavo. Métodos Ágeis – O que são métodos ágeis.
Graduação em Ciências da Computação, Universidade Federal de Brasília (UNB),
2004.
[ITIL, 2010] ITIL, ITIL® Home. Disponível em:
officialsite.com/home/home.asp>. Consultado em Julho de 2010.
<http://www.itil-
[LEHMAN, 1985] Lehman, M. M. Belady, L. A. Program evolution: processes of
software change. Orlando Academic Press, London, 1985.
[MANHÃES, 2005] MANHÃES, Vinícius. UM ESTUDO DE CASO DA ADOÇÃO
DAS PRÁTICAS E VALORES DO EXTREME PROGRAMMING.
Universidade Federal do Rio de Janeiro - UFRJ, IM / DCC, 2005.
[O’ BRIEN, 2006] O’ BRIEN, James A. Sistemas de informação e as decisões
gerenciais na era da Internet. James A. O’Brien; tradução Célio Knipel Moreira e
Cid Knipel Moreira. 2ª ed. São Paulo: Saraiva, 2006.
[SCHWABER, 2008] SCHWABER, Ken. SUTHERLAND, Jeff. Scrum Guide.
Scrum.Org, 2008.
[SEACORD , 2003] SEACORD, Robert C.; PLAKOSH, Daniel; LEWIS, Grace A.
Modernizing Legacy Systems: Software Technologies, Engineering Processes,
and Business Practices. Addison Wesley, 2003.
[SOMMERVILLE, 2003] SOMMERVILLE, Ian. Engenharia de Software; tradução
André Maurício de Andrade Ribeiro; revisão técnica Kechi Hirama. São Paulo:
Addison Wesley, 2003.
[SWEBOK, 2004] SWEBOK. Guide to the Software Engineering Body of
Knowledge.
IEEE:
Computer
Society,
2004.
Disponível
em:
<http://www2.computer.org/portal/web/swebok/htmlformat>. Consultado em Julho
de 2010.
[TALES, 2005] TELES, Vinícius Manhães, Um Estudo de Caso da Adoção das
Práticas e Valores do Extreme Programming. Orientador: Carlo Emmanoel Tolla
de Oliveira. Rio de Janeiro : UFRJ/IM, 2005. Dissertação (Mestrado em
Informática).
[TODOLIST, 2010] TODOLIST. ToDoList Resources AbstractSpoon Software.
Disponível em: <http://www.abstractspoon.com/>. Consultado em Maio de 2010.
[XP, 2010] XP, Extreme Programming (XP): A Gentle Introduction. Disponível em:
<http://www.extremeprogramming.org/>. Consultado em Agosto de 2010.