controle de processos com métodos Ágeis e itil
DESCRIPTION
Este trabalho tem como objetivo efetuar o levantamento do material necessário para a realização de um sistema para controle de processos, utilizando as boas práticas do ITIL para a Gestão de Incidentes e a Gestão de Problemas, utilizando 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.TRANSCRIPT
FACULDADE CENECISTA NOSSA SENHORA DOS ANJOS - FACEN SA
Mantida pela CNEC – Campanha Nacional de Escolas da Comunidade
CURSO DE GRADUAÇÃO
SISTEMAS DE INFORMAÇÃO
RAFAEL LEMOS PASSARELA
SISTEMA PARA CONTROLE DE PROCESSOS APLICANDO
MÉTODOS ÁGEIS E ITIL
Gravataí
2010
1
RAFAEL LEMOS PASSARELA
SISTEMA PARA CONTROLE DE PROCESSOS APLICANDO
MÉTODOS ÁGEIS E ITIL
Trabalho de Conclusão de Curso I apresentado como r equisito parcial para
obtenção do título de Bacharel em Sistemas de Infor mação da Faculdade
Cenecista Nossa Senhora dos Anjos - FACENSA
Orientador: Prof. Me. Guilherme Lacerda
Co-Orientador: Prof. Daniel Wildt
Gravataí
2010
2
RESUMO
Este trabalho tem como objetivo efetuar o levantamento do material necessário
para a realização de um sistema para controle de processos, utilizando as boas práticas
do ITIL para a Gestão de Incidentes e a Gestão de Problemas, utilizando 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: Controle de Processos, ITIL, Método s Ágeis, Gestão de
Incidentes, Gestão de Processos
3
ABSTRACT
This work aims to make the lifting of the material necessary for the realization of a
system for process control, using best practices for ITIL Incident Management and
Problem Management, using concepts of agile methods to improve the procurement of
metrics to control them using the language Pascal with CodeGear RAD Studio 2007 and
database FireBird 2.1.
Keywords: Process Control, ITIL, Agile Methods, Inc ident Management, Process
Management
4
LISTA DE FIGURAS
Figura 1 - Modelo para a entrada de informações .......................................................... 11
Figura 2 - Ciclo de Vida de Manutenção de Software .................................................... 18
Figura 3 - Métodos de Conversão para Redução de Impacto ........................................ 19
Figura 4 - Custo de Adição de Funcionalidade na Engenharia Tradicional .................... 21
Figura 5 - Custo de Adição de Funcionalidade na Nova Engenharia ............................. 21
Figura 6 - Diagrama de Atividades na Gerencia de Incidentes ...................................... 26
Figura 7 - Matriz de Impacto x Urgência ........................................................................ 27
Figura 8 - Atividades do Controle de Problemas ............................................................ 29
Figura 9 - Atividades do Controle de Erros .................................................................... 29
Figura 10 - Novo Projeto com o BaseCamp ................................................................... 31
Figura 11 - DashBoard do BaseCamp ........................................................................... 32
Figura 12 - To-do List do BaseCamp ............................................................................. 33
Figura 13 – Distribuição de Tarefas do BaseCamp ........................................................ 33
Figura 14 - Lista de Tempo de Atividades com o BaseCamp......................................... 34
Figura 15 - Definição de Estimativa de Tempo com BaseCamp .................................... 34
Figura 16 - Configuração Inicial do ToDoList ................................................................. 35
Figura 17 - Configuração de Colunas do ToDoList ........................................................ 36
Figura 18 - Seleção de Interface e Projeto de Exemplo do ToDoList ............................. 36
Figura 19 - Tela Principal do ToDoList ........................................................................... 37
Figura 20 - DashBoard do ClockingIT ............................................................................ 38
Figura 21 - Gráfico de Gantt utilizado no ClockingIT ...................................................... 39
Figura 22 - Cadastro de Task e To-do List no ClockingIT .............................................. 40
Figura 23 - Lista de tarefas no ClockingIT ...................................................................... 40
Figura 24 - Tela principal do Protótipo CaseSupport ...................................................... 44
Figura 25 - Controle de Arquivos Anexos do CaseSupport ............................................ 45
Figura 26 – Plano de Teste elaborado com Auxilio do CaseSupport ............................. 45
Figura 27 - Controle de Alterações por Versão no CaseSupport ................................... 46
Figura 28 - Diagrama de Caso de Uso ........................................................................... 47
5
Figura 29 - Diagrama de Classes do CaseSupport ........................................................ 48
Figura 30 - Diagrama ER do Sistema CaseSupport ....................................................... 49
6
LISTA DE QUADROS
Quadro 1 - Categorias de Manutenção de Software ...................................................... 15
Quadro 2 - Definições de Manutenção de Software ....................................................... 16
Quadro 3 - As oito leis de Lehman ................................................................................. 17
Quadro 4 - Definições de Métodos de Conversão .......................................................... 19
Quadro 5 - Classificação de Prioridades ........................................................................ 27
Quadro 6 - Comparativo de Ferramentas ....................................................................... 42
Quadro 7- Cronograma de desenvolvimento do TCC I .................................................. 53
Quadro 8 - Cronograma de desenvolvimento do TCC II ................................................ 54
7
LISTA DE ABREVIATURAS
Abreviaturas utilizadas ao longo deste trabalho:
ANS Acordo de Nível de Serviço
ER Entidade-Relacionamento
FDD Feature Driven Development
IDE Integrated Development Environment
IDPL Initial Developer's Public License
ITIL Information Technology Infrastructure Library
RDBMS Relational Database Management System
RUP Rational Unified Process
SGBDR Sistema Gerenciador de Banco de Dados Relacional
SQL Structured Query Language
TI Tecnologia da Informação
UP Unified Process
XP eXtreme Programming
WWW World Wide Web
8
SUMÁRIO
INTRODUÇÃO ............................................................................................................... 10
Motivação ....................................................................................................................... 11
Objetivo Geral ................................................................................................................ 12
Objetivo Específico: ........................................................................................................ 12
Estrutura do Trabalho ..................................................................................................... 12
1. REFERENCIAL TEÓRICO ......................................................................................... 14
1.1. Sistemas Legados ................................................................................................... 14
1.1.1. Manutenção de Software ...................................................................................... 15
1.2. Métodos Ágeis ......................................................................................................... 20
1.2.1. XP (eXtreme Programming) ................................................................................. 23
1.2.2. Scrum ................................................................................................................... 23
1.3. ITIL .......................................................................................................................... 24
1.3.1. Gestão de Incidentes............................................................................................ 25
1.3.2. Gestão de Problemas ........................................................................................... 28
2. ESTADO DA ARTE .................................................................................................... 31
2.1. BaseCamp ............................................................................................................... 31
2.2. ToDoList .................................................................................................................. 35
2.3. ClockingIT ............................................................................................................... 37
2.4. Comparativo de Ferramentas .................................................................................. 41
3. Solução Proposta ....................................................................................................... 43
3.1. Visão ....................................................................................................................... 43
3.2. Protótipo .................................................................................................................. 43
3.3. Funcionalidades Importantes .................................................................................. 46
3.4. Modelagem .............................................................................................................. 47
3.4.1. Caso de Uso ......................................................................................................... 47
3.4.2. Diagrama de Classes ........................................................................................... 48
3.4.3. Diagrama ER ........................................................................................................ 48
3.5. Tecnologias Utilizadas............................................................................................. 49
3.5.1. CodeGear RAD Studio ......................................................................................... 50
9
3.5.2. FireBird ................................................................................................................. 50
3.5.2.1. Banco de Dados Relacional .............................................................................. 51
4. Cronograma de Desenvolvimento .............................................................................. 53
4.1. TCC I ....................................................................................................................... 53
4.2. TCC II ...................................................................................................................... 54
CONSIDERAÇÕES FINAIS ........................................................................................... 55
REFERÊNCIAS .............................................................................................................. 56
10
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. Alem 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. Alem 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.
11
Motivação
O projeto 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.
A motivação 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.
Outro fator motivacional para este trabalho é 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 a entrada de informações
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.
12
Objetivo Geral
Mostrar 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 e 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.
Objetivo Específico:
- 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;
- Implementar e validar o programa proposto.
Estrutura do Trabalho
Além da introdução e considerações finais, o trabalho esta dividido em três
grandes seções:
13
- 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 proposta.
- Na segunda seção o trabalho mostra algumas ferramentas existentes no
mercado e faz um comparativo com a aplicação a ser criada.
- A terceira seção tratará da concepção da solução proposta e das tecnologias
envolvidas para atingir o objetivo que é a criação de um sistema para controle de
processos.
14
1. REFERENCIAL TEÓRICO
Nesta seção serão apresentadas informações referentes a sistemas legados,
manutenção de software e uma breve abordagem sobre métodos ágeis e ITIL.
1.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.
Com a evolução dos equipamentos, algumas empresas se deparam com a
necessidade de evoluir seus sistemas, sendo este talvez o principal motivo para
reestruturação e migração de um sistema legado, pois é sabido que muitas
15
organizações continuam usando sistemas desenvolvidos a mais de uma década. Dessa
forma, a reestruturação de um sistema legado 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.
1.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
Perfectiva : 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. Estes tipos de mudanças são também chamados de acessórios.
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
16
reativa, a preventiva age proativamente para mudanças, que visam simplificar a
evolução futura.
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.
Uma vez em funcionamento, defeitos são descobertos, o ambiente de operação
muda e novas necessidades dos usuários são criadas.
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.
A manutenção de software 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
Segundo (SWEBOK, 2004), a percepção comum da manutenção de software é
que ela sirva apenas para corrigir falhas, no entanto estudos e pesquisas ao longo dos
anos têm indicado que mais de 80% da manutenção do software é usada para ações
não corretivas.
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).
17
Lehman e Belady examinaram o crescimento e a evolução de uma série de
grandes sistemas de software. As leis propostas foram derivadas dessas medições
(SOMMERVILLE, 2003).
Durante um período de vinte anos, as pesquisas 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
18
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)
As observações de Lehman são pertinentes e devem ser levadas em conta no
planejamento do processo de manutenção, entretanto, dependendo do plano de
negócio adotado pela software house, tais observações devem ser ignoradas. O
marketing, por exemplo, pode adotar um esquema em que será necessário fazer
diversas mudanças em sistemas maiores em um único release e como conseqüência,
provavelmente, serão necessários um ou mais releases dedicados ao reparo de erros
(SOMMERVILLE, 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
19
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 Imp acto
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ções de Métodos de Conversão
20
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.
1.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.
Também conhecido como Desenvolvimento Ágil de Software, ou simplesmente
como Método Ágil, é uma estrutura conceitual que rege projetos de engenharia de
software como parte de uma metodologia 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.
21
Figura 4 - Custo de Adição de Funcionalidade na Eng enharia Tradicional
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 abaixo.
Figura 5 - Custo de Adição de Funcionalidade na Nov a Engenharia
22
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 foram definidos para o Manifesto Ágil
(AGILEMANIFESTO, 2010):
- Indivíduos e Interações são mais importantes que processos e ferramentas;
- 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;
Segundo HILMER (2004), para melhor compreensão dos Métodos Ágeis, deve-
se primeiramente entender as características principais que os norteiam, são elas:
- É uma atitude e não um processo prescritivo;
- É um suplemente aos métodos existentes e não uma metodologia completa;
- É uma forma efetiva de trabalho em conjunto para atingir as necessidades das
partes envolvidas;
- É uma atividade que funciona na prática e não uma teoria acadêmica;
- É a criação de documentos que possuam valor, e não documentos
burocráticos;
- Utiliza o modelo de processo interativo e incremental;
- O cliente faz parte da equipe de desenvolvimento.
23
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.
1.2.1. XP (eXtreme Programming)
Metodologia americana do final da década de 90 voltada para o desenvolvimento
de software, notória em diversos países por ajudar a criar sistemas de forma mais
econômica e em menor tempo que as formas habituais.
O XP é composto por um conjunto reduzido de práticas de desenvolvimento que
se organizam em torno de quatro valores básicos. Essas práticas possuem fortes inter-
relacionamentos formando um conjunto de elevada sinergia (MANHÃES, 2005).
(XP, 2010) afirma que o Extreme Programming é bem sucedido porque realça a
satisfação do cliente, pois em vez de entregar tudo o que ele poderia querer em alguma
data distante no futuro, este processo entrega o software que ele precisa quando ele
precisa.
Com o XP o cliente é inserido no meio do processo de desenvolvimento em uma
relação mais estrita com a equipe de desenvolvimento.
O XP baseia-se nos seguintes conceitos:
- Equipes de desenvolvimento trabalham diretamente com o cliente em ciclos
curtos;
- As entregas de versões do software ocorrem com freqüência;
- A equipa de desenvolvimento trabalha em colaboração total;
- O código é testado e limpo ao longo de todo o processo de desenvolvimento;
- Indicadores permitem medir o projeto auxiliando em mudanças ao longo do
desenvolvimento.
Conforme HILBER (2004), O XP é uma abordagem deliberada e disciplinada
onde seu sucesso advém da satisfação do cliente, possui princípios que devem ser
planejados e seguidos: simplicidade, comunicação, feedback, coragem e respeito.
1.2.2. Scrum
24
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?
1.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 (BS-1500), 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.
25
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) ainda comenta que isto leva a uma maior exigência para a alta qualidade de
serviços de TI.
Para minimizar o desperdício de tempo gasto em implementaçã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).
1.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.
As atividades do gerenciamento de incidentes incluem:
- Detecção de incidentes e registro;
26
- 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 abaixo mostra as atividades pertencentes ao
gerenciamento de incidentes.
Figura 6 - Diagrama de Atividades na Gerencia de In cidentes
Quanto à classificação, a Gerencia de Incidentes utiliza-se de três fatores:
prioridade, urgência e impacto.
- Prioridade: é definido em relação ao impacto que o incidente tem sobre o
negócio da organização, pode ser definido na ANS;
- Urgência: prioridade com que o incidente deve ser resolvido;
- Impacto: grau em que a provisão do serviço é interrompido;
27
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: Registrar informações básicas do
incidente;
- Classificação e Suporte Inicial: Classificar, comparar, priorizar, fornecer suporte
inicial para uma resolução rápida;
- Investigação e Diagnóstico: Avaliação do incidente e solução de contorno;
- Resolução e Recuperação: Resolver o incidente ou elaborar uma requisição de
Mudança e tomar ações corretivas;
- Fechamento do Incidente: Verificar junto ao cliente se o chamado foi atendido e
resolvido e comunicar o fechamento;
28
1.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
- 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.
29
Figura 8 - Atividades do Controle de Problemas
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
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.
30
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.
31
2. 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.
2.1. BaseCamp
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.
Nos passos que seguem, serão abordadas as principais telas do BaseCamp e
suas funcionalidades.
New Project: Permite adicionar um novo projeto ao sistema BaseCamp, como
pode ser observado na figura 10, é permitido escolher a visibilidade que o novo projeto
terá.
Figura 10 - Novo Projeto com o BaseCamp
32
DashBoard: Centraliza as informações de clientes e projetos em uma única tela,
como por exemplo, itens atrasados (1), itens pendentes para os próximos 14 dias (2),
lista de projetos disponíveis (3) e últimas atualizações do projeto (4). Estes itens podem
ser observados na figura 11.
Figura 11 - DashBoard do BaseCamp
To-do List: Permite a criação de listas de controle, com a possibilidade de
definição de pessoal responsável. Itens concluídos vão diretamente para o final da fila,
conforme mostra a figura 12.
33
Figura 12 - To-do List do BaseCamp
Milestones: Permite definir as tarefas bem como seus responsáveis, permitindo
saber para quem e para quando a mesma é devida, conforme mostra a figura 13, os
itens atrasados aparecem no topo (1), itens pendentes com entregas futuras aparecem
no calendário (2) e na lista de tarefas pendentes (3).
Figura 13 – Distribuição de Tarefas do BaseCamp
34
Time: Permite definir a estimativa de tempo a ser gasta em cada atividade, como
mostra a figura 14 e 15, permitindo também a definição do responsável.
Figura 14 - Lista de Tempo de Atividades com o BaseCamp
Figura 15 - Definição de Estimativa de Tempo com BaseCamp
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 e não permite a visualização das
tarefas em linha de tempo.
35
2.2. ToDoList
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.
Após efetuar o download, na primeira execução do sistema, uma janela de
configuração muito simples é mostrada, conforme a figura 16, onde é possível escolher
onde as configuração serão salvas e se as tasklists serão compartilhadas na rede.
Figura 16 - Configuração Inicial do ToDoList
Nas próximas janelas de configuração, é possível escolher quais colunas serão
visíveis na janela principal do sistema (figura 17) e definir qual interface será utilizada
na execução do sistema, permitindo optar pelo modo completo ou simples (figura 18).
36
Figura 17 - Configuração de Colunas do ToDoList
Figura 18 - Seleção de Interface e Projeto de Exemp lo do ToDoList
Uma das melhores características do ToDoList é sua simplicidade, tudo que é
preciso está na tela principal, possui informações importantes para gerenciamento e
previsão de entrega, como pode ser visto na figura 19.
37
Figura 19 - Tela Principal do ToDoList
O ToDoList surgiu como uma ferramenta para gerenciamento de tarefas, mas
encaixa-se perfeitamente no gerenciamento de projetos, 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.
2.3. ClockingIT
O ClockingIT é uma ferramenta web, totalmente free, de gerenciamento de
projetos, colaboração e TimeTracking, que permite total controle sobre as tarefas e
38
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 seus próprios criadores, o ClockingIT busca gerenciar seus planos de
tarefas e a agenda, permitindo verificar se a entrega de determinado requisito está
atrasada ou adiantada.
Possui excelentes relatórios que permitem obter quais tarefas foram feitas e
quanto tempo foi despendido na realização das mesmas.
Alguns elementos importantes do ClockingIT:
DashBoard: é totalmente configurável através de widgets, possui informações
referentes as tarefas mais importantes (1), tarefas novas (2) e estatísticas referentes a
projetos e tarefas em andamento (3) como Burn up e Burn down, conforme mostra a
figura 20.
Figura 20 - DashBoard do ClockingIT
39
GANTT: Criado em 1917 pelo engenheiro social Henry Gantt, este formato de
gráfico é altamente utilizado para ilustrar o avanço de diferentes etapas de um projeto.
Nele pode ser vistas as tarefas de cada membro da equipe, bem como o tempo gasto
para a execução de cada uma delas.
Construído totalmente utilizando controles Ajax, possui a grande vantagem de
configuração através de drag-and-drop e além deste recurso, basta adicionar a
estimativa de tempo e a data de vencimento da tarefa que o gráfico atualiza
automaticamente. O Gantt inserido no ClockingIT pode ser observado na figura 21.
Figura 21 - Gráfico de Gantt utilizado no ClockingIT
TaskList e To-do List: Cada tarefa criada possui dados suficientes para
classificá-la de acordo com a prioridade, impacto e urgência. Permite definir em qual
milestone está inserida e para qual projeto.
Também é possível definir o responsável e data de entrega desta tarefa, bem
como suas dependências. Cada tarefa possui seu próprio To-do.
Na figura 22, um exemplo de cadastro de Task (1) com seu To-do (2).
40
Figura 22 - Cadastro de Task e To-do List no ClockingIT
Na figura 23 é possível ver a lista de tarefas, em vermelho as tarefas atrasados e
em verde as tarefas em espera para a próxima interação.
Figura 23 - Lista de tarefas no ClockingIT
41
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.
2.4. Comparativo de Ferramentas
Todas as ferramentas propõem a gerencia de projetos com o controle de
processos envolvidos utilizando de algum artefato para controle de tarefas e
prioridades.
Este comparativo terá seu foco nas principais atribuições ou características que
um sistema de gerenciamento de projetos pode ter como:
- Plataforma
- Valor (Licença)
- Controle de Tarefas
- Controle de Estimativa de Tempo
- To-Do List’s
- Tarefas em linhas de tempo
- Controle de Arquivos Anexos
- Estimativa de Qualidade de Desenvolvimento
- Base de Conhecimento
- Acompanhamento por Feed-RSS
42
Característica BaseCamp ToDoList ClockingIT CaseSupport
Plataforma Web Windows
Desktop
Web Windows
Desktop
Valor da Licença Paga. Versão
free possui
limitações.
Open Source Free
Controle de
Tarefas
Controle de
Estimativa de
Tempo
To-do List’s
Tarefas em Linha
de Tempo
Controle de
Arquivos Anexos
Estimativa de
Qualidade de
Desenvolvimento
Base de
Conhecimento
Formato Wiki
– alimentado
manualmente
por
mensagens ou
writeboards
Formato Wiki
– Alimentado
manualmente
Gerado
automaticamente
conforme o
registro de
Incidentes e
Problemas
Acompanhamento
por Feed-RSS
Quadro 6 - Comparativo de Ferramentas
43
3. Solução Proposta
Nesta seção serão apresentadas informações referentes ao sistema proposto,
como uma breve visão do sistema, tecnologias utilizadas e funcionalidades importantes.
O sistema se chamará CaseSupport.
3.1. Visão
O sistema proposto será 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, busca-se uma ferramenta capaz de agilizar
a distribuição de tarefas de forma funcional e efetiva. Para que tal meta seja atingida,
será necessário que o responsável por tal distribuição conheça o potencial de produção
de sua equipe.
Dentre as métricas que o sistema de controle de processos propõe-se a gerar,
destacam-se 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.
A melhor fórmula de calcular está métrica ainda está sendo estudada.
3.2. Protótipo
O protótipo desenvolvido até então, permite coletar as informações de incidentes
e problemas, gera uma base de conhecimento para futuras pesquisas e possibilita o
controle de tarefas por usuários do sistema.
44
Quando o mesmo foi idealizado, em 2008, ainda não existia a visão proposta de
unir as metodologias ágeis com as boas práticas do ITIL em um único sistema para
controle de processos, como pode ser observado na figura 24, as nomenclaturas
utilizadas não condizem com os padrões propostos pelo ITIL. Outros itens que podem
ser observados na figura abaixo são: histórico do atendimento (1), lista de tarefas (2),
dados do atendimento (3) e histórico de alterações (4).
Figura 24 - Tela principal do Protótipo CaseSupport
Outras funcionalidades que podem ser observadas já no protótipo são:
- Controle de arquivos anexos (figura 25);
- Auxilio para elaboração de planos de teste (figura 26);
- Controle de alterações por versão (figura 27).
45
Figura 25 - Controle de Arquivos Anexos do CaseSupp ort
Figura 26 – Plano de Teste elaborado com Auxilio do CaseSupport
46
Figura 27 - Controle de Alterações por Versão no Ca seSupport
Estas são algumas funcionalidades já implementadas. Espero que, no decorrer
da elaboração do segundo trabalho de conclusão de curso, consiga atingir meus
objetivos e apresentar o sistema conforme o proposto.
3.3. Funcionalidades Importantes
Dentre as funcionalidades propostas para o sistema de gerenciamento,
destacam-se:
- Controle de Tarefas;
- Histórico de Alterações e Atendimentos;
- Registro de Incidentes e Problemas;
- To-do List por tarefa;
- Programar a entrega de tarefas;
- Visualizar em linha de tempo o cronograma de desenvolvimento;
- Controle de Arquivos Anexos;
- Controle de Estimativa de Tempo;
- Base de Conhecimento;
- Auxilio na elaboração de planos de teste.
47
3.4. Modelagem
Como até então trata-se apenas de um protótipo, os seguintes diagramas serão
incorporados apenas como caráter preliminar, pois estes provavelmente sofrerão
alterações no decorrer do projeto.
3.4.1. Caso de Uso
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 28 - Diagrama de Caso de Uso
Neste diagrama, o usuário do sistema detecta um erro, comunica o suporte por
e-mail ou telefonema e este dará a entrada das informações no banco de dados do
sistema de controle. O usuário pode inserir diretamente os dados do incidente
detectado diretamente no sistema web, que se encarrega de incluir no banco de dados
do sistema de controle.
48
3.4.2. Diagrama de Classes
A figura 29 mostra o diagrama abaixo mostra a reação das principais classes
encontradas no sistema.
Figura 29 - Diagrama 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.
3.4.3. Diagrama ER
A figura 30 mostra o diagrama de entidade-relacionamento (ER) das principais
tabelas que compões o sistema até o presente momento.
49
Figura 30 - Diagrama ER do Sistema CaseSupport
Como pode ser observado no ER, basicamente todo sistema gira em torno das
tarefas, representado pela tabela “CASES”.
3.5. Tecnologias Utilizadas
Nesta seção, será abordado alguns tópicos referentes as tecnologias utilizadas
para a criação do software proposto.
50
3.5.1. CodeGear RAD Studio
O CodeGear RAD Studio é uma excelente ferramenta de desenvolvimento, com
suporte a desenvolvimento nas linguagens .NET, C++ e Pascal.
Seu antecessor, o Delphi, dava suporte apenas a linguagem Pascal, com esta
nova versão estendendo-se para outras linguagens, teve seu nome alterado para RAD
Studio, mesmo assim, muitos desenvolvedores que utilizam esta ferramenta ainda o
chamam de Delphi.
O Delphi, atualmente possui a versão RAD Studio 2010, comercializado pela
empresa Embarcadero Technologies Inc, da suporte a diversas ferramentas integradas
diretamente em sua IDE que proporcionam suporte a uma vasta gama de recursos,
dentre eles:
- Suporte a banco de dados relacional cliente/servidor;
- Elementos de programação Windows e COM;
- Suporte a desenvolvimento Web e Intranet;
- Suporte a diagramas de classe e objetos;
- Garantias de qualidade (QA) com auditorias e métricas.
Segundo EMBARCADERO (2010), o RAD Studio é a mais poderosa suite para
desenvolvimento RAD e visual da indústria para criação de softwares que requerem
interfaces ricas e acesso a dados pelo usuário final, possibilitando a entrega de
aplicações 5 vezes mais rápidas em diferentes plataformas Windows e banco de dados.
3.5.2. FireBird
O FireBird é um banco de dados relacional que surgiu em 1981, funciona em
Unix, Linux, Windows, e uma variedade de outras plataformas cliente/servidor. Possui
suporte a: transações (concorrentes), linguagens de alto desempenho, procedures e
triggers.
Conforme FIREBIRD (2010), O FireBird é um projeto comercialmente
independente de programadores C e C++, conselheiros técnicos e suportes de
51
desenvolvimento em plataforma multi-sistema de RDBMS, baseado no código fonte
liberado pela Inprise Corp (agora conhecido como Borland Software Corp).
Segundo BORRIE (2006), O FireBird é um SGBDR de capacidade industrial com
alto nível de compatibilidade com a linguagem SQL, implementando ao mesmo tempo
recursos poderosos na esfera de programação procedural.
Possuindo código fonte open source, qualquer pessoa pode efetuar alterações e
criar uma versão personalizada, desde que mantenha a licença IDPL.
3.5.2.1. Banco de Dados Relacional
Em 1970, Edgar Frank Codd criou uma nova forma de juntar dados, que foi
chamada de banco de dados relacional. A sua ideia era quebrar os dados em arquivos
separados que pudessem ser relacionados usando-se um campo-chave em comum.
Para um arquivo de empregados, provavelmente as empresas usariam um número de
empregado como campo-chave. Cada empregado receberia um número de
identificação exclusivo e haveria um único arquivo informações gerais sobre cada
empregado, como: nome, endereço e outros dados básicos do empregado.
Haveria outro arquivo com o número do empregado e sua respectiva
remuneração, outro arquivo com o número do empregado e os benefícios a que teria
direito e assim por diante. As informações básicas, como nome e endereço,
apareceriam somente uma vez. Cada departamento teria um programa que usaria o
número do empregado para relacionar os dados básicos de que ele necessitava.
Com este formato de dados, a maioria dos controles de relacionamento de dados
estava no programa de gerenciamento de banco de dados. Este novo paradigma tirou a
responsabilidade de programadores terem de criar ponteiros que relacionassem um
arquivo ao outro.
Utilizando a teoria dos conjuntos, Codd analisou o banco de dados relacional e
descobriu maneiras de minimizar as repetições em buscas e ligações de entidades,
quebrando os dados em unidades separadas menores.
Como os bancos de dados relacionais são simples de visualizar e usar,
rapidamente transformaram-se no método preferido para lidar com dados complexos
(SIEGEL, 1994).
52
Uma das maiores razões para o sucesso dos bancos de dados relacionais é a
presença da SQL, a linguagem mais padronizada para comunicação com bancos de
dados. Embora a SQL seja cheia de acréscimos aborrecidos e complicados específicos,
o núcleo da sua sintaxe é comum e bem compreendido (FOWLER, 2006).
53
4. Cronograma de Desenvolvimento
O cronograma de desenvolvimento do Trabalho de Conclusão de Curso (TCC)
seguirá as atividades apresentadas nos quadros a seguir.
4.1. TCC I
Descrição da tarefa Mar Abr Mai Jun Jul
Reunião inicial do Trabalho de Conclusão
Entrega da definição do tema e do orientador
Reuniões com o orientador
Entrega da Proposta de Trabalho de Conclusão
Acompanhamento dos projetos da organização onde será
realizado o referido trabalho.
Levantamento de material bibliográfico
Referencial teórico
Elaboração da Monografia do Trabalho de Conclusão de
Curso I
Entrega da Monografia do Trabalho de Conclusão de Curso I
Preparação da Apresentação para o Seminário de
Andamento
Seminário de Andamento
Quadro 7- Cronograma de desenvolvimento do TCC I
54
4.2. TCC II
Descrição da tarefa Ago Set Out Nov Dez
Adequações propostas pela banca no TCCI
Reuniões com o orientador
Implantação da metodologia e desenvolvimento do software
proposto.
Elaboração da Monografia do Trabalho de Conclusão de
Curso II
Entrega da Monografia para a Banca
Preparação da Apresentação para a Defesa do Trabalho de
Conclusão
Defesa
Quadro 8 - Cronograma de desenvolvimento do TCC II
55
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.
Com a utilização de metodologias ágeis é possível elevar os ganhos em ordem
de grandeza proporcionada pelo baixo custo gerado para alterar o software a qualquer
momento, em comparação com as metodologias de desenvolvimento tradicionais.
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.
56
REFERÊNCIAS
37SIGNALS. Simple small business software, collaboration, CRM: 37signals.
Disponível em: <http://37signals.com/>. Consultado em Junho de 2010.
AGILEMANIFESTO, Manifesto for Agile Software Development . Disponível em:
<http://www.agilemanifesto.org>. Consultado em Março de 2010.
AMARAL, Fernando. Dicas de Mapeamento Objeto/Relacional . Disponível em:
<http://www.fernandoamaral.com.br/Default.aspx?Artigo=55>. Consultado em Abril de
2010.
AQUINO, Larissa R. Lira. Gerenciamento de Incidentes, segundo ITIL. MBA
Governança de Tecnologia da Informação. Faculdade Católica de Cuiabá, 2008.
BASECAMP. Project management, collaboration, and task softwar e. Disponível em:
<http://basecamphq.com/>. Consultado em Maio de 2010.
BON, Jan Von. Foundations of IT Service Management, based on ITIL . Lunteren - Holanda: Van Haren Publishing, 2005.
BORRIE, Helen; Tradução: FERNANDES, Acauan. Dominando o FireBird: Uma
Referência Para Desenvolvedores de Banco de Dados. Rio de Janeiro: Editora
Ciência Moderna, 2006.
CCTA, Central Computer and Telecommunications Agency. Service Support. Londres,
2000.
CLOCKINGIT. ClockingIT, Timetracking 2.0. Disponível em:
<http://www.clockingit.com/>. Consultado em Maio de 2010.
57
DESCHAMPS, Alexandro. SWAROWAKY, Hugo H. Gerencia de Configuração –
Ápice da Engenharia de Software . 2008.
ELMASRI, Ramez. Sistemas de Banco de Dados . São Paulo: Pearson Addison
Wesley, 2005.
EMBARCADERO. Embarcadero Technologies Inc . Disponível em:
<http://www.embarcadero.com>. Consultado em Junho de 2010.
FDD, Feature Driven Development - The portal for all thi ngs of FDD . Disponível em:
<http://www.featuredrivendevelopment.com/>. Consultado em Maio de 2010.
FIREBIRD. Firebird - The RDBMS that's going where you're goin g. Disponível em:
<http://www.firebirdsql.org>. Consultado em Junho de 2010.
FOWLER, Martin. Padrões de Arquitetura de Aplicações Corporativas . Porto Alegre:
Bookman, 2006.
FOWLER, Martin. Enterprise Patterns . Disponível em:
<http://www.martinfowler.com/articles/enterprisePatterns.html>. Consultado em Abril de
2010.
GAMMA, Erich. HELM, Richard. JOHNSON, Ralph, VLISSIDES, John. Padrões de
Projeto – Soluções reutilizáveis de Software Orient ado a Objetos . Bookman, 2000.
HALLAIS, Vitor; ALVES, Ramon. Gerencia de Serviços: Gerenciamento de
Problemas baseado no Modelo ITIL. Monografia de Engenharia de Software, PUC-
Minas, 2009.
HAUENSTEIN, Deise. Monografias, dissertações e teses : manual completo para
normalização segundo a ABNT. Porto Alegre: Nova Prova, 2008.
58
HEUVEL, Willem-Jan van den. Aligning modern business processes and legacy
systems: A component-based perspective. Massachusetts Institute of Technology,
2007.
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, ITIL® Home . Disponível em: <http://www.itil-officialsite.com/home/home.asp>.
Consultado em Março de 2010.
LARMAN, Craig, Utilizando UML e Padrões: uma introdução à análise e ao projeto
orientado a objetos . 3ª edição, Porto Alegre: Bookman, 2007.
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.
MARTIN, James. Princípios de Análise e projeto baseados em objetos . James
Martin; tradução de Cristina Bazán. Rio de Janeiro: Campus, 1997.
MAURER, Martel. Extreme Programming: Rapid Development for Web-Base d
Applications . IEEE Internet Computing, 2002.
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, Ken. SUTHERLAND, Jeff. Scrum Guide . Scrum.Org, 2008.
SIEGEL, Charles. A B C’s of Paradox . Longman Higher Education, Londres. 1990.
59
SEACORD, Robert C.; PLAKOSH, Daniel; LEWIS, Grace A. Modernizing Legacy
Systems: Software Technologies, Engineering Process es, and Business
Practices. Addison Wesley, 2003.
SEBESTA, Robert W. Conceitos de Linguagens de Programação. Robert W.
Sebesta; tradução de José Carlos Barbosa dos Santos – 4ª ed. Porto Alegre: Bookman,
2000.
SOFTWAREMINING. Breathing life into legacy applications. Disponível em:
<http://www.softwaremining.com/index.jsp>. Consultado em Maio de 2010.
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.
SOLLER, David. Progress Report on the National Geologic Map Databa se, Phase 3:
An Online Database of Map Information. U.S. Geological Survey Open Report, 2001.
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 Maio de
2010.
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. ToDoList Resources AbstractSpoon Software. Disponível em:
<http://www.abstractspoon.com/>. Consultado em Maio de 2010.
60
XP, Extreme Programming (XP): A Gentle Introduction. Disponível em:
<http://www.extremeprogramming.org/>. Consultado em Março de 2010.