Uma Estratégia para Substituição de Sistemas Legados

Tamanho: px
Começar a partir da página:

Download "Uma Estratégia para Substituição de Sistemas Legados"

Transcrição

1 Uma Estratégia para Substituição de Sistemas Legados Danuza Ferreira S. Neiva¹, Ecivaldo de Souza Matos² ¹ Departamento de Ciência da Computação Universidade Federal da Bahia, Salvador, BA-Brasil ² Departamento de Sistemas e Computação Universidade Federal de Campina Grande, Campina Grande, PB Brasil {danuzaneiva,ecivaldo}@gmail.com Abstract. Legacy systems are critical and old applications, characterized for a deficient structure and having suffered many updates. A solution is their substitution, but it involves some aspects of risks as cost, time and change of paradigm. This critical scene almost always is a consequence of the Software Engineering practices adopted, demanding more care with the reengineering of all the business processes and with the software development. Moreover, this article presents a strategy for the substitution of legacy systems, using agile practical and changes management and the knowledge management. It s the result of a work of conclusion of graduation course in Computer Science in the Federal University of Bahia. Resumo. Sistemas legados são aplicações críticas e antigas, caracterizadas por uma deficiente estrutura e por terem sofrido muitas atualizações. Substituí-los é uma solução normalmente adotada, mas envolve vários aspectos de riscos como custo, tempo e mudança de paradigma. Este cenário crítico, na maioria das vezes, é conseqüência das práticas de Engenharia de Software adotadas, exigindo cada vez mais cuidados com a reengenharia de todos os processos de negócio e com o desenvolvimento do produto de software. Diante disto, este artigo apresenta uma estratégia para a substituição de sistemas legados, utilizando práticas ágeis e gerenciamento de mudanças e do conhecimento, resultado de um trabalho de conclusão de curso de graduação em Ciência da Computação na UFBA. Palavras-chave: Engenharia de Software, sistemas legados, metodologias ágeis. 1. Introdução As empresas tendem a investir cada vez mais em tecnologia no planejamento, execução e avaliação de seus processos, esperando obter um retorno prolongado dos seus investimentos. Segundo Ian Sommerville (Sommerville 2003), o tempo de vida útil dos sistemas computacionais é muito variável, muitos sistemas de grande porte permanecem em uso por mais de dez anos. Muitos destes sistemas 1 são conhecidos como sistemas legados. Um sistema legado é um software antigo, crítico para o negócio, desenvolvido há alguns anos e que 1 O termo sistema é utilizado nesse artigo como sinônimo de software.

2 incorporou um grande número de alterações nas suas rotinas, freqüentemente com documentação desatualizada ou inexistente, sofrendo manutenção por vários anos. Portanto, é um software de fundamental importância para a regularidade dos processos da organização. Com efeito, por se tratar de uma aplicação crítica, qualquer falha pode refletir em sérios impactos nos negócios, conseqüentemente, o risco envolvido na substituição desse tipo de sistema é alto, o que leva a organização geralmente a optar por sua manutenção e não pela substituição. Contudo, quando o processo de substituição de sistemas legados trata de uma solução necessária, os seus aspectos de riscos devem ser analisados com cautela, como o custo, o tempo necessário para substituição, a mudança de paradigma na organização e o todo o impacto operacional causado pela implantação do novo sistema. O seu cenário crítico, na maioria das vezes, é conseqüência das práticas de engenharia de software adotadas, exigindo cada vez mais cuidados com a reengenharia dos processos de negócio, já que estes podem levar a mudanças na rotina organizacional, afetando inclusive a cultura organizacional. Temas correlatos são estudados pela disciplina de Engenharia de Requisitos, sendo notada uma carência de técnicas específicas para tratar as peculiaridades de um processo de substituição de sistemas legados, que envolve análise de requisitos, análise de riscos e custos das mudanças, além da administração de conflitos gerados com a mudança de paradigma. Neste contexto, este artigo apresenta uma estratégia específica para a substituição de sistemas legados baseada nas diversas metodologias e abordagens já tratadas na literatura da área, minimizando os problemas operacionais decorrentes da mudança e, conseqüentemente os seus riscos e custos. 2. Soluções para Sistemas Legados Estudos na área de sistemas legados têm identificado importantes problemas nos processos usuais de manutenção desse tipo de software. Segundo Ian Sommerville (Sommerville 2003), as dificuldades encontradas para manutenção de sistemas legados são conseqüências da falta de padronização na implementação de código, uso de linguagem obsoleta, documentação inadequada ou desatualizada, código-fonte de difícil compreensão, dados duplicados ou desatualizados, inexatos ou incompletos. A importância do sistema legado para a organização e a necessidade de mantê-lo em operação têm incentivado pesquisas na busca de soluções otimizadas para sua evolução. Tais soluções buscam prioritariamente evitar custos excessivos e manter o software em operação para continuar prestando os serviços corporativos essenciais. De acordo com Jesús Bisbal (Bisbal 1999), estas soluções são divididas geralmente em três categorias: Redesenvolver: reconstrução do sistema legado usando novo hardware e modernas arquiteturas, ferramentas e banco de dados. Ao final do processo de redesenvolvimento, a organização pode se encontrar com um sistema reconstruído baseado em uma tecnologia obsoleta.

3 Envolver: Consiste no reaproveitamento do que já existe, realizando melhorias, modificações de componentes e melhoria de interface. Migrar: converte um sistema existente para uma plataforma nova, retendo as funcionalidades do sistema legado e causando pouco rompimento no ambiente operacional e de negócio já existentes. Logo, pode-se observar que envolver é a estratégia que menos causa impacto no sistema legado, contudo depende da arquitetura desse sistema, que geralmente não é modularizada. O redesenvolver conduz a maioria das mudanças, porém é uma escolha de risco para a maioria das organizações. Dessa forma, a migração é uma solução intermediária entre envolver e redesenvolver, inclusive considerada mais amigável. Contudo, a estratégia a ser adotada depende da situação do sistema legado. Se as funcionalidades do sistema legado não atendem às necessidades da empresa e existem novas rotinas a serem envolvidas no sistema, um redesenvolvimento é o mais indicado. 3. Metodologias Ágeis O ambiente de desenvolvimento do software substituto do sistema legado é caracterizado por requisitos instáveis e desconhecidos. Na maioria dos sistemas legados existe um abismo entre a descrição documentada e as funcionalidades implementadas e realidade atual (Adolph 1996). A sua alta influência nos negócios da organização torna o processo de substituição arriscado, desejando-se um curto tempo de resposta. Diante deste cenário, a análise das metodologias vigentes é de grande relevância para a construção de uma estratégia para atender as necessidades desta substituição. As metodologias clássicas da Engenharia de Software tendem a tratar de uma mesma maneira os diferentes tipos de desenvolvimento de software. Consideram que na fase inicial de desenvolvimento de software os requisitos são previsíveis. Desta forma, o processo de desenvolvimento é prejudicado em ambientes em que as necessidades do cliente são instáveis ou não estão totalmente definidas. As metodologias em voga, em geral, são voltadas para grandes projetos e grandes equipes, com complexidade e burocracia aceitáveis e, às vezes, necessários para projetos desse nível. Os projetos de pequeno porte e com equipe reduzida podem ser orientados por metodologias mais simplificadas, que não causem tantos entraves para os pequenos times de desenvolvedores, com prazos cada vez mais curtos. Visualizando estes problemas, um grupo inicial de 17 pesquisadores, auto denominados de Aliança Ágil (Agile Alliance), iniciaram em 2001 uma discussão onde foi definido o Manifesto Ágil, cujo objetivo seria encorajar melhores meios de desenvolvimento de software, baseado nos seguintes valores (Manifest 2001): Indivíduos e interações valem mais que processos e ferramentas. Software funcionando vale mais do que documentação abrangente. Colaboração do cliente vale mais que a renegociação do contrato. Respostas rápidas a mudanças valem mais que seguir um plano. A prioridade que o Manifesto Ágil atribui a alguns valores não rejeita outras necessidades. Os processos e ferramentas, a documentação, a negociação de contratos

4 ou o planejamento são identificados como valores secundários em um processo de desenvolvimento de software. As metodologias que podem ser classificados como ágeis possuem em comum o fato de trabalharem em pequenos projetos, com requisitos instáveis, havendo priorização das pessoas e não dos processos, com relação constante com o cliente guiado pela fundamentação de que as pessoas devem trabalhar unidas e motivadas. Dentre as práticas e metodologias ágeis levantadas, foram analisadas e utilizadas neste trabalho as metodologias Scrum e Extreme Programming (XP). A Extreme Programming (XP) trata-se de uma metodologia de desenvolvimento de software que deve ser usada a todo tempo, e não em uma seqüência estática de procedimento (Beck 2000). É baseada nos valores de simplicidade, comunicação e feedback constante, reunindo toda a equipe sobre práticas simples, priorizando uma eficiente comunicação na equipe para que todos acompanhem e controlem o desenvolvimento. A Scrum é uma metodologia de gerência de projetos, orientada para flexibilidade, adaptabilidade e produtividade (Schwaber 1995). Com efeito, há foco nas pessoas, para que a equipe produza, de forma flexível, em um ambiente de constantes mudanças. Utiliza métodos ágeis, contudo, não adota explicitamente práticas de engenharia de software. Seu funcionamento consiste nas fases de planejamento, projeto arquitetural, desenvolvimento e encerramento. O desenvolvimento é realizado em ciclos iterativos, chamados de sprints, acompanhados de reuniões de revisão periódicas. A Scrum e a XP são complementares, pois Scrum provê práticas ágeis de gerenciamento, enquanto XP provê práticas integradas de engenharia de software. O fato de Scum e XP trabalharem com equipes pequenas possibilita um maior controle do gerenciamento de tarefas, propiciando uma maior produtividade. A escolha destas metodologias foi influenciada pelos seguintes fatores: - As metodologias Scrum e XP, consideram a imprevisibilidade, adotando práticas ágeis e flexíveis. O processo se adapta ao ambiente incorporando as inúmeras mudanças no decorrer do projeto. (Schwaber 1995; Soares 2004). - são amplamente conhecidas e cada vez mais utilizadas no desenvolvimento de software de pequeno e médio portes. (Wuestefeld 2001;Schwaber 1995); - possuem documentação suficiente para o aprofundamento dos estudos; 4. Estratégia para Substituição de Sistema Legado A Estratégia desenvolvida busca solucionar os problemas dos sistemas legados através da substituição de software, que pode ser um caso de migração ou redesenvolvimento, como visto na Seção 2. Fundamentada principalmente pelas práticas ágeis da Scrum, a Estratégia possui os seguintes elementos de controle no processo de desenvolvimento: Product BackLog: atividades definidas no planejamento para construir o produto final. É constituído de uma lista, que contém inicialmente as funcionalidades do sistema legado a serem implementadas. A cada iteração novos itens são incrementados, podendo ser requisitos ou atividades necessárias para o desenvolvimento. A lista pode ser composta por funcionalidades, manutenção corretiva, melhoramentos solicitados

5 pelo cliente, aprimoramento para uma maior competitividade do produto no mercado, atualizações de tecnologia, entre outros. À medida que os itens forem trabalhados serão excluídos do Product Backlog. A Figura 1 mostra as diversas origens do Product BackLog. Figura 1 - Origens que constituem o Product Backlog Sprint: é um conjunto de atividades de desenvolvimento conduzidas durante um período predefinido, usualmente de uma a quatro semanas. A fase de desenvolvido é composta por ciclos iterativos que implementam um conjunto de itens de backlog definidos no planejamento. Cada iteração corresponde a um sprint. Release: grupo de itens do backlog que serão trabalhados num conjunto de iterações. Ao fim desse conjunto de iterações tem-se uma versão estável do produto. A liberação dessa versão considera fatores como qualidade e necessidade do cliente. Contudo é importante identificar no processo de desenvolvimento a diferença entre release e versão. Considerando esses elementos fundamentais, o processo de substituição é dividido nas seguintes fases: a) Pré-desenvolvimento. b) Desenvolvimento. c) Pós-desenvolvimento. Tendo em vista o seu caráter evolucionário, o novo software é projetado para não repetir os erros identificados no sistema legado, evitando substituí-lo mais à frente por um outro software, por motivos similares ao da substituição atual Pré-desenvolvimento O pré-desenvolvimento é dividido nas etapas de Reengenharia e Planejamento, descritas a seguir Reengenharia Normalmente, a equipe que desenvolverá o novo sistema não é a mesma equipe que desenvolveu o sistema legado. Dessa forma, é necessária reengenharia dos processos envolvidos no software legado e uma integração do usuário/cliente na concepção do novo projeto.

6 Esta etapa foi fundamentada no trabalho realizado por Luciana Paiva e Victor Santander (Paiva e Santander 2004), sendo observada a relação da documentação do sistema legado com a sua reengenharia. Desta forma, as seguintes situações foram observadas: documentação inexistente: o sistema legado não possui nenhuma documentação. documentação desatualizada: situação comum tratando-se de sistemas legados, principalmente quando houve mudanças de membros de equipe de desenvolvimento. documentação atualizada: essa situação é a mais adequada, pois torna o processo ágil. Tem-se uma base de conhecimento consistente do sistema, facilitando a organização e captura dos requisitos. As situações da documentação do sistema legado com suas respectivas práticas para reengenharia dos processos do sistema legado podem ser visualizadas no quadro a seguir. Documentação Inexistente 1- Conhecer o funcionamento do sistema legado (E/S). 2- Analisar código fonte. 3- Entrevistar equipe / atores do sistema legado. 4- Documentar as informações levantadas. Práticas da Reengenharia Documentação Desatualizada 1- Conhecer o funcionamento do sistema legado (E/S). 2- Analisar código fonte. 3- Entrevistar equipe / atores do sistema legado. 4- Comparar a documentação existente com a análise efetuada, e atualizá-la. Documentação Atualizada 1- Conhecer o funcionamento do sistema legado (E/S). Quadro 1 - Resumo das práticas adotadas para a reengenharia do sistema legado. Para conhecer o funcionamento do sistema legado é necessário identificar principalmente os relatórios e consultas visuais. Independente da situação da documentação do sistema é importante que a equipe conheça o ambiente de aplicação, e que o analista tenha domínio com o negócio da organização. Esse conhecimento é necessário principalmente para análise dos riscos envolvidos nas mudanças de requisitos Planejamento Nesta etapa, é muito importante a realização de uma análise do histórico de projetos já realizados, caso exista. A seguir, são apresentadas as práticas e diretrizes que direcionam o planejamento. Seleção de Requisitos. Corresponde à definição dos requisitos do cliente que serão trabalhados no projeto. Esta seleção deve ser seguida pelas seguintes atividades:

7 a) Entender as informações levantadas: analisar os requisitos do sistema legado quanto ao grau de estabilidade, risco e influência nas atividades da organização, considerando as necessidades apontadas pelos stakeholders. b) Selecionar os requisitos funcionais: cabe ao cliente decidir quais os requisitos identificados serão mantidos, descartados ou melhorados, e definir novas funcionalidades para o sistema. c) Identificar os requisitos não funcionais: o cliente deve definir as restrições do sistema, suas necessidades de segurança, navegabilidade, dentre outros. Análise e Projeto. Nessa etapa é essencial adotar soluções simplificadas e eficientes. Para isso são apresentadas as seguintes diretrizes: a) Análise Orientada a Objetos: é indicado que seja realizada uma análise orientada a objetos, modelada em caso de uso. b) Projeto orientado a objetos: novos requisitos podem surgir neste momento, são os requisitos originados do projeto, que surgem a partir dos requisitos do cliente, para atender o desenvolvimento do projeto. c) Projeto Arquitetural: o projeto de arquitetura envolve a identificação dos principais componentes do sistema e das interconexões entre esses componentes. As decisões de um projeto de arquitetura têm um profundo efeito sobre a capacidade do sistema em implementar requisitos importantes como desempenho, confiabilidade e facilidade de manutenção. d) Projeto do banco de dados: essa estrutura será modificada também nos sprints, quando ocorre a revisão das classes e de seus atributos. A definição do projeto de banco de dados deve levar em consideração os dados do sistema legado que serão migrados. O banco precisa ser preparado para receber os dados do sistema legado. e) Projeto de Interface: a partir dos requisitos funcionais e não funcionais definidos pelos stakeholders, devem ser identificadas as necessidades de interface com o usuário e com outros softwares ou hardwares. Definição do Product Backlog. A partir dos elementos produzidos anteriormente, deve ser construído o Product BackLog. É importante destacar que o Product Backlog poderá ser modificado na etapa de desenvolvimento, para atender às mudanças de requisitos. As atividades identificadas como necessárias para o desenvolvimento do produto deve constar na lista, compondo o Product Backlog. Gestão do Conhecimento. É necessário que todo o conhecimento do projeto esteja bem organizado de forma a otimizar todo o processo de desenvolvimento, manutenção e comunicação da equipe. O gerenciamento do conhecimento pode ser conduzido seguindo os seguintes passos: a) Seleção do conhecimento: definição das informações que devem fazer parte da base de conhecimento. b) Definição dos itens de configuração: definição dos documentos, ou grupos de documentos relacionados, que estarão sob o controle de configuração.

8 Os itens de configuração a serem gerenciados devem ser escolhidos com base no planejamento das mudanças do software. c) Controle de versão: definição dos procedimentos e ferramentas para gerenciar as diferentes versões dos itens de configuração. d) Padrão de Codificação: devem ser estabelecidos padrões de codificação para serem seguidos durante o desenvolvimento e auxiliar a comunicação através do código. e) Construção da Matriz de Rastreabilidade: através de uma matriz de rastreabilidade é possível relacionar os requisitos com as funcionalidades implementadas, ajudando na manutenção da consistência do software num possível momento de manutenção do sistema. f) Controle das mudanças dos requisitos: todas as alterações realizadas em um requisito devem ser registradas. g) Definição dos sistemas e ferramentas de compartilhamento de conhecimento: o conhecimento deve ser mantido em um depósito de dados seguro e gerenciado, que seja acessível por todos os envolvidos no processo de Engenharia de Software. Seleção de Tecnologia e Ferramentas. É necessário avaliar adequadamente o risco das novas tecnologias e ferramentas CASE (Computer-Aided Software Engineering). a) Avaliação e escolha da tecnologia: as tecnologias devem atender às exigências do sistema (arquitetura, desempenho, segurança, portabilidade, entre outras), serem orientadas a objeto, além disso, devem atender a critérios como área de aplicação geral, complexidade computacional e algorítmica, disponibilidade de profissionais capacitados, acesso à documentação. b) Avaliação e escolha das ferramentas CASE: as ferramentas CASE auxiliam atividades de Engenharia de Software, como gerenciamento de requisitos, análise, modelagem, programação, refatoração de código e testes. Os fatores que devem ser avaliados ao escolher as ferramentas são: complexidade, experiência da equipe, custo e integração entre ferramentas. Estimativa de Esforço e Custo. Correspondem à estimativa de desenvolvimento e à estimativa de atividades de apoio (treinamento dos recursos humanos, aquisição de ferramentas de apoio, análise de projeto, entre outros). As estimativas de custo e tempo na prática não são exatas. Mas é necessária uma estimativa inicial que dê rumo ao projeto e influencie nas decisões a serem seguidas. Contudo, os recursos e escopo do projeto devem ser reanalisados periodicamente, em cada sprint. Seleção e Capacitação da Equipe. Corresponde à seleção de recursos humanos, definição de responsabilidades e treinamento Desenvolvimento

