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 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). <http://agilemanifesto.org>. 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. <http://www.jeffsutherland.org/oopsla/schwapub.pdf >. 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. <http://www.presidentekennedy.br/resi/ >. Sommerville, I. (2003) Engenharia de Software. 6ª. ed.: Addison Wesley Professional. Wuestefeld, K. (2001) XisPê Extreming Programming. <http://www.xispe.com.br/>.

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Garantia de Processo Leis de Lehman Manutenção de Softwares

Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Acidentes são eventos raros em sistemas críticos e pode ser impossível simulá-los durante testes de um sistema. Requisitos

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

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

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 SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

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

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

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

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

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

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

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

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

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

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

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

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0 Plano de Projeto G Stock Plano de Projeto G Stock Versão 1.0 Histórico das Revisões Data Versão Descrição Autores 10/09/2010 1.0 Descrição inicial do plano de projeto Denyson José Ellís Carvalho Isadora

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

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

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

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

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

ENG1000 Introdução à Engenharia

ENG1000 Introdução à Engenharia ENG1000 Introdução à Engenharia Aula 01 Processo de Desenvolvimento de Software Edirlei Soares de Lima Processo de Software O processo de software consiste em um conjunto estruturado

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

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

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

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

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

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

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

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

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

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia 1 Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos Prof.: Franklin M. Correia Na aula anterior... Metodologias ágeis Princípios do Manifesto ágil 12 itens do manifesto

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

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

Aplicação de uma Metodologia Ágil no Desenvolvimento de um Software Web envolvendo equipes Multidisciplinares

Aplicação de uma Metodologia Ágil no Desenvolvimento de um Software Web envolvendo equipes Multidisciplinares Aplicação de uma Metodologia Ágil no Desenvolvimento de um Software Web envolvendo equipes Multidisciplinares Paulo Júnior Varela Universidade Tecnológica Federal do Paraná - UTFPR paulovarela@utfpr.edu.br

Leia mais

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

Leia mais

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

Leia mais

Proposta Comercial. Empresa «Nome_da_empresa» Solução BPO Business Process Outsourcing. Número Proposta «Numero_Proposta» - «Versao»

Proposta Comercial. Empresa «Nome_da_empresa» Solução BPO Business Process Outsourcing. Número Proposta «Numero_Proposta» - «Versao» Proposta Comercial Empresa «Nome_da_empresa» Solução BPO Business Process Outsourcing Número Proposta «Numero_Proposta» - «Versao» Data 14 de setembro de 2012 Preparado para: «Nome» «Sobrenome» 1. Objetivo

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

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

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Métodos Ágeis para Desenvolvimento de Software Livre

Métodos Ágeis para Desenvolvimento de Software Livre Métodos Ágeis para Desenvolvimento de Software Livre Dionatan Moura Jamile Alves Porto Alegre, 09 de julho de 2015 Quem somos? Dionatan Moura Jamile Alves Ágil e Software Livre? Métodos Ágeis Manifesto

Leia mais

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados Tribunal de Justiça de Pernambuco Diretoria de Informática Guia de Utilização do Mantis Máquina de Estados Guia de Utilização Mantis Histórico de Alterações Data Versão Descrição Autor Aprovado Por 02/09/2008

Leia mais

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF 1. Identificação de um problema a ser implementado 2. Análise

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

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

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

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS

CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS CobiT 4.01 OBJETIVOS DE CONTROLE PARA INFORMAÇÃO E TECNOLOGIAS RELACIONADAS METODOLOGIA DE AUDITORIA PARA AVALIAÇÃO DE CONTROLES E CUMPRIMENTO DE PROCESSOS DE TI NARDON, NASI AUDITORES E CONSULTORES CobiT

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

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

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços

Leia mais

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software Análise e Projeto de Sistemas Análise e Projeto de Sistemas Contextualização ENGENHARIA DE SOFTWARE ANÁLISE E PROJETO DE SISTEMAS ENGENHARIA DA INFORMAÇÃO Perspectiva Histórica Engenharia de Software 1940:

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento Ciência da Computação ENGENHARIA DE SOFTWARE Planejamento e Gerenciamento Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Pessoas, Produto, Processo e Projeto; Gerência de

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

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

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?

Ideal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê? Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado

Leia mais

EXIN Agile Scrum Fundamentos

EXIN Agile Scrum Fundamentos Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

Software para especificação de motores de indução trifásicos

Software para especificação de motores de indução trifásicos Instituto Federal Sul-riograndense Campus Pelotas - Curso de Engenharia Elétrica Software para especificação de motores de indução trifásicos Disciplina: Projeto Integrador III Professor: Renato Neves

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

Especialização em Arquitetura e Engenharia de Software

Especialização em Arquitetura e Engenharia de Software Especialização em Arquitetura e Engenharia de Software O curso vai propiciar que você seja um especialista para atua atuar na área de Arquitetura de Software em diferentes organizações, estando apto a:

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais