FACULDADE CENECISTA NOSSA SENHORA DOS ANJOS - FACENSA 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 requisito parcial para obtenção do título de Bacharel em Sistemas de Informaçã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étodos Á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, Incident 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
A medida que um programa muda, sua estrutura tende a se
crescente
tornar mais complexa. Recursos devem ser dedicados para preservar e simplificar a estrutura.
Evolução de Programa
A evolução do programa é um processo auto-regulável.
de Grande Porte
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
Durante o ciclo de vida, sua taxa de desenvolvimento é
Organizacional
quase constante e independente de recursos dedicados ao desenvolvimento.
Conservação de
Durante o ciclo de vida de um sistema, mudanças
Familiaridade
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 Impacto
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 Engenharia 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 Nova 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
Manifesto
Ágil
Desenvolvimento de Software. Os
seguintes
princípios
foram
definidos
para
o
(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, devese 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 interrelacionamentos 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 Incidentes
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 Descrição
Prazo para Solução
Prioridade 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 Exemplo 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 subatividades 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 Plataforma
BaseCamp Web
ToDoList Windows
ClockingIT Web
Desktop Valor da Licença
Paga. Versão
Open Source
CaseSupport Windows Desktop
Free
free possui limitações. 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
Formato Wiki
Conhecimento
– alimentado manualmente por mensagens ou
Gerado Formato Wiki – Alimentado manualmente
writeboards Acompanhamento por Feed-RSS Quadro 6 - Comparativo de Ferramentas
automaticamente conforme o registro de Incidentes e Problemas
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 CaseSupport
Figura 26 â&#x20AC;&#x201C; Plano de Teste elaborado com Auxilio do CaseSupport
46
Figura 27 - Controle de Alterações por Versão no CaseSupport
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 Mar
Descrição da tarefa 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
Abr Mai Jun
Jul
54
4.2. TCC II Descrição da tarefa
Ago
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
Set Out Nov
Dez
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 software. 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.
<http://www.clockingit.com/>. Consultado em Maio de 2010.
Disponível
em:
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 things of FDD. Disponível em: <http://www.featuredrivendevelopment.com/>. Consultado em Maio de 2010.
FIREBIRD. Firebird - The RDBMS that's going where you're going. 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 Orientado a Objetos. Bookman, 2000.
HALLAIS, Vitor; ALVES, Ramon. Gerencia de Serviços: Gerenciamento de Problemas baseado no Modelo ITIL. Monografia de Engenharia de Software, PUCMinas, 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-Based 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
Processes,
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 Database, 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.
<http://www.abstractspoon.com/>. Consultado em Maio de 2010.
Disponível
em:
60
XP,
Extreme
Programming
(XP):
A
Gentle
Introduction.
DisponĂvel
<http://www.extremeprogramming.org/>. Consultado em Março de 2010.
em: