UMA REVISÃO DE ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE

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

Download "UMA REVISÃO DE ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE"

Transcrição

1 UMA REVISÃO DE ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE DANUZA FERREIRA SANTANA NEIVA Universidade Federal de Pernambuco RECIFE, 03 DE MARÇO DE 2008

2 DANUZA FERREIRA SANTANA NEIVA ENGENHARIA DE REQUISITOS PARA LINHA DE PRODUTO DE SOFTWARE Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Professor: Prof. Jaelson Brelaz de Castro Recife 03 de março de 2008

3 RESUMO Linhas de Produto de Software envolve um grande número de stakeholders com diferentes interesses e necessidades. Assim, seu contexto é mais complexo que o cenário de sistema único e requer soluções para evitar requisitos incompletos e inconsistentes, que são algumas das grandes causas de falhas em projetos de desenvolvimento de software. Estas soluções podem ser encontradas com um processo sistemático de engenharia de requisitos que permita uma correta elicitação, análise, especificação, validação e gerenciamento de requisitos. Contudo, a escolha de métodos e técnicas de engenharia de requisitos depende das diferentes situações da linha de produto. Diante disto, este trabalho busca investigar o cenário de Engenharia de Requisitos para Linhas de Produtos de Software, comparando as principais abordagens de Linhas de Produto encontradas na literatura, e apresentando métodos e técnicas de Engenharia de Requisitos direcionados para o contexto em análise. Palavras-chave: Engenharia de Requisitos, Linhas de Produto de Software, Engenahria de Domínio, Reuso de Software.

4 LISTA DE FIGURAS Figura 1: Atividades essenciais da Linha de Produto de Software [4] Figura 2: Ciclo de Vida do VODRD [27] Figura 3: Modelo de especificação de viewpoints [27] Figura 4: Modelo de Meta [28] Figura 5: Exemplo de variabilidade de interesses inicial [28] Figura 6: Exemplo de Árvore de Decomposição [28] Figura 7: Relação entre Metas, Cenários e Features [16] Figura 8: Ambiente de suporte para metas, cenários e casos de uso[17] Figura 9: Estrutura do processo de modelagem de metas e cenários [17] Figura 10: Metas e Cenários em nível de negócio e serviço [17] Figura 11: Relação entre metas, cenários e casos de uso [17] Figura 12: Exemplo de modelo de features [19] Figura 13: Modelo de Features [20] Figura 14: Exemplo de modelo de features para o domínio de segurança de casa [5] Figura 15: Tipos de Casos de Uso [3] Figura 16: Exemplo de ponto de extensão [3] Figura 17: exemplo de caso de uso de inclusão [3] Figura 18: Capturando informações legadas para construção de casos de uso [18] Figura 19: Visão geral da abordagem PuLSE-CaVE [18] Figura 20: Exemplo de elementos de casos de uso identificados em manual do usuário [18].45 Figura 21: Agrupamento de Features [5] Figura 22: Variabilidade em especificação de requisito textual [5] Figura 23: Modelando variabilidade ortogonal em requisitos textuais [5] Figura 24: Representação do Cenário do Caso de Uso [5] Figura 25: Representação no Diagrama de Seqüência [5] Figura 26: Representação em Diagrama de Caso de Uso [5] Figura 27: Sumário das atividades essenciais de ER LISTA DE TABELAS Tabela 1: Mapeamento das atividades, técnicas e métodos de RE nas abordagens de LPS Tabela 2: Tipo de relação com conjunção correspondente... 28

5 SUMÁRIO 1 INTRODUÇÃO LINHAS DE PRODUTO DE SOFTWARE (LPS) ENGENHARIA DE REQUISITOS PARA LPS REVISÃO DE ER NAS ABORDAGENS DE LPS RESULTADOS Atividades, Técnicas e Métodos Elicitação Análise e Negociação Especificação Validação Gerenciamento Pontos de Vista das Abordagens Pontos Fortes e Fracos TÉCNICAS E MÉTODOS DE ER PARA LPS Baseada em Pontos de Vista (Viewpoints) PLSVA VODRD Baseado em Metas (Goals) GVAA Baseado em Metas e Cenários GSM Orientado a Features FODA e FORM Baseada em Caso de Uso PLUS PuLSE-CAVE Modelo de Variabilidade Ortogonal CONCLUSÃO Sumário e Discussão Trabalhos Relacionados REFERÊNCIAS... 55

6 1 INTRODUÇÃO À medida que as indústrias de software aumentam a sua capacidade de produção, cresce também a demanda por sistemas mais complexos e com mais qualidade [1]. Desta forma, a competitividade dessas aumenta de acordo com a sua habilidade para reagir rapidamente às mudanças do mercado e aos requisitos dos usuários [2]. Existem várias formas de direcionar a demanda por mudanças, porém, uma das mais efetivas é o reuso de software [2]. Diversas tecnologias têm surgido para solucionar os problemas de reuso, mas, muitas dessas tecnologias, tais como desenvolvimento baseado em componentes e padrões de projeto, dão ênfase apenas ao reuso de código, contudo, o código representa cerca de 20% do total dos custos de desenvolvimento de software [3]. Diante deste cenário, a área de Linhas de Produto de Software (LPS) tem emergido como um paradigma de desenvolvimento de software importante e viável [4], cujo objetivo não é apenas o reuso de código, mas, principalmente, o reuso da arquitetura e dos requisitos, além de outros artefatos. Os principais objetivos de uma linha de produto são: a) redução dos custos de desenvolvimento; b) aumento da qualidade; e c) redução do tempo de entrega dos produtos [5]. Este paradigma de reuso é composto por algumas áreas práticas, entre elas a Engenharia de Requisitos (ER). ER identifica os problemas do domínio e fornece suporte ao desenvolvimento de soluções de LPS através da elicitação, análise, especificação, gerenciamento e validação dos requisitos do sistema. Esta prática é essencial no desenvolvimento de software e requer um esforço significante do projeto. Entretanto, existem muitos problemas nas atividades de ER, e a maioria é referente a fatores sociais e organizacionais. Requisitos de software têm sido reconhecidos repetidamente durante os últimos 25 anos por ser um problema real [21]. Suas atividades normalmente envolvem muitos stakeholders com diferentes necessidades, que pode resultar em conflitos de interesses. Estudos [22] mostram que incompletudes e inconsistência de requisitos são alguns dos grandes fatores para deficiência e cancelamento de projetos de software. No contexto de LPS, as atividades de engenharia de requisitos são mais complexas, pois envolvem mais produtos e stakeholders, e requer atenções para variabilidade e plataforma de reuso [4, 12]. Assim, o desenvolvimento

7 7 de LPS deve ser suportado por um processo de ER adequado para seu contexto, que permita a redução de riscos, custos e tempo de entrega, e aumente a qualidade dos produtos de trabalho. A elicitação e especificação das funcionalidades corretas para implementar o reuso é um desafio fundamental nas abordagens de linha de produto. Dois diferentes problemas têm sido direcionados nessas atividades. Um é o problema de capturar requisitos comuns para todos os membros da linha de produto, e requisitos válidos apenas para partes dos membros da linha. Um outro problema existente é especializar e instanciar requisitos genéricos da linha de produto em requisitos da aplicação para produto único. Para tratar esses problemas, a relação entre requisitos do produto e linha tem sido representada em abordagem de modelagem, que precisam suportar os conceitos de parametrização, especializarão, e generalização [18]. Considerando o contexto apresentado, este trabalho busca investigar o cenário de Engenharia de Requisitos nas abordagens de Linhas de Produto de Software, identificando as melhores práticas, pontos fortes e fracos. E em seguida apresentar técnicas e métodos direcionados para o cenário identificado. Assim, nas subseções seguintes são apresentados conceitos relevantes para o entendimento da Linha de Produtos de Software e de Engenharia de Requisitos neste contexto. A Seção 2 descreve o estado da arte de engenharia de requisitos nas abordagens de LPS. A Seção 3 apresenta as técnicas e métodos de ER para LPS. E por fim, na Seção 4 os resultados da análise são discutidos e sumarizados, seguidos pela apresentação dos trabalhos relacionados. 1.1 LINHAS DE PRODUTO DE SOFTWARE (LPS) Até 1998, o processo de reuso de software seguia apenas a direção da Engenharia de Domínio. Entretanto, nesse mesmo período, a área de Linhas de Produtos de Software (LPS) surgiu como uma nova tendência [4][6]. A Engenharia de Domínio(ED) corresponde a uma coleção de atividades requeridas para estabelecer e manter um conjunto de conhecimento e infra-estrutura técnica necessária para desenvolver e manter eficientemente uma família de aplicações de um dado domínio do problema [7]. Enquanto uma Linha de Produto de Software é um conjunto de sistemas intensivos de software, que compartilham um conjunto comum de features 1 para satisfazer necessidades especificas de um segmento de mercado particular, e que são desenvolvidos de um conjunto de artefatos básicos, em uma maneira bem definida [3]. Os dois conceitos possuem muitas semelhanças, e alguns estudos consideram ED e LPS como sinônimos [8, 9]. 1 Features são características do sistema visíveis ao usuário.

8 8 Entretanto, as principais diferenças entre elas têm direcionado para a consolidação de Linhas de Produtos de Software como um processo mais efetivo de desenvolvimento. Bayer et al. [6] define três razões básica que tornam a Engenharia de Domínio menos efetiva: (i) escopo equivocado da área de aplicação; (ii) lacunas de orientação operacional; e, (iii) foco excessivo nos assuntos organizacionais. As atividades essenciais de uma linha de produto são [4]: Desenvolvimento dos artefatos básicos (core assets), infra-estrutura essencial para o reuso, base para o desenvolvimento do produto em uma linha de produto. Exemplos de core assets são: arquitetura, componentes, especificação de requisitos, modelo do domínio, plano de testes, entre outros. Essa atividade é também conhecida como Engenharia do Domínio. Desenvolvimento dos produtos a partir dos core assets do domínio. Essa atividade é também chamada de Engenharia da Aplicação. Gerenciamento em nível organizacional e técnico da linha de produto. Essas três atividades são altamente iterativas e relacionadas, como pode ser visto na Figura 1. Muitas organizações iniciam a linha de produto desenvolvendo primeiro os artefatos básicos, ou seja, adotam abordagens pró-ativas. Outras organizações iniciam com apenas um ou um pequeno número de produtos, e então desenvolvem a linha de produtos (artefatos básicos e aplicações futuras) a partir deles, adotando abordagens reativas. Ambas as abordagens compartilham um dos grandes benefícios da linha de produto, a idéia que todos os membros da linha de produto são baseados em um único conjunto de artefatos. Com isso, o esforço de manutenção é reduzido para uma base de artefato único [10]. De acordo com Clements e Northrop [4], a Linha de Produto de Software permite que a organização ganhe vantagem competitiva devido ao aumento da produtividade em larga escala, aumento da qualidade, redução dos custos, redução do tempo de entrega, e minimização dos riscos dos produtos. Contudo, iniciar uma linha de produtos de software é uma decisão de negócio que não deveria ser feita aleatoriamente. Antes de começar a desenvolver uma linha de produto, a organização deve estabelecer objetivos sólidos e específicos para adotar essa estratégia de reuso. Uma linha de produtos de software requer um investimento inicial como também custos progressivos com a manutenção dos core assets. Inicialmente, os custos da linha de produtos são um pouco maiores que os benefícios, pois, muitos dos custos estão associados com a sua implantação. Os benefícios, por outro lado, aumentam a cada entrega de produto. Uma vez a abordagem estabelecida, a produtividade da organização acelera, e então os benefícios superam os custos. Mudanças tecnológicas, e em

9 9 práticas organizacionais e gerenciais são barreiras para a adoção bem sucedida da linha de produtos. O sucesso da prática de linha de produtos é uma combinação cuidadosa de aprimoramento tecnológico, organizacional, do processo e dos negócios [4]. Figura 1: Atividades essenciais da Linha de Produto de Software [4]. Áreas práticas da engenharia de software, tais como, engenharia de requisitos, apóiam o desenvolvimento das atividades essenciais da linha de produtos, fornecendo técnicas apropriadas para os tipos de abordagens (pró-ativa ou reativa). Na seção seguinte é apresentada uma visão geral das características principais de engenharia de requisitos para linhas de produtos de software, contextualizando as diferenças da engenharia de requisitos tradicional. 1.2 ENGENHARIA DE REQUISITOS PARA LPS Requisitos são definidos como uma especificação do que deve ser implementado no sistema. Descrevem como o sistema deve se comportar, informações do domínio de aplicação, restrições da operação do sistema, ou especificações de uma propriedade ou atributo do sistema [1]. A Engenharia de Requisitos fornece os mecanismos apropriados para entender os desejos do cliente, analisar as suas necessidades, avaliar a sua viabilidade, negociar uma melhor solução, validá-la, especificá-la de maneira não ambígua, e gerenciar os requisitos como eles são transformados em um sistema operacional [11]. O termo engenharia implica que

10 10 técnicas sistemáticas e repetíveis devem ser usadas para assegurar que os requisitos do sistema sejam completos, consistentes e relevantes [1]. No contexto de linha de produtos, os requisitos definem as aplicações e suas features, e são divididos em dois grupos: os requisitos comuns, que representam os requisitos de toda a linha de produtos; e os requisitos variáveis, que são específicos para um subconjunto de produtos. Requisitos comuns são representados com pontos de variação que podem ser instanciados para criar requisitos específicos do produto. As principais diferenças entre engenharia de requisitos para linha de produtos e para sistema único são [4, 5, 13]: Elicitação de Requisitos para linha de produtos foca no escopo, e deve capturar antecipadamente as variações esperadas ao longo do ciclo de vida da linha de produtos. Em geral, o processo de elicitação de requisitos para linhas de produtos envolve um maior número de stakeholders comparado com a elicitação de requisitos de um sistema único. Análise de Requisitos para linhas de produtos envolve a identificação de variações e similaridades nos requisitos elicitados, e a identificação de oportunidades para o extenso reuso com a linha de produtos. Esta análise deve envolver um mecanismo de resposta mais vigoroso para as solicitações, apontando onde um sistema particular pode encontrar economia se estiver hábil para usar mais requisitos comuns e menos requisitos únicos. Capturar requisitos para um grupo de sistemas pode requerer uma análise sofisticada e negociação intensiva para a escolha de requisitos comuns e variáveis. A análise de requisitos também deve identificar conflitos nos novos requisitos, analisando seu impacto na arquitetura do domínio. Esses conflitos devem ser resolvidos não apenas de um ponto de vista lógico, mas também considerando assuntos do mercado e econômicos. Especificação de Requisitos permite agora documentar os requisitos comuns da linha de produtos e os requisitos específicos dos produtos. A especificação dos requisitos comuns da linha de produtos deve incluir expressões simbólicas que permita que os requisitos específicos de um produto possam ser preenchidos, expandidos ou instanciados. Verificação de Requisitos inclui uma ampla concentração de revisores e ocorre em estágios. Em primeiro lugar, os requisitos comuns da linha de produtos devem ser verificados. Em seguida, quando um produto é desenvolvido ou atualizado, os

11 11 requisitos específicos do produto devem ser verificados. Nesta fase, os requisitos comuns da linha de produtos também devem ser verificados para certificar-se de que eles fazem sentido para este produto. Gerenciamento de Requisitos deve apresentar subsídios para tratar as atividades comuns e variáveis do processo de engenharia de requisitos. Políticas de gerenciamento de mudanças devem prever um mecanismo formal para propor alterações na linha de produtos e apoiar a avaliação sistemática do modo como alterações propostas terão um impacto na linha. Políticas de gerenciamento de mudanças governam como as mudanças nos requisitos da linha de produtos são propostas, analisadas e revisadas. O acoplamento entre os requisitos da linha de produtos e os core assets é identificada através da utilização de relações de rastreabilidade entre os requisitos e seus core assets associados. As práticas de RE inevitavelmente variam de uma organização para outra. Alguns fatores contribuem para a variabilidade do processo de RE, tais como maturidade técnica da organização, cultura organizacional, e domínio de aplicação [1]. Em linha de produtos existem muitas situações que influenciam diretamente a engenharia de requisitos, tais como [6, 12]: Contexto inicial: a linha de produto pode começar do zero; pode ser introduzida enquanto alguns produtos estão sendo desenvolvidos; ou ainda pode ser iniciada a partir da reengenharia de sistemas existentes. A estratégia de elicitação dos requisitos é influenciada pelo contexto em que a linha de produtos é iniciada. Orientação do mercado: a linha de produtos pode ser construída para um segmento de mercado especifico, sem um cliente concreto em mente; ou pode ser direcionada para projetos individuais de clientes. Esta decisão influencia a identificação dos stakeholders envolvidos na engenharia de requisitos, bem como a estratégia de elicitação a ser adotada. Tipo do produto: produtos individuais que complementam outros produtos para formar um software integrado (suite); ou sistemas similares, com funcionalidades comuns, direcionados para um segmento do mercado ou perfil de cliente. Assim como as outras situações anteriormente, o tipo de produto influencia no processo de elicitação dos requisitos. Maturidade do domínio: o domínio pode ser antigo, e por isso ser entendido facilmente; ou o domínio pode ser novo, podendo dificultar o entendimento do

12 12 problema. Assim, o nível de maturidade do domínio afeta diretamente a elicitação dos requisitos. Estabilidade do domínio: domínio estável, ou seja, não espera sua mudança em um futuro próximo; ou um domínio que muda constantemente. A estabilidade do domínio deve ser analisada para identificar melhores estratégias para o gerenciamento de mudanças dos requisitos Arquitetura: capacidade e restrições da plataforma de reuso. Isto influencia a negociação dos requisitos, pois os novos requisitos precisam ser consistentes com a plataforma. Tamanho da organização: número de empregados na organização que trabalham com desenvolvimento de linha de produtos de software. Isto afeta diretamente a estrutura organizacional, influenciando o nível de formalidade do processo de engenharia de requisitos. Distribuição geográfica da organização: número de locais de desenvolvimento envolvidos no desenvolvimento da linha de produto. Isto influencia a estratégia de gerenciamento dos requisitos, em que deve ser permitido o acesso aos requisitos de qualquer lugar. A escolha da ferramenta de suporte também é influenciada por esses fatores. A maioria das diferentes situações descritas influencia diretamente a elicitação dos requisitos, demonstrando a relevância de um processo de elicitação bem definido e customizado para diferentes contextos da linha de produtos. A seleção das técnicas de elicitação depende das características situacionais da linha de produtos, bem como de quais informações são necessárias para o seu desenvolvimento.

13 13 2 REVISÃO DE ER NAS ABORDAGENS DE LPS O processo de engenharia de requisitos ainda não é bem definido nas abordagens de LPS e de engenharia de domínio encontradas na literatura. Este resultado foi concluído a partir de uma revisão sistemática dessas abordagens, fornecendo evidências empíricas sobre as atividades de requisitos, e identificando suas direções, pontos fortes e fracos. A análise deste estudo foi construída a partir de questões de pesquisa, que serão apresentadas a seguir. Q1. Quais atividades, técnicas e métodos de engenharia de requisitos são adotados em cada abordagem de LPS? Esta questão objetiva identificar as atividades, técnicas e métodos de ER nas abordagens de LPS, e avaliar sua completude de acordo com critérios baseados nas necessidades de um processo básico de ER. De acordo com Kotonya e Sommerville [1], um processo é um conjunto organizado de atividades que transformam entradas em saídas. Em ER, um processo inevitavelmente varia de uma organização para outra, mas suas entradas e saídas são similares na maioria dos casos. Sua variabilidade é influenciada por diversos fatores, tais como maturidade técnica organizacional, cultura da organização, e domínio de aplicação. Assim, seus métodos e técnicas devem ser selecionados e customizados de acordo com o contexto da organização. Um processo básico de ER deve definir atividades para elicitação, análise e negociação, validação, especificação e gerenciamento de requisitos; a estrutura e planejamento das atividades; suas entradas e saídas, as diretrizes; e os papéis associados com suas atividades [1]. Portanto, em cada atividade, técnica e método encontrados nas abordagens são analisados esses requisitos básicos. Os dados coletados são classificados de acordo com os subcomponentes de ER (elicitação, análise e negociação, validação, especificação e gerenciamento de requisitos). Esses dados também são padronizados de acordo com esquema de nomes comuns, de maneira que possibilite mapear como a RE é definida no cenário de LPS. Q2. A abordagem possui ponto de vista tecnológica e/ou sócio-organizacional? As abordagens são classificadas em dois pontos de vista, o tecnológico e o socioorganizacional. O ponto de vista tecnológico tem uma visão objetiva dos requisitos e destaca aspectos tecnológicos do sistema. O ponto de vista socio-organizacional tem uma visão subjetiva dos requisitos, seu foco são os aspectos sociais e organizacionais dos sistemas de informação. As abordagens deste tipo de ponto de vista assumem que existem diferentes visões do mundo, considerando necessidades humanas e organizacionais. Elas definem

14 14 objetivos de negócio, razões dos requisitos, perspectives de diferentes stakeholders, e necessidades do mercado. Pontos de vista tecnológicos e socio-organizacionais são interrelacionados e descrevem diferentes perspectivas do domínio. Estas questões orientaram a revisão, onde foram incluídas abordagens de SPL e Engenharia de Domínio que apresentavam uma ou mais atividade de ER. As abordagens de Engenharia de Domínio foram consideradas por possuírem muitas similaridades com LPS. Estudos com informações insuficientes ou não direcionados para área de software foram excluídos desta análise. Uma breve descrição sobre as abordagens selecionadas é apresentada a seguir, seguindo a ordem cronológica de publicação. FODA (Feature-Oriented Domain Analysis 1990) [19] é um método de análise de domínio que consiste de três fases principais: análise de contexto (escopo), modelagem do domínio, e arquitetura do domínio. Desde sua publicação (1990), o processo FODA vem sendo adotado e estendido em outras abordagens. Algumas organizações definem variações deste processo, fornecendo mais detalhes na análise de domínio (ex. FORM [20]); outras integram o FODA com outros modelos no contexto de linha de produto de software (ex. Framework do SEI [4]) ou engenharia de domínio (ex. RiDE [25] e Odyssey [23]). FAST (Family-oriented Abstraction, Specification, and Translation ) [8, 9] é um processo sistemático para analisar família de produtos potenciais e desenvolver facilidades para produção efetiva dos membros da família. Este abordagem é composta de dois subprocessos - Engenharia de Domínio e Engenharia de Aplicação que são conectados por iterações contínuas para guiar a evolução da família e de seus artefatos. Nestas iterações, o ambiente é re-analisado, refinado e melhorado quanto necessário. FORM (Feature-Oriented Reuse Method ) [20] é um processo sistemático para Engenharia do Domínio (ED) e Engenharia da Aplicação (EA). As variabilidades e semelhanças das aplicações do domínio são capturadas como features, compondo o modelo do domínio que é utilizado para o desenvolvimento da arquitetura e dos componentes. A engenharia do domínio consiste de três fases: análise de contexto, análise de domínio e modelagem da arquitetura. PuLSE (Product Line Software Engineering ) [6, 10, 26] é uma das metodologias pioneiras e com maior experiência em Linhas de Produto de Software. Desde 1999, essa abordagem vem sendo experimentada em diferentes indústrias, consolidando sua aplicabilidade em uma larga variedade de contextos. Isso é possível devido, principalmente,

15 15 ao seu forte foco nos produtos, e seus processos e técnicas de customização e instanciação. A abordagem é dividida em três elementos principais: a) fases de desenvolvimento: descrevem as atividades executadas para configurar e usar o ambiente; b) componentes técnicos: em geral capturam processos, métodos, ferramentas e experiências relacionadas a práticas de uma linha de produto particular; e c) os componentes de suporte: pacotes de informações ou guias que permitem melhor adaptação, evolução e desenvolvimento da linha de produto. Framework do SEI (Software Engineering Institute ) [4] é um compêndio de atividades e práticas necessárias para ter sucesso com linha de produto de software. Seu desenvolvimento foi baseado em experiências na indústria, e desde sua publicação, em , ele vem evoluindo através de novas versões, que representam um esforço incremental para capturar as mais recentes informações sobre as práticas bem sucedidas de linha de produto. Este framework é estruturado para: a) descrever os fundamentos, benefícios e atividades essenciais da linha de produto de software; b) definir áreas práticas necessárias para uma organização ter a capacidade de desenvolver uma linha de produto de software; e c) definir práticas especificas para cada área. Suas atividades essenciais são executadas através das áreas práticas, que por usa vez utilizam práticas especificas. Três atividades essenciais são identificadas para o desenvolvimento de uma linha de produtos: desenvolvimento dos core assets (engenharia de domínio); desenvolvimento do produto (engenharia da aplicação); e gerenciamento. Odyssey (1999) [23] é um framework de desenvolvimento de software orientado a domínio, desenvolvido pela COPPE/UFRJ 3. Este ambiente dar suporte ao processo de engenharia de domínio e engenharia da aplicação; e é formado por modelos conceituais, modelos arquiteturais, e modelos de implementação. CoPAM (Component-Oriented Platform Architecture Method ) [24] é uma família de métodos para linha de produtos de software. Para cada linha (família) de produto é desenvolvido um método de acordo com o contexto de negócio e estrutura organizacional. Sua estrutura é composta por três subprocessos: engenharia da plataforma (engenharia do domínio); engenharia do produto (engenharia da aplicação); e engenharia da família (gerenciamento da engenharia da plataforma e engenharia do produto). 2 3 Fonte: Instituto Alberto Coimbra de Pós Graduação e Pesquisa de Engenharia / Universidade Federal do Rio de Janeiro.

16 16 Kobra (Komponentenbasierte Anwendungsentwicklung ) [2] é uma abordagem sistemática para engenharia de linha de produto baseada em componente. De uma perspectiva de linha de produto, esta abordagem é uma customização pré-definida do PuLSE. Seu princípio básico é a separação dos interesses, por exemplo, a especificação dos produtos é separada da especificação dos processos. Suas duas fases principais são: engenharia do framework (engenharia do domínio) e engenharia da aplicação. PLUS (Product Line UML-Based Software Engineering 2005) [3] é um processo evolucionário e iterativo para o desenvolvimento de linhas de produto de software, que usa a notação UML (Unified Modeling Language). Os dois maiores ciclos de vida desse processo são: engenharia da linha de produtos de software (engenharia de domínio) e engenharia da aplicação. As fases da engenharia da linha de produtos de software são: modelagem dos requisitos, modelagem da análise, modelagem do projeto, implementação incremental dos componentes, e teste. Framework SPLE (Software Product Line Engineering ) [5] fornece suporte à engenharia de domínio e engenharia de aplicação. A engenharia de domínio é composta pelos seguintes sub-processos: gerenciamento do produto, engenharia de requisitos do domínio, projeto do domínio, implementação e teste do domínio. O processo de engenharia da aplicação é composto pela engenharia de requisitos, projeto, implementação e teste da aplicação. RiDE (RiSE Process for Domain Engineering )[25] é um processo de engenharia de domínio desenvolvido pelo RiSE 4. Três etapas importantes definem o processo geral: Análise de Domínio, Projeto do Domínio e Implementação do Domínio. Mais detalhes sobre essas abordagens é descrito a seguir. A próxima seção descreve como estas abordagens são direcionadas para tratar a engenharia de requisitos, mostrando os resultados da revisão sistemática. 2.1 RESULTADOS Nesta seção serão relatados os resultados da revisão sistemática de acordo com as questões de pesquisa Atividades, Técnicas e Métodos As abordagens foram analisadas de acordo com as necessidades de um processo básico de ER, e foram classificados em três categorias: não definido, parcialmente definido, e definido. Atividades, técnicas e métodos encontrados que definem entradas, saídas, diretrizes e papéis 4 Grupo de Pesquisa de Reuso em Engenharia de Software, coordenado pelo Profº Silvio Meira.

17 17 foram classificados como definido. Se eles foram encontrados sem essas características, então foram classificados como parcialmente definida. E quando não encontrados foram classificados como não definido. Em cada sub-componentes de RE foram analisados suas necessidades de acordo com [4, 13, 15], como segue: a) elicitação deve definir atividades para descoberta de requisitos e variações antecipadas; b) análise e negociação devem encontrar variações e similaridades; identificar conflitos em novos requisitos, analisando seu impacto na arquitetura de domínio; identificar oportunidades de reuso; e estabelecer acordos para satisfazer todos os stakeholders; c) especificação deve documentar os requisitos das aplicações e da linha de produto; d) validação deve checar a consistência, completude e qualidade dos requisitos comuns e variáveis; e e) gerenciamento deve gerenciar as requisições de mudanças e a rastreabilidade. Assim, as abordagens foram mapeadas em atividades, métodos e técnicas de acordo com um esquema de nomes comuns, e agrupados nos sub-componentes apresentados anteriormente. Este mapeamento é apresentado na Tabela 1. Foram analisadas apenas as atividades, técnicas e métodos identificados nas abordagens, que são apresentados a seguir. Algumas técnicas e métodos são aplicáveis em mais de um sub-componente de ER, mas foram classificados onde são mais utilizados. A prototipagem, por exemplo, pode auxiliar na elicitação e validação, mas é mais aplicável em elicitação Elicitação α) Identificar fontes de requisitos: a informação vem de múltiplas fontes, assim é importante identificar as fontes necessárias para entender o domínio, tais como produtos existentes. Produtos competidores, literatura do domínio, especialistas do domínio [5, 19]. β) Identificar interesses de negócio: descobrir estratégias de negócio, vantagens competitivas para a empresa, seus objetivos de alto nível de abstração que devem ser satisfeitos com SPL. χ) Identificar restrições: capturar requisitos que definem limitações na LPS, tais como restrições de domínio e de projeto. δ) Identificar os interesses de marketing: conhecer as necessidades de Mercado, as vantagens competitivas, suas tendências atuais e futuras que ajudam na definição do domínio da LPS.

18 18 ε) Identificar artefatos disponíveis para reuso: buscar por artefatos que já estão disponíveis e analisar se eles são úteis como bases de reuso para linha de produto. φ) Entrevista: técnica que envolve discussão estruturada ou aberta entre um entrevistador (ex. analista de domínio) e um sujeito (ex. especialista do domínio) para elicitação dos requisitos. γ) Workshop: técnica que envolve um grupo de pessoas participando ativamente para elicitar e negociar requisitos. η) Viewpoint: técnica que identifica diferentes perspectivas dos requisitos do sistema. ι) Prototipagem: demonstração do sistema que simula seu comportamento, ajudando os stakeholders para refinar suas idéias sobre os requisitos dos produtos Análise e Negociação a) Definir limites da LPS: defining which requirements should be outside the scope of the SPL. b) Classificar Requisitos: categorizar requisitos como funcional e não-funcional (ex. atributos de qualidade, restrições). c) Priorizar Requisitos: prioridades são atribuídas aos requisitos, refletindo sua importância para os stakeholders. Isto ajuda os stakeholders na decisão e acordo nos requisitos básicos para LPS [5, 15, 26]. d) Analisar variações e similaridades: capturar os requisitos comuns (para todos os produtos) e variáveis (de produtos específicos) das aplicações do domínio. O principal objetivo da engenharia de requisitos do domínio é o desenvolvimento de artefatos comuns e variáveis para a linha de produto em ordem que permita o reuso em larga escala na engenharia da aplicação [5] Especificação a) Definir modelos padrões: definir um conjunto de modelos padrões (templates), que deve ser usado para organizar a descrição dos requisitos. Estes templates podem representar diferentes visões dos requisitos, desde a uma descrição mais abstrata (ex. modelo de features) a uma descrição mais detalhada (ex. modelo de casos de uso). b) Descrever termos padrões: identificar e armazenar termos padrões, tais como terminologias do domínio.

19 19 c) Descrever variabilidade: identificar pontos de variações nos documentos de requisitos. Requisitos comuns são escritos com pontos de variações que serão usados para criar requisitos específicos do produto. A documentação do ponto de variação permite que clientes localizem as decisões deitas. Por outro lado, a documentação de variações permite que clientes considerem as opções disponíveis para cada decisão [5]. d) Documentação Textual: documentação de requisitos textuais em linguagem natural. e) Documentação em XML: os requisitos são documentados usando linguagem de marcação - XML(eXtensible Markup Language). Este tipo de representação pode ser aplicada para permitir a documentação explícita de variabilidade em requisitos textuais [5]. f) Caso de Uso: requisitos são documentados usando modelos de casos de uso. g) Modelo de Features: requisitos são organizados por features, que representam as características do sistema visíveis pelos usuários finais [19]. h) Modelo de Decisão: todos as variações são descritas como decisões. i) Modelo Entidade-Relacionamento: representa o conhecimento do domínio explicitamente em termos de entidades do domínio e suas relações [2] Validação a) Definir casos de teste: para cada requisito é proposto um ou mais plano de teste, que pode ser usado para checar se o sistema reúne os requisitos. Esta é uma forma efetiva de revelar problemas em requisitos, tais como incompletude e ambigüidade [15]. b) Organização inspeção/revisão: a linha de produto deve ser validada por um grupo de pessoas responsáveis pela checagem dos requisitos, que se reúnem para discutir problemas com os requisitos e acordos para solucionar os problemas [15] Gerenciamento a) Definir gerenciamento de mudança: definir políticas para gerenciar mudanças para os requisitos que define como as mudanças são propostas e avaliadas, analisando seus efeitos. b) Definir rastreabilidade: definir quais informações de rastreabilidade devem ser mantidas e como elas devem ser representadas. Isto permite encontrar dependências entre requisitos, e entre requisitos e outros artefatos do domínio.

20 20 Tabela 1: Mapeamento das atividades, técnicas e métodos de RE nas abordagens de LPS. Abordagens/ Esquema comum de nomes FODA (1990) FAST (1997) FORM (1998) PuLSE (1999) Framework SEI (1999) ODYSSEY (1999) COPAM (2000) Kobra (2002) PLUS (2005) Framework SPLE (2005) RiDE (2007) Atividades Técnicas Atividades Métodos de Representação Atividades Elicitação Identificar fontes de requisitos Identificar Stakeholders Identificar Interesses de Negócio Identificar restrições Identificar necessidades de marketing Identificar artefatos disponíveis para reuso Entrevista Workshop Viewpoint Prototipagem Análise e Negociação Definir limites da LPS Classificar Requisitos Priorizar Requisitos Analisar variações e similaridades Especificação Definir templates padrões Descrever termos padrões Descrever variabilidade Documentação Textual Documentação XML Caso de Uso Modelo de Feature Modelo de Decisão Modelo Entidade- Relacionamento Validação Definir casos de teste Organizar inspeção/revisão Gerenciamento Definr Gerenciamento de Mudança Definir Rastreabilidade Legenda Não definido. Definido Parcialmente Definido

21 Pontos de Vista das Abordagens O ponto de vista tecnológico foi considerado por todas as abordagens analisadas. Este resultado é esperado, pois a visão de aspectos tecnológicos é um critério básico para um desenvolvimento de software, e frequentemente são representados em métodos tradicionais e estruturados, tais como modelo de caso de uso e modelo entidade-relacionamento. De acordo com a análise sistemática, apenas o Framework do SEI [4] apresenta o ponto de vista tecnológico e sócio-organizacional de maneira completa. Ele sugere modelagem de caso de uso e de features, que captura os aspectos tecnológicos; definem escopo e indica a modelagem viewpoints para capturar aspectos sócio-organizacionais. Entre as outras abordagens, três apresentam apenas aspectos tecnológicos [2, 3, 23], e sete apresentam ponto de vista tecnológico e algumas características do ponto de vista sócio-organizacional. 2.3 Pontos Fortes e Fracos A análise dos pontos fortes e fracos pode ajudar a melhorar o processo de ER para LPS, e identificar melhores práticas para serem aplicadas nesse contexto. A seguir são apresentados a avaliação relativa a cada abordagem. FODA [19]. Em geral, as atividades, papéis, entradas e saídas deste processo são bem definidos, e alguns produtos de trabalho são determinados com diretrizes. Seu principal produto é o modelo de features, que é útil para a representação do domínio, em que variabilidade e comunhão são identificadas. Além disso, modelo de features é entrada de outros modelos no processo. No entanto, existem algumas lacunas no processo, como segue. Ele não descreve como realizar a elicitação, ele apenas diz que features comuns e variáveis devem ser capturados. A validação do modelo de features é definida, mas não possui diretrizes. Não são definidos atividades para o gerenciamento e negociação de requisito. Os requisitos são documentados como modelos de features e entidade-relacionamento, que são representações de alto nível de abstração. Assim, a sua especificação não é suficiente para orientar a equipe de desenvolvimento. FAST [8, 9]. Esta abordagem define papéis em todas as etapas, e tem como característica chave de ER a especificação direcionada para derivação de uma DSL (Domain Language Specification) - linguagem de especificação de domínio -, que permite traduzir automaticamente os requisitos em código executável, contribuindo para o desenvolvimento de protótipos para validação dos requisitos. Contudo, o processo de desenvolvimento de DSL tem um custo elevado. Assim, ele torna-se mais arriscado, pois requisitos incorretos e

22 22 incompletos podem conduzir a uma grande perda de investimento. Considerando as atividades essenciais de RE, este processo não apresenta informações sobre o gerenciamento de requisitos, nem diretrizes para elicitação e especificação. FORM [20]. Em FORM, as features são modeladas com diferentes perspectivas: features de capacidade (preocupação principal dos usuários); features do ambiente operacional e da tecnologia do domínio (preocupação principal dos analistas do sistema e arquitetos); e features de implementação (preocupação principal dos desenvolvedores). Algumas atividades essenciais do RE não estão definidas no processo. Não há informações sobre gerenciamento (ex. gerenciamento de mudança e rastreabilidade) e negociação (ex. priorização de requisitos) dos requisitos. E não são definidas diretrizes para elicitação. PuLSE [6, 10, 26]. Em geral, esta abordagem tem entradas e saídas claramente definidas nas atividades de análise e modelagem. Sua flexibilidade permite a instanciação e customização de técnicas e modelos de requisitos para aplicações específicas, prevendo a evolução do projeto com conseqüentes mudanças nos requisitos. No entanto, a abordagem tem pouca informação sobre os seus artefatos (produtos trabalho) de requisitos. A validação dos requisitos é pouco descrita no processo, e não há uma definição clara dos papéis nas diferentes fases de requisitos de engenharia. Framework do SEI [4]. O framework do SEI é uma tecnologia madura de linha de produto de software, que vem sendo publicada e evoluída desde Em geral, o SEI define fundamentos e diretrizes para ER em SPL. Ele define práticas especificas e configuráveis para executar a ER, e apresenta os riscos associados com esse contexto. No entanto, o framework não identifica papéis entre os stakeholder, nem atividades para validação de requisitos. O gerenciamento de requisitos também é pouco definido, não definindo atividades para rastreabilidade dos artefatos. Odyssey [23] Este framework é apoiado por uma ferramenta que permite a especificação dos modelos do domínio; a integração de informações de diferentes domínios; o gerenciamento de seus modelos e rastreabilidade entre os modelos conceituais. Através de padrões conceituais são sugeridas práticas de modelagem do domínio, fornecendo documento padronizado para descrever os conceitos do domínio. Entretanto, existem lacunas nas atividades relacionadas à engenharia de requisitos, em que não são definidos atividades para elicitação e validação de requisitos. 5

23 23 CoPAM [24]. O COPAM permite adaptar seus métodos para diferentes contextos, considerando o interesses de negócios e a estrutura organizacional. Seu processo é focado em arquitetura, deixando muitas lacunas no processo de engenharia de requisitos. Não existem informações no processo sobre técnicas para validação, gerenciamento e negociação de requisitos, e seu processo de elicitação é pouco definido. Kobra [2]. Essa abordagem foca no projeto e especificação dos componentes. Diversos modelos e procedimentos para especificação são fornecidos. O processo de manutenção é bem definido, com atividades para gerenciar configuração e mudança, e planejar manutenção. Além disso, o KobrA é um processo flexível que pode ser customizado para diferentes contextos. Por outro lado, existem algumas lacunas em ER para essa abordagem. Por exemplo, fases essenciais em ER não são definidas claramente, tais como elicitação e negociação de requisitos. Em geral, os stakeholders essenciais não são identificados no processo, nem as fontes do conhecimento de domínio. PLUS [3] O PLUS fornece exemplos e diretrizes para executar a modelagem com notação UML, adicionando variabilidades para adequar à realidade de um desenvolvimento da linha de produtos, o que torna o processo de modelagem um dos pontos fortes dessa abordagem. Contudo, em geral, o PLUS não apresenta atividades para elicitação, negociação e gerenciamento dos requisitos. Framework SPLE [5]. Este trabalho descreve a especificação de requisitos de forma satisfatória, apresentando diferentes maneiras de representação em documentação textual e modelos. Estes documentos são descritos com relações de rastreabilidade entre eles, mas é difícil mantê-lo em um domínio grande e complexo sem um apoio ferramental. Em geral, processo de ER não é definido satisfatoriamente. Não são definidas atividades de validação de requisitos, nem papéis e stakeholders para toda a ER. RiDE [25]. Este processo é definido de maneira sistemática. São definidos procedimentos e papéis entre os stakeholders para executar as atividades; e os artefatos, entradas e saídas são bem definidos. No entanto, o processo de engenharia de requisitos é definido superficialmente. As atividades de elicitação, especificação e validação são definidas em nível de features. Em geral, não são apresentadas técnicas para elicitação e gerenciamento de requisitos, nem atividades de especificação mais detalhadas, tais como caso de uso.

24 24 3 TÉCNICAS E MÉTODOS DE ER PARA LPS São apresentadas a seguir algumas técnicas e métodos de Engenharia de Requisitos direcionadas para o contexto de LPS. 3.1 Baseada em Pontos de Vista (Viewpoints) Stakeholder possuem diferentes perspectivas e necessidades em relação à linha de produto. Desta forma, a técnica de viewpoints pode ser utilizada nos estágios iniciais da elicitação para identificar diferentes interesses e necessidades. Esta técnica também contribui para a análise e especificação dos requisitos de software. Viewpoints são um mecanismo explicito que considera diferentes perspectivas do problema e sistema, originadas de diferentes stakeholders [1]. Em um viewpoint pode conter, além dos requisitos, informações sobre o ambiente, domínio do sistema, fontes e razões dos requisitos [15] PLSVA Jaber et al. [14] propõe um modelo de viewpoints, PLSVA (Product Line Stakeholder Viewpoint Approach) com três visões da linha de produto, como segue: A visão da gerência da organização, que possui um entendimento claro sobre as direções da LPS. Ele interage com clientes, faz decisões de negócios, e é responsável por responder questões do tipo quem é o cliente e pessoa de contato; qual o intervalo de tempo, cronograma, custos e equipe dos produtos da LPS. A visão da equipe de reuso da organização, que foca nos artefatos e produtos do domínio. Esta equipe é capaz de identificar artefatos, o nível de reuso, e tipos de componentes usados. A visão dos desenvolvedores, que é interessada na arquitetura da LPS, produtos, sistema operacional e plataforma utilizado, artefatos, tipos de componentes e suas interfaces. O desenvolvimento dos viewpoints é realizado através do método VORD (Viewpointoriented Requirements Definition) [1], que é direcionado para descoberta e análise de requisitos. O modelo proposto utiliza as três primeiras fases do VORD: Identificação de Viewpoint: descoberta de viewpoint dos stakeholders e identificação dos atributos, tarefas e sub-viewpoints específicos.

25 25 Estruturação do Viewpoint: agrupamento dos viewpoints relacionados em uma hierarquia. Viewpoints comuns são agrupados no nível mais alto da hierarquia. Documentação do Viewpoint: refina a descrição dos viewpoints identificados. Contudo, o modelo proposto não identifica viewpoints suficientes para expressar todos os interesses relacionados à linha de produto. Não são identificados, por exemplo, as perspectivas da equipe de marketing, dos usuários e clientes - principais interessados na linha de produto VODRD VODRD (Viewpoint-Oriented Domain Requirements Definition) [27] é um método iterativo para análise de requisitos do domínio a partir da perspectiva dos stakeholders. Suas atividades são conduzidas em quatro etapas: definir escopo do domínio (scope domain), caracterizar domínio (characterize domain), documentar pontos de vista (documentar viewpoints), e analisar pontos de vista do documento (analyze document viewpoints). O ciclo de vida dessas etapas pode ser visto na Figura 2; Figura 2: Ciclo de Vida do VODRD [27] A definição do escopo do domínio compreende a identificação dos stakeholders e viewpoints do domínio. Esta atividade é realizada através de entrevistas e análise de documentos existentes. Para caracterizar o domínio são analisadas as fontes dos requisitos e então são definidos entidades (termos comuns) do domínio em um dicionário do domínio. Este dicionário deve ser criado por um analista do domínio e revisado por um especialista do domínio. A documentação dos viewpoints é baseada nos sistemas existentes. Nesta etapa os requisitos de cada produto do domínio são alocados para os viewpoints apropriados. Os viewpoints são documentados de acordo com um modelo padrão (Figura 3), em que são definidas a justificativa para inclusão (razão); associações de rastreabilidade; e requisitos com identificação, razão, associações e definição.

26 26 Após a documentação, os requisiteis são analisados e comparados nos viewpoints para identificar quais são reusáveis. Os artefatos gerados por esse método são o seguinte: dicionário de domínio, viewpoints do domínio, catálogo dos requisitos reusáveis. Figura 3: Modelo de especificação de viewpoints [27] Este método possui diretrizes bem definidas para construir os viewpoints, propondo atividades para elicitação, análise, especificação e gerenciamento dos requisitos. Contudo, em sua atividade de gerenciamento de requisitos não são definidos relações de rastreabilidade entre requisitos e outros artefatos da SPL, nem há descrições sobre a origem de cada requisito. Da perspectiva de reuso, este método não representa as variablidades de maneira satisfatória, com pontos de variações que facilite a tomada de decisão entre os requisitos do domínio para instanciação de uma aplicação da SPL.

27 Baseado em Metas (Goals) As metas identificam as razões para os requisitos da linha de produto, e representam direções, propósitos, objetivos de uma organização [17], e as causas das suas variações [28]. Este método fornece uma forma natural para identificar variabilidade em fases iniciais de requisitos, por permitir a captura de alternativas para que os stakeholders alcancem suas metas [28] GVAA GVAA (Goal-based Variability Acquisition and Analysis) é um processo de variabilidade intensivo para decompor e analisar metas. Estas metas são representas em digramas formais, que são estruturados em árvores de decomposição AND/OR. Um exemplo deste diagrama pode ser visto na Figura 4. Figura 4: Modelo de Meta [28] Metas (figuras ovais no diagrama) podem ser satisfeitas ou não satisfeitas. Quando uma meta g (de goal) possui uma decomposição AND em g1,...,gn, então g é satisfeita se, e somente se, gi é satisfeita para todos os i s. Se g é uma decomposição OR, ela é satisfeita se, e somente se, existe um i tal que gi é satisfeito. Em adicional, alguns tipos de relações são usados para representar restrições entre metas. Tais tipos de relações são mostrados na Tabela 2, com sua conjunção equivalente. O tipo de relação 1 expressa que quando g1 é satisfeito, g2 também é. Ao contrário do tipo 2, que indica que g2 não é satisfeito quando g1 satisfaz as condições. Os tipos 4 e 5 seguem a mesma lógica dos tipos 1 e 2, respectivamente, adicionando a recíproca das condições. Por exemplo, se g1 é satisfeito, g2 também é, e vice-

28 28 versa. Já o tipo 3 indica que g2 não pode ser satisfeito ao menos que g1 seja satisfeito. E por fim, as restrições mais complexas são representadas através de retângulos (ver Figura 5). Tabela 2: Tipo de relação com conjunção correspondente Tipo de Relação Conjunção Cada meta de alto nível pode ser associada a um conjunto de interesses, em resposta para que refinamentos alternativos da meta possam ser introduzidos. Este conjunto de interesse é classificado da seguinte forma: Agentive (A): interesse dos agentes (atores) cujas atividades afetam o estado das transações implícitas da meta. Ex: {Máquina, usuário}a envia mensagem. Dative (D): interesse dos agentes afetados pelas atividades implícitas da meta. Ex.: Enviar uma mensagem para {o administrador, o usuário}d. Objective (O): é o interesse do objeto que é afetado pelas atividades implícitas da meta. Ex: Enviar {uma mensagem de , um fax}o Factitive(F): é a preocupação do objeto ou ser que é resultante da atividade, ou é entendido como parte do verbo, por exemplo, Formata Texto {negrito, itálico}f. Process(P): é o interesse que representa o instrumento (P.ins) que envolve a execução das atividades, ou os meios (P.mea) e maneira (P.man) como a atividade é executada. Ex: pagamento {por débito, por crédito}p.ins. Locational (L): é o interesse sobre a localização espacial ocupada pela atividade genérica que é implicada pelo verbo. Ex: enviar uma mensagem {no carro, no ônibus}l. Temporal (T): é o interesse sobre a duração (T.dur) ou freqüência (T.frq) da atividade que é implicada pelo verbo. Ex. Verificar mensagem toda {hora, 10 min}t.frq. Conditional (C):interesse referente a condição alternativa sob a qual a meta pode ser representada (C.con), ou a sinais alternativas para o início de

29 29 atividades trigger (C.tri). Ex: Enviar produto apenas se {pagamento efetuado}c.con. Extent (E) interesses de variabilidade referentes ao grau alternativo pela qual a atividade é executada. Ex: Exibir os primeiros {10, 20 30}E registros. Figura 5: Exemplo de variabilidade de interesses inicial [28]. Um conjunto de variabilidade de interesses é identificado inicialmente para cada meta de alto nível, seguido por uma decomposição de metas para formar a árvore AND/OR. Antes de iniciar a decomposição, são analisadas as variabilidades de interesses que são relevantes para a meta (ex. Be Notified, na Figura 5). A coleção de interesses constitui o frame de variabilidade da meta. O conjunto de frames do domínio é usado para derivar variabilidades de interesses específicos para o problema. Em paralelo à definição de interesses, são considerados fatos contextuais que podem variar enquanto a meta está sendo representada, e influenciar a seleção e identificação de alternativas. Estes fatos podem ser intencionais, ou não intencionais. Na figura 5 estes fatores são representados no tópico de dependência ( depends on ). Uma vez que os interesses relevantes e seus domínios são coletados, é iniciada a etapa de decomposição da meta. Cada meta é rotulada com expressões unresolved, resolved e addressed. Inicialmente, para cada meta principal é atribuído o rótulo unresolved. Quando uma meta possui uma decomposição AND, todos os interesses relevantes para a meta pai são herdados por num mínimo uma das submetas. Quando uma meta possui uma decomposição OR, exatamente uma variabilidade de interesse relevante é direcionada, enquanto as outras

30 30 são automaticamente herdadas. Uma variabilidade de interesse é direciona para particionar seu domínio e atribuir cada partição para sua submetas OR. Se a partição contém apenas um elemento do domínio, então o interesse é rotulado como resolved, e suas submetas não herdam a decomposição da meta. Se existe mais elementos, então seu rótulo é addressed. O modelo de decomposição pode ser visto na Figura 6. Mais detalhes sobre o processo de decomposição e resolução de variabilidade pode ser visto em [28]. Figura 6: Exemplo de Árvore de Decomposição [28] Portanto, este método define a variabilidade com base nas necessidades e metas dos stakeholders, apresentando uma abordagem baseada em intenções organizacionais. Seus frames de variabilidade de interesses permitem descrever o conjunto de elementos do domínio (ex.: atores e condições) para representar o cenário envolvido em cada meta. Contudo, este método não categoriza os requisitos (ex.: funcionais e não funcionais), e sua notação não é de fácil entendimento, necessitando de visões complementares para atender aos diferentes tipos de stakeholders.

31 Baseado em Metas e Cenários OS cenários descrevem os comportamentos dos produtos, e são chaves para definição do escopo da linha de produto [4]. Eles descrevem interações de usuários ou sistemas com produtos na linha de produto. Estas interações podem ser comuns para todos os produtos, ou únicas para um subconjunto de produtos [16]. Assim, requisitos variantes são encontrados quando há mais de uma forma de representar cenário para alcançar uma meta, ou seja, existem cenários alternativos ou opcionais GSM Kim et al. [17] propõe uma modelagem de metas e cenários (Goal and Scenario Modeling - GSM) para identificar os requisitos do domínio e fornecer a razão para eles. Em sua primeira proposta [16], metas e cenários são integrados com features, e são representados em um modelo de requisitos do domínio (RMD). O processo RMD consiste em três atividades macros, que são: definição do escopo da LPS, análise de requisitos do domínio, e análise de variabilidades e semelhanças. Em [17], as features são substituídas pela Representação dos Requisitos do Domínio (RRD), ou seja, depois que as metas e cenários são identificados, os requisitos do domínio são representados como diagrama de casos de uso variáveis. A Figura 7 apresenta a relação entre cenários, metas e features [16]. Cada feature da LPS representa e exibe os comportamentos dos produtos que são descritos por cenários. Estes, por sua vez, capturam requisitos que descrevem situações reais ou comportamentos concretos. As metas são alcançadas por cenários, e relaciona-se indiretamente com as features. O processo de elicitação consiste em atividades de descoberta de metas, preparação dos cenários e conexão das features. Todas essas atividades são acompanhadas pela análise de variabilidade e semelhanças. Estas atividades são repetidas incrementalmente até completar a hierarquia de requisitos do domínio.

32 32 Figura 7: Relação entre Metas, Cenários e Features [16]. A abordagem mais recente [17], apresentada na Figura 8, possui uma árvore de metas como saída da modelagem de metas e cenários, consistindo de quatro níveis: nível de negócio, nível de serviço, nível de interação e nível interno. Estes níveis são hierarquias abstratas que representam diferentes perspectivas. O nível de negócio mostra qual é o objetivo de negócio da organização. O nível de serviço apresenta quais serviços podem alcançar o objetivo de negócio, e como o escopo na linha de produto é determinado. Os requisitos na linha de produto são identificados na perspective da interação entre o próprio sistema e entidades externas, também chamadas de agentes. O nível interno apresenta as funcionalidades entre objetos do sistema. Figura 8: Ambiente de suporte para metas, cenários e casos de uso[17]. Todas as metas se relacionam entre si através da árvore de metas. São definidos quatro tipos de metas de acordo com o nível de requisitos do domínio, que são: meta de negócio, meta de serviço, meta de interação e meta interna. Enquanto os cenários são classificados em três tipos: cenário de serviço, cenário de interação e cenário interno, como pode ser visto na

33 33 Figura 9. Uma representação mais detalhadas da variabilidade entre os cenários pode ser vista na Figura 10. Figura 9: Estrutura do processo de modelagem de metas e cenários [17] Um cenário é escrito como uma combinação de <S + V + Propósito + Direção + Maneira>, onde S é representa os agentes que interagem com o sistema, ou o próprio sistema concebido; V é um verbo ativo; Propósito é um objeto conceitual ou físico; Direção é uma fonte ou destino; e Maneira é a forma em que o cenário é implementado. Por exemplo, o cenário O HIS checa a temperatura atual com a temperatura do sensor é descrito como segue: <O HIS> = S, < checa> = V, <a temperatura atual> = Propósito, <com a temperatura do sensor> = Maneira. Figura 10: Metas e Cenários em nível de negócio e serviço [17].

34 34 Casos de uso são utilizados para refinar os requisitos, pois metas e cenários não os representam de maneira suficiente. Os requisitos do domínio são representados nos casos de uso através da transferência de regras de orientação, que ajudam a identificar requisitos comuns e variáveis como casos de uso variáveis. No nível de interação são identificadas relações entre o sistema e seus agentes, e o propósito da especificação do caso de uso é descrever como os agentes podem interagir com o sistema para obter serviços e alcançar suas metas. A Figura 5 apresenta a relação entre metas, cenários e casos de uso. Figura 11: Relação entre metas, cenários e casos de uso [17]. Este trabalho apresenta um método de modelagem eficiente para identificar requisitos em diferentes níveis de abstração, separando diferentes perspectivas, e permitindo a rastrebilidade entre os requisitos do domínio. A definição de múltiplas perspectivas aproxima esta técnica do mecanismo de viewpoints, contudo não são definidos os stakeholders envolvidos em cada visão. As razões dos requisitos são mapeadas através das metas, mas não são definidas suas fontes.

35 Orientado a Features Features são características, qualidades ou aspectos do sistema visíveis pelo usuário [19]. Sua modelagem é definida de maneira abstrata, sendo útil para parametrização dos produtos do domínio, possibilitando a identificação de diferenças entre aplicações através de refinamentos. Assim, o modelo de features pode ser utilizado por analistas de requisitos para negociar as funcionalidades das aplicações com os usuários. Os desenvolvedores podem utilizar o modelo de features para identificar o que necessita ser parametrizado em outros modelos e na arquitetura, e como essa parametrização deve ser feita. Além disso, este modelo representa um espaço de decisões para o desenvolvimento de software, em que é possível identificar candidatos de componentes reusáveis [20] FODA e FORM O método FODA (Feature-Oriented Domain Analysis) [19] propõe uma modelo de features para linhas de produto, em que são aplicadas primitivas de agregação e generalização para capturar as semelhanças das aplicações no domínio em termos de abstrações. O FORM (Feature-Oriented Reuse Method) [20] define a modelagem de features como uma extensão do modelo do FODA[19]. Sua estrutura é direcionada para auxiliar o desenvolvimento da arquitetura do domínio e de componentes. Estes dois métodos são apresentados em uma única seção por apresentarem o mesmo conceito de modelagem. Inicialmente, as features são identificadas através do conhecimento do domínio obtido dos especialistas do domínio, e de outras fontes, tais como documentações e sistemas existentes. Em seguida, as features são categorizadas em quatro perspectivas: i) capacidade, ii) ambiente operacional, iii) tecnologia do domíno, e iv) técnica de implementação. A capacidade caracteriza um serviço, operação, função ou desempenho que uma aplicação pode possuir. Eles podem ser subdividas em funcionais e não funcionais. O ambiente operacional representa atributos do ambiente em que uma aplicação é usada e operada. Tecnologia do domínio e técnica de implementação representam detalhes de implementação em um nível mais técnico e baixo, sendo que o primeiro representa características especificas do domínio, e o segundo representa características genéricas. Após a categorização, as features são analisadas e organizadas, construindo o modelo de features, que representa features padrões de uma família de sistemas no domínio e a relação entre elas. As features são relacionadas através de um grafo hierárquico AND/OR, com

36 36 relações dos to tipo: obrigatória, opcional, alternativa, composto-de, especialização/generalização, e implementado-por. O termo features alternativas indica que não mais que uma especialização em um grupo de features pode ser feita para o sistema. Algumas regras de composição complementam o diagrama de features. Features opcionais e alternativas que não podem ser selecionadas quando uma feature é selecionada deve ser declarada com a expressão mutuamente exclusiva com. Features opcionais e alternativas que devem ser selecionadas quando uma feature é selecionada deve ser definida usando a expressão requer. As razões para as features também são representadas no modelo, como pode ser vista na Figura 12. A representação mais detalhadas deste modelo pode ser vista na Figura 13. Figura 12: Exemplo de modelo de features [19].

37 Figura 13: Modelo de Features [20] 37

38 38 Este modelo possui especificações de requisitos em níveis abstratos, e por isso deve ser agregado a outros modelos para permitir uma base de conhecimento adequado para o desenvolvimento da linha de produto. Em um domínio maior, é difícil manter o gerenciamento dessas features, pois o modelo torna-se complexo. O modelo também possui o problema de ambigüidade, direcionando a diferentes interpretações. Por exemplo, na Figura 14, a feature de controle de entrada (admittance Control) tem duas features alternativas: acesso cartão magnético(magnet Card Access) e acesso a PIN (PIN Access), mas essa representação leva à diferentes interpretações: Cada uma das aplicações deve suportar exatamente um dos controles de entrada? Uma aplicação deve suportar ambos os tipos de controle de entrada. O usuário decide qual tipo de controle usará. Uma aplicação deve suportar um dos tipos ou ambos os tipos de controle de entrada. Figura 14: Exemplo de modelo de features para o domínio de segurança de casa [5] 3.5 Baseada em Caso de Uso Os casos de uso têm sido muito eficientes para modelar os requisitos funcionais de sistema único [3]. Para ser utilizado em linhas de produto de software, é necessário adaptações que para representar as variabilidades do domínio, permitindo a instanciação das aplicações. A seguir são apresentados alguns métodos para casos de uso no contexto de SPL. Diversas abordagens apresentam soluções para casos de uso, tais como [3], [18], [31] e [32]. Entretanto, neste trabalho serão apresentadas apenas as abordagens [3] e [18] por possuírem propósitos diferenciados, enquanto a [31] e [32] possuem o mesmo objetivo de [3].

39 PLUS O PLUS (Product Line UML-Based Software Engineering) [3] descreve a variabilidade do domínio através de casos de uso e modelos de features. O método classifica os casos de uso em três tipos: casos de uso obrigatórios (kernel), que são necessários para todos os membros da LPS; casos de uso opcionais, que são necessários para apenas alguns membros da LPS; e casos de uso alternativos, onde diferentes casos de uso são necessários para diferentes membros da linha de produto. Além dos casos de uso, os atores também podem apresentar variabilidade. Assim, os atores podem ser opcionais, alternativos ou obrigatórios.. Um exemplo da representação desses tipos pode ser vista na Figura 15. Figura 15: Tipos de Casos de Uso [3] Os casos de uso são documentados seguindo um modelo padrão, como segue: Nome caso de Uso: para cada caso de uso é dado um nome. Categoria de Reuso: especifica se o caso de uso é obrigatório, alternativo, ou opcional. Sumário: descrição breve do caso de uso. Atores: atores do caso de uso. Dependência: seção opcional que descreve se um caso de uso depende de outro, ou seja, se a relações extends ou include. Pré-condições: especifica uma ou mais condições que devem ser verdadeiras para iniciar o caso de uso.

40 40 Descrição: descreve as seqüências principais do caso de uso. Esta descrição é em forma de entrada do ator, seguida por resposta do sistema. O sistema é tratado como uma caixa preta, portanto não se deve descrever como o sistema faz internamente para responder para o ator. Alternativas: descreve seqüências alternativas do fluxo principal. Pontos de variação: seção opcional que define os lugares na descrição do caso de uso onde diferentes funcionalidades podem ser introduzidas para diferentes membros da linha de produto. Mais detalhes sobre essa seção será apresentado a seguir. Pós-condições: seção que descreve as condições que são sempre verdadeiras no final do caso de uso, se a seqüência principal tem sido seguida. Questões fora de série: documenta questões sobre o caso de uso para serem discutidas com os usuários. O PLUS trata as variações de duas formas. Para pequenas variações, o ponto de variação é descrito no próprio caso de uso, indicando o lugar no caso de uso onde a mudança ocorreu. Isto pode incluir uma linha ou uma seqüência alternativa. Quando o caso de uso se torna complexo devido à quantidade de alternativas, é necessário definir as variações em outros casos de uso e definir relações include ou extend. Em representações de pequenas variações, as seguintes informações devem ser fornecidas: Nome do ponto de variação. Tipo de funcionalidade que será inserida no ponto de variação. Esses tipos podem ser opcional, alternativo obrigatório e alternativo opcional. Linha no caso de uso descreve onde a variabilidade pode ser inserida. Descrição da funcionalidade inserida no ponto de variação. Funcionalidade alternativa ou opcional pode ser incluída no ponto de variação. Um ponto de variação que especifica funcionalidade opcional descreve funcionalidades que pode ou não ser fornecidas por um dado membro da linha de produto. Se a opção identificada pelo ponto de variação for selecionada para um produto, então esta funcionalidade será inserida no local identificado no ponto de variação. Um ponto de variação que especifica funcionalidade alternativa descreve muitas possíveis funcionalidades alternativas, uma das quais deve ser inserida no local do caso de uso especificado pelo ponto de variação. Quando uma das alternativas deve sempre ser selecionada, então a funcionalidade possui o tipo alternativo obrigatório. Se for possível não escolher uma alternativa, então seu tipo é alternativo opcional. Em pontos de variações complexas, as seqüências alternativas ou opcionais são divididas em caso de uso separado. Se o novo caso de uso for uma alternativa do ponto de variação,

41 41 então ele será estendido do caso de principal, se as condições apropriadas forem satisfeitas. É importante destacar que o caso de uso base não depende da extensão do caso de uso e pode funcionar independentemente. A extensão do caso de uso, por outro lado, só funciona se a condição no caso de uso base for satisfeita. No caso de uso base os pontos de extensões são definidos para indicar o local exato onde uma ou mais extensão deve ser incluída. Um exemplo de relação extend com ponto de extensão é mostrado na Figura 16. Figura 16: Exemplo de ponto de extensão [3]. Relações includes são usadas para suportar casos de uso opcionais. Estes casos de uso opcionais, ou de inclusão, possuem características abstratas, ou seja, o caso de não pode ser executado sozinho. Quando o caso de uso base inclui este novo caso de uso obedecendo a uma condição de inclusão. Um exemplo da relação de inclusão pode ser visto na Figura 17. Após a definição dos casos de uso, o PLUS propõe a construção do modelo de features a partir de grupos de casos de uso que compartilham similaridades. Mais delathes sobre esse processo pode ser encontrado em [3]. Portanto, o PLUS fornece diretrizes suficientes para modelar os requisitos funcionais e as variabilidades da LPS baseada em casos de uso, e orientada como derivar features a partir de casos de uso. No entanto, os modelos propostas para a especificação não representam as razões dos requisitos, nem diferentes visões dos stakeholders.

42 42 Figura 17: exemplo de caso de uso de inclusão [3] PuLSE-CAVE Muitas vezes a linha de produto é iniciada a partir de produtos predecessores, tais como linha de produtos existente, sistemas legados ou sistemas em desenvolvimento. Assim, os artefatos já existentes podem ser usados como base de conhecimento para o desenvolvimento da linha de produto. Fantechi et al. [18] define a abordagem PuLSE 6 -CaVE (Commonality and Variability Elicitation) para derivar requisitos de linha de produto em forma de casos de uso, a partir da análise de documentos de usuários de sistemas existentes, como pode ser visto na Figura 18. Com esta abordagem é possível identificar features comuns e variáveis, elementos de caso de uso, tarefas, e requisitos. O PuLSE-CaVE é dividido nas fases seguintes: Preparação: compreende a coleta de documentos existentes; seleção dos documentos que cobrem a variabilidade da linha de produto; divisão destes documentos em partes gerenciáveis e comparáveis; e decisão sobre a quantidade de variabilidade nas partes definidas. Busca: as partes dos documentos identificadas são analisadas, e os elementos dos casos de uso são buscados através de heurísticas. Os elementos de casos de uso que podem ser identificados são: nomes, atores, metas, pré-condições, pós-condições, etapas do fluxo principal, e etapas do fluxo secundário. Seleção, mudança e modificação: os elementos dos casos de uso são selecionados, checados e ajustados pelo especialista do domínio. 6 PuLSE (Product Line Software Engineering) é uma framework definido pelo Fraunhofer IESE para desenvolver linhas de produto de software.

43 43 Figura 18: Capturando informações legadas para construção de casos de uso [18]. As primeiras duas etapas podem ser executadas por pessoas que têm pouco entendimento do domínio, eles não precisam ser o especialista do domínio. A terceira etapa requer o envolvimento do especialista do domínio para validar as entidades da documentação que foram selecionadas. A visão geral da abordagem pode ser vista na Figura 19. Figura 19: Visão geral da abordagem PuLSE-CaVE [18]. As heurísticas utilizadas para identificar os elementos comuns e variáveis dos casos de uso são: Títulos de seções ou subseções tipicamente contêm nomes de casos de uso;

44 44 Frases como apenas por, por usar, no caso de podem ser marcadas como précondições dos casos de uso; Pré-condições e metas dos casos de uso podem ser encontradas no início dos capítulos; Pré-condições podem ser encontradas antes ou na descrição do caso de uso; Frases como normalmente, frequentemente, com a exceção, exceto podem marcar os fluxos secundários dos casos de uso; As listas enumeradas ou com marcadores são marcados como um processo ordenado do fluxo principal, e descreve o caso de uso; Sentenças que descrevem interações com o sistema na forma de para fazer isto...faça isso... são descrições do caso de uso; Voz passiva é tipicamente um marcador para atividade do sistema. Estas sentenças podem ser utilizadas na descrição do caso de uso. As variabilidades e semelhanças nos elementos dos casos de uso podem ser encontradas com as heurísticas seguintes: Elementos arbitrários que ocorrem apenas em um manual de usuário provavelmente são elementos opcionais; Títulos ou subtítulos que ocorrem em apenas uma das documentações pode ser um caso de uso opcional; Títulos ou subtítulos que têm nomes diferentes ou ligeiramente diferentes, mas que ocupam o mesmo lugar na tabela de conteúdos, são possíveis casos de uso alternativos; Frases que diferem em apenas uma ou poucas palavras podem ser evidências para alternativas; Se valores numéricos diferem, então eles podem ser variabilidades paramétricas; Itens de menu que são escritos em apenas alguns dos documentos podem ser uma funcionalidade opcional ou alternativa (casos de uso ou partes deles);

45 45 Figura 20: Exemplo de elementos de casos de uso identificados em manual do usuário [18]. A efetividade desta técnica depende da padronização dos documentos do usuário. Se os documentos são estruturados de maneira diferente, torna-se difícil aplicar as heurísticas para encontrar variabilidades e semelhanças.

46 Modelo de Variabilidade Ortogonal Pohl et al. [5] propõe um modelo de variabilidade ortogonal (MVO), que representa variabilidade em um diagrama (Variability Diagram) e relaciona suas entidades com as variações dos artefatos de requisitos, definindo explicitamente a variabilidade da linha de produto. O MVO é proposto também para resolver problemas encontrados em diversos artefatos de requisitos para SPL, tais como modelo de features e casos de uso. No modelo de features, Pohl el al. [5] aponta o problema de representação de agrupamento de features. Por exemplo, na Figura 21, as features Câmera Surveillance e Outdoor Câmera Surveillance não podem ser agrupadas apenas com o modelo de features. Através do modelo de variabilidade ortogonal, o problema de agrupamento pode ser resolvido, relacionando o agrupamento com uma variação do modelo. Figura 21: Agrupamento de Features [5]. Na especificação de requisitos textual, há uma forte expressividade dos requisitos, contudo, o uso de linguagem natural direciona também ao problema de ambigüidade. Estes documentos expressam a variabilidade por palavras chaves ou frases, por exemplo: O sistema de segurança da casa deve ser equipado com câmeras coloridas ou preta e branca capazes de capturar imagens infra-vermelho. Neste exemplo, não está claro se apenas câmeras coloridas, ou ambas os tipos devem ser capazes de fotografar infra-vermelho. Assim,

47 47 a esta forma de documentação de variabilidade deixa aberturas para ambigüidade. Para evitar a ambigüidade, a variabilidade deve ser definida de forma explícita, como o exemplo da figura 22. Figura 22: Variabilidade em especificação de requisito textual [5]. No entanto, se for necessário utilizar esse ponto de variação em outras partes do documento, será necessário reescrever o texto. Assim, o MVO pode ser utilizado para solucionar esse problema, como pode ser visto na Figura 23. Figura 23: Modelando variabilidade ortogonal em requisitos textuais [5]. O MVO também permite a representação de variabilidade em modelos de caso de uso, tais como cenários de casos de uso (Figura 24), diagrama de seqüência (Figura 25), diagrama de caso de uso (Figura 26). Outros diferentes modelos também são representados através da variabilidade, tais como diagrama de fluxo de dados, diagrama de classes, diagramas de máquina de estado. Todos os artefatos de requisitos são relacionados com um único diagrama

48 48 de variabilidade de maneira que facilite a rastreabilidade, facilitando as futuras mudanças nos requisitos. Figura 24: Representação do Cenário do Caso de Uso [5]. Figura 25: Representação no Diagrama de Seqüência [5].

49 49 Figura 26: Representação em Diagrama de Caso de Uso [5]. A proposta de MVO é viável quando existe uma ferramenta de suporte para manter a ratreabilidade dos artefatos de requisitos que são relacionados com o diagrama de variabilidade. Ao contrário, é complexo gerenciar a grande quantidade de artefatos e de requisitos relacionados com um único modelo de variabilidade.

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

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

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

Leia mais

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

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos)

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Engenharia, Levantamento, Elicitação, Gerenciamento Fernando Pedrosa fpedrosa@gmail.com 1 2 Área da Engenharia

Leia mais

Engenharia de Software

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

Leia mais

Modelos de processos de desenvolvimento de software

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

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

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

Leia mais

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

! 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

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

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

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

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

Leia mais

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

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

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

Engenharia de Requisitos. Aécio Costa

Engenharia de Requisitos. Aécio Costa Aécio Costa Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004) Um requisito é algo que o sistema é capaz

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

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

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

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

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

Gerenciamento de Escopo na Gestão de Projetos

Gerenciamento de Escopo na Gestão de Projetos Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior aebjr@terra.com.br MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro

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

APOO Análise e Projeto Orientado a Objetos. Requisitos

APOO Análise e Projeto Orientado a Objetos. Requisitos + APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas

Leia mais

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

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

Leia mais

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

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

Leia mais

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

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

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

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

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

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

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

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

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

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

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE VI: Como desenvolver Sistemas de Informação e Gerenciar Projetos. Novos sistemas de informação são construídos como soluções para os problemas

Leia mais

Instrutora: Claudia Hazan claudinhah@yahoo.com. Motivações para Engenharia de Requisitos (ER) Processo de Requisitos

Instrutora: Claudia Hazan claudinhah@yahoo.com. Motivações para Engenharia de Requisitos (ER) Processo de Requisitos ,PSODQWDomRGHXP 3URFHVVR GH *HVWmR GH 5HTXLVLWRV VHJXLQGRR R &00, 0, Instrutora: Claudia Hazan claudinhah@yahoo.com Agenda Motivações para Engenharia de Requisitos (ER) Processo de Requisitos Visão Geral

Leia mais

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

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

Leia mais

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

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

Documento de Requisitos

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

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

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

Professor: Disciplina:

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

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

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

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software. Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo

Leia mais

Pós Graduação Engenharia de Software

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

Leia mais

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

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

Leia mais

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

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

Leia mais

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor Reuso de Software Aula 05 Agenda da Aula Linha de Produtos de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 19 Março 2012 Padrões arquiteturais Cliente-Servidor

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

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

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

Leia mais

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

Modelagem de Casos de Uso (Parte 1)

Modelagem de Casos de Uso (Parte 1) Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de

Leia mais

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Software Gerenciamento de Requisitos Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Requisitos (ER) Engenharia de O termo Engenharia implica em dizer que um processo sistemático

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

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

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

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

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

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Roteiro Conceitos Engenharia de requisitos Artigo Definições de requisitos Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas

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

Projeto de Sistemas I

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

Leia mais

MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO 1ª Edição 2012 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO

Leia mais

Introdução CMMI. Qualidade e Teste de Software CMMI 1

Introdução CMMI. Qualidade e Teste de Software CMMI 1 Introdução CMMI O propósito da qualidade é estabelecer um diferencial competitivo, através de contribuições como redução de defeitos, redução de custos, redução de retrabalho e aumento da produtividade,

Leia mais

Engenharia de Software

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

Leia mais

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

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente

Leia mais

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.

Leia mais

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases Engenharia de Software Modelagem de Requisitos com Casos de Uso 1 Objetivos Descrever em detalhe a técnica de Modelagem com Use Cases 2 1 Use Case É uma forma específica de uso do sistema através da execução

Leia mais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais Objetivos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

Feature-Driven Development

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

Leia mais

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

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

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

Leia mais

Verificação e Validação de Requisitos

Verificação e Validação de Requisitos Verificação e Validação de Requisitos Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência

Leia mais

ÁGEIS. Autor. Fernanda Rodrigues dos Santos d Amorim. Orientador. Prof. Jaelson Freire Brelaz de Castro. Recife, julho 2008

ÁGEIS. Autor. Fernanda Rodrigues dos Santos d Amorim. Orientador. Prof. Jaelson Freire Brelaz de Castro. Recife, julho 2008 UNIVERSIDADE FEDERAL DE PERNAMBUCO PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA ENGENHARIA DE REQUISITOS PARA MÉTODOS ÁGEIS Autor Fernanda Rodrigues dos Santos d Amorim Orientador Prof.

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

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

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

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

Leia mais

Modelagem de Casos de Uso! Um modelo funcional

Modelagem de Casos de Uso! Um modelo funcional Modelagem de Casos de Uso Diagrama de Casos de Uso Especificação de Cenários! Um modelo funcional! Mostra como os valores são processados, sem preocupações com:! ordenamento (seqüência) das ações;! as

Leia mais

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

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

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

Leia mais

Linha de Produto de Software

Linha de Produto de Software Linha de Produto de Software Jair C Leite DIMAp/UFRN O que é linha de produto de software? Técnica de produção baseada em outras engenharias fábricas que desenvolvem uma mesma família de produtos com partes

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

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

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

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

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

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

Leia mais

Engenharia de Software. 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