Um Modelo de Processo de Desenvolvimento de Software ERP Alexandre Bertan Veiga, Alison Dennis Vilcenski, Fbio Basso, Marcelo Fileto

Lima, Moiss de Sousa Galian, Regiane Tavares Tampellini Universidade Estadual de Londrina abveiga@onda.com.br, alisondv@yahoo.com, marcelolima@sercomtel.com.br, moisesgalian@hotmail.com, regitt@uol.com.br Abstract. This article aims to compare software development methodologies and suggest a model of software development process for ERP (Enterprise Resource Planning). The ERP software has become vital to the management systems of companies, hospitals and non-governmental organizations (Rego, 2007) where its use constitutes the foundation for the administration of these, on the other hand, the development and deployment is a complex task and is subject to constant change not only in relation to corporate business rules but also in relation to external variables such as laws and requirements of customers and suppliers.Desfazer edies Resumo. Este artigo tem o objetivo comparar metodologias de desenvolvimento de software e sugerir um modelo de processo de desenvolvimento para softwares ERP (Enterprise Resource Planning) . Os softwares ERP tornaram-se vitais para os sistemas de gesto de empresas, hospitais e organizaes no governamentais (Rgo, 2007) onde sua utilizao constitui-se no alicerce para a administrao destas, por outro lado, o desenvolvimento e implantao uma tarefa complexa e est sujeita a mudanas constantes no apenas em relao a regras de negcio das empresas mas tambm em relao as variveis externas como leis e exigncias de clientes e fornecedores. 1. Introduo Nas ltimas dcadas a tecnologia da informao mudou radicalmente o processo de trabalho nas empresas, automatizando tarefas, gerenciando volumes gigantescos de dados e oferecendo informao em tempo real. O uso de sistemas ERP intensificou-se a partir da dcada de 90, deixando de ser exclusividade das grandes empresas e chegando tambm nas pequenas e mdias empresas. Sistemas ERP so (teoricamente) capazes de integrar toda a gesto da empresa, agilizando o processo de tomada de deciso (Meireles, 2010). O desenvolvimento de software uma tarefa complexa e cara e o produto final nem sempre considerado de boa qualidade. Muito esforo tem sido feito para a criao de metodologias que melhorem a qualidade do processo de software. Segundo Schach (2009), processo de software a maneira pela qual um software produzido. 2. ERP - Enterprise Resource Planning 2.1 Conceito Os ERP, sigla inglesa de Enterprise Resource Planning, so sistemas integrados de informao de tipo back office (ou de retaguarda est associado aos departamentos administrativos de uma

empresa, departamentos que mantm nenhum ou muito pouco contato com os clientes (King, 2000). Os softwares ERP integram os dados e processos de vrios ou at mesmo da totalidade dos departamentos da organizao num nico sistema: esta integrao pode ser efetuada ao nvel departamental ou funcional (sistemas finanas, marketing, comercial, pessoal, produo, etc.) ou ento a nvel processual (sistema de tratamento de encomendas, sistema de informao de gesto, sistema de apoio deciso, etc.). Para isso, o ERP inclui um conjunto de aplicaes de software muito variado, dos quais podemos citar: software de controle de produo, gesto de encomendas, gesto de estoque, contabilidade, processamento de salrios, controle de contas correntes, faturamento, entre outros. 2.2 Histrico De acordo com Haberkorn (2006), o sistema ERP (Enterprise Resource Planning) surgiu com a evoluo do MRP I (Materials Resource Planning) e MRP II (Manufacturing Resource Planning) em meados da dcada de 90. O sistema MRP I foi uma das primeiras grandes aplicaes comerciais onde calcula-se a necessidade de compra de matria-prima e produo de componentes a partir de uma previso de vendas e da situao do estoque. Ele informa apenas o que deve ser produzido e comprado, mas no diz como. J o sistema MRP II surgiu com a misso de fornecer informaes de quem vai produzir, quando e quais so os recursos necessrios. Mas as empresas no so movidas apenas por materiais e mquinas, existe tambm como parte integrante e importante neste processo as pessoas e os recursos financeiros. Os recursos financeiros so controlados pelo mdulo financeiro e contbil e as pessoas pelo RH (Recursos Humanos). Com o objetivo de integrar e automatizar todos estes processos e procedimentos seja eles financeiro, contbeis, RH, estoque, custo, compras, produo, faturamento e etc., foi sugerido o novo nome para este tipo de soluo o ERP (Enterprise Resource Planning).

2.3 Importncia ERP nas organizaes O sistema ERP de suma importncia nas organizaes devido a integrao de todos os processos e departamentos da empresa. Segundo Mendes (2003), a importncia do ERP est segmentada nas melhorias que o sistema proporciona, tais como: Evoluo da base tecnolgica: permite reduo no tempo de processamento das informaes, obteno das informaes em tempo real e agilidade nas tarefas da empresa, mediante otimizao e uniformizao dos procedimentos internos;

 Integrao entre as diversas reas da empresa: auxiliada pela adoo de um nico sistema em toda empresa. O sistema auxilia o controle e integridade das informaes, pois elimina redundncia dos dados e permite a reduo no fluxo de papis; Impacto no controle e gesto da empresa: pode ser percebido por diminuio no retrabalho de tarefas administrativas; melhoria no desempenho da empresa; crescimento da empresa, possibilitado pelo controle em suas tarefas; centralizao das atividades administrativas; otimizao da comunicao; tomada de decises com informaes obtidas em tempo real e maior comprometimento e responsabilidade do funcionrio no apontamento. Impacto na administrao de recursos humanos (RH) da empresa: percebido por reduo de custos por meio da reduo de mo-de-obra e de horas extras, racionalizao de recursos e melhoria do nvel tcnico dos funcionrios em informtica. 2.4 Caractersticas Segundo Souza e Zwicker (1999) destacam como principais caractersticas dos sistemas ERP: so pacotes comerciais desenvolvidos a partir de modelos padro de processos baseados nas melhores prticas, integram os sistemas das diversas reas da empresa, utilizam banco de dados corporativo e atendem a uma ampla gama de funes empresariais. Os autores apresentam ainda um conjunto de termos relacionados aos sistemas ERP: funcionalidade, modularidade, parametrizao, customizao e atualizao. Os sistemas ERP tratam de uma arquitetura em que a informao disponvel e circula por todas as reas da empresa, tais como logstica, manufatura, finanas, recursos humanos e outras, utilizando um banco de dados nico, operando em uma plataforma comum, interagindo com diversas aplicaes e integrando todas as operaes do negcio em um s ambiente computacional, portanto, trata-se de um sistema integrado de gesto. Uma de suas caractersticas principais a habilidade de necessitar a entrada da informao apenas uma vez. Os sistemas ERP permitem s empresas automatizarem e integrarem parcela substancial de seus processos de negcios, abrangendo todas as reas de influncia para que o controle seja possvel, uniformizando estes processos, produzindo informaes em tempo real e oferecendo mudanas em quatro dimenses do negcio: estrutura organizacional, processo gerencial, situao tecnolgica e capacidade de fazer negcios. 2.6 Modelos de Processo de Desenvolvimento Os modelos de processo de desenvolvimento referem-se as principais etapas do desenvolvimento do software, desde a produo at a sua manuteno e instalao. Existem diversos modelos de desenvolvimento que buscam as melhores prticas ao tratar os requisitos, o projeto/desenvolvimento e a implantao/manuteno. Este artigo abordar como fonte de estudo e comparao os modelos RUP, XP, SCRUM e MSF. A partir dos principais aspectos destes

modelos sero descritas comparaes que permitiram propor um novo modelo sugerido ao desenvolvimento de softwares ERP.

2.6.1 A metodologia RUP A metodologia RUP (Rational Unified Process) um processo de engenharia de software que fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organizao de desenvolvimento, cujo objetivo assegurar a produo de software de alta qualidade dentro de prazos e oramentos previsveis (Kruchten, 2003). O RUP baseado em boas prticas de desenvolvimento, onde preciso instncia-lo e definir padres e guias especficos para a realidade de cada empresa ou projeto, para o desenvolvimento de sistemas seguindo a metodologia: Iterativo e Incremental; Caso de uso; Baseado na arquitetura do sistema; Orientado a objetos;

Em cada iterao so identificados e especificados os casos de uso mais relevantes, onde feita a analise e projeto, usando a arquitetura como guia, tambm levanto em conta a anlise dos riscos envolvidos, dentre estes, os quais devem ser realizados seguindo a sequencia dos que possuem maiores riscos, para a sua eliminao o quanto antes. O caso de uso so utilizados para especificar os requisitos, no planejamento e acompanhamento das iteraes, durante a anlise e projeto, eles so implementados, nesta fase, so realizados os testes, verificando se o sistema realiza o que est descrito no modelo de caso de uso. Baseado na arquitetura do sistema, onde esta prototipada e definida logo nas primeiras iteraes, onde o desenvolvimento consiste em complementar a arquitetura, ou seja, guia o projeto e a implementao das diversas partes do sistema, servindo para organizar o desenvolvimento, estruturar a soluo e identificar as oportunidades de reuso. A metodologia Orientada a Objetos, utiliza a anlise e Projeto em UML, que uma linguagem usada para especificar, modelar e documentar os artefatos de um sistema, onde tem se tornado o padro empresarial para modelagem orientada a objetos As exigncias dos clientes so muito bem tratadas no RUP, como a disciplina de requisitos est fortemente envolvida durante as fases de iniciao e elaborao, articulando claramente os marcos essenciais e pontos de deciso. A figura 1 apresenta os elementos bsicos do RUP. Nesta metodologia, o projeto passa por 4 (quatro) fases bsicas. Estas fases so: Concepo - entendimento da necessidade e viso do projeto; Elaborao - especificao e abordagem dos pontos de maior risco;

 Construco - desenvolvimento principal do sistema; Transio - ajustes, implantao e transferncia de propriedade do sistema;

Figura 1: Fases do RUP

Cada uma das fases citadas acima pode ser realizada de forma itertica, com resultados desenvolvidos incrementalmente. Embora o RUP no seja um processo adequado a todos os tipos de desenvolvimento de software, ele representa uma nova gerao de processos genricos. A mais importante inovao a separao de fases e workflows, e o reconhecimento de que a implantao de software no ambiente do usurio parte do processo. As fases so dinmicas e tem objetivos.

2.6.2 A metodologia XP - Extreme Programming - Alison A metodologia XP uma metodologia de desenvolvimento gil voltada para pequenas e mdias equipes, que desenvolvem software baseado em requisitos vagos e que se alteram com rapidez (Beck, 1999). A preocupao maior est em desenvolver rapidamente o software e na satisfao do cliente, cumprindo as estimativas de custo e prazo. De acordo com as definies dessa metodologia, seus principais valores so: comunicao, simplicidade, feedback, coragem e respeito (Beck, 2004). O objetivo da comunicao criar e manter o melhor relacionamento possvel entre o cliente e o prestador de servios, dando preferncia s conversas pessoais. A comunicao entre os

desenvolvedores e o gerente de projeto tambm encorajada e se caracteriza como um dos principais fatores na XP, que conversar ao mximo pessoalmente, evitando o uso do telefone e de mensagens de e-mail. A metodologia emprega algumas prticas que foram uma maior comunicao por parte da equipe, sendo uma dessas prticas a programao em pares. Um dos lemas do XP o mais simples possvel que possa funcionar, implementando apenas o que estritamente necessrio. Sendo assim, a simplicidade visa minimizar o cdigo, desprezando funes consideradas desnecessrias ou no essenciais. Para isto, deve-se desenvolver pensando apenas no presente, sempre procurar atender aos requisitos emergenciais e evitar adicionar funcionalidades ligadas evoluo do produto. O XP estabelece vrias prticas para que o feedback seja alto e ocorra o mais cedo possvel. Testes unitrios peridicos fornecem informaes sobre o cdigo indicando tanto erros individuais quanto do software integrado. O cliente transmite equipe do projeto novas caractersticas e informaes sobre a qualidade do software atravs de testes realizados sobre as verses liberadas. O andamento do projeto informado todos atravs de reunies dirias e mtricas simples coletadas frequentemente. Para o XP funcionar, os membros da equipe devem ter coragem para confiarem uns nos outros, nos seus clientes, nas suas prticas e em si prprios. A coragem um dos valores da metodologia XP por ela pregar que podem existir momentos em que ser necessrio jogar fora todo o cdigo desenvolvido durante alguns dias porque o resultado final no foi o esperado. A coragem tambm ser necessria quando o desenvolvedor ou a equipe precisar alterar um processo que no estiver funcionando, solicitar ao cliente a reduo do escopo de uma liberao e at mesmo pararem quando estiverem cansados. O respeito o valor que d sustentao aos demais valores. No desenvolvimento XP todas as pessoas so igualmente importantes, nenhum membro da equipe vale mais ou menos do que os outros. Saber ouvir, compreender e respeitar o ponto de vista do outro essencial para que um projeto de software seja bem sucedido. Membros de uma equipe s iro se preocupar em comunicar-se melhor se se importarem uns com os outros. Segundo Beck (1999), o desenvolvimento de software utilizando a metodologia XP consiste basicamente de quatro atividades, sendo elas planejamento, projeto, codificao e testes. As equipes XP planejam utilizando estrias escritas em pequenos cartes, chamados de Story cards, onde as estrias normalmente so escritas pelos prprios clientes. Os desenvolvedores utilizam o dilogo presencial com o cliente para aprender o mximo possvel sobre os detalhes de cada estria, ficando desta forma o registro do CRC Card apenas como um lembrete do dilogo. No planejamento, feita uma reunio no incio de cada ciclo semanal, na qual o cliente escreve novas estrias para serem implementadas na iterao que se inicia. Os desenvolvedores ento estimam cada estria e colocam o valor das estimativas nos cartes. Com base na velocidade de desenvolvimento da iterao anterior, os desenvolvedores fornecem um oramento para o cliente indicando a quantidade de estrias que podero ser implementadas na iterao. Com base nessas informaes, o cliente prioriza as estrias que possam gerar mais valor para ele quando estiverem implementadas.

O projeto de software na metodologia XP se baseiam na prtica Projeto de Software Simples, ou seja, deve-se projetar visando sempre um projeto de software o mais smples possvel que possa resolver o problema atual, sem mtodos, estruturas ou funes que no sero utilizadas no momento. A prtica Metforas, que relacionam elementos criados pelos desenvolvedores com elementos do mundo fsico, como por exemplo a lixeira, janelas e pastas, auxilia no projeto de software simples e ajuda a elevar a compreenso mtua. O uso de cartes CRC recomendado de forma a permitir o design em equipe, e permitem a descrio dos conceitos identificados na metfora na forma de classes. Na codificao, ou desenvolvimento, a equipe passa a implementar as estrias selecionadas para a iterao corrente, sendo este o momento em que a maioria das prticas definidas pelo XP so utilizadas. Uma dessas prticas o Refactoring, em que a equipe deve analisar o cdigo produzido visando melhor-lo, alterando sua estrutura mas sem alterar sua funcionalidade, com a finalidade de remover duplicidade de cdigo, melhorar sua performance e torn-lo mais simples. Outra prtica utilizada em XP a programao em pares. A programao em pares tem algumas vantagens, como por exemplo se um membro da equipe sair, um dos programadores do par possuir o mesmo conhecimento do cdigo e um programador sem muita experincia pode adquirir experincia mais rapidamente com outro programador. Os pares no so fixos durante todo o projeto, devendo ser mudados vrias vezes, mesmo durante um dia de trabalho. A atividade de testes define a realizao de testes unitrios e testes de aceitao. Os testes unitrios so testes de caixa-branca, devem ser automticos e desenvolvidos em conjunto com o software. O XP prega que os testes devem ser implementados antes mesmo de implementar o software, e a todo momento os testes devem estar funcionando em sua totalidade. Os testes de aceitao devem ser especificados pelo cliente, que ter a responsabilidade de afirmar de que forma ele aceitar o produto que est sendo desenvolvido. Os testes de aceitao tambm devem ser automatizados e a equipe responsvel por implement-los. 2.6.2.1 Consideraes importantes A metodologia XP considera que um ambiente de projeto deve ser amplo, com pequenos espaos privados e uma rea de programao no centro, sendo as mesas propcias para a programao em pares. Outro aspecto considerado pela metodologia de que comemoraes devem ser realizadas e contribuem para o sucesso do projeto. Ron Jeffries (Jeffries, 2004), um dos fundadores do XP, sugere comemorar a concluso de tarefas e estrias com toda a equipe, pizza para comemorar o final de uma iterao e champagne para a entrega de uma release, pois o trabalho divertido e gostoso quando h um sentimento de realizao, de finalizao. Estes momentos devem ser promovidos. Devemos citar ainda que projetos XP seguem a filosofia de que o mais importante no trabalhar mais, e sim trabalhar de forma mais inteligente. Uma equipe que trabalha muito mas produz vrias coisas erradas no est progredindo, est apenas consumindo energia. O importante no se movimentar muito, mas se mover na direo certa, de forma inteligente e sustentvel.

2.5.3 O Framework Scrum Desenvolvida por Jeff Sutherland na dcada de 90 o Scrum um processo de desenvolvimento iterativo e incremental focado no gerenciamento de projetos e seus principios bsicos seguem o manifesto gil. O Scrum segundo Schwaber e Sutherland (2011) no uma metodologia, mas sim um framework. O nome deste framework no se trata de um acrnimo: Scrum refere-se a uma posio de jogo do esporte rugby - trabalhar fortemente juntos para deslocar a bola em campo uma inspirao sobre o modo de trabalho da equipe. As metodologias geis surgiram como uma nova maneira de desenvolver software mais rpido, com menos burocracia e maior qualidade, e o uso de aes como definir reunies frequentes para implementar os requisitos dos usurios. No caso do Scrum os requisitos de software so descritos em estrias. A partir das estrias a equipe reune-se para definir prazos, estabelecer prioridades e tambm especificar o que ser feito por quem, desta forma temos os papis definidos do product owner, scrum master, e da equipe. O product owner o responsvel por trazer as estrias para a reunio inicial do processo e a presena deste fundamental para controlar trs variveis: escopo, estimativa e importncia. Escopo e importncia so definidas pelo product owner e estimativa pela equipe. Neste framework o papel de gerente de projetos pode ser encontrado na figura do Scrum Master que busca garantir progresso do desenvolvimento do produto, e que cada membro da equipe tenha as ferramentas que eles precisam para realizar seus trabalhos. Ele organiza reunies, monitora o trabalho sendo feito e facilita o desenvolvimento da verso. O Scrum Master pode ser encarado como um gerente de projetos, facilitador e mediador. No restante do time (a equipe) encontraremos os desenvolvedores, designers e demais profissionais que atuam no desenvolvimento do produto. Geralmente a equipe formada por um grupo pequeno de 5 a 9 pessoas e atravs de uma das premissas do modelo trabalha de forma autogerenciada. Assim que os requisitos so definidos, construindo a lista de desejos ou Product Backlog, necessrio comear a planejar quais requisitos especficos sero realizados em particular para essa verso do produto, o resultado dessa deciso chamado de Release Planning. No Release Planning a equipe comea com o Product Backlog: eles identificam os requisitos que sero implementados nessa verso e dessa forma e esses requisitos tornam-se parte do Release Backlog. O time ento prioriza os requisitos e estima quanto tempo de trabalho envolve cada uma delas provendo uma idia geral da quantidade de trabalho envolvido para completar toda a verso. Com o Release Backlog priorizado, possvel planejar as vrias Sprints - Sprint Backlog - para realizar o trabalho. De acordo com Schwaber e Sutherland (2011) a Sprint definida como Um ciclo de iterao, ou uma repetio do trabalho semelhante, que produz incremento de produto ou sistema. No mais do que um ms e geralmente mais do que uma semana . Dessa forma pode-se considerar sprints como tarefas, e estas pequenas partes do todo permitem a equipe construir o corpo do projeto com o conjunto de iteraes de todos sprints. Os Sprints geralmente duram alguns dias at no mximo 30 dependendo dos ciclos do release do produto. Quanto mais curto for o ciclo do release do produto, mas breve o Sprint dever ser. Elas so uma forma de levar o Product Backlog a um estado geral de pronto, de tal forma que a entrega de cada uma delas represente 100% do seus requisitos e seja potencialmente utilizvel, ou seja pronto para colocar em operao, integrar um mdulo ou demonstrar as partes interessadas.

Tambm encontramos neste framework os artefatos que auxiliam no processo. Um artefato que permite o monitoramento do desempenho e do tempo o Burndown Chart. Ele permite a visualizao de projeto, e assegura que o projeto esteja progredindo dentro da agenda. No escopo do grfico, o que tambm chamado de Burndown Velocity, possvel visualizar a quantidade mdia de produtividade ao decorrer dos dias. Alm dos artefatos existem cerimnias recomendadas como a do o SCRUM dirio. Os membros da equipe devem se comprometer em reunies dirias curtas em p - a ideia por trs das reunies de p, que como todos esto em p, ningum desperdia tempo, e por isso as reunies sero curtas - se encontrando diariamente possvel garantir de que todos esto em dia com suas tarefas. Conduzida pelo Scrum Master as seguintes questes podem ser levantadas: O que foi feito ontem? O que se pretende fazer hoje? Quais so os impedimentos que esto atrapalhando a execuo das tarefas? Assim cada Sprint termina com uma reviso do trabalho realizado, uma retrospectiva, e num prximo Sprint comea e a equipe escolhe outro requisito na lista do Product Backlog e o processo se inicia novamente. Kniberg (2007) afirma sobre a possibilidade da integrao do Scrum focado nas prticas de gerenciamento da organizao e do modelo de desenvolvimento XP que d mais ateno s tarefas de programao para que um complemente o outro. Onde as prticas que se apresentam como semelhantes - toda equipe, sentar juntos, estrias e Planning Game so utilizadas as premissas do framework Scrum, e prticas relativas a programao como programao em par a mtodo XP prevalecer. Na figura 2 possvel observar a sequncia que o framework sugere para o desenvolvimento dos trabalhos.

Figura 2 Fluxo do Framework Scrum.

2.5.4 O Modelo MSF - Microsoft Solutions Framework O modelo MSF (Microsoft Solutions Framework) foi criado pelo prpria Microsoft Consulting Services em 1994 atravs de uma anlise de como a Microsoft desenvolve seus

produtos. Ele designado para uso interno como tambm de seus clientes. No considerada como uma metodologia, mas sim como uma disciplina de boas prticas, ou seja, serve como um guia de boas prticas, mas no aprofunda-se em detalhes. Esta ausncia de detalhes do MSF pode parecer uma deficincia do modelo, porm com esta caracterstica, possvel uma fcil compreenso tanto por parte da equipe como do cliente, alm de ser flexvel. Esta flexibilidade pode oferecer suporte com uma ampla variao na execuo dos processos, assim, mantm um conjunto de princpios fundamentais e mentais. O modelo de processo MSF, consiste em sries curtas de ciclos de desenvolvimento e iteraes, e a cada iterao tem um foco diferente e o resultado estvel de um sistema global. O objetivo que cada membro da equipe deve interagir com os demais sempre que precisarem tomar decises, priorizar tarefas entre outros. O MSF possui oito princpios fundamentais, que representam a espinha dorsal para os outros modelos e disciplinas do MSF, sendo eles: 1. Capacitar membros da equipe: 2. Comunicao aberta: A informao deve estar prontamente compartilhada e disponvel para todos os membros da equipe. 3. Estabelecer uma responsabilidade clara e compartilhada: Deve-se assegurar que todos os membros da equipe esto de acordo como o que est sendo construdo e que cada membro esteja ciente da sua responsabilidade no projeto. 4. Adaptar-se as mudanas e ser gil: 5. Trabalhar a favor de uma viso compartilhada: 6. Investir na qualidade: 7. Aprender com as experincias: 8. Concentrar-se no negcio: Estes princpios so universais e podem ser aplicados ao RUP, XP, SCRUM ou qualquer outro modelo. O modelo MSF, possui tambm em sua estrutura o modelo de equipe e modelo de processo. O modelo de equipe descreve a estrutura de responsabilidade e papis de cada membro da equipe de que forma como a equipe deve agir e se relacionar. O modelo de processo descreve os processos e mtodos a serem realizados pela equipe do projeto para planejar, desenvolver e implantar.

3 Modelo Proposto - XYZ O modelo XYZ, sugerido pela equipe, um processo de engenharia de software baseado nas melhoras prticas dos modelos estudados, XP, Scrum e RUP e ainda referncias de gerencia projeto do Guia PMBOK, utilizando ainda como apoio os modelos Gaia Riscos e Gaia RH, e que busca atender as especificidades de um sistema ERP e aborda tanto os processos de desenvolvimento quanto de manuteno de software.

3.1 Caractersticas do Modelo: 3.1.2 Ciclos de Vida

3.2 Gerncia de Projetos - Alison Uma definio do termo projeto pode ser encontrada no Guia PMBOK Um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. (PMI, 2008). Em relao ao termo gerencia de projetos a definio O gerenciamento de projeto a aplicao de conhecimentos, habilidades , ferramentas e tcnicas s atividades do projeto a fim de atender seus requisitos. (PMI, 2008) O guia PMBOK sugere a gerncia de projetos atravs de aplicao e integrao de processos que esto dispostos em cinco grupos que so: Iniciao, planejamento, execuo, monitoramento e controle. O gerenciamento do projeto se d de forma iterativa devido as mudanas inerentes a seu prprio desenvolvimento, assim desejvel que a busca da melhoria continua ocorra durante o prprio ciclo de vida do projeto, e conforme se d sua evoluo o nvel de detalhes aumenta permitindo maior gerncia. Segundo Pressman (Pressman, 2006), para ter sucesso o Project team precisa estar organizado de forma que cada pessoa tenha suas caractersticas e habilidades maximizadas. Gerentes de sucesso focam na resoluo do problema em insistem na alta qualidade do produto. No modelo XYZ, os projetos tem um ciclo de vida de 30 dias, e ao final deste prazo gerado um novo incremento de software que disponibilizado ao cliente para testes e aceitao. Este perodo de tempo para os projetos foi estabelecido visando uma maior flexibilidade s mudanas, e permitindo um acompanhamento constante do cliente sobre o produto que est sendo desenvolvido. As atividades de planejamento da verso e acompanhamento/monitoramento do desenvolvimento so feitas pelo gerente de projetos.

Com base nos requisitos levantados pelos analistas de negcio, e de acordo com as prioridades estabelecidas que foram baseadas nas necessidades do cliente, o gerente de projetos organiza o trabalho a ser desenvolvido na prxima iterao, sempre considerando a quantidade horas disponveis por projeto e o nvel de maturidade da equipe. Aps o planejamento das atividades, as mesmas so distribudas aos membros da equipe de acordo com a experincia e nvel de conhecimento de cada um. Se durante o desenvolvimento de uma atividade um membro da equipe estiver com dvidas ou no possuir conhecimentos suficientes para conclu-la, cabe ao gerente fornecer o suporte necessrio, seja esclarecendo as dvidas, alocando um membro da equipe mais experiente para auxili-lo ou at mesmo realocando a atividade para outra pessoa e delegando ao mesmo uma tarefa mais simples. O gerente de projetos sempre procura manter uma margem de folga de aproximadamente 15% (quinze por cento) do total de horas alocadas para o projeto que sero destinadas alocao de atividades extras ou para suprir atrasos que possam surgir durante a iterao do projeto. Se durante o ciclo de um projeto surgirem novos requisitos ou mudana de requisitos existentes que ocasionem a necessidade de atividades evolutivas e/ou corretivas que no possa aguardar para serem alocadas no prximo projeto, e que exijam uma demanda de tempo maior do que o total de horas reservadas para atividades extras, o gerente de projetos ir avaliar se dentre as atividades que esto sendo desenvolvidas existem atividades que possam ser realocadas para o prximo projeto. Em ltimo caso, no havendo a possibilidade de realocao suficiente de atividades para dar lugar s novas atividades, o gerente de projetos tem autonomia para alocar mo-de-obra externa, buscando sempre entre os parceiros da empresa a mo-de-obra necessria. Ao trmino do projeto, so realizadas medies para avaliar o tempo gasto com anlises, desenvolvimento e testes. Tambm so calculadas as mtricas para mensurar a quantidade de atividades evolutivas, a quantidade de atividades corretivas originadas por erros dos projetos anteriores e a quantidade de atividades que acabaram sendo includas durante o decorrer do projeto.

Gerncia de Configurao - Alison Assegurar a integridade das configuraes de hardware e software requer o estabelecimento e a manuteno de um repositrio de configurao preciso e completo. Esse processo inclui a coleta inicial das informaes de configurao, o estabelecimento de um perfil bsico, a verificao e a auditoria das informaes de configurao e a atualizao do repositrio de configurao conforme necessrio. Um gerenciamento de configurao eficaz facilita uma maior disponibilidade do sistema, minimiza as questes de produo e soluciona problemas com maior rapidez (COBIT 4.1, 2007). Segundo Pressman (PRESSMAN, 2004), a Gerncia de Configurao o conjunto de atividades projetadas para controlar as mudanas pela identificao dos produtos do trabalho que sero alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o

gerenciamento de diferentes verses destes produtos, controlando as mudanas impostas, e auditando e relatando as mudanas realizadas. Podemos ento entender configurao como o estado em que um sistema se encontra em um determinado momento. Este sistema pode ser composto de todo tipo de elementos, como peas de hardware, artefatos eletrnicos ou no (i.e. documentos em papel), etc. A Configurao de Software trata apenas dos elementos que se encontram em formato eletrnico e fazem parte dessa configurao. Isso inclui todos os arquivos fontes, todos os documentos eletrnicos, modelos de banco de dados, scripts de banco de dados, as ferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as bibliotecas de software, etc. No modelo XYZ, os artefatos utilizados no projeto e os itens de software so versionados e suas modificaes so documentadas e controladas. A verso dos itens de configurao do projeto anterior utilizada como linha de base para o desenvolvimento do novo incremento. Um banco de dados de configuraes utilizado para registrar as informaes sobre as verses geradas do sistema, quais foram as mudanas (evolutivas ou corretivas) realizadas na verso (atividades de anlise ou desenvolvimento - Gerncia de Projetos), quais os requisitos do sistema de cada verso e quais so os clientes do sistema e as respectivas verses que cada um utiliza. Para o controle dos itens de configurao, utilizado o sistema de controle de verses denominado Subversion (SVN), que tem a finalidade de gerenciar diferentes verses dos itens de configurao. O SVN trabalha com o sistema de repositrio central onde os itens de configurao e suas verses ficam armazenados, e cada desenvolvedor ou analista possui uma cpia de cada item de configurao na sua estao de trabalho. Ao final das alteraes do item de configurao a pessoa responsvel, utilizando a interface grfica do SVN que fica instalado em cada estao de trabalho, faz a atualizao do repositrio central aplicando as modificaes realizadas. Nesse momento, o responsvel pela modificao descreve um histrico das alteraes que foram realizadas e referencia o nmero da atividade (tarefa). Este histrico ficar registrado na verso gravada do item de configurao e servir para referncias futuras. Como uma forma de facilitar o controle dos itens de configurao e identificar quais os itens e quais verses fazem parte da verso gerada, ao final iterao, ou seja, no momento da gerao da release, todos os itens que compuseram a verso so marcados com uma tag (identificador) cuja descrio o prprio nmero da verso de software gerada. Para ajudar a medir o impacto que uma modificao de um item de configurao pode ter no sistema, no incio de cada item so registrados quais outros itens do sitema tem relao com o item que est sendo alterado. Antes de proceder com as modificaes, o responsvel deve analisar todos os itens e verificar como eles sero afetados com a modificao. Desta forma, possvel avaliar por exemplo quantos itens de configurao, considerando telas e relatrios do sistema, a incluso de um atributo novo no cadastro de produtos poder afetar. O conjunto de itens de configurao utilizado na verso concluda sempre servir de linha de base para a verso futura, e assim sucessivamente. Essa configurao varia com o tempo, pois novos arquivos so includos, e arquivos existentes so alterados ou removidos. O objetivo da Gerncia de Configurao como um todo

organizar todos estes elementos de forma a saber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento (por exemplo, quando o sistema foi entregue ao cliente, quando o sistema passou por uma mudana de verso, quando o sistema foi enviado para auditoria, etc). A Gerncia de Configurao como um todo trata dos elementos, incluindo hardware, necessrios para a manuteno apropriada do sistema. a Gesto de Configurao de Software trata especificamente dos elementos necessrios a construo de sistemas de software, e em geral, controla apenas os elementos em formato computadorizado. Gerncia de Requisitos - Requisitos do software e de ambiente Alexandre Segundo Pressman (2006), a gerncia de requisitos um conjunto de atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificaes de requisitos em qualquer poca, medida que o projeto prossegue. A gerncia de requisitos tem como principal objetivo identificar e registrar as necessidades que o produto de software ter que atender, alm de orientar a avaliao de impactos destas mudanas nos planos do projeto. O processo de gerenciamento de requisitos surgiu da constatao que as mudanas ocorrem durante o processo de desenvolvimento de produtos. Estas mudanas so geradas por alteraes de legislao, de objetivos de negcio, ou mesmo de um melhor entendimento das potencialidades oferecidas pelos sistemas de informaes. Na maioria das vezes, tais mudanas implicam em renegociao de prazo, custo e de esforo para o projeto. Para que exista um gerenciamento de requisitos necessrio aps a avaliao de impacto que as mudanas sejam documentadas, ou seja, os requisitos existentes podero ser alterados e/ou includos novos. Dependendo da modificao dos requisitos necessrio que os mesmos sejam novamente aprovados pelo cliente. Alm dos requisitos, dever ser aprovado e renegociado, quando for o caso, o plano de desenvolvimento, planejamento do projeto e compromissos assumidos). O modelo XYZ tratar a gerencia de requisitos em algumas etapas a seguir: levantamento de requisitos, registro e catalogao, classificao de requisitos, avaliao de impactos, eaprovao de mudanas junto ao usurio. Quando tratar-se de um requisito j existente, e que necessite de alterao, o processo passar pelas etapas: identificao de mudanas e documentao de mudanas. Aps essas duas etapas o requisito entra no processo normal de gerenciamento, seguindo para etapa de classificao, e as outras subsequentes. A etapa de classificao vai identificar se o requisito funcional ou no funcional. Caso o requisito for no funcional, o mesmo ser direcionado gerencia de projetos. Gerncia de RH (Alocacao de recursos) Utiliza o modelo Gaia RH.

Gerncia de Riscos Utiliza o modelo Gaia Riscos. Gerncia de Comunicao (Treinamento, Interao com o usurio) - Marcelo Para o desenvolvimento de um software necessria uma comunicao entre pessoas, que podem ou no estar fisicamente juntas, esta comunicao pode ser falha, deixando essas informaes comprometidas, sendo em equipes distribudas ou locais. de suma importncia que existe a comunicao entre as equipes, pois vrios problemas que envolvem esforos mtuos dos participantes podem ser solucionados de forma integra. A grande maioria dos projetos, tem como maior parte o planejamento das comunicaes, onde da-se nas fases iniciais do projeto, no entendo, os resultados desses processos de planejamento so reexaminados regularmente durante todo o projeto e revisado conforme a necessidade, ou melhoria continua. De acordo com o Guia do PMBOK (PMI, 2008), a comunicao uma rea de conhecimento e possui seus processos independentes das outras reas, esses so divididos em cinco processos: Identificar as partes interessadas: Definir quem so as partes que faro parte da comunicao para o sucesso do projeto; Planejar as comunicaes: identificar as necessidades e definir as ferramentas de comunicao bem como sua periodicidade; Distribuir as informaes: Seguir e executar o que foi planejado disponibilizando as informaes aos interessados; Gerenciar as expectativas: Reportar o desempenho: Informar o desempenho e andamento das atividades desenvolvidas, bem como previses e medies. Segundo Fleury (1996) diz que a comunicao constitui um dos elementos essenciais no processo de criao, transmisso e cristalizao do universo simblico de uma organizao. O Modelo XYZ ter o seu projeto de comunicao baseado em uma ferramenta web, onde cada membro da equipe envolvida no projeto ter acesso a patir de um login e senha; onde essa administrao ficar a cargo do Gerente de Projetos. Para aumentar a comunicao entre os membros da equipe de projetos e os interessados, ser liberado de acordo com o nvel do usurio, aplicativos de mensagens instantneas e e-mail. Ser possvel agendar reunies, especificando data e horrio, sendo os usurios informados automaticamente por e-mail, sobre solicitaes e mudanas envolvendo o projeto. Artefatos Documentos de anlise, modelo de dados, registro de reunies, registro de solicitaes do cliente, fluxos para os processos mais complexos.

Melhoria Continua Software (Itil, Cobit) - Alison "Se voc no sabe para onde quer ir, qualquer caminho voc pode seguir. Se no sabe aonde esta, um mapa no vai te ajudar". - (Roger Pressman). No se pode gerenciar o que voc no pode controlar, no se pode controlar o que no se pode medir, No se pode medir o que no se pode definir [ITIL, 2007]. O Itil [ITIL, 2007] define o modelo de melhoria continua de servios baseada em cinco questes, sendo elas: Qual a viso (Viso, metas, objetivos e misso da empresa)? Onde estamos agora (Avaliao/levantamento para definir a baseline inicial? Onde queremos estar (Definio de objetivos mensurveis)? Como chegaremos l (Melhoria de processos e servios)? Chegaremos l (Mensurao e mtricas)? O modelo XYZ trabalha o processo de melhoria contnua aplicada aos processos de anlise e desenvolvimento de software, e as mtricas so definidas com a finalidade de classificar e quantificar os problemas encontrados durante a fase de testes e aps a entrega do incremento de software ao cliente. Para a aplicao do processo de melhoria contnua, o modelo XYZ faz uso do Ciclo PDCA, que um mtodo gerencial subdividido em quatro partes e que reflete a base da filosofia do melhoramento contnuo. Em conjunto com o ciclo PDCA, o modelo tambm faz uso do Balanced Scorecard, que um modelo de gesto estratgica apoiado em indicadores de desempenho e que auxilia na mensurao do progresso das organizaes rumo suas metas de longo prazo [Kaplan e Norton, 1997]. Para auxiliar na identificao dos indicadores, o modelo XYZ utiliza ainda como metodologia de apoio o sistema 5W2H. Como um dos pontos mais importantes para o sucesso do processo na organizao o engajamento da equipe de trabalho, o primeiro passo do modelo XYZ no processo de melhoria contnua a conscientizao dos colaboradores, o incentivo e a recompensa para que identifiquem e solucionem problemas, e o encorajamento para realizar novas aes diminuindo assim o medo da falha e estimulando o indivduo a melhorar cada vez mais. O processo em si se inicia com a identificao da viso, da misso, das metas e dos objetivos da empresa, essenciais para o direcionamento das aes de melhoria. Como ferramenta de apoio para auxiliar a identificao e visualizao desses dados, nesta fase o modelo sugere a utilizao da matriz SWOT. Em seguida, dando afirmao citao de Pressman de que Se no sabe aonde esta, um mapa no vai te ajudar", deve ser feito uma anlise com a finalidade de estabelecer a baseline inicial. As baselines tambm servem para identificar se determinado servio ou processo necessita ser melhorado [ITIL, 2007]. Se refletirmos sobre o conceito de melhoria contnua, todos os processos podem e devem ser melhorados, mas necessrio estabelecer prioridades para que no seja criado um cenrio muito grande que pode tornar impraticvel e/ou desestimulante a aplicao da melhoria contnua. Com os objetivos e baselines estabelecidos, o prximo passo identificar os principais pontos que precisam ser melhorados, identificar os indicadores e estabelecer as mtricas que sero utilizadas. O BSC sugere que sejam utilizados de 20 a 25 indicadores, distribudos entre as

perspectivas Financeira, Cliente, Processos internos e Aprendizado e crescimento. Como o foco do processo de melhoria do modelo XYZ so as fases de anlise e desenvolvimento, o modelo sugere como ponto de partida os seguintes indicadores: Financeira: - Custo/hora desenvolvedor - Custo/hora analistas - Custo/hora reunies com clientes para levantamento de requisitos. - Custo mdio de cada tarefa desenvolvida. - Custo mdio da hora em tarefas de retrabalho. Cliente: - Quantidade de reclamaes - Dvidas encontradas aps a atualizao do sistema - Atividades realizadas no prazo combinado - Nvel de satisfao com o incremento/produto. - Quantidade de alteraes de requisitos. Processos internos: - Quantidade de atividades realizadas por iterao. - Quantidade de horas gastas com levantamento de requisitos. - Quantidade de horas gastas com anlise. - Quantidade de horas gastas com desenvolvimento. - Tempo mdio de das atividades de desenvolvimento. - Quantidade de erros novos. - Quantidade de atividades de retrabalho por erros - Quantidade de atividades de retrabalho por mudana de requisitos. Aprendizado e crescimento: - Nvel de conhecimento do produto de software; - Nivel de conhecimento das ferramentas; - Nvel de interesse na melhoria profissional (Cursos externos realizados, assuntos estudados); Ao final da iterao, deve ser feita a anlise das mtricas e avaliar se os esforos realizados no processo de melhoria esto sendo empregados corretamente e verificar se os objetivos traados esto sendo alcanados. Com base nos resultados obtidos atravs da anlise das mtricas, devem ser identificados os pontos-fracos do processo e realizar os devidos ajustes para que estejam alinhados com os objetivos traados, iniciando assim um novo ciclo PDCA. Controle de Testes Registro dos testes feitos pelo desenvolvedor, testador e de aceitao do cliente. Utilizao de ferramenta TestComplete para testes de caixa-preta para as regras mais complexas. Processo Iterativo e incremental Incremental: utiliza perodos de 30 dias para o desenvolvimento de incrementos do software. Iterativo: O ciclo recomea aps a entrega de cada incremento. Caracteristicas Especficas do Sistema ERP

Versionamento Para cada incremento criado, criada uma baseline de todos os itens que compem o projeto e de seus requisitos e um novo cdigo de verso atribudo ao produto de software. Implantao Existe um processo padro com os procedimentos necessrios para a implantao de um novo incremento do software. Sistema em Estrutura Modular No controla especificamente mdulos do sistema, mas sim incrementos de software. Documentao das Funcionalidades do Sistemas (parmetros do sistema) A descrio das funcionalidades feita no Help do sistema. Customizao / Flexibilizao / Adaptabilidade / Integrao No diretamente. As mudanas e/ou adaptaes necessrias so avaliadas pelo Gerente de Projeto juntamente com o cliente (qdo necessrio) e programadas para os prximos incrementos conforme sua necessidade e urgncia. Acordo de Nivel de Servio (SLA) - Moiss possvel definir o Acordo de Nvel de Servio (ou SLA, acrnimo de Service Level Agreement) como a parte de contrato de servios entre duas ou mais entidades em que as regras de execuo dos servios so definidas de maneira formal. Um acordo de nvel de servio um instrumento para a gesto das expectativas do cliente. Sua meta definir uma estrutura para a gesto da qualidade e quantidade dos servios entregues e, por conseguinte, atender demanda dos clientes a partir de um entendimento claro do conjunto de compromissos. (Gomes et al, 2005). De acordo com Gonalves (2007) Esse instrumento, que serve como uma ferramenta de comunicao e de preveno de conflitos, um documento dinmico (deve ser sempre actualizado para reviso do acordo, adequao dos servios e negociao de ajustes no acordo) e a base para garantir que ambas as partes usem os mesmos critrios para avaliar a qualidade do servio. O modelo XYZ

So estipulados os horrios de atendimento, pagamento de honorrios, responsabilidades do cliente e fornecedor, prazo do projeto, etc... Gerenciamento de Mudana Alison Mudanas so um fato da vida para sistemas grandes de softwares. Suas necessidades e requisitos organizacionais alteram-se durante a vida til de um sistema. Para garantir que essas mudanas sero aplicadas ao sistema de maneira controlada, necessrio um conjunto de procedimentos de gerenciamento de mudanas apoiado por ferramentas (Sommerville, 2007).

O objetivo do processo de gerenciamento de mudanas certificar de que as mudanas sero registradas e avaliadas, autorizadas, priorizadas, planejadas, testadas, implementadas, documentadas e revisadas de maneira controlada [ITIL, 2007]. Para um bom controle de mudanas, todas as mudanas devem ser avaliadas, passarem pela anlise de impacto, serem aprovadas, planejadas, e devem ter seus detalhes registrados na documentao de gerenciamento de mudanas. No caso de mudanas emergenciais, as mesmas podero ser documentadas retrospectivamente, ou seja, aps j terem sido realizadas. Mudanas simples que a primeira vista parecem inofensivas podem causar danos ao software e consequentemente ao negcio do cliente infinitas vezes maior do que a sua complexidade [ITIL, 2007], por isso, de suma importncia que todas as solicitaes de mudanas passem por uma anlise detalhada de impacto e que seja estabelecido tolerncia zero para mudanas no autorizadas. O modelo XYZ sugere a criao do CAB (Change Advisory Board), ou Conselho para avaliao de mudanas, composto de duas ou mais pessoas que possuam conhecimento do sistema e do negcio do cliente para estarem avaliando e aprovando as solicitaes de mudanas. papel do CAB avaliar o risco da mudana para o negcio, avaliar seu impacto, levantar quais os recursos necessrios para a mudana, gerenciar o cronograma das mudanas solicitadas, coordenar a implementao e revisar e avaliar se a mudana foi implementada corretamente. Para auxiliar na avaliao e aprovao das mudanas, o modelo XYZ recomenda que o CAB utilize os 7 Rs [ITIL, 2007]: - Quem solicitou? (Who RAISED the change?) - Qual a razo? (What is the REASON for the change?) - Qual o retorno esperado? (What is the RETURN required from the change?) - Quais os riscos (What are the RISKS involved in the change?) - Quais os recursos necessrios (What RESOURCES are required to deliver the change?) - Quem sero os responsvels pelo desenvolvimento, testes e implementao? (Who is RESPONSIBLE for the build, test and implementation of the change?) - Qual o relacionamento desta mudana com outras j solicitadas? (What is the RELATIONSHIP between this change and other changes?) O modelo XYZ recomenda que todas as reunies realizadas pelo CAB, tanto para aprovao de mudanas quanto para reviso das prioridades, sejam registradas em atas. O registro dessas aes evitar que assuntos no concludos caiam no esquecimento e ajudar a fortalecer o compromentimento dos membros do CAB no processo de gerenciamento de mudanas. Para o registro e controle de mudanas, o modelo XYZ sugere a utilizao dos RFCs (formulrio para solicitao de mudanas), a criao de um cronograma de mudanas programadas, e a utilizao do CMDB (Configuration Management Data Base) uma vez que o Gerenciamento de Mudanas trabalha em conjunto com o Gerenciamento de Configurao. Se possvel, os RFCs e o cronograma devem estar em formato eletrnico, preferenciamente utilizando uma ferramenta de apoio. Antes de registrar uma nova solicitao de mudanas, deve-se fazer uma consulta s solicitaes que j encontram-se registradas para evitar redundncias, e tambm realizar uma anlise para certificar-se de que a solicitao procede e de que no se trata apenas de um engano. Todas as mudanas registradas devem ter um nvel de prioridade definido. A prioridade da mudana ir depender de seu risco para o sistema e de sua urgncia. O CAB necessitar de informaes sobre as consequncias que a mudana pode trazer ao negcio para poder avaliar efetivamente o risco da implementao ou para rejeitar a mudana.

O modelo XYZ utiliza uma escala que vai de 1 5 para classificar a prioridade da solicitao de mudanas, sendo 1 para muito baixa e 5 para mudanas de necessidade imediata (urgentes). Abaixo segue a tabela de prioridades utilizada pelo modelo. Prioridade Caracterstica 5 Erros graves no sistema ou a necessidade de incluso/modificao em curtssimoprazo de funcionalidades que afetam a regra de negcio, normalmente originados por erros de entendimento da regra de negcio ou por falhas no planejamento. Mudanas necessrias para atender alteraes na legislao ou para atender alteraes nas regras de negcio do cliente, como por exemplo uma nova poltica de vendas ou surgimento de uma nova obrigao fiscal. Solicitaes que no afetam a regra de negcio, mas que no podem aguardar at a prxima release, como por exemplo pequenos erros no sistema que dificultam a operao do sistema. Solicitaes que no afetam a regra de negcio, mas que dificultam a operao do sistema. Podem aguardar at a prxima release, como por exemplo a melhoria em telas e leiautes e a criao de novos relatrios. A necessidade de mudana existe, mas no afeta as regras de negcio e nem a utilizao do sistema. Se enquadram nesse nvel melhorias na usabilidade e/ou incluso de novas facilidades.
Tabela 1: Prioridades de mudanas utilizada pelo modelo XYZ.

O modelo XYZ recomenda que, no incio do planejamento da nova iterao ou a cada nova solicitao de mudana criada, o cronograma de mudanas planejadas seja revisado, confirmando se no houveram alteraes nas prioridades estabelecidas e se os prazos esto sendo cumpridos, pois uma falha no planejamento das mudanas pode colocar em risco o negcio do cliente ou at mesmo tornar o software obsoleto. Durante o processo de implementao, o processo de Gerenciamento de Mudana tem a responsabilidade de assegurar que as mudanas sejam implementadas conforme sua programao. Neste ponto o processo de Gerenciamento de Mudana realiza apenas a atividade de coordenao, uma vez a execuo das atividades de responsabilidade dos setores competentes. Ao trmino do processo de implementao, o processo de Gerenciamento de Mudana deve realizar uma reviso com a finalidade de avaliar se a mudana atingiu seus objetivos, que as partes interessadas esto satisfeitas e de que no existe nenhum efeito colateral. Um gerenciamento de mudanas eficaz proporcionar para a empresa benefcios como: - Melhor alinhamento dos servios de TI com os requisitos do negcio; - Estimativa de risco melhorada; - Reduo do impacto da mudana, causando uma maior satisfao do cliente; - Aumento da produtividade atravs do direcionamento correto das atividades. - Reduo do tempo mdio para realizao de mudanas. - Reduo de mudanas originadas de mudanas anteriores mal-elaboradas.

Referncias Carvalho, R. A, Johansson, Bjorn, Manhaes, R. S. Mapping Agile Methods to ERP: Directions and Limitations. Disponvel em http://3gerp.iwvi.unikoblenz.de/docs/Carvalho_Johansson_Soares_CONFENIS_2009_paper.pdf. Acesso em 07/05/2012 Meireles, M., Sordi, J. O. (2010) Administrao de Sistemas de Informao, Saraiva Schach, S. R. (2009) Engenharia de Software: Os Paradigmas Clssico & Orientado a Objetos, McGrawHill. King, Mervyn J. - Bank & brokerage back office procedures & settlements. Chicago: Amacom, 2000. ISBN 978-0-8144-0534-5 Haberkorn, Ernesto. Gesto Empresarial com ERP - 3 Edio. So Paulo: 2006. ISBN 85903951-1-1 Kniberg, Henrik - Scrum e Xp direto das Trincheiras - C4Media: 2007. ISBN 978-1-4303-22641 Kruchten, Phillippe. (2003), Introduo ao RUP: Rational Unified Process, Primeira Edio, Cincia Moderna. Mendes, Juliana Veiga; Filho, Edmundo Escrivo. Sistemas Integrados de Gesto (ERP) em Pequenas e Mdias Empresas: Um Confronto entre a Teoria e a Prtica Empresarial. So Paulo: Atlas, 2003. Beck, Kent. Extreme Programming Explained - Primeira edio, 1999. ISBN 0-201-61641-6. Beck, Kent. Extreme Programming Explained - Segunda edio, 2004. ISBN 0-321-27865-8. Gomes, Silvia Boga; Falbo, Ricardo de Almeida; Menezes, Credin Silva de. Um Modelo para Acordo de Nvel de Servio em TI - Mestrado em Informtica - UFES, 2005. Disponvel em: http://www.inf.ufes.br/~falbo/download/pub/2005-Sbqs.pdf Gonalves, Diogo Nesbitt. IT Governance Alignment of SLA contracts with objectives of the Organizations. IST - Universidade Tcnica de Lisboa, 2007. XP. Extreme Programming. Disponvel em: http://improveit.com.br/xp XP. Extreme Programming. Disponvel em: http://epf.eclipse.org/wikis/xppt/index.htm XP. Extreme Programming. Disponvel em: http://www.extremeprogramming.org/ Jeffries, Ron. Extreme Programming Adventures in C#, 2004. ISBN 0-735-61949-2.

Sutherland, Jefff and Schwaber, Ken. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework - Draft 29 Jan 2011, Paris. Pressman, Roger. Software Engineering: A Practitioner's Approach - sexta edio, 2004. ISBN 0-073-01933-X . Sommerville, Ian. Engenharia de Software - 8 edio, 2007. ISBN 9788588639287. Fleury, Maria Tereza Leme et al. Cultura e poder nas organizaes. So Paulo: Atlas, 1996, p.24. Pressman, Roger. Engenharia de Software. 6. ed. So Paulo: McGraw-Hill, 2006. PMI - Project Management Institute - Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) - Quarta Edio, 2008. Kaplan e Norton. Estraggia em Ao: Balanced Scorecard. 13 edio, 1997. ISBN 8535201491.

-=--=-=- Anotaes do Desenvolvimento -=-=O uso de ERP em hospitais http://www.fernandozaidan.com.br/docs/Avaliacao%20da%20Implantacao%20de%20ERP.pdf O uso de ERP em organizaes no governamentais http://www3.iesam-pa.edu.br/ojs/index.php/sistemas/article/viewFile/503/403 -Gesto de defeitos caberia aqui? http://www.devmedia.com.br/Gestao-de-Defeitos-no-Teste-de-Software.html/21940 http://asespecialistas.blog.com/2011/08/17/metrics/ http://www.devmedia.com.br/artigo-engenharia-de-software-gestao-de-defeitos/8036 Citar balanced score card? Quais os tpicos de melhoria contnua? Link ITIL: http://www.scribd.com/doc/50809607/10/Livros-da-biblioteca-ITIL-v3#page=171 3 Continual Service Improvement principles - pg 47. Service improvement must focus on increasing the efficiency, maximizing the effectiveness and optimizing the cost of services and the underlying ITSM processes. The only way to do this is to ensure that improvement opportunities are identified throughout the entire service lifecycle. O uso de mtricas no processo de software prov indicaes de estratgias para melhorias e adaptaes no fluxo de trabalho e nas atividades Gerenciamento de Mudana - Alison D:\...\Mestrado\Gesto de Configurao\Sommerville - sobre Gerencia Configuracao.doc D:\...\Mestrado\Aulas\Governana\Material\apostila-itil-v3-3.pdf Cobit-4_1: AI6 Gerenciar Mudanas