9 A fase de desenvolvimento, ou implementação, foi baseada nas práticas da Scrum, é constituída de ciclos iterativos, sprints, que implementam um conjunto de itens de Product Backlog. As práticas que devem ser realizadas em cada sprint são: Planejamento do release. Consiste em uma reunião entre cliente e gerência do projeto, onde o cronograma, os componentes, os módulos prioritários, as medidas de desempenho e quantos itens do backlog podem ser feitos em cada iteração são definidos. Planejamento do sprint. Prática realizada no início de cada sprint. Corresponde a um plano do novo sprint definido a partir das prioridades do cliente e estimativas técnicas. O planejamento deve seguir as seguintes diretrizes: a) Construção do Sprint Backlog: a seleção dos itens do backlog que serão desenvolvidos, constituindo o Sprint Backlog, é definida pelo cliente, baseado na sua prioridade. A gerência de projeto deverá verificar a matriz de rastreabilidade para analisar as dependências entre os requisitos e a relação com componentes, definindo a viabilidade do desenvolvimento desses itens selecionados. b) Definição do teste de aplicação: o cliente deve descrever os testes de aplicação para cada final de ciclo, conduzindo o desenvolvimento e estabelecendo um critério de validação. c) Alocação de recursos: a equipe responsável pelo desenvolvimento do Sprint Backlog é formada. O esforço necessário e a experiência com o sub-ambiente de aplicação a ser trabalhado são critérios a serem analisados para definir o tamanho e membros da equipe, respectivamente. As equipes podem ser formadas para atuarem em um determinado conjunto de funcionalidades ou em determinadas camadas do sistema. d) Projeto do sprint: o gerente do projeto, com o auxílio da equipe de desenvolvimento, projeta detalhadamente o sprint. e) Cronograma: cada atividade do sprint deve ser definida, com prazos e responsáveis, obedecendo o tempo ideal estabelecido para cada iteração. Desenvolvimento do sprint. a) Testes: os desenvolvedores, com base no teste de aplicação definido pelo cliente e com uma análise dos itens a serem implementados, escrevem testes de unidade mais detalhados, para validar o sprint. É implementado um teste para cada item do backlog, antes mesmo de ocorrer a implementação. b) Reuniões diárias: todo dia, ou em dias alternados, é realizada uma reunião com uma duração média de 15 minutos onde a equipe expõe à gerência as atividades a serem feitas até próximo encontro, os fatores de impedimento, e o progresso geral do desenvolvimento. Nessa reunião será criado um documento, que indique as inconsistências entre o projeto de trabalho e os requisitos alocados.

10 c) Refatoração: a cada nova funcionalidade desenvolvida, o design do código deve ser trabalhado até ficar na sua forma mais simples, eliminando duplicações e melhorando a comunicação e flexibilidade. Esta melhoria é feita sem comprometer o comportamento externo do software. d) Revisão de padrão: a partir da definição dos padrões de codificação determinado na etapa de planejamento, o desenvolvedor deverá analisar se o seu código segue as exigências do projeto, realizando as devidas modificações. As atividades de refatoração, testes de unidade e padronização do código são baseadas na XP. Enquanto a reunião diária, com feedback constante, é uma prática ágil comum a XP e Scrum. Reunião de revisão do sprint. A reunião de revisão ocorre no último dia do sprint. A equipe de desenvolvimento, o cliente e o gerente de projeto devem estar presentes nesta reunião. a) Análise dos resultados: análise dos relatórios das reuniões diárias, verificando as inconsistências encontradas entre os requisitos alocados e o que foi desenvolvido. b) Análise de riscos: o gerente deve discutir com a equipe e o cliente as possibilidades de riscos ao final de cada sprint. Quando o risco tem origem ou impactos funcionais, ou seja, diretamente ligados à gerência de requisitos, a matriz de rastreabilidade deve ser utilizada para orientar essa análise. c) Atualização do Product Backlog: novos itens de backlog, que se apresentarem necessários durante a reunião, podem ser adicionados na lista de backlog. d) Atualização da documentação: nas reuniões de revisão são documentadas todas as discussões e soluções relevantes para as etapas futuras e para o histórico da organização, de forma a facilitar a comparação com outros projetos Pós-desenvolvimento O pós-desenvolvimento consiste nas etapas de Encerramento e Substituição Encerramento Ao final de um conjunto de sprints, quando a gerência percebe que tem uma versão estável com as novas funcionalidades requeridas, com qualidade e pronta para competir, essa nova versão é declarada encerrada e o processo entra em no estágio de encerramento. Portanto, após a verificação do cliente, tem-se um release que já pode entrar em operação. As práticas do encerramento são descritas a seguir. Testes de sistemas: correspondem a testes realizados para verificação das funcionalidades do sistema. Inclusive comparando o sistema legado com sistema novo, através de uma simulação dos processos do sistema legado que foram incorporados no sistema novo.

11 Testes de integração: no final de cada sprint a integração dos itens desenvolvidos com o software deve ser testada. Testes de estresse: após a integração completa do sistema é possível testá-lo quanto aos requisitos não-funcionais como desempenho, portabilidade e confiabilidade. Criação de documentação do usuário: nessa fase deve ser criado o manual do usuário. Sempre que possível deve ser utilizado sistema de ajuda on-line. Se, por ventura, os casos de testes não forem satisfatórios, deve-se retornar ao estágio de desenvolvimento, incluindo os novos itens no Product Backlog. Contudo, esse caso é uma exceção, já que testes devem ser realizados periodicamente, ao final de cada sprint. Considera-se que o encerramento só é alcançado quando realmente se tem certeza que a versão é estável Substituição O estágio de substituição ocorre quando o cliente confirma a validação e verificação do sistema, não havendo mais nenhuma pendência para que o novo sistema entre em operação. Para realizar a substituição do sistema novo pelo sistema legado é fundamental a adoção das práticas abaixo: Treinamento. A equipe responsável pelo treinamento deve conhecer o sistema legado, identificar a relação de cada processo da empresa executado nos dois sistemas, atentando-se principalmente para as funcionalidades que se comportam de maneira diferente entre o novo e antigo sistema. Além disso, o marketing interno do software desenvolvido é importante para mostrar aos usuários as vantagens do processo de substituição. Migração dos dados. Os dados do sistema legado que serão migrados, já definidos na etapa de planejamento, serão mapeados no novo sistema, e posteriormente deverá ser preparado um programa (rotina) para sua migração automática, é aconselhável executar simulações numa área de testes, para evitar surpresas desagradáveis. Homologação. Quando o novo sistema estiver implantado, o cliente deverá assinar um termo de homologação, registrando a finalização do processo de substituição do sistema legado. Depois de realizada a substituição do sistema legado, essa Estratégia poderá ser utilizada para as futuras manutenções, já que foi estruturada para prever essa evolução. Contudo, nos casos de manutenção, os estágios de reengenharia e substituição devem ser descartados. Além disso, devem ser descartadas também as atividades restritas para o caso de substituição, ou seja, não são utilizadas em processos de desenvolvimento e manutenção de software, por exemplo, a definição dos dados a serem migrados (estágio de planejamento), e a simulação do sistema novo no sistema legado (estágio de encerramento). No Quadro 2 é possível visualizar a Estratégia resumida nas fases, estágios e práticas adotadas.

12 Reengenharia Estratégia para substituição de sistema legado Pré-desenvolvimento Conhecer o funcionamento do sistema legado (E/S) Analisar código fonte. Entrevistar equipe / atores do sistema legado. Planejamento Análise Definição do Product Backlog Gerenciamento do Conhecimento Seleção da Tecnologia e Ferramentas CASE Estimativa de Esforço e Custo Seleção e Capacitação da Equipe Planejamento do release Planejamento do sprint Desenvolvimento do sprint Reunião de revisão do sprint Encerramento Testes de sistemas Testes de Integração Testes de Estresse Criação de documentação do usuário Substituição Treinamento Migração de dados Homologação 5. Considerações Finais Desenvolvimento Pós-Desenvolvimento Quadro 2 - Resumo da estratégia de substituição de sistema legado. A substituição de sistema legado é uma solução arriscada e por vezes radical, mas a depender da situação pode ser a melhor opção a ser adotada para os negócios da organização. Contudo, é necessário que as empresas de desenvolvimento de software tratem a substituição de sistemas legados como um processo diferenciado de produção, considerando as suas peculiaridades. É notado que as metodologias normalmente utilizadas para desenvolvimento de software não são adequadas a ambientes de desenvolvimento de software caracterizados pela instabilidade e imprevisibilidade dos requisitos, risco associado à alta influência nos processos da organização, além da necessidade de um curto tempo de resposta. Portanto, a Estratégia apresentada se mostra relevante ao orientar o processo de desenvolvimento de software através de soluções que minimizam os impactos causados

