Gerenciando Variabilidade e Reusabilidade em Linhas de Produto de Software

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

Download "Gerenciando Variabilidade e Reusabilidade em Linhas de Produto de Software"

Transcrição

1 Gerenciando Variabilidade e Reusabilidade em Linhas de Produto de Software Luiz Carlos d Oleron, Cleyton Mário de Oliveira Rodrigues Centro de Informática (CIn) Universidade Federal de Pernambuco Recife, PE, Brasil Improvess Olinda, PE, Brasil {lcadb, Gleibson Oliveira, Lúcio Santos Centro de Informática (CIn) Universidade Federal de Pernambuco Recife, PE, Brasil Improvess Olinda, PE, Brasil {grso, Abstract One of the biggest challenges in software companies is to identify and track changes in deployed solutions among its customers; applications originally similar but that have been customized or extended to serve more specific purposes. Maintenance on a system impacts, potentially, other customers, making an arduous task to manage the process variability without a process-guide, with explicitly roles, activities and artifacts. Recent advances in Software Engineering advocate, on the other hand, the use of engineering driven by models for Software Product Lines, where the management of variability is more intense. This paper presents, therefore, a process that combines the best of both worlds, development driven by models, covering management of variability, thus increasing productivity and reusability of artifacts within a software factory. Index Terms Variability Management, Process, Reuse, Software Product Line. I. INTRODUÇÃO Uma das experiências mais recentes em fábricas de software para acelerar a entrega de produtos/serviços ao mercado, sem impactar os recursos financeiros e humanos é remover do programador o trabalho de construir from the scracth a solução final. Neste novo contexto, ao invés de códigos, os modelos passam a ser os artefatos primários. Basicamente, estes modelos são abstrações em alto nível do domínio do problema a ser resolvido, independente de qualquer plataforma/linguagem de programação, os quais, por intermédio de sucessivas transformações automáticas ou manuais, são refinados até produzir o código final da aplicação. Este novo contexto centrado em modelos, todavia, ainda está longe de atingir a maturidade, devido à falta de ferramentas ou mesmo pelo uso inadequado destes modelos (apenas como documentação contemplativa)[1]. Linhas de Produto de Software (em inglês, Software Product Line-SPL) - conjunto de sistemas de software que satisfaz as necessidades de uma determinada parte do mercado [2] - é uma estratégia de desenvolvimento comumente aplicada para uma ampla gama de produtos. SPL incorpora reusabilidade dentro de uma família de produtos similares. Em contrapartida, Modelos de Domínio (em inglês, Domain Specific Modeling-DSM) é uma ramificação da Engenharia dirigida por modelos, onde são fabricados modelos utilizando uma linguagem de cunho específico, muitas vezes definida pelo próprio programador [3]. Mesmo havendo um conjunto de boas práticas reunindo os dois mundos (SPL + DSM) [4], existe a carência de um processo genérico, que sirva como um guia de atividades bem estruturadas a serem aplicadas sistematicamente, com os seus respectivos papéis, etapas e artefatos gerados. Este trabalho, portanto, apresenta o processo REUSE, fundamentado em um contexto de desenvolvimento baseado em modelos e que contenpla atividades críticas dentro de uma fábrica de produtos de software, como a gerência de variabilidade. O restante do artigo está organizado da seguinte forma. Nas seções 2 e 3, discutimos brevemente todo o arcabouço teórico que fundamenta esta pesquisa. Alguns trabalhos semelhantes são discutidos na seção 4. A seção 5 descreve o processo, utilizando a notação BPMN. Em seguida, na seção 6, nós consideramos um breve estudo de caso e, finalmente, conclusões e perspectivas para trabalhos futuros são discutidas na seção 7. II. DESENVOLVIMENTO DIRIGIDO POR MODELOS E MODELOS DE DOMÍNIO Desenvolvimento dirigido por modelos (em inglês, Model Driven Development-MDD) é um paradigma de desenvolvimento onde os modelos (gráficos ou textuais) não são mais artefatos meramente informais. Enquanto aumenta o nível de abstração da solução, independente de qualquer plataforma subjacente de codificação, é possível ganhar mais em termos de reutilização e produtividade. De acordo com Stahl e Volter (2006) [1], MDD introduz benefícios, tais como velocidade de desenvolvimento, qualidade de software e facilidade no gerenciamento de mudanças. Atkinson e Küuhne (2003) [5], definem a infra-estrutura de MDD como: conceitos, regras e restrições do domínio além de uma notação formal para a definição de modelos expressivos, adaptáveis, abstratos, que são facilmente exportados para outras plataformas, além de geradores de código automático inteligentes. À luz do novo contexto de desenvolvimento, DSM emerge como uma solução de duas vias: Em primeiro lugar, eleva

2 o nível de abstração além da programação, especificando a solução em uma linguagem que usa diretamente conceitos e regras de um determinado problema de domínio. Em seguida, gera produtos finais em uma linguagem de programação escolhida ou outra forma a partir dessas especificações de alto nível [3]. III. ANÁLISE DE DOMÍNIO: GERÊNCIA DE VARIABILIDADE Gerência de Variabilidade representa a definição do escopo, similaridades e variabilidades entre os produtos de software de uma única família [6], [7]. Esta análise pode ser realizada a nível de componentes, arquitetura, artefatos e até mesmo, casos de teste [8]. Variabilidade pode ser definida como [...] a capacidade de um requisito de se adaptar aos usos em contextos de produtos diferentes que estão no escopo da linha de produtos [9]. Essa idéia se torna mais clara em fábricas de SPL: uma atividade corriqueira no processo de análise e desenvolvimento de soluções [6], [10]. Para a reusabilidade, é necessário analisar o quanto cada produto de uma família difere dos outros da mesma família. Esta análise contempla capacidades da aplicação, arquitetura, requisitos não-funcionais, e até mesmo aspectos tecnológicos. A partir destas semelhanças observadas, é razoável pensar em termos de um modelo abstrato, abrangente, cobrindo todas estes pontos em comum, enquanto permanece longe de qualquer plataforma de codificação. Nestas circunstâncias, Feature-Oriented Domain Analysis (FODA) [11] surge como um método para capturar as variabilidades. FODA pode ser delineado em três etapas: (i) a análise de domínio (por documentações ou aplicações existentes, requisitos, informações do domínio), (ii) extração de similaridades na criação de um modelo genérico e paramétrico, (iii) refinamento do modelo em diferentes aplicações. IV. TRABALHOS RELACIONADOS Bragança e Machado (2007) [12] argumentam que o uso do MDD com SPL traz diversas melhorias, ao avaliar o reuso intra-organizacional através da análise de variabilidade. No entanto, os autores discutem sobre a falta de uma padronização internacional quanto ao método, a experiência e as ferramentas existentes para a otimização da sinergia destas abordagens. Assim, um processo é proposto, conhecido como 4SRS (Four Step Rule set). O processo contempla o estudo da variabilidade e é inteiramente baseado em UML 1. No entanto, o uso de um diagrama de atividades para descrever o processo não reflete todas as informações necessárias, tais como produtos de saída e responsabilidades. Outras obras como [13], [14] preocupam-se em definir os ganhos potenciais com a sinergia entre SPL e MDD. Estes trabalhos também destacam transformações entre modelos e geração de código, mas não se preocupam em definir uma seqüência planejada de etapas e, como e quando (em que situação) técnicas, métodos e ferramentas devem ser utilizadas 1 para alcançar a reutilização, mitigando riscos e, reduzindo custos. Outros trabalhos abordam o uso de MDD e SPL dentro do contexto de MDA (em inglês, Model Driven Architecture) 2, tais como [15] e [16]. Krahn et al. [4] definiu uma série de papéis que podem ser associados com o desenvolvimento em DSM, como desenvolvedor de linguagem, desenvolvedor de ferramentas, e o desenvolvedor da biblioteca e de produtos; além disso, o artigo define as três atividades genéricas para o desenvolvimento de uma aplicação arbritária. Um conjunto de boas práticas para o desenvolvimento de aplicações neste paradigma pode ser encontrado em [3]. De fato, essas políticas de uso e os papéis definidos em [4] serviram como pano de fundo para a criação do processo apresentado neste artigo. No entanto, o objetivo deste processo é ser simples, claro, mas completo o suficiente para que todos os participantes possam facilmente entendê-lo, ajudando a melhorar a comunicação intra-organizacional. V. PROCESSO REUSE Os processos descritos a seguir foram desenvolvidos utilizando o Business Process Model and Notation (BPMN) [17], mantida pela Object Management Group-OMG 3. Entre os principais benefícios que norteou a escolha deste sistema de notação, destacam-se, que ele é compreensível por todos os usuários de negócios, além de ser apto para processos de negócios. O processo, conhecido como REUSE, figura 1, pode ser descrito em termos de cinco macro-processos internos: (1) Análise de Domínio (2) Análise da Variabilidade, (3) Definição da Linguagem (4) construção das Ferramentas Gráficas e (5) Definição do Gerador de Código. Para cada subprocesso, produtos de trabalho são gerados e estes artefatos serão tomados como entrada para as fases subsequentes.nas subseções que seguem, cada sub-processo será detalhado. Pela dimensão do artigo, as figuras foram ajustadas para não prejudicar a legibilidade. A. Papéis Fig. 1. Processo REUSE Os seguintes papéis foram identificados: Analista de Domínio - Especialista para compreender regras de negócio envolvidas na solução; Arquiteto da Linguagem - Desenvolvedor com conhecimento em (meta)modelagem que irá gerenciar o projeto da linguagem para representar o domínio; Desenvolvedor de Componentes - Capaz de encapsular comportamento 2 3

3 comum entre os trechos do gerador de código; Desenvolvedor da Ferramenta - Desenvolve ferramentas que aumentam a produtividade do usuário final no uso da linguagem; Desenvolvedor do Gerador - Cria o gerador de código. B. Sub-processos Análise de Domínio: Neste processo, o Analista de Domínio é o responsável pelo conjunto das atividades listadas abaixo. Nesta fase (Figura 2), temos: Entrada Um documento que descreve os requisitos da família da aplicação-alvo (Especificação de Requisitos) e documentação de todos os produtos a serem gerados. Atividades 1. Listar Entidades: Levantamento das entidades do domínio da família dos produtos. Essas entidades são os elementos básicos das regras de negócio que a aplicação representa. 2. Listar Relacionamentos das Entidades: Definir as relações entre entidades do domínio e seu comportamento lógico. As dependências são mapeadas e as entidades são classificadas em forte ou fraca. 3. Analisar Documentação de Componentes de Software da mesma SPL: Analisar a documentação de qualquer produto de software que pertenca a mesma linha de produção. Esta análise permite uma visão superficial da complexidade do cenário. Produtos de Trabalho Documento com uma análise completa do domínio. gerador de código. Essa análise também é feita ao nível da observação e documentação de software. 3. Identificar os requisitos que variam entre diferentes versões do produto: Realizar análise para identificar as necessidades que variam em diferentes versões do produto. Esta análise é realizada ao nível da funcionalidade e da observação da arquitetura e do código fonte. 4. Identificação das variações de restrições em relação ao conhecimento de domínio: Identificar restrições que existem entre a família de produtos de software. Estas restrições serão mapeadas (em actividades posteriores) nos elementos do domínio da linguagem. Inicialmente restrições podem estar em conformidade com o fator da variabilidade (onde o mesmo recurso está disponível com diferentes comportamentos) ou obedecer o fator de inclusão/exclusão (onde o recurso está presente ou não no produto final). Produtos de Trabalho Relatório contendo a análise da viabilidade e da variabilidade do cenário; Definição dos pontos de similaridade e variabilidade da SPL. Fig. 3. Subprocesso da Análise de Variabilidade Fig. 2. Subprocesso da Análise de Domínio Análise da Variabilidade: Todas as atividades deste subprocesso são da responsabilidade do Analista de Domínio (Figura 3). Entrada Mesmos documentos da fase anterior acrescido do Documento com a análise completa do domínio em que a DSM será utilizada. Atividades 1. Identificar os requisitos comuns dentro da linha de produtos: Atividade para identificar os elementos que se repetem em todos os membros da linha de produção de software. Esta análise é realizada a nível de observação e documentação de software. 2. Identificar os requisitos distintos dentro da linha de produtos: Atividade para identificar os elementos que variam dentro da família de produtos. Estas diferenças evidenciam pontos em que a linguagem deve oferecer flexibilidade. Esses pontos também são refletidos no Definição da Linguagem: Todas as atividades deste subprocesso são da responsabilidade do Arquiteto da Linguagem, no entanto, nas duas primeiras atividades, a experiência do Analista de Domínio é ainda valiosa (Figura 4). Entrada Modelo Caraterísticas Variáveis e Similares; Ferramentas usadas para modelar a linguagem DSL. Atividades 1. Define as entidades que estarão disponíveis: Configurar entidades de domínio que serão fornecidas pela linguagem para os usuários finais, além de quais personalizações podem ser realizada para cada entidade (em relação ao comportamento). 2. Define recursos a serem disponibilizados: Definir características ou comportamentos que serão fornecidas pela linguagem para usuários finais e personalizações que podem ser realizadas em cada um. 3. Configuração de restrições da linguagem em relação ao conhecimento de domínio: Definir como os pontos de variabilidade serão apresentados para possíveis alterações na construção de produtos finais de software. 4. Implementar a linguagem usando um metamodelo: Construção do metamodelo da linguagem. Este define a estrutura de linguagem que é utilizada para determinar

4 o comportamento no campo analisado. Produtos de Trabalho Metamodelo da linguagem que expressará o domínio investigado nas últimas etapas. Fig. 5. Subprocesso de Construção da Ferramenta Fig. 4. Subprocesso da definição da linguagem Construção da ferramenta gráfica: Neste quarto passo, o desenvolvedor da ferramenta tem a responsabilidade do subprocesso (Figura 5). Entrada Metamodelo da Linguagem. Atividades 1. Criação do templates do Gerador: Modelo responsável por gerar o código base de plug-ins (edit, editor e testes). 2. Criar Modelo Gráfico: O modelo gráfico contém links para as imagens que farão parte do modelo do usuário final. Este modelo se baseia na definição destas imagens e com a personalização das relações entre as entidades mapeadas no início do projeto. 3. Criação do Modelo de Mapeamento: Este é responsável por implementar a ligação entre o modelo gráfico e do modelo da paleta (o modelo responsável pela gestão/organização da paleta para o usuário final). Neste modelo, é possível especificar quais os elementos da paleta o usuário final terá acesso. Portanto, o metamodelo deve identificar todas as possibilidades e o modelo de mapeamento deve restringir quais as possibilidades que estarão disponíveis para o usuário final. 4. Personalizar o código do plu-in gráfico gerado: Depois de definir todos os modelos e gerar o código do plug gráfico, nós modificamos trechos do código, a fim de melhorar a aparência da ferramenta. As mensagens para o usuário (dicas de ferramenta e mensagens de alerta sobre inconsistências/incoerências) são definidas nesta etapa. Produtos de Trabalho Plug in que representa a ferramenta DSM em produção. Definição do Gerador de Código: As três atividades descritas a seguir são realizadas pelo desenvolvedor do gerador (Figura 6). Entrada Metamodelo da Linguagem. Atividades 1. Definir a granularidade do gerador de código: Definir o nível de abstração do gerador de código. Nesta atividade, a separação entre o código comum e do domínio da aplicação é realizada, por exemplo, formulários para aplicações web, o código específico que contém regras de negócio. O código comum é agrupados em templates que facilitam a reutilização de partes do gerador em outros projetos. Como o gerador de código é também um software, sua arquitetura é passível de estruturação e análise de reutilização. Nesta fase, as inspecções serão realizadas em aplicação da família de produtos para capturar a estrutura do código. Esta estrutura deve ser antecipado pelo gerador, determinando a distribuição do código entre os templates. 2. Implementação dos templates: estes modelam a arquitetura da solução e padronizam o código gerado. A organização torna a estrutura do gerador mais próxima da aplicação, tornando a manutenção mais fácil. Os templates também são agrupados de acordo com a natureza do código gerado, comum ou específico da aplicação. Nesta atividade, a análise é indispensável para a geração de templates mais genéricos para facilitar a manutenção evolutiva. Estes templates genéricos podem ser utilizados para melhorar a estrutura do design do gerador, bem como para incluir recursos genéricos que podem ser ampliados com a adição de novos templates.3. Teste do gerador: nesta atividade, alguns aplicativos são criados e amostras do código são inspecionados para analisar o comportamento final. A variabilidade da solução é testada com a geração de muitos exemplos, analisando a presença ou ausência de certos requisitos. Estes testes endorssam o metamodelo criad, além de testar a exatidão e a completude do gerador de código. Produtos de Trabalho Templates de geração de código responsáveis pela geração do código comportamental final; Aplicação gerada e pronta para a avaliação final. Além dos papéis apresentados ao longo desta seção, os outros são incorporados no processo tradicional de desenvolvimento de software. É oportuno esclarecer que há uma dependência natural entre a linguagem e o gerador de código. Este último pode tornar-se excessivamente complexo se toda a codificação necessária ficar sob sua responsabilidade. Para minimizar este problema, pode-se configurar, manter e reutilizar componentes que podem ser integrados de forma a tornálo mais viável. Assim, para trabalhos futuros, sugerimos um novo subprocesso opcional que cria e reutiliza componentes utilizados pelos aplicativo.

5 Fig. 6. Subprocesso do Gerador de Código VI. ESTUDO DE CASO Um projeto piloto foi realizado para avaliar o desenvolvimento de uma solução utilizando o processo REUSE: um software para estoque e gestão financeira. A gestão de estoques é um sistema de atividades logísticas com um plano estratégico com foco no processo de produção. Isto envolve uma série de entidades, desde o estoque de materiais, transporte, bem como o controle completo sobre logística e quando (segurança), quanto, onde (fornecedores) e como comprar os produtos, mantendo o saldo do estoque em perfeito equilíbrio. Já um sistema financeiro inclui clientes, fornecedores, centro de custo, taxas associadas, transferência de contas, contas a pagar e a receber, reembolso e de período de competência, além das demais regras de negócio (omitidas por questão de espaço). O projeto foi desenvolvido em inglês, por isso, as figuras estão todas na língua inglesa. Fig. 7. Visão Parcial do Metamodelo Após a análise do domínio, um documento com as prováveis entidades e relacionamentos foi criado. Este documento serviu como um argumento para gerar o modelo FODA. O modelo foi criado pelo Plug in Eclipse Compositional Variability Management 4. A Análise da variabilidade foi feita em dois níveis. No nível macro, ou seja, entre os sistemas, podendo haver quatro combinações possíveis: Sistema Gestão de Estoque para Prefeituras; Sistema de Gerenciamento de Estoque para Micro e Médias Empresas; Sistema Financeiro; Sistema de Gerenciamento de Estoque para Micro e Médias Empresas acoplado ao Sistema Financeiro. Não é possível acoplar o sistema financeiro e o sistema de estoque para prefeituras, por incompatibilidades funcionais. No nível micro, isto é, variabilidade à nível de presença/ausência de entidades, os seguintes resultados foram alcançados: para o sistema de estoque foram identificadas 5, 4, 5 e 20 entidades obrigatórias, opcionais, alternativas e número de relacionamentos, respectivamente; para o sistema financeiro, obtivemos 9, 2, 2 e 28, respectivamente. Para desenvolver o metamodelo (Definição da Linguagem), foi utilizado o Eclipse Modeling Framework Project [18]. Uma parte do metamodelo de estoque é ilustrado na figura 7. Por razões de espaço, o metamodelo para o sistema financeiro foi omitido. A definição da (Ferramenta gráfica) foi feita através do Eclipse Graphical Editing Framework (GEF) 5, onde foi criada uma paleta com quatro seções bem definidas: uma lista os sistemas disponíveis, outra os elementos do domínio do estoque, a terceira os elementos do domínio financeiro, e uma quarta seção com os elementos comuns entre os sistemas. Além disso, o modelo gráfico foi criado para representar as entidades mapeadas para cada elemento do domínio de aplicação. Tomemos, por exemplo, a entidade Product na Figura 8: não é nada mais do que uma imagem cuja semântica está vinculada à classe Product no metamodelo. Esta figura representa um exemplo de uma DSM, com as seguintes entidades: Product, Output, Group, Family of Products e Release. Pelo espaço limitado deste artigo, a paleta do sistema foi omitida (do financeiro inclusive). Na última etapa, o o gerador de código foi construído utilizando o código fonte da aplicação original. Não foram feitas melhorias como refatoração dos modelos para gerar código-fonte de qualidade superior ao sistema original. Assim, verificou-se que a estrutura e o comportamento do sistema gerado permaneceu idênticos ao do sistema original. O tempo gasto para criar o gerador de código foi superior as outras atividades. Como resultados preliminares, foi utilizado o teste de regressão [19]. O comportamento gerado pelo sistema de estoque permaneceu o mesmo quando comparado com a aplicação original. Além disso, a análise estática de código [20] para identificar os acoplamentos e a presença de ciclos indicou que a estrutura do do código-fonte gerado é praticamente mantido em relação ao original, como pode ser observado na figura 9. O Gráfico, no eixo horizontal, está dividido em quatro partes: total de classes, classes abstratas, concretas e acoplamento aferentes (afferent coupling). O eixo vertical 4 5

6 Fig. 9. Fig. 8. Exemplo DSM Análise Estática do Código do Sistema de Estoque mostra a medição por packages da aplicação (7 no total). O mesmo coportamento foi mantido para o sistma financeiro. VII. CONCLUSÃO O processo REUSE aqui discutido se destina a ser suficientemente amplo para ser adequado para qualquer plataforma de desenvolvimento. Espera-se que o próprio processo facilite a reutilização mesmo entre diferentes aplicações e plataformas. Além disso, em vez de um conjunto disperso de práticas e sem estrutura, foi definido um framework de atividades sincronizadas com os respectivos papéis dos responsáveis e produtos de trabalho, mostrando como cada atividade está em estrita conformidade com as passadas e futuras, tornando-se bastante consistente. No entanto, argumentamos que ainda há muito trabalho a ser feito. Há um projeto em andamento para ampliar o processo com componentes pré-fabricados. Além disso, pretendemos desenvolver um estudo de caso em novas aplicações para analisar quantitativamente os benefícios do uso do processo em termos de manutenção, custo, produtividade e qualidade de software. REFERENCES [1] T. Stahl and M. Völter, Model-Driven Software Development: Technology, Engineering, Management. Chichester, UK: Wiley, [2] C. M. U. Software Engineering Institute, Software product lines, Jun [3] S. Kelly and J.-P. Tolvanen, Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, March [Online]. Available: [4] H. Krahn, B. Rumpe, and S. Volkel, Roles in software development using domain specific modelling languages, in In Proceedings of the 6th OOPSLA Workshop on Domain-Specific Modeling 2006, 2006, pp [5] C. Atkinson and T. Kuhne, Model-driven development: a metamodeling foundation, Software, IEEE, vol. 20, no. 5, pp , [Online]. Available: [6] T. Myllymäki, Variability management in software product-lines, Institute of Software Systems, Tampere University of Technology, Tech. Rep., December 2001, technical report 30. [7] D. H. James Coplien and D. Weiss, Commonality and variability in software engineering, Software, IEEE, vol. 15, no. 6, pp , November [Online]. Available: [8] M. A. B. Lianping Chen and N. Ali, Variability management in software product lines: a systematic review, in SPLC 09: Proceedings of the 13th International Software Product Line Conference. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp [9] F. Bachmann and P. C. Clements, Variability in software product lines, Tech. Rep. September, [10] J. Estublier and G. Vega, Reuse and variability in large software applications, in ESEC/FSE-13: Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering. New York, NY, USA: ACM, 2005, pp [11] J. A. H. W. E. N. Kyo C. Kang, Sholom G. Cohen and A. S. Peterson, Feature-Oriented Domain Analysis (FODA) Feasibility Study, [12] A. Braganca and R. J. Machado, Model driven development of software product lines, in QUATIC 07: Proceedings of the 6th International Conference on Quality of Information and Communications Technology. Washington, DC, USA: IEEE Computer Society, 2007, pp [13] K. Czarnecki, M. Antkiewicz, C. H. P. Kim, S. Lau, and K. Pietroszek, Model-driven software product lines, in OOPSLA 05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. New York, NY, USA: ACM, 2005, pp [14] G. Rushton and R. Baillargeon, Model-driven product line software development process, General Motors Corp., Tech. Rep., [15] K. Garces, C. Parra, H. Arboleda, A. Yie, and R. Casallas, Variability management in a model-driven software product line, Avances en Sistemas e Informática, vol. 4, no. 2, pp. 3 12, [16] I. Schaefer, Variability modelling for model-driven development of software product lines, in VaMoS, ser. ICB-Research Report, vol. 37. Universität Duisburg-Essen, 2010, pp [17] O. M. Group, Business process modeling notation (bpmn) version 2.0, Tech. Rep., June [Online]. Available: [18] M. P. Dave Steinberg, Frank Budinsky and E. Merks, EMF: Eclipse Modeling Framework (2nd Edition) (Eclipse), 2nd ed. Addison-Wesley Longman, Amsterdam, January [Online]. Available: [19] G. J. Myers and C. Sandler, The Art of Software Testing. John Wiley & Sons, [20] N. Ayewah, D. Hovemeyer, J. D. Morgenthaler, J. Penix, and W. Pugh, Using static analysis to find bugs, IEEE Software, vol. 25, pp , 2008.

Solução DSM para Micro e Pequenas Software House

Solução DSM para Micro e Pequenas Software House Solução DSM para Micro e Pequenas Software House Luiz Carlos d Oleron 12, Cleyton Mário de Oliveira Rodrigues 12, Gleibson Oliveira 12, Lúcio santos 12 1 Centro de Informática Universidade Federal de Pernambuco

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Gabriela Guedes de Souza, Jaelson Castro e Carla Silva ggs@cin.ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.br DEPARTAMENTO DE

Leia mais

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Ricardo Terra 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Campus da Pampulha 31.270-010

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Ana Paula Blois 1, 2, Karin Becker 2, Cláudia Werner 1 1 COPPE/UFRJ, Universidade Federal do Rio de Janeiro,

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

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

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web } Com o forte crescimento do comércio eletrônico por

Leia mais

VISUAL STUDIO TEAM SYSTEM IMPLANTAÇÃO DA SUITE DE FERRAMENTAS

VISUAL STUDIO TEAM SYSTEM IMPLANTAÇÃO DA SUITE DE FERRAMENTAS UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA VISUAL STUDIO TEAM SYSTEM IMPLANTAÇÃO DA SUITE DE FERRAMENTAS PARA APOIO AO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

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

UML - Unified Modeling Language

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

Leia mais

Representando Características Autonômicas nos Processos de Negócio

Representando Características Autonômicas nos Processos de Negócio Representando Características Autonômicas nos Processos de Negócio Karolyne Oliveira, Tarcísio Pereira, Emanuel Santos, Jaelson Castro Universidade Federal de Pernambuco UFPE, Recife, PE 50 740-560, Brazil

Leia mais

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Benefícios da modelagem Em uma organização orientada a processos, modelos de processos são o principal meio para medir o desempenho

Leia mais

V Workshop Anual do MPS - WAMPS 2009 Estudo de Viabilidade de Domínio para Avaliar o Potencial da Organização Quanto à Implementação do Processo Desenvolvimento para Reutilização do MR-MPS MPS Mylene Lisbôa

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Desenvolvimento de software orientado a características e dirigido por modelos

Desenvolvimento de software orientado a características e dirigido por modelos Desenvolvimento de software orientado a características e dirigido por modelos Universidade Federal de Uberlândia Rodrigo Reis Pereira Prof. Dr. Marcelo Almeida Maia Agenda Motivação Introdução Modelagem

Leia mais

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira 3º semestre CONCEITOS CONCEITOS Atividade Ação executada que tem por finalidade dar suporte aos objetivos da organização. Correspondem

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

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 Abordagem Dinâmica de Linha de Produto para Gestão de Processos de Negócio

Uma Abordagem Dinâmica de Linha de Produto para Gestão de Processos de Negócio Uma Abordagem Dinâmica de Linha de Produto para Gestão de Processos de Negócio Trabalho de Mestrado Roberto dos Santos Rocha (Aluno), Marcelo Fantinato (Orientador) Programa de Pós-graduação em Sistemas

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

2 Engenharia de Software

2 Engenharia de Software 20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004 Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

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

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

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

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

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes MARACATU A component search tool Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes Vinicius Cardoso Garcia July 29, 2005 Agenda Introdução Especificação

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

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

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

Unidade II MODELAGEM DE PROCESSOS

Unidade II MODELAGEM DE PROCESSOS Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que

Leia mais

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

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

Leia mais

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação CobiT 5 Como avaliar a maturidade dos processos de acordo com o novo modelo? 2013 Bridge Consulting All rights reserved Apresentação Sabemos que a Tecnologia da

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas

Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas Tânia Eiko Eishima 1, Jandira Guenka Palma 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL)

Leia mais

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Marco Antonio De Grandi, Valter Vieira de Camargo, Edmundo Sérgio Spoto Centro Universitário Eurípides de Marília

Leia mais

Engenharia de Software

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

Leia mais

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS. PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?

Leia mais

Uma proposta de um processo prático para apoiar o reuso de software

Uma proposta de um processo prático para apoiar o reuso de software Uma proposta de um processo prático para apoiar o reuso de software Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br Ivanir Costa (UNIP) icosta@unip.br Mauro Spínola (UNIP) mspinola@unip.br Resumo A

Leia mais

Fator Estratégico para a Governança e a Efetividade da TI

Fator Estratégico para a Governança e a Efetividade da TI Fator Estratégico para a Governança e a Efetividade da TI Introdução Conceituação Transformando a TI: de Operacional para Estratégica Por que implementar Quem implementou Quem está implementando Como Implementar

Leia mais

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Lucas A. de Oliveira, Rui A. R. B. Figueira, Expedito C. Lopes Mestrado em Sistemas e Computação Universidade de Salvador (UNIFACS)

Leia mais

Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e

Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e JEANE MENDES DA SILVA SANTOS Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e Plano de Trabalho de Conclusão de Curso apresentado à Universidade Federal de

Leia mais

ECOSSISTEMAS DE SOFTWARE

ECOSSISTEMAS DE SOFTWARE ECOSSISTEMAS DE SOFTWARE MODELOS E REUTILIZAÇÃO EM ECOSSISTEMAS DE SOFTWARE Alunos: Felyppe Rodrigues da Silva (Mestrado) Gabriella Castro Barbosa Costa (Doutorado) Professor: Toacy Cavalcante de Oliveira

Leia mais

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix.

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix. UNIP Sistemas de Informação Análise Essencial de Sistemas Prof.Marcelo Nogueira Análise Essencial de Sistemas 1 Introdução A produção de Software é uma atividade build and fix. Análise Essencial de Sistemas

Leia mais

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software Eduardo Barbosa da Costa Juiz de Fora, MG Julho de 2008 Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software

Leia mais

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Thiago Bianchi 1 Elisa Yumi Nakagawa 2 1 IBM - International Business Machines 04753-080, São Paulo, SP, Brazil tbianchi@br.ibm.com

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

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

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

Leia mais

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da 6 Conclusões No âmbito do framework teórico da Engenharia Semiótica, este trabalho faz parte de um esforço conjunto para desenvolver ferramentas epistêmicas que apóiem a reflexão do designer durante o

Leia mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

21. Qualidade de Produto ou Qualidade de Processo de Software?

21. Qualidade de Produto ou Qualidade de Processo de Software? 21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

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

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

Leia mais

Feature-Driven Development

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

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G

UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G 1082 X Salão de Iniciação Científica PUCRS UMA PROSTA DE ADEQUAÇÃO DO MS VISUAL STUDIO TEAM SYSTEM (VSTS) PARA O MPS.BR NÍVEIS F e G Agner Macedo Paiva, Bernardo Copstein (orientador) FACIN, PUCRS, Centro

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software

Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software Usando RDL para Derivação de Produtos em uma Linha de Produtos de Software Juliano Dantas Santos Universidade Federal do Rio de Janeiro COPPE - Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 27 http://www.ic.uff.br/~bianca/engsoft2/ Aula 27-26/07/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Desenvolvimento de Software Orientado a Características e Dirigido por Modelos Revisitado

Desenvolvimento de Software Orientado a Características e Dirigido por Modelos Revisitado Desenvolvimento de Software Orientado a Características e Dirigido por Modelos Revisitado Autor: Rodrigo Reis Pereira 1 Orientador: Marcelo Almeida Maia 1 1 Programa de Pós-Graduação em Ciência da Computação

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Desenvolvimento Baseado em Componentes e o Processo UML Components

Desenvolvimento Baseado em Componentes e o Processo UML Components Desenvolvimento Baseado em Componentes e o Processo UML Components Cecília Mary Fischer Rubira Patrick Henrique da Silva Brito Instituto de Computação (IC) Universidade Estadual de Campinas (Unicamp) INF064

Leia mais

MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES

MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES MODELAGEM DE UM SUBSISTEMA IMOBILIÁRIO UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE MODELING A REAL ESTATE SUBSYSTEM USING SOFTWARE PRODUCT LINES Silvia Ribeiro Mantuani 1 ; Fernando Henrique Campos 2 ; Vinícius

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

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

ÀREA DE DESENVOLVIMENTO

ÀREA DE DESENVOLVIMENTO ÀREA DE DESENVOLVIMENTO Sumário O que é o Cardio? O que é o Telos? Ambiente de Desenvolvimento Ambiente Visual Studio Team System Projeto de Refatoração O que é Cardio? Tamanho atual do aplicativo: ü Arquivos.cs

Leia mais

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software

Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Itana M. S. Gimenes 1 itana@din.uem.br Radames J. Halmeman 1 radames@cm.cefetpr.br Fabrício R.

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

Orientações para o Planejamento e Realização do Projeto Final

Orientações para o Planejamento e Realização do Projeto Final Orientações para o Planejamento e Realização do Projeto Final Simone Diniz Junqueira Barbosa Versão: 1.0.4 Orientações para o Planejamento e Realização do Projeto Final Sumário 1 Introdução... 3 2 Projeto

Leia mais

Estratégias de Pesquisa

Estratégias de Pesquisa Estratégias de Pesquisa Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Agenda Survey Design e Criação Estudo de Caso Pesquisa Ação Experimento

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (Business Process. George Valença gavs@cin.ufpe.br BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de

Leia mais

7 Trabalhos Relacionados A idéia é tentar dar todas as informações que ajudem os outros a julgar o valor da sua contribuição; não apenas as informações que levem o julgamento a uma direção em particular.

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

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

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

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Gustavo Zanini Kantorski, Marcelo Lopes Kroth Centro de Processamento de Dados Universidade Federal

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Arquitetura de Software. Silvia Regina Vergilio

Arquitetura de Software. Silvia Regina Vergilio Arquitetura de Software Silvia Regina Vergilio Atividades de Projeto Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos. Descreve a organização

Leia mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

Introdução à Computação

Introdução à Computação Aspectos Importantes - Desenvolvimento de Software Motivação A economia de todos países dependem do uso de software. Cada vez mais, o controle dos processos tem sido feito por software. Atualmente, os

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

Processo de Desenvolvimento de Software Linhas de Produtos de Software

Processo de Desenvolvimento de Software Linhas de Produtos de Software Processo de Desenvolvimento de Software Linhas de Produtos de Software Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte Departamento Acadêmico de Gestão e Tecnologia da Informação

Leia mais