FACULDADE CENECISTA NOSSA SENHORA DOS ANJOS - FACENSA Mantida pela CNEC Campanha Nacional de Escolas da Comunidade

CURSO DE GRADUAO SISTEMAS DE INFORMAO

RAFAEL LEMOS PASSARELA

SISTEMA PARA CONTROLE DE PROCESSOS APLICANDO MTODOS GEIS E ITIL

Gravata 2010

RAFAEL LEMOS PASSARELA

SISTEMA PARA CONTROLE DE PROCESSOS APLICANDO MTODOS GEIS E ITIL

Trabalho de Concluso de Curso I apresentado como requisito parcial para obteno do ttulo de Bacharel em Sistemas de Informao da Faculdade Cenecista Nossa Senhora dos Anjos - FACENSA

Orientador: Prof. Me. Guilherme Lacerda

Co-Orientador: Prof. Daniel Wildt

Gravata 2010

RESUMO

Este trabalho tem como objetivo efetuar o levantamento do material necessrio para a realizao de um sistema para controle de processos, utilizando as boas prticas do ITIL para a Gesto de Incidentes e a Gesto de Problemas, utilizando conceitos de mtodos geis para facilitar a obteno de mtricas 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, Mtodos geis, Gesto de Incidentes, Gesto de Processos

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

LISTA DE FIGURAS

Figura 1 - Modelo para a entrada de informaes.......................................................... 11 Figura 2 - Ciclo de Vida de Manuteno de Software .................................................... 18 Figura 3 - Mtodos de Converso para Reduo de Impacto ........................................ 19 Figura 4 - Custo de Adio de Funcionalidade na Engenharia Tradicional .................... 21 Figura 5 - Custo de Adio de Funcionalidade na Nova Engenharia ............................. 21 Figura 6 - Diagrama de Atividades na Gerencia de Incidentes ...................................... 26 Figura 7 - Matriz de Impacto x Urgncia ........................................................................ 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 Distribuio de Tarefas do BaseCamp ........................................................ 33 Figura 14 - Lista de Tempo de Atividades com o BaseCamp......................................... 34 Figura 15 - Definio de Estimativa de Tempo com BaseCamp .................................... 34 Figura 16 - Configurao Inicial do ToDoList ................................................................. 35 Figura 17 - Configurao de Colunas do ToDoList ........................................................ 36 Figura 18 - Seleo de Interface e Projeto de Exemplo do ToDoList ............................. 36 Figura 19 - Tela Principal do ToDoList ........................................................................... 37 Figura 20 - DashBoard do ClockingIT ............................................................................ 38 Figura 21 - Grfico 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 Prottipo 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 Alteraes por Verso no CaseSupport ................................... 46 Figura 28 - Diagrama de Caso de Uso ........................................................................... 47

Figura 29 - Diagrama de Classes do CaseSupport ........................................................ 48 Figura 30 - Diagrama ER do Sistema CaseSupport ....................................................... 49

LISTA DE QUADROS

Quadro 1 - Categorias de Manuteno de Software ...................................................... 15 Quadro 2 - Definies de Manuteno de Software ....................................................... 16 Quadro 3 - As oito leis de Lehman ................................................................................. 17 Quadro 4 - Definies de Mtodos de Converso.......................................................... 19 Quadro 5 - Classificao 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

LISTA DE ABREVIATURAS

Abreviaturas utilizadas ao longo deste trabalho:

ANS ER FDD IDE IDPL ITIL RDBMS RUP SGBDR SQL TI UP XP WWW

Acordo de Nvel de Servio Entidade-Relacionamento Feature Driven Development Integrated Development Environment Initial Developer's Public License Information Technology Infrastructure Library Relational Database Management System Rational Unified Process Sistema Gerenciador de Banco de Dados Relacional Structured Query Language Tecnologia da Informao Unified Process eXtreme Programming World Wide Web

SUMRIO

INTRODUO ............................................................................................................... 10 Motivao ....................................................................................................................... 11 Objetivo Geral ................................................................................................................ 12 Objetivo Especfico: ........................................................................................................ 12 Estrutura do Trabalho ..................................................................................................... 12 1. REFERENCIAL TERICO ......................................................................................... 14 1.1. Sistemas Legados ................................................................................................... 14 1.1.1. Manuteno de Software...................................................................................... 15 1.2. Mtodos geis......................................................................................................... 20 1.2.1. XP (eXtreme Programming) ................................................................................. 23 1.2.2. Scrum ................................................................................................................... 23 1.3. ITIL .......................................................................................................................... 24 1.3.1. Gesto de Incidentes............................................................................................ 25 1.3.2. Gesto 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. Soluo Proposta ....................................................................................................... 43 3.1. Viso ....................................................................................................................... 43 3.2. Prottipo .................................................................................................................. 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

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 CONSIDERAES FINAIS ........................................................................................... 55 REFERNCIAS .............................................................................................................. 56

10

INTRODUO

Atualmente as empresas encontram-se em um mercado cada vez mais globalizado, onde a busca e a captao de clientes so feitas de diversas maneiras, como por exemplo, oferecendo produtos ou servios inovadores, algo que os destaque dos demais concorrentes. Existem segmentos de mercado onde a personalizao e a constante evoluo do produto so considerados pontos cruciais para garantir que a empresa ser a escolhida pelo cliente. Organizaes de TI, principalmente as que se dedicam a construo de software, tm estes dois fatores como essenciais para a satisfao do cliente. Alem de evitar que o sistema apresente bugs e corrigir os que eventualmente apaream, de suma importncia efetuar as personalizaes para os clientes, desde um simples ajuste em um relatrio a at mesmo o desenvolvimento de uma nova funcionalidade. Para isto, necessrio conhecer a real capacidade da equipe de desenvolvimento sabendo quantas funcionalidades podem ser entregues por interao. Segundo (DESCHAMPS, 2008), existem quatro necessidades fundamentais que levam a realizao de uma mudana em um software: novas necessidades de mercado, novas necessidades do cliente, crescimento/diminuio dos negcios, restries de oramento ou cronograma. Diante de tal fato, muitas software houses realizam estas modificaes no software sem conhecer os reais motivos que levam a tal alterao, outras, sequer no conhecem a capacidade da equipe em suportar tais demandas. Alem disto, no possuem rastreabilidade sobre as implementaes, onde no sabem quem solicitou, quem alterou e nem para qual motivo o software foi modificado. Apesar de existirem sistemas capazes de gerenciar tais informaes e elevar os ganhos em ordem de grandeza proporcionada pelas mtricas geradas, poucas organizaes se beneficiam destas ferramentas. Esta baixa adoo pode ser explicada pela complexidade envolvida na utilizao das mesmas, ressaltando que, em sistemas mais simples, existem informaes que so ignoradas e nos sistemas mais complexos sua interface os torna degradantes.

11

Motivao O projeto surgiu da necessidade da criao de uma ferramenta que torne possvel gerenciar de forma simples e eficaz todas as tarefas necessrias para a distribuio de requisies durante as interaes em um projeto de software. A motivao que leva ao desenvolvimento deste trabalho bem como a definio da ferramenta para controle de requisitos, teve como base a quantidade de solicitaes (bugs, novas implementaes e personalizaes), existentes em qualquer empresa de desenvolvimento de software que no 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 solicitaes populam a base de dados do sistema de controle. Abaixo segue o modelo sugerido para a entrada de informaes no sistema de controle de requisitos:

Figura 1 - Modelo para a entrada de informaes

Aps a entrada dos dados ser possvel separar as informaes entre incidentes e problemas, bem como consultar registros semelhantes atravs da base de conhecimento gerada.

12

Objetivo Geral Mostrar como possvel gerenciar de forma simples e eficaz a distribuio de tarefas durante as interaes presentes no ciclo de desenvolvimento de software bem como obter mtricas capazes de identificar a potencial carga de trabalho suportada pela equipe de desenvolvimento. Prope-se ento a criao de um sistema para controle de processos com a capacidade de gerenciar de forma prtica os requisitos necessrios para a distribuio de tarefas durante o ciclo de interaes. Espera-se diminuir o tempo necessrio para gerencia de processos presentes durante o ciclo das interaes de software, de modo que este tempo seja melhor aproveitado para projet-lo, aplicando bons princpios de engenharia de software para a construo de arquivos fontes e com um padro adotado e conhecido pela maioria dos desenvolvedores. Com a entrada dos requisitos em um nico sistema, ser possvel obter uma base de conhecimento sobre os sistemas desenvolvidos, proporcionando aos demais setores usufrurem desta ferramenta, como por exemplo, o suporte a clientes.

Objetivo Especfico: - Estudar sistemas de gerenciamento de projeto; - Estudar gerencia de incidentes; - Estudar gerencia de problemas; - Estudar a linguagem de programao 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 Alm da introduo e consideraes finais, o trabalho esta dividido em trs grandes sees:

13

- Na primeira seo tem-se o referencial terico que trar em seu contedo informaes para as questes que norteiam a definio de um aplicativo para controle de processos como princpios bsicos para: manuteno de software, ITIL (gerencia de projetos e gerencia de incidentes), mtodos geis e a arquitetura necessria para construo da ferramenta proposta. - Na segunda seo o trabalho mostra algumas ferramentas existentes no mercado e faz um comparativo com a aplicao a ser criada. - A terceira seo tratar da concepo da soluo proposta e das tecnologias envolvidas para atingir o objetivo que a criao de um sistema para controle de processos.

14

1. REFERENCIAL TERICO Nesta seo sero apresentadas informaes referentes a sistemas legados, manuteno de software e uma breve abordagem sobre mtodos geis e ITIL.

1.1. Sistemas Legados Softwares tornam-se legados quando eles comeam a resistir a modificao e a evoluo. No entanto, o conhecimento incorporado nestes sistemas constitui um trunfo importante nas organizaes. Estes sistemas podem ainda proporcionar um importante valor comercial, tornando-se assim objetos de modernizao ou substituio (SEACORD, 2003) Sistemas legados em geral, utilizam uma estrutura imperativa e com as seguintes caractersticas: - Sistemas com difcil manuteno; - Sistemas sem documentao utilizada; - Sistemas sem padronizaes; - Foram escritos em linguagens que no existem mais no mercado; - Foram escritos por programadores que j se aposentaram; - Sistemas que possuem um alto custo para modernizao. Por falta de documentao e com a mudana do pessoal tcnico que participou originalmente no desenvolvimento dos sistemas legados, os mesmos podem apresentar problemas tais como: - Estilos de programao distintos; - Dificuldade de compreenso das regras de negcio; - Desconhecimento das razes que levaram a determinadas decises; - 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 avanados. Com a evoluo dos equipamentos, algumas empresas se deparam com a necessidade de evoluir seus sistemas, sendo este talvez o principal motivo para reestruturao e migrao de um sistema legado, pois sabido que muitas

15

organizaes continuam usando sistemas desenvolvidos a mais de uma dcada. Dessa forma, a reestruturao de um sistema legado proporciona uma oportunidade para a considerao de um maior nmero de variveis, sejam na atualizao de hardware, mas tambm de software. Em contrapartida para certas empresas, o valor mais significante para a atualizao de seus programas de computador a oportunidade de reorganizar as operaes departamentais, tendo como base um maior ganho de produtividade e a utilizao de softwares modernos.

1.1.1. Manuteno de Software As razes que levam a manuteno de software se dividem nas seguintes categorias conforme mostra o quadro abaixo (SWEBOK, 2004): Correo Pr-ativa Reativa Preventiva Corretiva Aprimoramento Perfectiva Adaptativa

Quadro 1 - Categorias de Manuteno de Software

Perfectiva: So feitas para melhorar o produto, como adicionar necessidades dos usurios, ou para melhor o desempenho, facilitar a utilizao, ou agregar outros atributos. Estes tipos de mudanas so tambm chamados de acessrios. Existem quatro necessidades fundamentais que levam a realizao de uma mudana em um software: novas necessidades de mercado, novas necessidades do cliente, crescimento/diminuio dos negcios, restries de oramento ou cronograma (DESCHAMPS, 2008). Adaptativa: So feitas para acompanhar o ritmo das mudanas ambientais, tais como: novos sistemas operacionais, novas linguagens, banco de dados de sistemas de gesto comercial e outros componentes. Corretiva: As mudanas so feitas para reparar defeitos no sistema. Preventiva: As mudanas so feitas para melhorar o futuro da manuteno e confiabilidade de um sistema. Ao contrrio das ltimas trs razes para a mudana

16

reativa, a preventiva age proativamente para mudanas, que visam simplificar a evoluo futura. Os esforos de desenvolvimento de software resultam na entrega de um produto de software que satisfaa os requisitos dos usurios, assim o software tem que mudar ou evoluir. Uma vez em funcionamento, defeitos so descobertos, o ambiente de operao muda e novas necessidades dos usurios so criadas. A fase de manuteno no ciclo de vida do software inicia aps o perodo de garantia ou suporte, aps a entrega do software, mas as atividades de manuteno ocorrem muito mais cedo. A manuteno de software segue definies criadas nas seguintes normas, conforme o quadro 2 abaixo: Norma IEEE 1219 Definio Define a alterao do software aps a entrega, com atividades para: corrigir falhas, implementar melhorias, criar interface com outros sistemas, adaptar programas para diferentes hardwares e softwares, migrao 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 manuteno do mesmo. IEEE 14764 Define a nvel internacional, a manuteno de software nas mesmas condies da norma IEEE 12207.
Quadro 2 - Definies de Manuteno de Software

Segundo (SWEBOK, 2004), a percepo comum da manuteno de software que ela sirva apenas para corrigir falhas, no entanto estudos e pesquisas ao longo dos anos tm indicado que mais de 80% da manuteno do software usada para aes no corretivas. Lehman e Belady (1985) realizaram a maioria dos trabalhos referentes a dinmica de evoluo do programa focando nas mudanas do sistema. Com base nestes estudos propuseram um conjunto de leis referentes as mudanas nos sistemas (Leis de Lehman).

17

Lehman e Belady examinaram o crescimento e a evoluo de uma srie de grandes sistemas de software. As leis propostas foram derivadas dessas medies (SOMMERVILLE, 2003). Durante um perodo de vinte anos, as pesquisas de Lehman levaram a formulao de oito leis conforme mostra a quadro 3, todas relacionadas a manuteno e ciclo de vida de software (SWEBOK, 2004). Lei Mudana Contnua Descrio Um programa usado e ambiente de produo 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. Evoluo de Programa de Grande Porte A evoluo do programa um processo auto-regulvel. Atributos de sistemas como tamanho, tempo entre releases e nmero de erros reportados so quase invariveis em cada verso do sistema. Estabilidade Organizacional Durante o ciclo de vida, sua taxa de desenvolvimento quase constante e independente de recursos dedicados ao desenvolvimento. Conservao de Familiaridade Crescimento Contnuo Durante o ciclo de vida de um sistema, mudanas incrementais em cada verso so quase constantes. As funcionalidades oferecidas pelo sistema devem aumentar continuamente para manter a satisfao do usurio. Qualidade em Declnio A qualidade do sistema entrar em declnio a menos que eles sejam adaptados a mudanas em seus ambientes operacionais. Sistema de Feedback Os processos de evoluo incorporam um sistema de feedback com vrios agentes e loops e voc devem trat-los para conseguir aprimoramentos significativos de produto.
Quadro 3 - As oito leis de Lehman

18

As organizaes 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 mudana contnua ou se torna progressivamente menos til. (SEACORD, 2003) As observaes de Lehman so pertinentes e devem ser levadas em conta no planejamento do processo de manuteno, entretanto, dependendo do plano de negcio adotado pela software house, tais observaes devem ser ignoradas. O marketing, por exemplo, pode adotar um esquema em que ser necessrio fazer diversas mudanas em sistemas maiores em um nico release e como conseqncia, provavelmente, sero necessrios 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 utilizao em uma organizao. Conforme a figura 2 (SEACORD, 2003) verifica-se a existncia de uma atividade continua de desenvolvimento, at que um novo sistema entre em operao.

Figura 2 - Ciclo de Vida de Manuteno de Software

19

Um novo sistema computadorizado normalmente torna-se uma tarefa difcil. Visando amenizar esta tarefa, existem mtodos de converso que reduzem o impacto gerado pela introduo de novas tecnologias (O BRIEN, 2006), conforme pode ser observado na figura 3 abaixo.

Figura 3 - Mtodos de Converso para Reduo de Impacto

As definies destas quatro formas de converso podem ser observadas no quadro quatro. Converso Paralela Definio O sistema legado e o sistema novo funcionam em paralelo at que o a equipe de desenvolvimento e a administrao concordem em utilizar somente o novo. Resultados e desempenhos so 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 aplicao ou alguns departamentos so convertidos, um de cada vez permitindo a implantao 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 - Definies de Mtodos de Converso

20

Segundo SOMMERVILLE (2003), assim que o software colocado em uso, novos requisitos emergem, e os requisitos existentes so modificados medida que a empresa que executa esse software passa por modificaes, tornando impossvel produzir sistemas de qualquer tamanho que no precisem ser modificados. Mesmo aps serem entregues, softwares necessitam ser modificados, seja para correo de bugs, adio de novas funcionalidades ou aperfeioamento das j existentes, em suma, eles sempre evoluem, em resposta s exigncias de mudanas.

1.2. Mtodos geis Segundo TALES (2005), as indstrias de software buscam a dcadas tcnicas 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 inmeras propostas para melhorar o desempenho dos projetos, iniciados pelo processo de desenvolvimento linear e seqencial (em cascata) at aos atuais processos geis de desenvolvimento. Tambm conhecido como Desenvolvimento gil de Software, ou simplesmente como Mtodo 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 mudanas (HILMER, 2004). A relao entre o custo e o momento em que a alterao adicionada na engenharia tradicional pode ser observada na figura 4, deixando evidente que quanto mais tempo uma alterao ou funcionalidade postergada, maior ser o custo aplicado sobre tal.

21

Figura 4 - Custo de Adio de Funcionalidade na Engenharia Tradicional

HILMER (2004) define a nova engenharia de software utilizando mtodos geis, como a forma que permite constantemente alterar o cdigo sem que a qualidade seja comprometida. A relao custo e momento em que a alterao adicionada para este caso pode ser observado na figura 5 abaixo.

Figura 5 - Custo de Adio de Funcionalidade na Nova Engenharia

22

A introduo dos mtodos geis na engenharia de software visa reduzir o ciclo de vida do mesmo, e com isto acelerar seu desenvolvimento disponibilizando verses do sistema com funcionalidades mnimas, executando exatamente o que foi solicitado. As demais funcionalidades, bem como aperfeioamentos e correes de bugs, so adicionadas nas verses subseqentes com base em um processo continuo e interativo. Mtodos geis aplicam uma coleo de prticas guiadas por princpios 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 reunio surgiu o Manifesto gil para

Desenvolvimento de Software. Os seguintes princpios foram definidos para o Manifesto gil

(AGILEMANIFESTO, 2010): - Indivduos e Interaes so mais importantes que processos e ferramentas; - Software funcionando mais importante do que documentao completa e detalhada; - Colaborao com o cliente mais importante do que negociao de contratos; - Adaptao a mudanas mais importante do que seguir o plano inicial;

Segundo HILMER (2004), para melhor compreenso dos Mtodos geis, devese primeiramente entender as caractersticas principais que os norteiam, so elas: - uma atitude e no um processo prescritivo; - um suplemente aos mtodos existentes e no uma metodologia completa; - uma forma efetiva de trabalho em conjunto para atingir as necessidades das partes envolvidas; - uma atividade que funciona na prtica e no uma teoria acadmica; - a criao de documentos que possuam valor, e no documentos burocrticos; - Utiliza o modelo de processo interativo e incremental; - O cliente faz parte da equipe de desenvolvimento.

23

Conforme TALES (2005), graas aos mtodos geis, o cliente inteiramente o piloto do seu projeto e obtm muito rapidamente uma primeira produo 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 dcada de 90 voltada para o desenvolvimento de software, notria em diversos pases por ajudar a criar sistemas de forma mais econmica e em menor tempo que as formas habituais. O XP composto por um conjunto reduzido de prticas de desenvolvimento que se organizam em torno de quatro valores bsicos. Essas prticas possuem fortes interrelacionamentos formando um conjunto de elevada sinergia (MANHES, 2005). (XP, 2010) afirma que o Extreme Programming bem sucedido porque reala a satisfao 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 relao 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 verses do software ocorrem com freqncia; - A equipa de desenvolvimento trabalha em colaborao total; - O cdigo testado e limpo ao longo de todo o processo de desenvolvimento; - Indicadores permitem medir o projeto auxiliando em mudanas ao longo do desenvolvimento. Conforme HILBER (2004), O XP uma abordagem deliberada e disciplinada onde seu sucesso advm da satisfao do cliente, possui princpios que devem ser planejados e seguidos: simplicidade, comunicao, feedback, coragem e respeito. 1.2.2. Scrum

24

O Scrum baseado em controle de processos empricos que visam uma abordagem interativa e incremental, otimizando assim a previsibilidade e o controle de riscos. Pode ser encarado como um framework, e no um processo ou uma tcnica de desenvolvimento, onde se pode empregar processos e tcnicas. Seu papel fazer transparecer a eficcia relativa das suas prticas de desenvolvimento para que voc possa melhor-las (SCHWABER, 2008). O Scrum um processo para construir software incremental em ambientes complexos, onde os requisitos no so claros ou mudam com muita freqncia (HILMER, 2004). Com princpios semelhantes ao XP, possui equipes pequenas, requisitos poucos estveis ou desconhecidos e interaes curtas para promover a visibilidade do desenvolvimento. As equipes trabalham as funcionalidades definidas no inicio de cada sprint, diariamente realizada uma reunio de aproximadamente 15 minutos onde a equipe expe o que est sendo feito e o que ser feito. O tema destas reunies focado sobre trs perguntas: - O que voc realizou desde a ltima reunio? - Quais problemas voc encontrou? - Em que voc trabalhar at a prxima reunio?

1.3. ITIL Apesar de ser confundida muitas vezes com uma metodologia, ITIL na verdade um conjunto de boas prticas. Foi criada pela secretria de comrcio do governo ingls (Office of Government Commerce, OGC) para definir as melhores prticas para a gesto da rea de TI de empresas pblicas 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 necessrios para gerenciar a infra-estrutura de TI eficientemente e eficazmente de modo a garantir os nveis de servio acordados com os clientes internos e externos.

25

O ITIL fortalece a idia de que as organizaes esto cada vez mais dependentes da rea de TI, como uma forma de satisfazer e alcanar as necessidades impostas pelas regras de negcio de pequenas, mdias e grandes corporaes. (ITIL, 2010) ainda comenta que isto leva a uma maior exigncia para a alta qualidade de servios de TI. Para minimizar o desperdcio de tempo gasto em implementao, responsvel 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 indivduo trabalha, individualmente e coletivamente dentro da equipe, qual sua real produtividade, seu nvel de qualidade na aplicao de uma implementao. Para conseguir estas mtricas, podem ser utilizados alguns conceitos de indicadores obtidos no ITIL, onde os principais so: Gesto de Incidentes (Incidents), Gesto de Problemas (Problem).

1.3.1. Gesto de Incidentes Segundo ITIL (2010), um incidente todo evento que no faz parte da rotina do modelo de gesto de um servio, podendo gerar uma interrupo ou reduo na qualidade do servio prestado. Gerenciar incidentes garantir que estes eventos atpicos sejam solucionados o mais breve possvel, minimizando o impacto e garantindo que estes atendam aos nveis de servios pr-estabelecidos entre TI e cliente (AQUINO, 2008). Em suma, o gerenciamento de incidentes possui quatro objetivos principais: - Resolver os incidentes o mais rpido possvel, restabelecendo a normalidade do servio no prazo acordado no ANS; - Manter a comunicao dos status dos incidentes aos usurios; - Definir as prioridades dos incidentes e classific-los para os grupos de atendimento para que seja cumprido o prazo de resoluo; - Avaliar os incidentes e as possveis causas, informando ao Gerenciamento de Problemas. As atividades do gerenciamento de incidentes incluem: - Deteco de incidentes e registro;

26

- Classificao e suporte inicial - Investigao e diagnstico - Resoluo e restaurao - Fechamento do incidente Responsabilidade pelo incidente, monitorao, acompanhamento e

comunicao. O diagrama exibido na figura abaixo mostra as atividades pertencentes ao gerenciamento de incidentes.

Figura 6 - Diagrama de Atividades na Gerencia de Incidentes

Quanto classificao, a Gerencia de Incidentes utiliza-se de trs fatores: prioridade, urgncia e impacto.

- Prioridade: definido em relao ao impacto que o incidente tem sobre o negcio da organizao, pode ser definido na ANS; - Urgncia: prioridade com que o incidente deve ser resolvido; - Impacto: grau em que a proviso do servio interrompido;

27

No quadro 5, pode-se observar a classificao das prioridades. Cdigo da Descrio Prioridade 1 2 3 4 5 Crtico Alto Mdio Baixo Planejado 1 hora 8 horas 24 horas 48 horas Planejado Prazo para Soluo

Quadro 5 - Classificao de Prioridades

Com base na urgncia e no impacto, pode ser gerada uma matriz que define sua relao com os servios de suporte, como pode ser observado na figura 7 abaixo.

Figura 7 - Matriz de Impacto x Urgncia

Outros aspectos pertencentes s atividades de gerencia de incidentes podem ser definidos como: - Deteco de Incidentes e Registros: Registrar informaes bsicas do incidente; - Classificao e Suporte Inicial: Classificar, comparar, priorizar, fornecer suporte inicial para uma resoluo rpida; - Investigao e Diagnstico: Avaliao do incidente e soluo de contorno; - Resoluo e Recuperao: Resolver o incidente ou elaborar uma requisio de Mudana e tomar aes corretivas; - Fechamento do Incidente: Verificar junto ao cliente se o chamado foi atendido e resolvido e comunicar o fechamento;

28

1.3.2. Gesto de Problemas Segundo HALLAIS (2009), a gesto de problemas lida com os incidentes que no puderam ser resolvidos pela Gesto de Incidentes e foram direcionados para identificar a causa raiz do incidente. Este processo foca em encontrar a relao entre os incidentes, problemas e erros conhecidos, onde estes trs itens formam a chave para o conhecimento da causa raiz do incidente. O principio bsico est em comear 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 primrias, divididas em sub-atividades: - Controle de Problemas - Identificar e Registrar - Classificar - Pesquisar e Diagnosticar - Controle de Erros - Identificar e Registrar - Avaliar - Registrar a Soluo e o Fechamento - Monitorar o Problema - Gerenciamento Proativo de Problemas - Analisar tendncias - Medida de suporte com objetivos definidos - Proporcionar informaes a empresa - Finalizao de reviso dos problemas graves

O controle de problemas responsvel por encontrar a soluo definitiva para a causa raiz do incidente. Este possui atividades especficas, 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 so pesquisados e corrigidos. As atividades especficas do controle de erros so apresentadas na figura 9.

Figura 9 - Atividades do Controle de Erros

HALLAIS (2009) define o erro como sendo uma condio identificada por meio de um diagnostico bem sucedido da causa raiz de um problema, onde a falha confirmada e a soluo provisria identificada. O processo de identificao de erros pode ser feito de maneira reativa ou prativa. Esta ultima tida como sendo o modo ideal, pois o cliente no percebe qualquer alterao em seu sistema.

30

O modo reativo visa eliminar as origens causadoras de incidentes e minimizar as conseqncias, solues de contorno e apresentao 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 tendncias, identificando os pontos vulnerveis e as fraquezas. Como mencionado anteriormente, neste modo, o cliente no foi afetado e desconhece a existncia do erro.

31

2. ESTADO DA ARTE Nesta seo sero apresentados estudos feitos em sistema que apresentam funcionalidades semelhantes as do sistema proposto, so eles: BaseCamp, ToDo List e ClockingIT.

2.1. BaseCamp O BaseCamp uma ferramenta de colaborao e gerenciamento de projetos baseada em web, onde possvel distribuir tarefas, verificar prazos e centralizar o feedback. Conforme 37SIGNALS (2010), o BaseCamp foi criado em 2004 e desde ento mantido pela 37Signals, ele aborda a gerencia de projetos de um ngulo totalmente inovador at ento, com enfoque na colaborao e na comunicao. O BaseCamp um software pago, mas possui uma verso 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 pgina de Dashboard. Nos passos que seguem, sero 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 informaes de clientes e projetos em uma nica tela, como por exemplo, itens atrasados (1), itens pendentes para os prximos 14 dias (2), lista de projetos disponveis (3) e ltimas atualizaes do projeto (4). Estes itens podem ser observados na figura 11.

Figura 11 - DashBoard do BaseCamp

To-do List: Permite a criao de listas de controle, com a possibilidade de definio de pessoal responsvel. Itens concludos vo 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 responsveis, 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 calendrio (2) e na lista de tarefas pendentes (3).

Figura 13 Distribuio 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 tambm a definio do responsvel.

Figura 14 - Lista de Tempo de Atividades com o BaseCamp

Figura 15 - Definio de Estimativa de Tempo com BaseCamp

O BaseCamp mostra-se uma ferramenta extremamente til no gerenciamento de projetos, permitindo a criao de tarefas com pessoal responsvel definido, to-do lists, controle de estimativa de tempo e compartilhamento de arquivos. Todas suas funcionalidades so acessadas com poucos cliques, porem, a definio de carga de trabalho torna-se demorada e no permite a visualizao das tarefas em linha de tempo.

35

2.2. ToDoList O ToDoList uma ferramenta open source para gesto 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 fcil mantendo dentro de um agrupamento criado sobre a tarefa original. Cada projeto possui seu arquivo de TaskList, o que permite gerenciar inmeros projetos mas no todos sobre a mesma viso. Para executar o programa, basta efetuar o download diretamente do site (www.abstractspoon.com), no necessrio realizar a instalao, o que permite que o sistema rode diretamente de um Pen Drive. Aps efetuar o download, na primeira execuo do sistema, uma janela de configurao muito simples mostrada, conforme a figura 16, onde possvel escolher onde as configurao sero salvas e se as tasklists sero compartilhadas na rede.

Figura 16 - Configurao Inicial do ToDoList

Nas prximas janelas de configurao, possvel escolher quais colunas sero visveis na janela principal do sistema (figura 17) e definir qual interface ser utilizada na execuo do sistema, permitindo optar pelo modo completo ou simples (figura 18).

36

Figura 17 - Configurao de Colunas do ToDoList

Figura 18 - Seleo de Interface e Projeto de Exemplo do ToDoList

Uma das melhores caractersticas do ToDoList sua simplicidade, tudo que preciso est na tela principal, possui informaes importantes para gerenciamento e previso 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 criao de tarefas definindo o responsvel, sua estrutura de to-do list permite uma visualizao ampla das atividades em desenvolvimento e em espera, a fcil diviso de uma atividade em subatividades menores um dos pontos em destaque deste sistema. Todas suas funcionalidades so acessadas facilmente e esto centralizadas em uma nica janela. O fator negativo para este sistema fica em no ser possvel visualizar as tarefas para projetos distintos em um local centralizado.

2.3. ClockingIT O ClockingIT uma ferramenta web, totalmente free, de gerenciamento de projetos, colaborao e TimeTracking, que permite total controle sobre as tarefas e

38

sobre o tempo gasto nas mesmas, com foco em desenvolvimento de software e manipulao 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 responsvel por toda a programao, enquanto Ellen responsvel pelo design de interface, grficos e cores. Conforme seus prprios 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 relatrios que permitem obter quais tarefas foram feitas e quanto tempo foi despendido na realizao das mesmas. Alguns elementos importantes do ClockingIT: DashBoard: totalmente configurvel atravs de widgets, possui informaes referentes as tarefas mais importantes (1), tarefas novas (2) e estatsticas 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 grfico altamente utilizado para ilustrar o avano de diferentes etapas de um projeto. Nele pode ser vistas as tarefas de cada membro da equipe, bem como o tempo gasto para a execuo de cada uma delas. Construdo totalmente utilizando controles Ajax, possui a grande vantagem de configurao atravs de drag-and-drop e alm deste recurso, basta adicionar a estimativa de tempo e a data de vencimento da tarefa que o grfico atualiza automaticamente. O Gantt inserido no ClockingIT pode ser observado na figura 21.

Figura 21 - Grfico 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 urgncia. Permite definir em qual milestone est inserida e para qual projeto. Tambm possvel definir o responsvel e data de entrega desta tarefa, bem como suas dependncias. Cada tarefa possui seu prprio 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 possvel ver a lista de tarefas, em vermelho as tarefas atrasados e em verde as tarefas em espera para a prxima interao.

Figura 23 - Lista de tarefas no ClockingIT

41

O ClockingIT mostra-se uma excelente ferramenta para gerenciamento de projetos, permitindo a criao de tarefas com pessoal responsvel definido, to-do lists separados por tarefas, controle de estimativa de tempo, indicadores de BurnUp e BurnDown e compartilhamento de arquivos. Todas suas funcionalidades so acessadas com poucos cliques. Possui um grande diferencial em relao s outras ferramentas analisados, o Grfico 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 propem 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 atribuies ou caractersticas que um sistema de gerenciamento de projetos pode ter como:

- Plataforma - Valor (Licena) - Controle de Tarefas - Controle de Estimativa de Tempo - To-Do Lists - Tarefas em linhas de tempo - Controle de Arquivos Anexos - Estimativa de Qualidade de Desenvolvimento - Base de Conhecimento - Acompanhamento por Feed-RSS

42

Caracterstica Plataforma

BaseCamp Web

ToDoList Windows Desktop

ClockingIT Web

CaseSupport Windows Desktop

Valor da Licena

Paga. Verso free possui limitaes.

Open Source

Free

Controle de Tarefas Controle de Estimativa de Tempo To-do Lists 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 Acompanhamento por Feed-RSS
Quadro 6 - Comparativo de Ferramentas

Gerado Formato Wiki Alimentado manualmente automaticamente conforme o registro de Incidentes e Problemas

43

3. Soluo Proposta Nesta seo sero apresentadas informaes referentes ao sistema proposto, como uma breve viso do sistema, tecnologias utilizadas e funcionalidades importantes. O sistema se chamar CaseSupport.

3.1. Viso O sistema proposto ser capaz de centralizar as informaes de incidentes e problemas, gerar uma base de conhecimento, controlar a distribuio de tarefas, estimativas de tempo, tempo gasto por atividade e medir a qualidade de desenvolvimento sobre determinada implementao ou de indivduo especfico. Como uma das metas deste projeto, busca-se uma ferramenta capaz de agilizar a distribuio de tarefas de forma funcional e efetiva. Para que tal meta seja atingida, ser necessrio que o responsvel por tal distribuio conhea o potencial de produo de sua equipe. Dentre as mtricas que o sistema de controle de processos prope-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 perodo de tempo, que pode ser estabelecido como sendo o perodo entre as interaes. 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 homologao e retornar, pois no atingiu a funcionalidade total esperada ou surgiram outros erros decorrentes da alterao efetuada no cdigo fonte. O nmero destas reincidncias ir afetar a qualidade do trabalho realizado. A melhor frmula de calcular est mtrica ainda est sendo estudada.

3.2. Prottipo O prottipo desenvolvido at ento, permite coletar as informaes de incidentes e problemas, gera uma base de conhecimento para futuras pesquisas e possibilita o controle de tarefas por usurios do sistema.

44

Quando o mesmo foi idealizado, em 2008, ainda no existia a viso proposta de unir as metodologias geis com as boas prticas do ITIL em um nico sistema para controle de processos, como pode ser observado na figura 24, as nomenclaturas utilizadas no condizem com os padres propostos pelo ITIL. Outros itens que podem ser observados na figura abaixo so: histrico do atendimento (1), lista de tarefas (2), dados do atendimento (3) e histrico de alteraes (4).

Figura 24 - Tela principal do Prottipo CaseSupport

Outras funcionalidades que podem ser observadas j no prottipo so: - Controle de arquivos anexos (figura 25); - Auxilio para elaborao de planos de teste (figura 26); - Controle de alteraes por verso (figura 27).

45

Figura 25 - Controle de Arquivos Anexos do CaseSupport

Figura 26 Plano de Teste elaborado com Auxilio do CaseSupport

46

Figura 27 - Controle de Alteraes por Verso no CaseSupport

Estas so algumas funcionalidades j implementadas. Espero que, no decorrer da elaborao do segundo trabalho de concluso 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; - Histrico de Alteraes 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 elaborao de planos de teste.

47

3.4. Modelagem

Como at ento trata-se apenas de um prottipo, os seguintes diagramas sero incorporados apenas como carter preliminar, pois estes provavelmente sofrero alteraes 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, atravs do suporte telefnico, por e-mail ou diretamente pela web.

Figura 28 - Diagrama de Caso de Uso

Neste diagrama, o usurio do sistema detecta um erro, comunica o suporte por e-mail ou telefonema e este dar a entrada das informaes no banco de dados do sistema de controle. O usurio 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 reao das principais classes encontradas no sistema.

Figura 29 - Diagrama de Classes do CaseSupport

No diagrama acima, observa-se a centralizao dos processos sobre a classe TCases, que responsvel 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 compes 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 seo, ser abordado alguns tpicos referentes as tecnologias utilizadas para a criao 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 verso 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 verso 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 programao Windows e COM; - Suporte a desenvolvimento Web e Intranet; - Suporte a diagramas de classe e objetos; - Garantias de qualidade (QA) com auditorias e mtricas.

Segundo EMBARCADERO (2010), o RAD Studio a mais poderosa suite para desenvolvimento RAD e visual da indstria para criao de softwares que requerem interfaces ricas e acesso a dados pelo usurio final, possibilitando a entrega de aplicaes 5 vezes mais rpidas 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: transaes (concorrentes), linguagens de alto desempenho, procedures e triggers. Conforme FIREBIRD (2010), O FireBird um projeto comercialmente independente de programadores C e C++, conselheiros tcnicos e suportes de

51

desenvolvimento em plataforma multi-sistema de RDBMS, baseado no cdigo fonte liberado pela Inprise Corp (agora conhecido como Borland Software Corp). Segundo BORRIE (2006), O FireBird um SGBDR de capacidade industrial com alto nvel de compatibilidade com a linguagem SQL, implementando ao mesmo tempo recursos poderosos na esfera de programao procedural. Possuindo cdigo fonte open source, qualquer pessoa pode efetuar alteraes e criar uma verso personalizada, desde que mantenha a licena 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 nmero de empregado como campo-chave. Cada empregado receberia um nmero de identificao exclusivo e haveria um nico arquivo informaes gerais sobre cada empregado, como: nome, endereo e outros dados bsicos do empregado. Haveria outro arquivo com o nmero do empregado e sua respectiva remunerao, outro arquivo com o nmero do empregado e os benefcios a que teria direito e assim por diante. As informaes bsicas, como nome e endereo, apareceriam somente uma vez. Cada departamento teria um programa que usaria o nmero do empregado para relacionar os dados bsicos 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 repeties em buscas e ligaes de entidades, quebrando os dados em unidades separadas menores. Como os bancos de dados relacionais so simples de visualizar e usar, rapidamente transformaram-se no mtodo preferido para lidar com dados complexos (SIEGEL, 1994).

52

Uma das maiores razes para o sucesso dos bancos de dados relacionais a presena da SQL, a linguagem mais padronizada para comunicao com bancos de dados. Embora a SQL seja cheia de acrscimos aborrecidos e complicados especficos, o ncleo da sua sintaxe comum e bem compreendido (FOWLER, 2006).

53

4. Cronograma de Desenvolvimento

O cronograma de desenvolvimento do Trabalho de Concluso de Curso (TCC) seguir as atividades apresentadas nos quadros a seguir.

4.1. TCC I Descrio da tarefa Reunio inicial do Trabalho de Concluso Entrega da definio do tema e do orientador Reunies com o orientador Entrega da Proposta de Trabalho de Concluso Acompanhamento dos projetos da organizao onde ser realizado o referido trabalho. Levantamento de material bibliogrfico Referencial terico Elaborao da Monografia do Trabalho de Concluso de Curso I Entrega da Monografia do Trabalho de Concluso de Curso I Preparao Andamento Seminrio de Andamento
Quadro 7- Cronograma de desenvolvimento do TCC I

Mar

Abr Mai Jun

Jul

da

Apresentao

para

Seminrio

de

54

4.2. TCC II Descrio da tarefa Adequaes propostas pela banca no TCCI Reunies com o orientador Implantao da metodologia e desenvolvimento do software proposto. Elaborao da Monografia do Trabalho de Concluso de Curso II Entrega da Monografia para a Banca Preparao da Apresentao para a Defesa do Trabalho de Concluso Defesa
Quadro 8 - Cronograma de desenvolvimento do TCC II

Ago

Set Out Nov

Dez

55

CONSIDERAES FINAIS

Todas as atividades relacionadas ao desenvolvimento de produtos de software sofrem alteraes, motivadas por inmeros aspectos, como novas necessidades de mercado, novas necessidades do cliente, crescimento/diminuio dos negcios, restries de oramento ou cronograma. Para acompanhar estas mudanas e manter o nvel de satisfao do usurio final sem elevar os custos de produo do software, necessrio possuir mecanismos para controle destas alteraes que proporcionem mtodos de gerenciar a equipe de desenvolvimento como: definio de tarefas, controle de estimativa de tempo, controle do tempo gasto com implementaes, capacidade e qualidade de produo. Com a utilizao de metodologias geis possvel elevar os ganhos em ordem de grandeza proporcionada pelo baixo custo gerado para alterar o software a qualquer momento, em comparao com as metodologias de desenvolvimento tradicionais. Fica evidente que ao utilizar um sistema que proporcione as mtricas citadas anteriormente e que este utilize alguns dos conceitos presentes nos mtodos 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 correo de bugs, adio de novas funcionalidades ou aperfeioamento das j existentes, em suma, eles sempre evoluem, em resposta s exigncias de mudanas. O sistema de controle de requisitos no ir sanar todas as necessidades de negcio envolvidas na produo de software, mas ir proporcionar grande auxilio na distribuio de tarefas e fechamento de cronogramas, permitindo produzir mais em menos tempo.

56

REFERNCIAS

37SIGNALS. Simple small business software, collaboration, CRM: 37signals. Disponvel em: <http://37signals.com/>. Consultado em Junho de 2010.

AGILEMANIFESTO, Manifesto for Agile Software Development. Disponvel em: <http://www.agilemanifesto.org>. Consultado em Maro de 2010.

AMARAL, Fernando. Dicas de Mapeamento Objeto/Relacional. Disponvel 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 Governana de Tecnologia da Informao. Faculdade Catlica de Cuiab, 2008.

BASECAMP. Project management, collaboration, and task software. Disponvel 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; Traduo: FERNANDES, Acauan. Dominando o FireBird: Uma Referncia Para Desenvolvedores de Banco de Dados. Rio de Janeiro: Editora Cincia Moderna, 2006.

CCTA, Central Computer and Telecommunications Agency. Service Support. Londres, 2000.

CLOCKINGIT.

ClockingIT,

Timetracking

2.0.

Disponvel

em:

<http://www.clockingit.com/>. Consultado em Maio de 2010.

57

DESCHAMPS, Alexandro. SWAROWAKY, Hugo H. Gerencia de Configurao pice da Engenharia de Software. 2008.

ELMASRI, Ramez. Sistemas de Banco de Dados. So Paulo: Pearson Addison Wesley, 2005.

EMBARCADERO.

Embarcadero

Technologies

Inc.

Disponvel

em:

<http://www.embarcadero.com>. Consultado em Junho de 2010.

FDD, Feature Driven Development - The portal for all things of FDD. Disponvel em: <http://www.featuredrivendevelopment.com/>. Consultado em Maio de 2010.

FIREBIRD. Firebird - The RDBMS that's going where you're going. Disponvel em: <http://www.firebirdsql.org>. Consultado em Junho de 2010.

FOWLER, Martin. Padres de Arquitetura de Aplicaes Corporativas. Porto Alegre: Bookman, 2006.

FOWLER,

Martin.

Enterprise

Patterns.

Disponvel

em:

<http://www.martinfowler.com/articles/enterprisePatterns.html>. Consultado em Abril de 2010.

GAMMA, Erich. HELM, Richard. JOHNSON, Ralph, VLISSIDES, John. Padres de Projeto Solues reutilizveis de Software Orientado a Objetos. Bookman, 2000.

HALLAIS, Vitor; ALVES, Ramon. Gerencia de Servios: Gerenciamento de Problemas baseado no Modelo ITIL. Monografia de Engenharia de Software, PUCMinas, 2009.

HAUENSTEIN, Deise. Monografias, dissertaes e teses: manual completo para normalizao 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. Mtodos geis O que so mtodos geis. Graduao em Cincias da Computao, Universidade Federal de Braslia (UNB), 2004.

ITIL, ITIL Home. Disponvel em: <http://www.itil-officialsite.com/home/home.asp>. Consultado em Maro de 2010.

LARMAN, Craig, Utilizando UML e Padres: uma introduo anlise e ao projeto orientado a objetos. 3 edio, Porto Alegre: Bookman, 2007.

MANHES, Vincius. UM ESTUDO DE CASO DA ADOO DAS PRTICAS E VALORES DO EXTREME PROGRAMMING. Universidade Federal do Rio de Janeiro UFRJ, IM / DCC, 2005.

MARTIN, James. Princpios de Anlise e projeto baseados em objetos. James Martin; traduo de Cristina Bazn. 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 informao e as decises gerenciais na era da Internet. James A. OBrien; traduo Clio Knipel Moreira e Cid Knipel Moreira. 2 ed. So Paulo: Saraiva, 2006.

SCHWABER, Ken. SUTHERLAND, Jeff. Scrum Guide. Scrum.Org, 2008.

SIEGEL, Charles. A B Cs 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 Programao. Robert W. Sebesta; traduo de Jos Carlos Barbosa dos Santos 4 ed. Porto Alegre: Bookman, 2000.

SOFTWAREMINING. Breathing life into legacy applications. Disponvel em: <http://www.softwaremining.com/index.jsp>. Consultado em Maio de 2010.

SOMMERVILLE, Ian. Engenharia de Software; traduo Andr Maurcio de Andrade Ribeiro; reviso tcnica Kechi Hirama. So 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. Disponvel em:

<http://www2.computer.org/portal/web/swebok/htmlformat>. Consultado em Maio de 2010.

TELES, Vincius Manhes, Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming. Orientador: Carlo Emmanoel Tolla de Oliveira. Rio de Janeiro : UFRJ/IM, 2005. Dissertao (Mestrado em Informtica).

TODOLIST.

ToDoList

Resources

AbstractSpoon

Software.

Disponvel

em:

<http://www.abstractspoon.com/>. Consultado em Maio de 2010.

60

XP,

Extreme

Programming

(XP):

Gentle

Introduction.

Disponvel

em:

<http://www.extremeprogramming.org/>. Consultado em Maro de 2010.