13 pela substituição de sistemas legados. É proposta a utilização de práticas ágeis, que lidam com processos mais simples, mais eficientes e que atendem às mudanças de requisitos e auxiliam no levantamento das necessidades do cliente. A fidelidade do software às necessidades da empresa é ampliada através da reengenharia das funcionalidades do sistema legado e de constantes interações com os stakeholders,. Suas práticas voltadas para o controle contínuo do conhecimento e mudanças são essenciais para atender ao caráter evolutivo desse tipo de software. As reuniões periódicas facilitam a boa comunicação da equipe com o cliente. A preocupação com o aumento do tempo de vida útil e com a minimização de reincidências dos problemas encontrados no sistema legado faz valer os investimentos da organização pela substituição do software legado. É importante destacar que a eficiência desta Estratégia depende muito mais das pessoas que dos processos. A construção do software útil depende do conhecimento da equipe de desenvolvimento quanto aos processos envolvidos na aplicação, da sua coragem para aceitar mudanças, da sua relação com o cliente e da percepção da necessidade dos processos. Além disso, é necessário perceber que uma transformação de paradigma só eficiente se for compreendida e aceita por todos os atores envolvidos. Referências Adolph, W.S. (1996) Cash Cow in the Tar Pit: Reengineering a Legacy System. In: IEEE Software, v. 13, n. 3, p Beck, K. (2000) Extreme Programming Explained: Embrace Change. Addison Wesley. Bisbal, J. et al. (1999) Legacy information systems: issues and directions. In: IEEE Software, v. 16, n. 5, p Manifest for Agile Software Development (2001). < Paiva, L.; Santander, V. (2004) Uma proposta de evolução em Sistemas Legados, In: Anais do WER04 - Workshop em Engenharia de Requisitos, Tandil, Argentina, p Schwaber, K. (1995) SCRUM Development Process, In: OOPSLA'95 Workshop on Business Object Design and Implementation, 1995, Springer-Verlag. Anais eletrônico. < >. Soares, M. (2004) Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. In: Revista Eletrônica de Sistemas de Informação, Ed. 4. < >. Sommerville, I. (2003) Engenharia de Software. 6ª. ed.: Addison Wesley Professional. Wuestefeld, K. (2001) XisPê Extreming Programming. <

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

EVOLUÇÃO DE SOFTWARE

EVOLUÇÃO DE SOFTWARE EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1 Mudança de Software 2 Manutenção de software Mudança de software é inevitável

Leia mais

Gerenciamento de Problemas

Gerenciamento de Problemas Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar

Leia mais

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br Gerenciamento de projetos cynaracarvalho@yahoo.com.br Projeto 3URMHWR é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Modernização e Evolução do Acervo de Software Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Tópicos 1. Estudo Amplo sobre Modernização 2. Visão IBM Enterprise Modernization 3. Discussão - Aplicação

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

Processo de Abertura de Projetosescritorio. Bizagi Process Modeler

Processo de Abertura de Projetosescritorio. Bizagi Process Modeler Processo de Abertura de Projetosescritorio Bizagi Process Modeler Índice PROCESSO DE ABERTURA DE PROJETOS-ESCRITORIO...1 BIZAGI PROCESS MODELER...1 1 PROCESSO DE ABERTURA DE PROJETOS...5 1.1 PROCESSO

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Material de Apoio. Sistema de Informação Gerencial (SIG)

Material de Apoio. Sistema de Informação Gerencial (SIG) Sistema de Informação Gerencial (SIG) Material de Apoio Os Sistemas de Informação Gerencial (SIG) são sistemas ou processos que fornecem as informações necessárias para gerenciar com eficácia as organizações.

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Expresso Livre Módulo de Projetos Ágeis

Expresso Livre Módulo de Projetos Ágeis Expresso Livre Módulo de Projetos Ágeis Desenvolvedor / Orientador Rafael Raymundo da Silva Guilherme Lacerda Out / 2010 1 Sumário 1.Conhecendo a ferramenta...3 2.Gerência de projetos ágeis...3 2.1Product

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

Gerenciamento de Incidentes

Gerenciamento de Incidentes Gerenciamento de Incidentes Os usuários do negócio ou os usuários finais solicitam os serviços de Tecnologia da Informação para melhorar a eficiência dos seus próprios processos de negócio, de forma que

Leia mais

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert: BRAlarmExpert Software para Gerenciamento de Alarmes A TriSolutions conta com um produto diferenciado para gerenciamento de alarmes que é totalmente flexível e amigável. O software BRAlarmExpert é uma

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

ERP Enterprise Resource Planning

ERP Enterprise Resource Planning ERP Enterprise Resource Planning Sistemas Integrados de Gestão Evolução dos SI s CRM OPERACIONAL TÁTICO OPERACIONAL ESTRATÉGICO TÁTICO ESTRATÉGICO OPERACIONAL TÁTICO ESTRATÉGICO SIT SIG SAE SAD ES EIS

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

Gerenciamento de Projetos Modulo VIII Riscos

Gerenciamento de Projetos Modulo VIII Riscos Gerenciamento de Projetos Modulo VIII Riscos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Prof. Me. Marcos Echevarria

Prof. Me. Marcos Echevarria Prof. Me. Marcos Echevarria Nas décadas de 80 e 90 a visão geral sobre a melhor maneira de desenvolver software era seguir um cuidadoso planejamento para garantir uma boa qualidade; Esse cenário era aplicável

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17

PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17 PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17 Índice 1. Conceitos de Ciclo de Desenvolvimento de Sistemas...3 1.1. Principais Fases... 3 1.2. Técnicas... 4 1.3. Papéis de Responsabilidades... 4 1.3.1.

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

MODELO CMM MATURIDADE DE SOFTWARE MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Referência: An Introductory Overview of ITIL v2 Livros ITIL v2 Cenário de TI nas organizações Aumento da dependência da TI para alcance

Leia mais

http://www.microsoft.com/pt-br/case/details.aspx...

http://www.microsoft.com/pt-br/case/details.aspx... Casos de Sucesso A Cyrela está completamente focada no pós-venda e a utilização do Microsoft Dynamics 2011 só reflete mais um passo importante na busca pela qualidade do atendimento ao cliente Roberto

Leia mais

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,

Leia mais

UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br

UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br SINOP MT 2015-1 COMO SÃO DESENVOLVIDOS OS SISTEMAS DE INFORMAÇÃO? São desenvolvimento como uma estrutura

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Universidade Federal de Goiás UFG Campus Catalão CAC Departamento de Engenharia de Produção. Sistemas ERP. PCP 3 - Professor Muris Lage Junior

Universidade Federal de Goiás UFG Campus Catalão CAC Departamento de Engenharia de Produção. Sistemas ERP. PCP 3 - Professor Muris Lage Junior Sistemas ERP Introdução Sucesso para algumas empresas: acessar informações de forma rápida e confiável responder eficientemente ao mercado consumidor Conseguir não é tarefa simples Isso se deve ao fato

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?

Leia mais

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

Leia mais

PROJETO NOVAS FRONTEIRAS. Descrição dos processos de gerenciamento da qualidade

PROJETO NOVAS FRONTEIRAS. Descrição dos processos de gerenciamento da qualidade PROJETO NOVAS FRONTEIRAS PLANO DE GERENCIAMENTO DA QUALIDADE QUALITY MANAGEMENT PLAN Preparado por Mara Lúcia Menezes Membro do Time Versão 3 Aprovado por Rodrigo Mendes Lemos Gerente do Projeto 15/11/2010

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA Jeferson Boesing 1 ; Tiago Heineck 2 ; Angela Maria Crotti da Rosa 3 ; Leila Lisiane Rossi 4 INTRODUÇÃO Alunos

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos

Leia mais

5. Métodos ágeis de desenvolvimento de software

5. Métodos ágeis de desenvolvimento de software Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014. A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Desenvolvimento de Interfaces Prototipação

Desenvolvimento de Interfaces Prototipação Autarquia Educacional do Vale do São Francisco AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Centro de Engenharia e Ciências Tecnológicas CECT Curso de Ciência da Computação Desenvolvimento

Leia mais

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO Pesquisa realizada com os participantes do de APRESENTAÇÃO O perfil do profissional de projetos Pesquisa realizada durante o 16 Seminário Nacional de, ocorrido em Belo Horizonte em Junho de, apresenta

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

POLÍTICA DE GESTÃO DE RISCO - PGR

POLÍTICA DE GESTÃO DE RISCO - PGR POLÍTICA DE GESTÃO DE RISCO - PGR DATASUS Maio 2013 Arquivo: Política de Gestão de Riscos Modelo: DOC-PGR Pág.: 1/12 SUMÁRIO 1. APRESENTAÇÃO...3 1.1. Justificativa...3 1.2. Objetivo...3 1.3. Aplicabilidade...4

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

ANEXO X DIAGNÓSTICO GERAL

ANEXO X DIAGNÓSTICO GERAL ANEXO X DIAGNÓSTICO GERAL 1 SUMÁRIO DIAGNÓSTICO GERAL...3 1. PREMISSAS...3 2. CHECKLIST...4 3. ITENS NÃO PREVISTOS NO MODELO DE REFERÊNCIA...11 4. GLOSSÁRIO...13 2 DIAGNÓSTICO GERAL Este diagnóstico é

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM Peterson Vieira Salme 1, Claudete Werner 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil petersonsalme@gmail.com, claudete@unipar.br

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

IDÉIAS SOBRE IMPLANTAÇÃO DE SISTEMAS EMPRESARIAIS INTEGRADOS. Prof. Eduardo H. S. Oliveira

IDÉIAS SOBRE IMPLANTAÇÃO DE SISTEMAS EMPRESARIAIS INTEGRADOS. Prof. Eduardo H. S. Oliveira IDÉIAS SOBRE IMPLANTAÇÃO DE SISTEMAS EMPRESARIAIS INTEGRADOS Introdução Nos últimos seis anos, tem ocorrido no Brasil uma verdadeira revolução na área de gestão empresarial. Praticamente, todas as grandes

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

MRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior

MRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior MRP II Introdução A lógica de cálculo das necessidades é conhecida há muito tempo Porém só pode ser utilizada na prática em situações mais complexas a partir dos anos 60 A partir de meados da década de

Leia mais

Levantamento, Análise e Gestão Requisitos. Aula 12

Levantamento, Análise e Gestão Requisitos. Aula 12 Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e

Leia mais

Gerenciamento de Requisitos Gerenciamento de Requisitos

Gerenciamento de Requisitos Gerenciamento de Requisitos Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso

Leia mais

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti. TI Aplicada Aula 02 Áreas e Profissionais de TI Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais