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/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Á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

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

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

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

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

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

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

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

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

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

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

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

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

Leia mais

APLICAÇÃO DE SCRUM NO DESENVOLVIMENTO DE SISTEMAS PARA O PROGRAMA DE MONITORAMENTO DO CLIMA ESPACIAL (INPE) - ESTUDO DE CASO. André A.

APLICAÇÃO DE SCRUM NO DESENVOLVIMENTO DE SISTEMAS PARA O PROGRAMA DE MONITORAMENTO DO CLIMA ESPACIAL (INPE) - ESTUDO DE CASO. André A. APLICAÇÃO DE SCRUM NO DESENVOLVIMENTO DE SISTEMAS PARA O PROGRAMA DE MONITORAMENTO DO CLIMA ESPACIAL (INPE) - ESTUDO DE CASO André A. de Souza Ivo Instituto Nacional de Pesquisas Espaciais (INPE), Brasil,

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

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

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

Tecnologia da Informação para EPPGG 2013. Victor Dalton

Tecnologia da Informação para EPPGG 2013. Victor Dalton Tecnologia da Informação para EPPGG 2013 Victor Dalton Edital TECNOLOGIA DA INFORMAÇÃO: 1. Noções sobre processo de desenvolvimento de software: modelos organizacionais, stakeholders, modelagem de negócio,

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

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

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

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

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

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

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

Uma Experiência de Engenharia de Requisitos em Empresas de Software

Uma Experiência de Engenharia de Requisitos em Empresas de Software Uma Experiência de Engenharia de Requisitos em Empresas de Software Carina Frota Alves Centro de Informática, Universidade Federal de Pernambuco, Brasil cfa@cin.ufpe.br Resumo. Este artigo apresenta uma

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

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

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

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

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

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

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

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

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

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

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2 ENGENHARIA DE SOFTWARE II Modelos de Ciclo de Vida e Processos de Software AULA 2 Sumário Motivação Conceitos de Processo de Desenvolvimento de Software Atividades que compõem os processos de desenvolvimento

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

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS Sumário 1. DIRETRIZES PARA O PROCESSO DE DESENVOLVIMENTO DE PROJETOS DE APLICATIVOS...172 1.1. INTRODUÇÃO...172

Leia mais

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Roberto Costa Araujo Orientador: Cristiano T. Galina Sistemas de Informação Universidade do Vale do Rio dos Sinos

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

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

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

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

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

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 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MIRILIAN CARLA ARAUJO CORILLO 1, ANDREA PADOVAN JUBILEU 2. 1 Tecnóloga em Análise e Desenvolvimento de Sistemas

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

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Micaelly P. Soares e Silva, Carla I. M. Bezerra, Camilo C. Almendra, Enyo José T. Gonçalves Universidade

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

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

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

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

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

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

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

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

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

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

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

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming

Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming T. M. R. Dias 1 ; G. F. Moita 2 ; M. P. Silva 3 ; B. Ferreira 1 ; A. M. Silva 1 1 IFMG Instituto

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

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

Questões Gerais e Modelos de Ciclo de Vida

Questões Gerais e Modelos de Ciclo de Vida Questões Gerais e Modelos de Ciclo de Vida 41 Existem vários modelos de desenvolvimento de software, cada um com suas particularidades. A respeito desse assunto, assinale a opção correta. A) No modelo

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

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

Termo de Abertura Sistema de Vendas de Pizzas Online (PizzaWeb) - Versão 1.0

Termo de Abertura Sistema de Vendas de Pizzas Online (PizzaWeb) - Versão 1.0 Termo de Abertura Sistema de Vendas de Pizzas Online (PizzaWeb) - Versão 1.0 Versão do Documento: 1.1 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011 1.0 Montar o Termo de Abertura.

Leia mais

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS Rosiane da Silva Biscaia Discente do curso Tecnologia em Análise e Desenvolvimento de Sistemas Faculdades

Leia mais

ENGENHARIA DE SOFTWARE: TESTES E QUALIDADE DE PRODUTO Prof. José Manuel de Sacadura Rocha

ENGENHARIA DE SOFTWARE: TESTES E QUALIDADE DE PRODUTO Prof. José Manuel de Sacadura Rocha ENGENHARIA DE SOFTWARE: TESTES E QUALIDADE DE PRODUTO Prof. José Manuel de Sacadura Rocha RESUMO Trata-se da qualidade no desenvolvimento do produto software principalmente com respeito à fase de testes

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

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

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

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 AOS MÉTODOS ÁGEIS

INTRODUÇÃO AOS MÉTODOS ÁGEIS WESLLEYMOURA@GMAIL.COM INTRODUÇÃO AOS MÉTODOS ÁGEIS ANÁLISE DE SISTEMAS Introdução aos métodos ágeis Metodologias tradicionais Estes tipos de metodologias dominaram a forma de desenvolvimento de software

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos SOFTWARE PROCESSES Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Introduzir modelos de processo de software Descrever uma variedade de modelos de processo

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

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