Este documento apresenta os resultados de um mapeamento sistemático sobre padrões de software para reengenharia de sistemas publicados em conferências especializadas. O estudo catalogou 23 padrões, classificou-os de acordo com as disciplinas do RUP e levantou informações sobre os processos de reengenharia, linguagens de programação e conferências abordadas nos padrões.
Gerência de Configuração de Software: Benefícios Do Controle de Versões Distr...Gilmar Pupo
Este projeto sugere melhorias no modelo de versionamento de arquivos de um projeto de software e aponta problemas enfrentados no uso de sistemas de controle de versão centralizados. O estudo de caso realizado visualizou a aplicabilidade da adoção de um sistema de controle de versão distribuído no processo de desenvolvimento de software e a importância que a cultura e as comunidades de desenvolvedores possuem no processo evolutivo do conhecimento da indústria de software. As conclusões indicaram que nas empresas estudadas, os sistemas de controle de versão distribuído reforçaram a interação entre os desenvolvedores e incentivam a adoção de melhores práticas de engenharia de software, otimizam o uso de recursos computacionais e oferecem soluções a problemas enfrentados no dia a dia do desenvolvimento de software e também que a adoção de um sistema de controle de versão distribuído pela Gerência de Configuração de Software pode ser simples desde que reconhecido como um novo paradigma.
O documento discute fatores críticos de sucesso na implementação de processos. Ele apresenta 6 componentes principais: 1) Comprometimento, 2) Relacionamento, 3) Melhorias em Processos, 4) Capacitação, 5) Recursos, 6) Institucionalização. Cada componente contém vários fatores que influenciam o sucesso das iniciativas de melhoria de processos em organizações. O documento fornece exemplos teóricos para cada fator identificado.
1) A reunião de análise crítica discutiu os resultados da auditoria interna, reclamações de clientes e indicadores de qualidade.
2) Foram apontadas ações para melhorar processos, reduzir refugos, ausenteísmo e horas de máquinas paradas.
3) A direção também analisou propostas de mudanças no sistema da qualidade, planos de investimento e manutenção preventiva.
O documento descreve o Rational Unified Process (RUP), um modelo de processo de software que fornece boas práticas para o desenvolvimento de sistemas. O RUP é dividido em quatro fases principais: Iniciação, Elaboração, Construção e Transição. Cada fase tem objetivos, artefatos esperados e critérios de avaliação para marcos importantes no projeto. O documento detalha os principais elementos de cada fase do RUP.
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...Adson Wendel
1) O documento apresenta um mapeamento entre a metodologia ágil FDD e o Modelo de Qualidade MPS.BR nos níveis de maturidade G e F, realizado por Adson Wendel Cirilo Ferreira para obtenção do título de Especialista em Engenharia de Software.
2) O objetivo é ajudar empresas a definirem um processo ágil e ganharem mais velocidade nos processos dos resultados esperados pela certificação MPS.BR, tornando-se mais competitivas.
3) O documento revisa a FDD, o MPS.BR
Este documento resume um trabalho sobre rejuvenescimento de software gerido pelo Project Office. Ele explica o que é rejuvenescimento de software e suas características, apresenta uma metodologia proposta e um estudo de caso onde o rejuvenescimento e o Project Office foram aplicados.
O documento discute a aplicação de uma metodologia ágil combinando Scrum e Kanban no gerenciamento de projetos de sistemas. Ele explica que Scrum e Kanban podem ser usados juntos para melhorar os processos de gerenciamento e desenvolvimento de projetos, aproveitando as características adaptativas de ambos e permitindo entregas incrementais frequentes.
O documento descreve a disciplina de teste no modelo Rational Unified Process (RUP). A disciplina de teste tem como objetivo avaliar a qualidade do produto através de atividades como definir a missão de avaliação e verificar a estabilidade dos builds. Ela inclui tarefas como avaliar a qualidade, definir a abordagem de teste e executar conjuntos de testes. A disciplina de teste também interage com outras disciplinas do RUP como requisitos, análise e projeto.
Gerência de Configuração de Software: Benefícios Do Controle de Versões Distr...Gilmar Pupo
Este projeto sugere melhorias no modelo de versionamento de arquivos de um projeto de software e aponta problemas enfrentados no uso de sistemas de controle de versão centralizados. O estudo de caso realizado visualizou a aplicabilidade da adoção de um sistema de controle de versão distribuído no processo de desenvolvimento de software e a importância que a cultura e as comunidades de desenvolvedores possuem no processo evolutivo do conhecimento da indústria de software. As conclusões indicaram que nas empresas estudadas, os sistemas de controle de versão distribuído reforçaram a interação entre os desenvolvedores e incentivam a adoção de melhores práticas de engenharia de software, otimizam o uso de recursos computacionais e oferecem soluções a problemas enfrentados no dia a dia do desenvolvimento de software e também que a adoção de um sistema de controle de versão distribuído pela Gerência de Configuração de Software pode ser simples desde que reconhecido como um novo paradigma.
O documento discute fatores críticos de sucesso na implementação de processos. Ele apresenta 6 componentes principais: 1) Comprometimento, 2) Relacionamento, 3) Melhorias em Processos, 4) Capacitação, 5) Recursos, 6) Institucionalização. Cada componente contém vários fatores que influenciam o sucesso das iniciativas de melhoria de processos em organizações. O documento fornece exemplos teóricos para cada fator identificado.
1) A reunião de análise crítica discutiu os resultados da auditoria interna, reclamações de clientes e indicadores de qualidade.
2) Foram apontadas ações para melhorar processos, reduzir refugos, ausenteísmo e horas de máquinas paradas.
3) A direção também analisou propostas de mudanças no sistema da qualidade, planos de investimento e manutenção preventiva.
O documento descreve o Rational Unified Process (RUP), um modelo de processo de software que fornece boas práticas para o desenvolvimento de sistemas. O RUP é dividido em quatro fases principais: Iniciação, Elaboração, Construção e Transição. Cada fase tem objetivos, artefatos esperados e critérios de avaliação para marcos importantes no projeto. O documento detalha os principais elementos de cada fase do RUP.
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...Adson Wendel
1) O documento apresenta um mapeamento entre a metodologia ágil FDD e o Modelo de Qualidade MPS.BR nos níveis de maturidade G e F, realizado por Adson Wendel Cirilo Ferreira para obtenção do título de Especialista em Engenharia de Software.
2) O objetivo é ajudar empresas a definirem um processo ágil e ganharem mais velocidade nos processos dos resultados esperados pela certificação MPS.BR, tornando-se mais competitivas.
3) O documento revisa a FDD, o MPS.BR
Este documento resume um trabalho sobre rejuvenescimento de software gerido pelo Project Office. Ele explica o que é rejuvenescimento de software e suas características, apresenta uma metodologia proposta e um estudo de caso onde o rejuvenescimento e o Project Office foram aplicados.
O documento discute a aplicação de uma metodologia ágil combinando Scrum e Kanban no gerenciamento de projetos de sistemas. Ele explica que Scrum e Kanban podem ser usados juntos para melhorar os processos de gerenciamento e desenvolvimento de projetos, aproveitando as características adaptativas de ambos e permitindo entregas incrementais frequentes.
O documento descreve a disciplina de teste no modelo Rational Unified Process (RUP). A disciplina de teste tem como objetivo avaliar a qualidade do produto através de atividades como definir a missão de avaliação e verificar a estabilidade dos builds. Ela inclui tarefas como avaliar a qualidade, definir a abordagem de teste e executar conjuntos de testes. A disciplina de teste também interage com outras disciplinas do RUP como requisitos, análise e projeto.
Engenharia de software apostila analise de requisitos irobinhoct
1) O documento discute as fases de engenharia de software, incluindo análise de requisitos, desenvolvimento e verificação.
2) A fase de análise de requisitos envolve reconhecimento do problema, avaliação do problema, síntese da solução e especificação dos requisitos do software.
3) As atividades de análise de requisitos incluem reconhecimento do problema, avaliação do problema e síntese da solução através de modelagem, para entender melhor o fluxo de dados e controle do sistema.
Este documento descreve uma experiência acadêmica de uma fábrica de software livre geograficamente distribuída que utilizou processos adaptados para atender requisitos de qualidade e alta produtividade. A fábrica simulada, chamada de Smart Factory, tinha uma estrutura organizacional com áreas de suporte, gestão e produção. Processos baseados em RUP e CMMI foram definidos para guiar o desenvolvimento de software de forma a atender às necessidades de um cliente real.
Introdução à Engenharia de Requisitos e RUPVagner Santana
O documento apresenta uma introdução à engenharia de requisitos e ao processo unificado racional (RUP), descrevendo o que são requisitos, a estrutura do processo de engenharia de requisitos e os objetivos, estrutura e artefatos do RUP.
O documento discute o processo DRU do Nível C do MPS.Br, que trata do desenvolvimento de software para reuso. Apresenta as vantagens da reutilização, técnicas como SOA e componentes, e destaca a empresa Powerlogic como exemplo de certificação no processo DRU.
O documento discute o Capability Maturity Model Integration (CMMI) e o The Open Group Architecture Framework (TOGAF). O CMMI é um modelo de maturidade e melhores práticas para desenvolvimento e manutenção de software, enquanto o TOGAF é um framework para arquitetura empresarial. O documento também fornece contexto histórico sobre o desenvolvimento do CMMI e descreve suas principais representações e níveis de maturidade.
O documento descreve a modelagem de negócios no RUP, que é a primeira disciplina e serve de base para as outras. Ela é mais atuante na fase de Iniciação/Concepção e tem como objetivos entender o que construir, identificar funcionalidades chaves e determinar soluções possíveis. Os principais artefatos incluem a Visão do Negócio, Regras de Negócios e Caso de Uso de Negócios.
O documento descreve o modelo CMMI (Capability Maturity Model Integration), que fornece um framework para melhoria de processos de software e sistemas. O CMMI inclui níveis de maturidade, áreas de processo, metas e práticas. O documento também fornece um histórico do desenvolvimento do CMMI e seus modelos anteriores.
Engenharia de software apostila analise de requisitos iirobinhoct
Este documento propõe uma estratégia para implantar processos de gerenciamento e desenvolvimento de requisitos em uma organização visando melhorar a qualidade de software. A estratégia inclui definir processos para gerenciar requisitos, planejar o desenvolvimento com base nos requisitos e validar/verificar os produtos do desenvolvimento.
Implementing Product Line VariabilitiesMichel Alves
A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.
Este documento descreve a concepção, implementação e lições aprendidas de uma fábrica de software construída em um ambiente acadêmico. Ele detalha o processo de criação da fábrica, incluindo a definição de perfis funcionais, metodologia de desenvolvimento e plano de processos. Além disso, relata experiências com um projeto piloto e um projeto real, apontando lições que podem ser úteis para contextos similares.
Ferramenta de apoio a gerência de configuração de softwareelliando dias
O documento descreve o desenvolvimento de uma ferramenta para apoiar o processo de gerência de configuração de software. Detalha os objetivos, fundamentação teórica, requisitos, especificação, implementação e resultados do trabalho. A ferramenta foi comparada com outras ferramentas existentes e atendeu às diretrizes do modelo MPS.BR para gerência de configuração. O trabalho alcançou os objetivos propostos de controlar as atividades de gerência de configuração de software.
O documento descreve o plano de projeto para o desenvolvimento de um sistema de painel de estoque para um hospital universitário utilizando Java. Ele inclui estimativas de esforço, análise de riscos, planejamento de tarefas e qualidade, além de detalhar os requisitos funcionais e não funcionais do sistema. A equipe estima que o projeto pode ser concluído em 48 dias.
Este documento fornece orientações para a implementação do Nível D do MR-MPS-SW, detalhando cinco novos processos necessários nesse nível: Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação e Verificação. A evolução para o Nível D não apresenta novidades nos processos e atributos do Nível E, apenas requer a implementação desses cinco novos processos com a mesma capacidade dos processos existentes.
O documento discute processos e metodologias de desenvolvimento de software, como Análise Estruturada, Análise Essencial, Processo Unificado e Catalysis. Ele também propõe diretrizes para apoiar a evolução de sistemas legados, mapeando informações de diagramas de fluxo de dados para casos de uso em UML.
O RUP é uma metodologia iterativa e incremental para desenvolvimento de software baseada em casos de uso e arquitetura, organizada em fases, iterações e fluxos de atividades com responsáveis e artefatos.
Este documento discute a engenharia de processos de negócios, apresentando suas aplicações e metodologias. Apresenta duas metodologias principais - ARIS e IDEF3 - e discute como a modelagem de processos pode apoiar o redesenho de processos, análises e melhorias, e a implantação de sistemas integrados de gestão.
Linhas de Processos de Software - Minicurso - SBQS 2011Uirá Kulesza
O documento apresenta os conceitos e desafios da engenharia de processos de software e linhas de processo de software. Ele discute a motivação para customizar processos de software para diferentes projetos e como lidar com a variabilidade entre processos relacionados. Também introduz conceitos como linhas de produto de software e engenharia de processos para promover o reuso sistemático entre famílias de processos.
Manutenção de software tem uma série de peculiaridades quando comparada ao desenvolvimento de software. Este artigo descreve um caso de sucesso da resolução de questões na gestão tática e estratégica no planejamento e controle de software comercializado usando pontos de função como unidade de produto. Entre essas questões, as mais críticas são: gerir a programação das solicitações de mudança da base de cliente em um cenário onde quatro versões são liberadas em uma janela de tempo de um ano; aumentar a qualidade e a produtividade; diminuir a carga de trabalho não ligada à produção dos departamentos de desenvolvimento e teste. A Área de Processo de Medição e Análise foi usada como um mapa e as melhoria críticas alcançadas pela definição e implementação de: Marcos de acompanhamento gerencial para acompanhar o progresso dissociado das disciplinas da engenharia de software; unidade padrão de pacotes de trabalho como unidade de gestão para as demandas do departamento de planejamento, segregando atividades medidas pela produção daquelas medidas pela disponibilidade.
O documento descreve a gestão do programa MPS.BR, que tem como objetivo disseminar um modelo de melhoria de processos de software no Brasil. A gestão envolve uma estrutura organizacional com diferentes entidades responsáveis por atividades como o desenvolvimento do modelo MPS, credenciamento de instituições e disseminação do programa. O ciclo PDCA é utilizado para planejamento e monitoramento das atividades. Lições aprendidas na gestão incluem a importância de alinhamento com objetivos da indústria de software e envolvimento de diversas partes interessadas.
Um estudo de mapeamento sistemático sobre o processo de desenvolvimento de so...Robson de Negreiros
O documento descreve um estudo de mapeamento sistemático sobre os processos de desenvolvimento de software de código aberto. O estudo analisou trabalhos primários para comparar as atividades dos processos de código aberto e tradicionais. Concluiu que as atividades de manutenção são as mais diferentes, com a comunidade de código aberto tendo um processo mais de reinvenção do que manutenção tradicional. Um trabalho relacionado encontrou ainda mais diferenças nas atividades de manutenção.
1) O documento discute pensamento sistêmico e mapeamento de sistemas, incluindo como traçar padrões de comportamento e relações causais entre variáveis.
2) É explicado o que é um mapa sistêmico e como ele representa variáveis e relações de causa e efeito.
3) São descritos diferentes tipos de relações como enlaces, enlaces reforçadores, enlaces balanceadores e atrasos.
Engenharia de software apostila analise de requisitos irobinhoct
1) O documento discute as fases de engenharia de software, incluindo análise de requisitos, desenvolvimento e verificação.
2) A fase de análise de requisitos envolve reconhecimento do problema, avaliação do problema, síntese da solução e especificação dos requisitos do software.
3) As atividades de análise de requisitos incluem reconhecimento do problema, avaliação do problema e síntese da solução através de modelagem, para entender melhor o fluxo de dados e controle do sistema.
Este documento descreve uma experiência acadêmica de uma fábrica de software livre geograficamente distribuída que utilizou processos adaptados para atender requisitos de qualidade e alta produtividade. A fábrica simulada, chamada de Smart Factory, tinha uma estrutura organizacional com áreas de suporte, gestão e produção. Processos baseados em RUP e CMMI foram definidos para guiar o desenvolvimento de software de forma a atender às necessidades de um cliente real.
Introdução à Engenharia de Requisitos e RUPVagner Santana
O documento apresenta uma introdução à engenharia de requisitos e ao processo unificado racional (RUP), descrevendo o que são requisitos, a estrutura do processo de engenharia de requisitos e os objetivos, estrutura e artefatos do RUP.
O documento discute o processo DRU do Nível C do MPS.Br, que trata do desenvolvimento de software para reuso. Apresenta as vantagens da reutilização, técnicas como SOA e componentes, e destaca a empresa Powerlogic como exemplo de certificação no processo DRU.
O documento discute o Capability Maturity Model Integration (CMMI) e o The Open Group Architecture Framework (TOGAF). O CMMI é um modelo de maturidade e melhores práticas para desenvolvimento e manutenção de software, enquanto o TOGAF é um framework para arquitetura empresarial. O documento também fornece contexto histórico sobre o desenvolvimento do CMMI e descreve suas principais representações e níveis de maturidade.
O documento descreve a modelagem de negócios no RUP, que é a primeira disciplina e serve de base para as outras. Ela é mais atuante na fase de Iniciação/Concepção e tem como objetivos entender o que construir, identificar funcionalidades chaves e determinar soluções possíveis. Os principais artefatos incluem a Visão do Negócio, Regras de Negócios e Caso de Uso de Negócios.
O documento descreve o modelo CMMI (Capability Maturity Model Integration), que fornece um framework para melhoria de processos de software e sistemas. O CMMI inclui níveis de maturidade, áreas de processo, metas e práticas. O documento também fornece um histórico do desenvolvimento do CMMI e seus modelos anteriores.
Engenharia de software apostila analise de requisitos iirobinhoct
Este documento propõe uma estratégia para implantar processos de gerenciamento e desenvolvimento de requisitos em uma organização visando melhorar a qualidade de software. A estratégia inclui definir processos para gerenciar requisitos, planejar o desenvolvimento com base nos requisitos e validar/verificar os produtos do desenvolvimento.
Implementing Product Line VariabilitiesMichel Alves
A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.
Este documento descreve a concepção, implementação e lições aprendidas de uma fábrica de software construída em um ambiente acadêmico. Ele detalha o processo de criação da fábrica, incluindo a definição de perfis funcionais, metodologia de desenvolvimento e plano de processos. Além disso, relata experiências com um projeto piloto e um projeto real, apontando lições que podem ser úteis para contextos similares.
Ferramenta de apoio a gerência de configuração de softwareelliando dias
O documento descreve o desenvolvimento de uma ferramenta para apoiar o processo de gerência de configuração de software. Detalha os objetivos, fundamentação teórica, requisitos, especificação, implementação e resultados do trabalho. A ferramenta foi comparada com outras ferramentas existentes e atendeu às diretrizes do modelo MPS.BR para gerência de configuração. O trabalho alcançou os objetivos propostos de controlar as atividades de gerência de configuração de software.
O documento descreve o plano de projeto para o desenvolvimento de um sistema de painel de estoque para um hospital universitário utilizando Java. Ele inclui estimativas de esforço, análise de riscos, planejamento de tarefas e qualidade, além de detalhar os requisitos funcionais e não funcionais do sistema. A equipe estima que o projeto pode ser concluído em 48 dias.
Este documento fornece orientações para a implementação do Nível D do MR-MPS-SW, detalhando cinco novos processos necessários nesse nível: Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação e Verificação. A evolução para o Nível D não apresenta novidades nos processos e atributos do Nível E, apenas requer a implementação desses cinco novos processos com a mesma capacidade dos processos existentes.
O documento discute processos e metodologias de desenvolvimento de software, como Análise Estruturada, Análise Essencial, Processo Unificado e Catalysis. Ele também propõe diretrizes para apoiar a evolução de sistemas legados, mapeando informações de diagramas de fluxo de dados para casos de uso em UML.
O RUP é uma metodologia iterativa e incremental para desenvolvimento de software baseada em casos de uso e arquitetura, organizada em fases, iterações e fluxos de atividades com responsáveis e artefatos.
Este documento discute a engenharia de processos de negócios, apresentando suas aplicações e metodologias. Apresenta duas metodologias principais - ARIS e IDEF3 - e discute como a modelagem de processos pode apoiar o redesenho de processos, análises e melhorias, e a implantação de sistemas integrados de gestão.
Linhas de Processos de Software - Minicurso - SBQS 2011Uirá Kulesza
O documento apresenta os conceitos e desafios da engenharia de processos de software e linhas de processo de software. Ele discute a motivação para customizar processos de software para diferentes projetos e como lidar com a variabilidade entre processos relacionados. Também introduz conceitos como linhas de produto de software e engenharia de processos para promover o reuso sistemático entre famílias de processos.
Manutenção de software tem uma série de peculiaridades quando comparada ao desenvolvimento de software. Este artigo descreve um caso de sucesso da resolução de questões na gestão tática e estratégica no planejamento e controle de software comercializado usando pontos de função como unidade de produto. Entre essas questões, as mais críticas são: gerir a programação das solicitações de mudança da base de cliente em um cenário onde quatro versões são liberadas em uma janela de tempo de um ano; aumentar a qualidade e a produtividade; diminuir a carga de trabalho não ligada à produção dos departamentos de desenvolvimento e teste. A Área de Processo de Medição e Análise foi usada como um mapa e as melhoria críticas alcançadas pela definição e implementação de: Marcos de acompanhamento gerencial para acompanhar o progresso dissociado das disciplinas da engenharia de software; unidade padrão de pacotes de trabalho como unidade de gestão para as demandas do departamento de planejamento, segregando atividades medidas pela produção daquelas medidas pela disponibilidade.
O documento descreve a gestão do programa MPS.BR, que tem como objetivo disseminar um modelo de melhoria de processos de software no Brasil. A gestão envolve uma estrutura organizacional com diferentes entidades responsáveis por atividades como o desenvolvimento do modelo MPS, credenciamento de instituições e disseminação do programa. O ciclo PDCA é utilizado para planejamento e monitoramento das atividades. Lições aprendidas na gestão incluem a importância de alinhamento com objetivos da indústria de software e envolvimento de diversas partes interessadas.
Um estudo de mapeamento sistemático sobre o processo de desenvolvimento de so...Robson de Negreiros
O documento descreve um estudo de mapeamento sistemático sobre os processos de desenvolvimento de software de código aberto. O estudo analisou trabalhos primários para comparar as atividades dos processos de código aberto e tradicionais. Concluiu que as atividades de manutenção são as mais diferentes, com a comunidade de código aberto tendo um processo mais de reinvenção do que manutenção tradicional. Um trabalho relacionado encontrou ainda mais diferenças nas atividades de manutenção.
1) O documento discute pensamento sistêmico e mapeamento de sistemas, incluindo como traçar padrões de comportamento e relações causais entre variáveis.
2) É explicado o que é um mapa sistêmico e como ele representa variáveis e relações de causa e efeito.
3) São descritos diferentes tipos de relações como enlaces, enlaces reforçadores, enlaces balanceadores e atrasos.
Apresentação do método Revisão Sistemática da Literatura - Systematic Literature Review (SLR) - na I Capacitação em Metodologia de Pesquisa Científica do Programa de Pós-Graduação e Pesquisa em Administração (PPGA/UFPB) - em 2012.
O documento descreve os principais aspectos de uma revisão sistemática da literatura, comparando-a com uma revisão narrativa. Ele explica o que é uma revisão sistemática, suas características e o método proposto por Rother, E.T., incluindo a formulação da pergunta de pesquisa, a busca de estudos, a avaliação crítica, a extração e síntese dos dados. O documento também apresenta um exemplo de revisão sistemática publicada em uma conferência.
Revisão Sistemática é uma metodologia de estudo secundário que visa estabelecer um levantamento formal do estado da arte, de forma robusta e consistente, a partir de um planejamento e execução criteriosos. O processo de pesquisa é conduzido segundo uma série metodologicamente bem definida de etapas, de acordo com um protocolo de estudo previamente planejado.
O documento introduz os principais conceitos de revisão sistemática da literatura, incluindo seus objetivos, tipos de estudos e a importância de um protocolo de revisão bem estruturado. Explica como definir questões de pesquisa e desenvolver um plano de busca, seleção, avaliação e síntese dos estudos de forma transparente e replicável.
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenhari...Erivan de Sena Ramos
Este documento apresenta um resumo de uma monografia sobre um mapeamento sistemático de padrões de software para reengenharia de sistemas. O documento descreve o autor, a instituição, o título, o orientador e as informações bibliográficas da monografia.
Aula 3 revisão de literatura e metodologiabioalvarenga
O documento fornece orientações sobre a metodologia de pesquisa científica, incluindo a revisão de literatura e as etapas de um projeto de pesquisa, como introdução, objetivos, metodologia, cronograma e orçamento. A revisão de literatura é fundamental para contextualizar teoricamente o problema de pesquisa, enquanto as etapas de um projeto garantem a coerência e o encadeamento lógico do trabalho.
This document introduces systematic reviews, covering their objectives, differences from traditional reviews, characteristics, and process. The process involves planning, conducting searches and study selection, assessing quality, extracting and synthesizing data, and documentation. Systematic reviews aim to comprehensively identify and analyze all available research on a topic to summarize evidence and identify gaps.
Engenharia de software é a área voltada para especificação, desenvolvimento e manutenção de sistemas de software. Modelagem objetiva manter aplicações robustas e fáceis de manter, evitando problemas futuros. Análise investiga problemas e requisitos, enquanto projeto foca em soluções para esses requisitos.
O documento descreve o Rational Unified Process (RUP), um processo de engenharia de software que utiliza uma abordagem iterativa e orientada a objetos. O RUP é dividido em quatro fases principais (concepção, elaboração, construção e transição) e nove disciplinas agrupadas em disciplinas de engenharia e disciplinas de apoio. A disciplina de modelagem de negócios é a primeira das seis disciplinas de engenharia e tem como objetivo estabelecer uma compreensão do negócio e dos requisitos do cliente.
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO ...Fábio Pio
Este artigo discute como o desenvolvimento dirigido a testes, uma prática ágil, pode contribuir para a criação de software de qualidade. O artigo faz uma revisão bibliográfica sobre garantia da qualidade, ciclos de teste tradicionais e desenvolvimento dirigido a testes. Também apresenta um estudo de caso aplicando questionários a desenvolvedores para avaliar suas percepções sobre as abordagens.
O documento discute técnicas de desenvolvimento de software da 4a geração, comparando metodologias tradicionais e ágeis. Também apresenta o Rational Unified Process (RUP), um processo iterativo e orientado a objetos que utiliza a notação UML para documentar as fases de concepção, elaboração, construção e transição.
O documento discute técnicas de desenvolvimento de software da 4a geração, comparando metodologias tradicionais e ágeis, e descreve o Rational Unified Process (RUP). O RUP é um processo iterativo e orientado a objetos com 4 fases - concepção, elaboração, construção e transição. Ele utiliza disciplinas como modelagem de negócios, requisitos, análise, projeto, implementação, teste e implantação.
O documento discute metodologias de desenvolvimento de software, especificamente o Rational Unified Process (RUP). O RUP é uma metodologia iterativa e incremental que utiliza a linguagem UML para modelagem. Ele define atividades como análise, projeto e implementação ao longo de fases como iniciação, elaboração e construção.
Este documento resume uma aula sobre processos de software. Apresenta conceitos como processo de software, modelos de processo de desenvolvimento de software, modelos de ciclo de vida como cascata e iterativos, além de linguagens, métodos e ferramentas CASE. O objetivo é introduzir os alunos aos principais elementos envolvidos no desenvolvimento de software.
Proposta TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVO...Juliano Oliveira
Este documento apresenta uma proposta de trabalho de conclusão de curso que visa mapear as práticas do framework Scrum aos processos de gerência e desenvolvimento de requisitos do MPS.BR. O objetivo é mostrar como o MPS.BR e o Scrum podem ser aplicados conjuntamente para melhorar a qualidade e agilidade dos processos de software. O trabalho será realizado por meio de pesquisas bibliográficas, análise dos resultados esperados do processo de requisitos do MPS.BR e mapeamento deste processo com as práticas do Scrum.
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
O documento discute o desenvolvimento ágil de software usando a metodologia Kanban. Apresenta as dificuldades do desenvolvimento de software tradicional e como as metodologias ágeis, incluindo Kanban, buscam solucionar esses problemas com foco em pessoas, interações e satisfação do cliente. Kanban usa um quadro visual para limitar o trabalho em progresso e melhorar o fluxo e a produtividade da equipe.
O documento descreve a aplicação das metodologias ágeis Scrum e XP em um processo de desenvolvimento de software. O artigo apresenta as características e práticas de Scrum e XP, como equipes pequenas, ciclos curtos de desenvolvimento e participação ativa do cliente. O objetivo é demonstrar como estas metodologias foram aplicadas em um ambiente organizacional para desenvolver software.
O documento discute o rejuvenescimento de software como forma de melhorar a qualidade e reduzir custos de manutenção. Apresenta estratégias como redocumentação, refatoração e engenharia reversa. Também aborda quando deve ser utilizado o rejuvenescimento e os tipos de manutenção de software.
Este documento apresenta um experimento acadêmico para implementar um processo de desenvolvimento de software livre adaptado ao modelo OSS em uma fábrica de software distribuída. O projeto piloto desenvolveu um sistema chamado Canto Livre para compartilhamento de conteúdo artístico usando licenças Creative Commons. O processo baseado no RUP envolveu papéis como analista, arquiteto e programadores dentro da fábrica, com contribuições da comunidade externa por meio de um integrador.
O documento descreve o IBM Rational Unified Process (RUP), um processo proprietário de engenharia de software criado pela Rational Software Corporation e agora de propriedade da IBM. O RUP usa uma abordagem orientada a objetos e é projetado para aumentar a produtividade das equipes de desenvolvimento de software. Ele define linhas mestras, fases e princípios como gestão de requisitos, uso de arquitetura baseada em componentes e modelagem visual para guiar o desenvolvimento de software.
Este artigo analisa as metodologias híbridas de desenvolvimento de software baseadas em publicações de autores que já contribuíram com a comunidade científica e acadêmica através de pesquisas e estudos de casos abordando o tema. Primeiramente, aborda-se uma série de acontecimentos, em ordem cronológica, que vão desde as primeiras soluções pensadas para fazer frente à crise de software até o surgimento dos métodos híbridos. Em seguida, são detalhadas algumas metodologias mais conhecidas, tanto tradicionais, quanto ágeis. Feito isso o uso dos paradigmas híbridos é descrito, e por fim, o trabalho é concluído com a análise dos trabalhos analisados.
Este documento apresenta o professor Rodrigo Gomes da Silva e seu seminário sobre o Processo Iterativo com RUP. Ele fornece seus contatos, certificações, formação acadêmica e experiência profissional, além da agenda do seminário, que inclui tópicos como sintomas de problemas em desenvolvimento de software, as melhores práticas da engenharia de software, princípios do desenvolvimento iterativo, o processo RUP e suas fases, disciplinas, papéis e artefatos.
O documento descreve como um ambiente de desenvolvimento de software foi criado utilizando ferramentas como Netbeans, Grails e Visual Paradigm para UML. O ambiente foi usado para desenvolver a aplicação G-INFO utilizando Scrum. Diagramas de classe e banco de dados foram criados para especificar os requisitos da aplicação.
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processocrc1404
1) A metodologia desenvolvida pelo CenPRA visa implantar ou melhorar o processo de teste de software em empresas.
2) A metodologia inclui treinamento, um processo de teste genérico e suporte para geração de documentos de teste baseados na norma IEEE 829.
3) A metodologia foi aplicada com sucesso em uma empresa de software para melhorar seu processo de teste.
Este documento apresenta conceitos básicos de engenharia de software. Ele discute sistemas e suas características, definindo software como um sistema. Também apresenta definições formais de sistemas e engenharia de sistemas. Por fim, descreve engenharia de software como uma tecnologia em camadas focada na qualidade, processos, métodos e ferramentas.
Semelhante a Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas (20)
Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
1. Um Mapeamento Sistemático sobre Padrões de
Software para Reengenharia de Sistemas
E. S. Ramos e M. M. A. Brasil
Resumo— Este trabalho teve como objetivo investigar, software são descrições que aconselham soluções práticas para
catalogar e classificar os padrões para reengenharia de sistemas determinado problema; podendo ser aplicados durante a
publicados em conferências e workshops PLoP (Pattern modelagem e codificação de um software, de acordo com o
Languages of Programs), por meio de um estudo de mapeamento contexto e as circunstâncias apresentadas. Os padrões de
sistemático. Além da catalogação bibliográfica, o estudo apresenta
a totalização dos padrões quanto ao tipo de processo de
software aplicados na reengenharia visam registrar o
reengenharia; o levantamento das linguagens de programação conhecimento sobre como modificar softwares legados, ajudam
abordadas, as Conferências e Workshops onde os padrões foram a diagnosticar problemas, e identificam as soluções mais
publicados, bem como a evolução das publicações por ano. Quanto apropriadas aos novos requisitos [8]. Nesse sentido, uma
à classificação, os padrões de reengenharia foram categorizados catalogação bibliográfica, bem como uma classificação desses
de acordo com as disciplinas do RUP (Rational Unified Process). padrões, pode ajudar o engenheiro de software a localizar e
Palavras-chave— Sistemas Legados. Reengenharia. Padrões de identificar rapidamente o melhor padrão a ser utilizado em seu
Software. PLoP. RUP. Mapeamento Sistemático. projeto de reengenharia de software.
Abstract— Through a systematic mapping studies, this II. MAPEAMENTO SISTEMÁTICO
work aimed to investigate, catalog and classify the patterns
for systems reengineering published in conferences and O mapeamento sistemático é um tipo de revisão
workshops PLoP (Pattern Languages of Programs). In addition to sistemática, onde se realiza uma revisão mais ampla dos
cataloging literature, the study presents the aggregation of estudos primários, em busca de identificar quais evidências
standards regarding the type of process reengineering, estão disponíveis, bem como identificar lacunas no conjunto
the survey of programming languages discussed, as well as dos estudos primários onde seja direcionado o foco de revisões
conferences and workshops and the development of publications sistemáticas futuras e identificar áreas onde mais estudos
per year. Regarding classification, patterns of reengineering were primários precisam ser conduzidos [9]. O estudo de
categorized according to the disciplines of the RUP (Rational mapeamento sistemático fornece uma visão geral de uma área
Unified Process). de pesquisa, identificando a quantidade, tipo de pesquisas,
Keywords— Legacy Systems. Reengineering. Software resultados disponíveis, além de freqüências de publicações ao
Patterns. PLoP. RUP. Systematic Mapping Studies. longo do tempo para identificar tendências [10].
I. INTRODUCÃO O presente artigo apresenta a pesquisa de [11], na qual foi
realizado um mapeamento sistemático, por ser mais adequado
As organizações têm um alto custo de dinheiro quando
ao escopo da mesma, utilizando-se da mesma metodologia de
investem em um software e, para que haja um retorno
base da revisão sistemática com a intenção de se obter uma
financeiro satisfatório, este software é utilizado por muitos
revisão rigorosa, confiável e passível de auditoria. O capítulo a
anos [1]. Em contrapartida, o software é um produto que deve
seguir apresenta o processo do mapeamento sobre os padrões
estar em constante evolução de acordo com mudanças nas
de reengenharia de sistemas conduzido neste trabalho, bem
regras de negócio das organizações, necessidade de melhoria
como analisa os resultados de acordo com as questões de
do processo produtivo ou adequação do produto ou serviço que
pesquisa previamente definidas.
utiliza tecnologia da informação [2]. A esses softwares
utilizados ao longo do tempo pelas organizações dá-se o nome III. MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE
de sistemas legados. Tais sistemas normalmente não possuem SOFTWARE PARA REENGENHARIA DE SISTEMAS
documentação, ou possuem documentação desatualizada.
Esses, dentre outros fatores, dificultam e aumentam o custo da A. Planejamento – Definição do Protocolo
manutenção dos mesmos; incentivando os pesquisadores a 1) Descrição do Problema
buscarem soluções que facilitem a redução dos custos com a
manutenção [3]. Para que os sistemas legados se mantenham alinhados às
expectativas dos negócios das organizações, é necessário que
Quando um importante sistema legado não tem mais haja constantemente a manutenção e evolução dos mesmos.
capacidade de suportar as mudanças em seus requisitos, Devido à criticidade existente em projetos que prevêem a
comumente, é submetido ao processo de reengenharia [4], que manutenção ou evolução de um sistema legado, a utilização de
consiste em um processo de análise de sistemas legados que Padrões de Software apresenta-se como uma alternativa viável
identifica e representa seus componentes em um nível mais alto no sentido de minimizar o consumo de tempo e de esforço,
de abstração [5]. A reengenharia de sistemas apresenta-se como melhorar a qualidade do produto final e, por conseguinte,
um dos maiores desafios para os engenheiros de software, pois, diminuir os custos financeiros do projeto à organização. Para
embora trate um problema comum e persistente nas diminuir a dificuldade de entendimento e utilização, se faz
organizações, seus resultados interferem diretamente na necessário um esquema de organização dos padrões existentes,
continuidade dos negócios das mesmas [6]. que tratam de reengenharia em sistemas legados.
Diante desse contexto, os padrões de software surgem como 2) Objetivo
uma ferramenta capaz de auxiliar o engenheiro de software em
um processo de reengenharia. Conforme [7] os padrões de O foco deste mapeamento sistemático foi identificar,
2. catalogar, e classificar os Padrões de Software documentados Languages Of Program; ParaPLoP - Workshop on Parallel
para reengenharia, com o intuito de contribuir de forma Programming Patterns; Scrum PLoP; Viking PLoP - Nordic
substancial no entendimento dos mesmos e torná-los de fácil Conference On Pattern Languages Of Programs; PEAM -
consulta para o engenheiro de software. Pretendendo realizar European Workshop on Patterns for Enterprise Architecture
ainda um levantamento dos padrões publicados por tipo de Management; ChiliPloP; KoalaPLoP e MensorePLoP.
processo, linguagem de programação, conferências/workshops
e ano de publicação. 6) Critérios para Inclusão e Exclusão dos Estudos
3) Questões de Pesquisa Os critérios definidos para inclusão e exclusão dos estudos
são apresentados a seguir na Tabela I. Os estudos que não
As questões a serem respondidas ao final da pesquisa são: atenderam aos critérios abaixo descritos foram
desconsiderados.
Q1. Quais os padrões de reengenharia publicados nas
Conferências e Workshops especializados em padrões de TABELA I. CRITÉRIOS DE INCLUSÃO E EXCLUSÃO
software? 1 Os estudos devem ter sido publicados nas Conferências e Workshops
Q2. Como se classificam os padrões de reengenharia, listados no item 5.
publicados nas Conferências e Workshops especializados 2 Os estudos devem estar escritos em inglês ou português;
3 Os estudos devem estar disponíveis na web;
em padrões de software, quanto às disciplinas do processo 4 Os estudos que apresentem alguma das strings de busca em seu título,
de engenharia de software RUP? resumo/abstract ou palavras-chaves;
Q3. Os padrões publicados apresentados abordam qual 5 Os estudos devem apresentar a proposta de um ou mais padrões de
tipo de processo de reengenharia: Engenharia Reversa, reengenharia em sistemas.
Engenharia Avante ou Reestruturação?
Q4. Os usos conhecidos dos padrões publicados abordam 7) Critério de Qualidade dos Estudos
quais linguagens de programação? A única questão considerada para a qualidade dos estudos é
Q5. Quais Conferências e Workshops têm apresentado em apresentada a seguir na Tabela II. Após a seleção dos estudos,
seus anais padrões para reengenharia de sistemas? Em somente foram considerados os padrões que apresentaram a
quais anos? Quem se destaca em números de estudos e descrição completa do mesmo, garantindo dessa forma a
padrões publicados? integridade do resultado da revisão.
TABELA II. CRITÉRIO DE QUALIDADE
População: Publicações contendo Padrões de Software.
1 Os estudos apresentam padrões de reengenharia documentados em um
Intervenção: Padrões de Software para Reengenharia. formato de escrita de padrões, descritos de forma explícita e
organizada.
Resultados: Catalogação bibliográfica dos padrões de
reengenharia; classificação dos padrões de reengenharia; 8) Método de Avaliação dos Estudos
totalização dos padrões quanto ao tipo de processo de
reengenharia; levantamento das linguagens de programação Cada estudo, realizado de acordo com o método
abordadas em padrões de reengenharia; levantamento da estabelecido para a pesquisa de fontes primárias, foi avaliado
evolução das publicações de padrões de reengenharia. de acordo com os critérios para inclusão e exclusão. Os estudos
que se enquadraram nesses critérios foram utilizados para a
4) Palavras-Chave finalidade do mapeamento sistemático.
As palavras-chave utilizadas como strings de busca foram 9) Método de Extração dos Dados
as seguintes: sistema legado; software legado; aplicação
legada; padrão de reengenharia; engenharia reversa; engenharia A extração dos dados foi realizada como descrito abaixo:
avante; reestruturação; reengenharia; legacy system; a) Pesquisador aplica a estratégia de pesquisa para identificar
reengineering pattern; reverse engineering; forward os potenciais estudos primários. A identificação dos estudos
engineering; restructuring; e reengineering. primários é realizada por meio da leitura do título,
5) Método Utilizado para Pesquisa de Fontes Primárias resumo/abstract e palavras–chave em busca das strings de
busca. A busca é registrada por meio de um Formulário de
O método utilizado para a pesquisa de fontes primárias foi Condução da Revisão;
realizar buscas nos anais das conferências PLoP (Pattern b) O conjunto de estudos é selecionado a partir da verificação
Languages of Programs), grupo de conferências anuais dos critérios de inclusão e exclusão. A seleção
1
apoiadas pelo The Hillside Group , com o objetivo de (inclusão/exclusão) dos estudos é feita por meio de uma
desenvolver e aperfeiçoar a arte de padrões de projeto de leitura superficial dos estudos primários, tendo como foco
software: PLoP – Conference On Pattern Languages Of identificar os critérios estabelecidos. A etapa de seleção é
Programs; Sugarloaf PLoP – Conferência Latino-Americana documentada em um Formulário de Seleção dos Estudos;
em Linguagens de Padrões para Programação; EuroPLoP - c) Todos os estudos incluídos como resultados da pesquisa
European Conference On Pattern Languages Of Programs; inicial são revisados, inteira e minuciosamente, por outro
Meta EuroPLoP; Asian PLoP - Asian Conference On Pattern pesquisador.
d) Os resultados são revisados por todos os pesquisadores
1 envolvidos e quaisquer desacordos são discutidos e
O The Hillside Group (http://hillside.net/) promove o uso, registro, análise e
suporte às novas práticas de linguagens de padrões de software. resolvidos.
3. e) Os resultados da revisão, que conta com os detalhes das TABELA III. CATALOGAÇÃO DOS PADRÕES DE REENGENHARIA DE
pesquisas realizadas nos estudos primários selecionados, SISTEMAS
são registrados em um Formulário de Extração dos Dados. Id Título Referência
1 Preparar o Processo de Reengenharia [12]
10) Método da Síntese dos Dados 2 Planejar o Processo de Reengenharia
3 Acompanhar o Progresso de Reengenharia
Foi realizada uma meta-análise sobre os dados quantitativos 4 Realizar Inspeção de Garantia de Qualidade
dos estudos. Os dados dos estudos selecionados foram 5 Controlar a Configuração
comparados, com a finalidade de realçar as similaridades e 6 Elaborar Lista de Procedimentos e Funções
diferenças entre os estudos de acordo com as questões da 7 Elaborar Lista de "Chama/Chamado Por"
8 Modelar Dados do Software Legado
pesquisa. 9 Criar Lista de Anomalias
B. Condução da Revisão 10 Criar Visão OO de Dados
11 Criar Diagramas de Caso de Uso do MASA
Dentre as fontes definidas inicialmente no protocolo 12 Descrever Casos de Uso do MASA
somente não foi possível obter acesso aos anais das 13 Abstrair Diagrama de Pseudo-Classes
Conferências ChiliPloP; KoalaPLoP; e MensorePLoP. Desta 14 Criar Diagramas de Caso de Uso do MAS
15 Descrever Casos de Uso do MAS
forma, a busca foi realizada em 57 Anais de 9 tipos de 16 Elaborar Diagrama de Classes de Projeto
Conferências e Workshops especializadas em Padrões de 17 Construir Diagramas de Sequência
Software, conforme detalhado a seguir: 18 Implementar as Classes
19 Implementar a Lógica de Armazenamento
• PLoP: 17 edições, entre 1994 e 2004; 20 Implementar a Lógica de Apresentação
• Sugarloaf PLoP: 08 edições, entre 2001 e 2010; 21 Speculate about Domain Objects [13]
22 Reconstruct the Persistent Data
• EuroPLoP: 16 edições, entre 1996 e 2011;
23 Identify the Largest
• Meta EuroPLoP: 01 edição em 2011; 24 Recover the Refactorings
• Asian PLoP: 01 edição em 2010; 25 Tie Code and Questions [14]
• ParaPLoP: 03 edições, entre 2009 e 2011 26 Transform Self Conditional to Subclassing [15]
27 Transform Client Conditional to Polymorphism
• Scrum PLoP: 02 edições, entre 2010 e 2011; 28 Apply State
• Viking PLoP: 07 edições, entre 2002 e 2008; e 29 Apply Null Object
• PEAM: 02 edições, em 2009 e 2010. 30 Type Check Elimination in a Provider Hierarchy [4]
31 Type Check Elimination in Clients
O processo de busca foi executado utilizando as palavras- 32 The Bridge to the New Town [16]
33 Reengineering for Parallelism [17]
chave definidas (subseção 3.4) e seguindo o método de
34 Mile-Wide, Inch Deep [18]
pesquisa de fontes primárias do protocolo (subseção 3.5). 35 Keeper of the Flame
36 Archetype
A consulta obteve êxito somente nas seguintes fontes: 37 Iniciar Análise dos Dados [5]
• PLoP: 3 estudos encontrados e pré-selecionados. 38 Definir Chaves
39 Identificar Relacionamentos
• Sugar Loaf PLoP : 6 encontrados e pré-selecionados. 40 Criar Visão OO dos Dados
• EuroPLoP: 7 encontrados e pré-selecionados. 41 Obter Cenários
42 Construir Diagramas de Use Cases
Desta forma, 16 estudos foram contabilizados, os quais 43 Elaborar a Descrição de Use Cases
foram lidos e verificados através dos critérios de inclusão e 44 Tratar Anomalias
45 Definir as Classes
exclusão estabelecidos. Dos 16 artigos pré-selecionados, 12 46 Definir Atributos
estavam de acordo com todos os critérios previstos no 47 Analisar Hierarquias
protocolo de revisão e tiveram seus dados extraídos e 48 Definir Métodos
analisados. Os 4 estudos excluídos não atendiam ao critério de 49 Construir Diagramas de Seqüência
inclusão e exclusão. 50 Definir hierarquia Chama/Chamado [3]
51 Identificar Casos de Uso
C. Apresentação, Análise e Discussão dos Resultados 52 Identificar Supostas Classes e Supostos Atributos
53 Identificar Supostos Métodos
Aqui são respondidas as questões de pesquisa delineadas no 54 Identificar Relacionamentos
planejamento da revisão. Nos 12 estudos selecionados, 67 55 Identificar Cardinalidades
padrões para reengenharia foram identificados. 56 Criar Supostas Classes e Supostos Atributos
57 Alocar Supostos Métodos nas Supostas Classes
1) Resultados obtidos para a questão 1 (Q1 - Quais os padrões 58 Criar Especificações das Classes e dos Atributos
59 Criar Especificações dos Métodos
de reengenharia publicados nas Conferências e Workshops
60 Criar Casos de Uso
especializados em padrões de software?) 61 Criar Diagrama de Seqüência
62 Criar Especificações dos Relacionamentos e
Foi realizada a catalogação bibliográfica dos 67 padrões Cardinalidades
selecionados no mapeamento sistemático, a qual é apresentada 63 Definir Plataforma [6]
64 Converter o Banco de Dados
na Tabela III. Alguns estudos [13] [18] ainda citavam padrões 65 Implementar Métodos
com suas descrições incompletas, os quais foram 66 Realizar Melhorias de Interface
desconsiderados para não afetarem as questões de pesquisa do 67 Reverse Variability Engineering [19]
mapeamento sistemático.
4. 2) Resultados obtidos para a questão 2 (Q2- Como se Análise e Projeto 6 Elaborar Lista de Procedimentos e Funções
classificam os padrões de reengenharia, publicados nas 7 Elaborar Lista de "Chama/Chamado Por"
8 Modelar Dados do Software Legado
Conferências e Workshops especializados em padrões de 9 Criar Lista de Anomalias
software, quanto às disciplinas do processo de engenharia 10 Criar Visão OO de Dados
de software RUP?) 13 Abstrair Diagrama de Pseudo-Classes
16 Elaborar Diagrama de Classe do Projeto
17 Construir Diagramas de Sequência
Os padrões foram classificados de acordo com as 9 21 Speculate about Domain Objects
disciplinas do RUP, observando as características e propostas 22 Reconstruct the Persistent Data
de cada padrão apresentado, relacionado-os com os propósitos 23 Identify the Largest
e atividades realizadas em cada disciplina. Não foram levadas 24 Recover the Refactorings
em consideração as linguagens ou grupos dos padrões, somente 26 Transform Self Conditional to Subclassing
27 Transform Client Conditional to Polymorphism
suas características individuais. A Fig. 1 mostra graficamente a 28 Apply State
distribuição dos padrões após a classificação realizada. 29 Apply Null Object
30 Type Check Elimination in a Provider
Hierarchy
31 Type Check Elimination in Clients
33 Reengineering for Parallelism
34 Mile-Wide, Inch Deep
35 Keeper of the Flame
36 Archetype
37 Iniciar Análise dos Dados
38 Definir Chaves
39 Identificar Relacionamentos
40 Criar Visão OO dos Dados
41 Obter Cenários
44 Tratar Anomalias
45 Definir as Classes
46 Definir Atributos
47 Analisar Hierarquias
Figura 1. Porcentagem de Padrões por Disciplina do RUP 48 Definir Métodos
49 Construir Diagramas de Seqüência
Observa-se que a disciplina Análise e Projeto, com o 50 Definir hierarquia Chama/Chamado
percentual de 66%, abrange o maior número dos padrões de 52 Identificar Supostas Classes e Supostos
reengenharia, seguida da disciplina Requisitos com 13%. Já as Atributos
53 Identificar Supostos Métodos
disciplinas Testes e Implantação não são apresentadas no 54 Identificar Relacionamentos
gráfico porque não envolvem nenhum padrão de reengenharia 55 Identificar Cardinalidades
selecionado durante o mapeamento sistemático. A 56 Criar Supostas Classes e Supostos Atributos
classificação dos padrões por disciplina do RUP é apresentada 57 Alocar Supostos Métodos nas Supostas Classes
na Tabela IV. O número identificador (Id) corresponde a 58 Criar Especificações das Classes e dos
Atributos
seqüência definida na Tabela 3. 59 Criar Especificações dos Métodos
61 Criar Diagrama de Seqüência
62 Criar Especificações dos Relacionamentos e
TABELA IV. CLASSIFICAÇÃO DOS PADRÕES DE REENGENHARIA POR Cardinalidades
DISCIPLINA DO RUP
Disciplina Id Padrão 67 Reverse Variability Engineering
Modelagem de Negócios 1 Preparar o Processo de Reengenharia
Requisitos 11 Criar Diagramas de Caso de Uso do MASA 3) Resultados obtidos para a questão 3 (Q3 - Os padrões
12 Descrever Casos de Uso do MASA
14 Criar Diagramas de Caso de Uso do MAS publicados apresentados abordam qual tipo de processo de
15 Descrever Casos de Uso do MAS reengenharia?)
41 Obter Cenários
42 Construir Diagramas de Use Cases No que se refere ao processo de reengenharia, os padrões
43 Elaborar a Descrição de Use Cases
51 Identificar Casos de Uso
apresentados apresentam o seguinte panorama:
60 Criar Casos de Uso
Gerência de Projeto 2 Planejar o Processo de Reengenharia
• Total de Padrões de Engenharia Reversa: 49;
3 Acompanhar o Progresso de Reengenharia • Total de Padrões de Engenharia Avante: 10;
4 Realizar Inspeção de Garantia de Qualidade • Total de Padrões de Reestruturação: 3.
Implementação 18 Implementar as Classes
19 Implementar a Lógica de Armazenamento
A Fig. 2 representa de forma clara o quanto a Engenharia
20 Implementar a Lógica de Apresentação
25 Tie Code and Questions Reversa é o processo predominante abordado nas publicações,
64 Converter o Banco de Dados representando 73% dos padrões apresentados e incluídos na
65 Implementar Métodos pesquisa, enquanto que a Engenharia Avante representa 13% e
66 Realizar Melhorias de Interface a Reestruturação apenas 5% dos padrões de reengenharia. A
Ambiente 63 Definir Plataforma
publicação de [12] apresenta ainda 05 padrões que não se
Configuração e Gerência 5 Controlar a Configuração
de Mudança 32 The Bridge to the New Town enquadram nos três processos indicados. Os mesmos tratam da
aplicação de diretrizes de qualidade durante o projeto.
5. 5) Resultados obtidos para a questão 5 (Q5 - Quais
Conferências e Workshops têm apresentado publicações
com padrões de reengenharia de sistemas? Em quais
anos? Quem se destaca em números de estudos e
padrões publicados?)
De acordo com os estudos selecionados, foi verificada a
periodicidade das publicações sobre o tema analisado, bem
como, o ranking dos padrões publicados, levando em conta
a Conferência no qual o trabalho foi defendido e o ano de
sua publicação. Na Fig. 4, pode-se verificar a evolução do
número de publicações com padrões de reengenharia. Pode-
se inferir que o número de publicações tem sido pequena,
Figura 2. Percentual de Padrões por Processo de Reengenharia com exceção do ano de 2000 (um único trabalho foi o
4) Resultados obtidos para a questão 4 (Q4 - Os usos responsável, pois apresentou uma linguagem de padrões) e
conhecidos dos padrões publicados abordam qual tipo 2003. Também é importante ressaltar que a EuroPLoP
apresenta um maior número publicações relacionadas ao
de linguagem de programação?)
tema pesquisado.
Foram analisadas nos estudos quais as linguagens de
programação que podem utilizar-se dos padrões de
reengenharia. Dos 67 padrões selecionados durante o
mapeamento sistemático, 28% não citam ou não especificam
uma linguagem de programação nos usos conhecidos do
padrão. Verificou-se então que as linguagens de
programação abordadas nos estudos, de usos conhecidos na
aplicabilidade dos padrões de reengenharia, são: Java (02
padrões); Stalmak (07 padrões); C/C++ (11 padrões); Ada
(11 padrões); Clipper (17 padrões); COBOL (17 padrões);
RPGII (17 padrões); e Delphi (20 padrões)
A Fig. 3 apresenta a quantidade de padrões que podem
ser empregados por cada linguagem de programação. Figura 4. Estudos publicados por ano.
Enquanto a linguagem de programação Delphi abrange uma Quando se refere à quantidade de padrões apresentados
maior quantidade de padrões de reengenharia, totalizando 20 nos artigos selecionados, a Fig. 5 mostra que o ano de 2003
padrões, a linguagem Java apresenta a menor abrangência apresentou maior número. Conclui-se ainda que em se
com apenas 2 padrões. Em geral, nota-se uma tratando de quantidade de padrões de reengenharia
predominância de linguagens de programação procedurais. apresentados, o SugarLoafPLoP se destaca com o maior
Vale ressaltar que, embora alguns padrões apresentem número de publicações.
como uso conhecido uma linguagem de programação
específica, nada impede que o mesmo padrão seja adaptado
para ser utilizado por outra linguagem.
Figura 5. Padrões apresentados por ano
Totalizando os anos de 2002 e 2003, o SugarLoafPLoP
apresentou 50 padrões de reengenharia em 4 publicações.
Enquanto o EuroPLoP apresentou 16 padrões em 7
Figura 3. Quantidade de Padrões por Linguagem de Programação publicações (1998, 2000 e 2009) e o PLoP apresentou
O estudo de [12] apresenta um bom exemplo disso, no apenas 1 padrão (2005) sobre o tema.
qual os 20 padrões de reengenharia apresentados foram
originalmente desenvolvidos para serem usados em um IV. CONCLUSÃO
sistema desenvolvido na linguagem Clipper e depois foram Este trabalho teve por objetivo avaliar os padrões de
instanciados para softwares implementados em Delphi. software para reengenharia de sistemas por meio do
6. processo de mapeamento sistemático, um modo mais amplo para o Processo de Engenharia Avante na Reengenharia Orientada a
de se aplicar uma revisão sistemática. Objetos de Sistemas Legados Procedimentais”, in: Sugar Loaf PLoP
2003, Porto de Galinhas-PE, 2003.
O mapeamento sistemático foi conduzido por um [7] C. Larman, “Utilizando UML e Padrões”, 3ª ed., São Paulo:
protocolo de revisão que especificou os métodos utilizados Bookman, 2005.
durante a condução do trabalho. Os critérios definidos no [8] G. S. Lemos, “PRE/OO – Um Processo de Reengenahria Orientada
protocolo foram necessários e suficientes para se obter os a Objetos com Ênfase na Garantia da Qualidade”, 171f. Dissertação
estudos primários necessários para a realização da pesquisa. (Mestre em Ciência da Computação) – Universidade Federal de São
Carlos, São Carlos, 2002.
A realização de um mapeamento sistemático se mostra uma
[9] B. Kitchenham, “Procedures for Performing Systematic Reviews”,
metodologia eficaz, embora dispendiosa de tempo, que Technical Report Software Engineering Group, Keele University,
envolve um trabalho árduo de leitura e análise dos estudos Australia, 2004.
primários para se obter respostas às questões levantadas para [10] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, “Systematic
a pesquisa. Mapping Studies in Software Engineering”, in: 12th International
Conference on Evaluation and Assessment in Software Engineering,
A partir dos resultados obtidos na pesquisa, foi possível Australia, 2008.
responder às questões levantadas. Assim, foi possível [11] E. S. Ramos, M. M. A. Brasil, “Um Mapeamento Sistemático sobre
realizar a catalogação bibliográfica de 67 padrões Padrões de Software para Reengenharia de Sistemas”, 80f.
relacionados à reengenharia de sistemas, bem como o Monografia (Especialização em Engenharia de Software com
levantamento dos processos e linguagens de programação Ênfase em Padrões de Software) – Universidade Estadual do Ceará,
abordadas, além da classificação dos padrões selecionados Fortaleza-CE, 2011.
de acordo com as disciplinas do processo de engenharia de [12] G. S. Lemos, E. Recchia, R. Penteado. R. Braga, “Padrões de
software RUP. Acredita-se que a presente pesquisa Reengenharia auxiliados por Diretrizes de Qualidade de Software”,
in: SugarLoafPLoP 2003, Porto de Galinhas- PE, 2003.
apresenta benefícios nos seguimentos: acadêmico e
[13] S. Demeyer. S. Ducasse, O. Nierstrasz, “A Pattern Language for
profissional. Reverse Engineering”, in: EuroPLoP 2000, Irsee – Germany, 2000.
No que diz respeito ao benefício acadêmico, os [14] S. Demeyer, S. Ducasse, O. Nierstrasz, “Tie Code And Questions: a
levantamentos quanto à linguagem de programação e ao Reengineering Pattern”, in: EuroPLoP 2000, Irsee – Germany,
processo de reengenharia apontam quais as áreas necessitam 2000.
de mais pesquisas. No que se refere à linguagem de [15] S. Demeyer, S. Ducasse, O. Nierstrasz, “Transform Conditionals: a
Reengineering Pattern Language”, in: EuroPLoP 2000, Irsee –
programação (levando em consideração os padrões que Germany, 2000.
identificaram as linguagens de programação abordadas),
[16] W. Keller, “The Bridge to the New Town - A Legacy System
verificou-se que há um menor número de padrões que Migration Pattern”, in: EuroPLoP 2000, Irsee-Germany, 2000.
atendem à reengenharia de linguagens de programação [17] B. Massingill, T. Mattson, B. Sanders, “Reengineering for
orientadas a objetos. Quanto ao processo de reengenharia, Parallelism: An Entry Point into PLPP (Pattern Language for
padrões para a Engenharia Avante e para a Reestruturação Parallel Programming) for Legacy Applications”, in: PLoP 2005,
estão em menor número (necessitando talvez de uma maior Monticello, Illinois, USA, 2005.
atenção por parte dos pesquisadores), enquanto que padrões [18] A. O’Callaghan, “Patterns for Architectural Praxis”, in: EuroPLoP
que tratam de Engenharia Reversa são a maioria. 2000, Irsee, NYrmany, 2000.
[19] Schütz, “Reverse Variability Engineering”, in: EuroPLoP 2009,
No que diz respeito ao benefício profissional, a Bavaria-Germany, 2009
catalogação bibliográfica, bem como a classificação
realizada, beneficiam o engenheiro de software no momento Erivan de Sena Ramos é Especialista em Engenharia de Software com
da seleção dos padrões a serem utilizados em um projeto de Ênfase em Padrões de Software pela UECE - Universidade Estadual do
reengenharia. Deste modo, este trabalho apresenta-se como Ceará. Bacharel em Sistemas de Informação pela Universidade Estácio de
uma fonte de consulta a padrões de reengenharia de Sá - Faculdade Integrada do Ceará. Atualmente é Analista de Sistemas na
Politec Global IT Services, uma empresa da Indra Company, prestando
sistemas, onde é possível eleger os padrões mais adequados serviços para o Banco do Nordeste do Brasil. Atua na área de Ciência da
e de acordo com as disciplinas do processo de engenharia de Computação, com ênfase em Engenharia de Software, desempenhando
software. atividades relacionadas à análise de requisitos e reengenharia de sistemas.
Marcia Maria Albuquerque Brasil é Mestre em Ciência da Computação
REFERÊNCIAS da UECE e integrante do Grupo de Otimização em Engenharia de Software
[1] I. Sommerville, “Engenharia de Software”, 8ª. ed., São Paulo: da UECE (GOES.UECE). Bacharel em Ciências da Computação pela
Addison-Wesley, 2007. Universidade Estadual do Ceará UECE, com Especialização em
Tecnologias de Banco de Dados pela Universidade de Fortaleza UNIFOR, é
[2] E. P. Zanlorenci, R. C. Burnett, “Abordagem da Engenharia de Analista de Sistemas do Serviço Federal de Processamento de Dados
Requisitos para Software Legado”, in: VI Workshop em Engenharia SERPRO. Atua na área de Ciência da Computação, com ênfase em
de Requisitos, Piracicaba- SP, 2003. Engenharia de Software, onde desempenha atividades relacionadas ao
[3] D. R. Peres, A. Alvaro, V. Fontanette, V. C. Garcia, A. F. Prado, R. desenvolvimento de software nas fases de requisitos e implementação.
T. V. Braga, “TB-REPP - Padrões de Processo para a Engenharia
Reversa baseado em Transformações”, in: Sugar Loaf PLoP 2003,
Porto de Galinhas- PE, 2003.
[4] S. Ducasse, R. Nebbe, T. Richner, “Type-Check Elimination: Two
Reengineering Patterns”, in: EuroPLoP 1998, Irsee, Germany, 1998.
[5] E. L. Recchia, R. Penteado, “FaPRE/OO: Uma Família de Padrões
para Reengenharia Orientada a Objetos de Sistemas Legados
Procedimentais”, in: Sugar Loaf PLoP, Rio de Janeiro, 2002.
[6] E. L. Recchia, G. S. Lemos, R. Penteado, R. T. V. Braga, “Padrões