identificando requisitos comuns e variantes em linhas de produtos de software

Identificando requisitos comuns e variantes em linhas de produtosde software

Engenharia de Requisitos de Softwares - Prof. Dr. Paulo Sérgio Muniz Silva – 2016

André Rocha Agostinho

Objetivos da apresentação

Análise de domínio e reuso de requisitos de softwareAté o momento, a finalidade do sistema de gestão de crise era a de gerenciar o atendimento de acidentes de veículos em estradas. Agora, seu escopo deve ser ampliado para tratar diversas situações de crise, como as decorrentes de desastres naturais, de várias modalidades de transporte, etc., constituindo uma linha de produtos de software.

• Apresentar uma versão inicial de parte significativa do modelo de domínio, numa linguagem apropriada, que identifique e especifique requisitos comuns e variantes da linha de produtos. Para tanto:– Empregar o método de modelagem proposto por (Kim, J. et al., 2006).

Explicitar as premissas assumidas. – Apresentar uma avaliação a respeito da viabilidade de aplicação prática

deste método de modelagem.

2

Objetivos da apresentação

Rastreabilidade dos requisitos de softwareConsiderando a solução proposta na primeira parte:• Definir a Estratégia de Rastreabilidade dos requisitos de software para a linha

de produtos definida.• Considerando a estratégia definida:

– Elaborar alguns fragmentos de matrizes de rastreabilidade considerando os requisitos de domínio identificados como requisitos comuns e variantes.

– Definir os principais atributos dos requisitos de software a serem utilizados na gerência dos requisitos. Justificar.

3

Organização da apresentação1. Linha de produtos de software

– Definição– Motivação– Reuso do software

2. Análise de domínio utilizando a abordagem Feature Oriented Domain Analysis– Conceitos– Processo de análise de domínio– Análise de produtos de domínio

3. Modelagem de domínio– Premissas estabelecidas– Modelos de domínio– Identificação de requisitos comuns e variantes– Especificação de requisitos comuns e variantes

4. Rastreabilidade dos requisitos do software– Estratégia de rastreabilidade– Matrizes de rastreabilidade– Atributos dos requisitos de software a serem gerenciados

4

• Definição• Motivação• Reuso do software

Linha de produtos de software 5

Uma Linha de Produtos de Software é um conjunto de sistemas intensivos em software, compartilhando um conjunto controlado de características comuns que satisfazem a uma necessidade ou missão específica de um segmento particular do mercado, desenvolvido a partir de um conjunto comum de ativos fundamentais (core assets) segundo uma prescrição.

Linha de produtos de softwareDefinição

(Pohl, K. el al., 2005)

6

(Pohl, K. el al., 2005)

Break-Even Point• (Weiss and Lai 1999) entre 3 e 4 • (Pohl, K. el al., 2005) 3

Principal: Redução do custo no desenvolvimento

Outras motivações:Melhorias na qualidade, redução no time to market, menor esforço de manutenção e etc.

Considerações:A ponto preciso depende de várias características da organização e do mercado previsto, tais como base de clientes, expertise e tipos de produtos. A estratégia inicial pra criar o primeiro produto também vai influenciar neste número.

Linha de produtos de softwareMotivação

7

As partes que serão reutilizadas podem ser partes existentes ou desenvolvidas para reuso futuro.

Linha de produtos de softwareReuso do software

Podem incluir, entre outros: • Conhecimento do domínio • Modelo de domínio • Técnicas de elicitação, análise e modelo de requisitos • Arquitetura e componentes de software • Planos de teste e casos de teste• Processos, métodos e ferramentas

(Pohl, K. el al., 2005)

8

• Conceitos• Processo de análise de domínio• Análise de produtos de domínio

Análise de domínio – abordagem FODA 9

• Domínio (ou domínio da aplicação): Um conjunto de aplicações atuais ou futuras que compartilham um conjunto comum de capacidades e dados.

• Análise de domínio: O processo de identificar, coletar, organizar e representar as informações relevantes do domínio, baseado no estudo dos sistemas existentes e de suas histórias de desenvolvimento.

• Modelo do domínio: Definição das funções, dados e relações num domínio.

• Característica (feature)Atributos do sistema que afetam os usuários finais e stakeholders: eles devem entender as características para utilizarem o sistema.

(Kang et al., 1990)

Análise de domínio – abordagem FODA Conceitos

10

• Reuso de software: O processo para implementer novos sistemas de software com base na informação de um software existente.

• Reuso de componentes: Um componente de software (incluindo requisitos, arquitetura, código, testes e etc) concebido e implementado para uma finalidade específica de reutilização.

(Kang et al., 1990)

Análise de domínio – abordagem FODA Conceitos

11

Análise de domínio reúne e representa as informações em sistemas de software que compartilham um conjunto comum de recursos e dados.

Métodos [GILR89A, MCNI86A, PRIE87A] sugerem 3 fases no processo de análise de domínio.

1. Análise de contexto: Define a extensão (ou limites) de um domínio para análise.

2. Modelagem de domínio: Deescreve os problemas dentro do domínio que são endereçados pelo software.

3. Modelagem de arquitetura: Cria arquitectura (s) de software que implementa uma solução para os problemas no domínio.

Análise de domínio – abordagem FODA Processo de análise de domínio - Fases

(Kang et al., 1990)

12

Fontes Produtor Consumidores

Usuário final Usuário final

Especialista De domínio

Analistade domínio

Analistade Requisitos

Projetista de Software

(Kang et al., 1990)

Análise de domínio – abordagem FODA Processo de análise de domínio - Participantes

13

1) Análise de contexto 2) Modelagem de domínio 3) Modelagem de arquitetura

Info.Produt

os

Modelo de

domínio

Modelo de

domínio

Modelo de

Arquit.

EscopoE

Limites

Analista de domínio, usuários e especialista do domínio

• Limites e escopo do domínio.

• Reunir informações para análise.

Analista de domínio, usuários, especialista do domínio e analista de requisitos

• Fontes de informação e outros produtos de análise de contexto

• Apoiar a criação de um modelo de domínio

• Revisão do modelo

Analista de domínio, especialista do domínio, analista de requisitos e projetista de software

• Produzir o modelo de arquitetura com o modelo de domínio.

• Revisão do modelo

Análise de domínio – abordagem FODA Processo de análise de domínio - Processo

(Kang et al., 1990)

14

Produtos da análise

do domínio

Produtos do novo sistema

a ser desenvolvido

Análise de contexto

Modelagemde Domínio

Modelagemda Arquitetura

Contexto e

escopo

Modelos (Features,

ER, etc)

Arq. Estrutura

de controle

Novo contexto

Novas espec.

Nova arquit.

Requisitos

Requisitos

Requisitos Software

Domínio

Domínio

Domínio

Usuário

Usuário

Especialista do domínio

Analistado domínio

Adicionar, Modificar e remover “features”



Análise de domínio – abordagem FODA Processo de análise de domínio – Adaptando novos produtos

(Kang et al., 1990)

15

• Premissas estabelecidas• Modelos de domínio• Identificação de requisitos comuns e variantes• Especificação de requisitos comuns e variantes

Modelagem de domínioSistema de Gestão de Crises

16

1. Formação de uma equipe seguindo a formação de participantes da abordagem FODA:

Papéis Representados por

Analista de domínioPessoa com sólida experiência em análise e modelagem de domínios de sistemas variados.

Especialistas de domínio

Pessoas especializadas em gestão de crises de qualquer natureza com foco em modalidades de transportes.

UsuáriosRepresentantes: Atendente, Supervisor, Coordenador, Observador, Grupo de Apoio à Crise (Bombeiros. Médicos, Enfermeiros)

Modelagem de domínioPremissas estabelecidas

• Analista de domínio• Analistas de requisitos• Especialistas de domínio• Projetistas de softwares• Usuários

17

2. Etapa da análise de contexto foi realizada seguindo o processo de análise de domínio da abordagem FODA

Insumos utilizados no processo:Documento visão do SGAVE (Sistema de Gestão de Acidentes de Veículos em Estradas)- Definição e finalidade do produto- Relação dos stakeholders e usuários


18

3. Aplicar o método FODA para abstrair elementos do SGC

“Desenvolvimento de produtos de domínio genéricos e amplamente aplicáveis dentro de um domínio é o principal objetivo do método FODA. Este conhecimento geral pode ser alcançado por abstrair "fatores" que fazem uma aplicação diferente de outras aplicações. No entanto, para desenvolver aplicações dos produtos genéricos, os fatores que foram abstraídos devem ser feito de forma específica e introduzida durante o refinamento. Não só o conhecimento geral, mas também os fatores que tornam cada aplicativo exclusivo são partes importantes do conhecimento de domínio e devem ser capturados nos produtos de domínio.”

(Kang et al., 1990)

Conceitos de modelagem utilizados- Agregação/Decomposição- Generalização/Especialização


19

4. Escopo, limites e contexto

Produto: Sistema de Gestão de Crises (SGC).

Definição: Sistema de gestão de acidentes em rodovias no Estado de São Paulo.

Foco de atuação: Acidentes de veículos em rodovias

Finalidade: Facilitar o processo de gestão de crise, auxiliando a designação eficaz de recursos e orquestrando a comunicação entre todas as partes envolvidas no tratamento da crise.


20

4. Escopo, limites e contexto

Produto: Sistema de Gestão de Crises (SGC).

Linha de Produtos: Sistema de Gestão de Crises para Modalidades de Transportes (SGCMT).

Foco de atuação: Meios de transportes (Carros, Motos, Caminhões, Aviões, Helicópteros, Trens e etc).

Finalidade: Facilitar o processo de gestão de crise, auxiliando a designação eficaz de recursos e orquestrando a comunicação entre todas as partes envolvidas no tratamento da crise.


PLANO DE MERCADO PLANO DE PRODUTO

21

5. Diagrama de estrutura (alto nível)

SGC

GCAR GCAF GCAA

Gestão da crise

SGCMT

Gestão da crise

Gestão da crise

1) Família de produtos SGC Sistema de Gestão de Crise

2) Linha de produtos SGCMTSistema de Gestão de Crise para Modalidades de Transportes

3) Produtos SGCMT• GCAR - Gestão de Crise para

Acidentes Rodoviários• GCAF - Gestão de Crise para

Acidentes Ferroviários• GCAA - Gestão de Crise para

Acidentes Aéreos

4) FinalidadeFacilitar o processo de gestão de crise, deslocando recursose orquestrando a comunicação entre todas as partes envolvidas.


22

6. Stakeholders comuns da linha de produtos SGCMT

ProdutoResumo dos principais

StakeholdersResumo dos stakeholders

em comum

GCARPolícia RodoviáriaConcessionárias de Rodovias

1. Governo do Estado de São Paulo2. Vítimas3. Testemunhas4. Comunidade local5. Operadoras de Telefone6. Atendente da Crise7. Coordenador da Equipe de Gestão de Crise8. Equipe de Gestão de Crise9. Grupos de resgate

1. GRAU (Grupo de Resgate e Atendimento a Urgências)

2. CBPMESP (Corpo de Bombeiros Militar do Estado de São Paulo)

3. Grupamento de Radiopatrulha Aérea da Polícia Militar.

GCAFPolícia FerroviáriaConcessionárias de Ferrovias

GCAAPolícia FederalForça Área BrasileiraExército BrasileiroMarinha do Brasil


23

7. Usuários comuns da linha de produtos SGCMT

ProdutoResumo dos stakeholders

em comumResumo dos usuários

em comum

GCAR 1. Governo do Estado de São Paulo2. Vítimas3. Testemunhas4. Comunidade local5. Operadoras de Telefone6. Atendente da Crise7. Coordenador da Equipe de Gestão

de Crise8. Equipe de Gestão de Crise9. Grupos de resgate

1. GRAU (Grupo de Resgate e Atendimento a Urgências)

2. CBPMESP (Corpo de Bombeiros Militar do Estado de São Paulo)

3. Grupamento de Radiopatrulha Aérea da Polícia Militar.

• Atendente 6. Atendente da Crise

• Coordenador7. Coordenador da Equipe de Gestão de Crise

• Observador, Supervisor6 Equipe de Gestão de Crise

• Recursos Humanos9. Grupos de resgate

• Centro de Controle8. Equipe de Gestão de Crise

• Operadora de Telefonia5. Operadoras de Telefone

GCAF

GCAA


24

Produto Atores Casos de Uso

GCAR• Atendente • Coordenador• Observador• Supervisor• Recursos

Humanos• Centro de

Controle

1. Abrir chamado de incidente 2. Cancelar chamado de incidente3. Consultar chamado de incidente4. Avaliar chamado de incidente 5. Registrar ocorrência da crise6. Cancelar ocorrência da crise7. Monitorar situação da crise8. Modificar situação da crise9. Encerrar ocorrência da crise10. Definir estratégia de mitigação 11. Modificar estratégia de mitigação 12. Cancelar estratégia de mitigação 13. Avaliar estratégia de mitigação 14. Definir procedimentos de mitigação 15. Consultar procedimentos de mitigação 16. Alocar recursos para a crise

GCAF

GCAA

Use Cases: Best Practices - By Ellen Gottesdiener - 2003 - IBM

8. Atores candidatos e casos de uso


25

9. A escolha da linguagem de modelagem

• Um artefato composto de um vocabulário de conceitos do domínio (suas definições e propriedades), um modelo mostrando todas as relações possíveis entre estes conceitos e um conjunto de regras formais que restringem a interpretação dos conceitos e relações, representando de maneira clara e não ambígua o conhecimento do domínio.

(Guarino, 1997)

Selecionadas• ER• SBVR• Método de modelagem por metas e cenários (Kim, J. et al., 2006)


26

Análise de domínio e reuso de requisitos de softwareAté o momento, a finalidade do sistema de gestão de crise era a de gerenciar o atendimento de acidentes de veículos em estradas. Agora, seu escopo deve ser ampliado para tratar diversas situações de crise, como as decorrentes de desastres naturais, de várias modalidades de transporte, etc., constituindo uma linha de produtos de software.

• Apresentar uma versão inicial de parte significativa do modelo de domínio, numa linguagem apropriada, que identifique e especifique requisitos comuns e variantes da linha de produtos. Para tanto:– Empregar o método de modelagem proposto por (Kim, J. et al., 2006).

Explicitar as premissas assumidas. – Apresentar uma avaliação a respeito da viabilidade de aplicação prática

deste método de modelagem.

Objetivo 1 27



28

Chamado

Estratégia de mitigação

Procedimentos de mitigação

Recursos MITIGA CriseCONTÊM

REGISTRA

ANALISA

Atendente

Supervisor REGISTRA

Coordenador

ALOCA

Modelagem de domínioModelos de Domínio - ER

29

1 N

DEFINE

CONSOME

1

N

1

N

1N

1

1

1

N

N

N

1

N

Modelagem de domínioModelos de Domínio - SBVR

30

Regra R1:O coordenador deve aguardar a ocorrência de uma crise para definir uma estratégia de mitigação.

Regra R2:O supervisor registra uma ocorrência de uma crise após um chamado ser classificado como legítimo

Regra R3:Os recursos consomem procedimentos de mitigação quando alocados pelo coordenador

Termo: É usado para designar um conceito de palavra.

Verbo: O verbo é usado para designar conceitos de verbos, usualmente um verbo, preposição ou combinação. Tal designação é definida no contexto na forma de expressão.

Palavra-chave: A palavra-chave é usada para símbolos linguísticos na construção de declarações – as palavras podem ser combinadas com outras designações para formular declarações e definições



31

MotivaçãoAs principais abordagens orientadas à características FODA/FeaturSEB NÃO SUPORTAM um processo bem definido e a fonte de variabilidade.

• Processo bem definidoSem um processo bem definido, a abordagem torna-se menos aplicável pela ausência de um conjunto de passos de como se aplicar o método

• Fonte de variabilidadeSem capturar o conhecimento da fonte de variabilidade, torna-se mais difícil prever quando as variações vão ocorrer e de onde elas se originam.

Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment

32

Metas e cenários na engenharia de requisitos

“São formas efetivas de indentificação de requisitos na engenharia de requisitos.”

(Kim et al, 2004, Potts, 1997; Rolland et al., 1998b. Sutcliffe, 1998)

“Metas fornecem uma análise racional para requisitos . Requisitos existem porestarem fundamentados sobre metas. Metas fornecem uma base para requisitos.”

(Dardenee et al., 1991; Kim et al., 204; Sommerville and Sawyer, 1997)

“Cenários descrevem situação reais, capturando requisitos reais em um determinado contexto.”

(Rolland et al, 1998b)


33

• No contexto de linha de produto metas de negócios de alto nível guiam planos de marketing e planos de produtos e forcam produtos em uma família de produtos a terem requisitos comuns e variantes.

• Nas metas de negócios as características dos produtos são determinadas e também fornecem uma análise sobre os requisitos do domínio.

• A modelagem de metas e cenários possibilita a gestão adequada das variações entre produtos em uma família de produto.


Metas e cenários em características de produtos

34

CenárioMeta< Alcança

N

Autor >

1

Comum

Alternativo

Opcional

Tipo de variação

Meios de se alcançar a meta

Tipos de cenários


Metas e cenários na análise de requisitos do domínio

35

Meta V + Target + Direction

V: Verbo ativoTarget: Objeto concentual ou físicoDirection: Fonte ou destino

Cenário S + V + Target + Direction + Manner

S: Agente para o sistema projetado ou o próprio sistema projetadoV: Verbo ativoTarget: Objeto conceitual ou físicoDirection: Fonte ou destinoManner: Forma o qual o cenário está implementado


Escrevendo metas e cenários em características de produtos

36


Características da abordagem

37


Análise de requisitos do domínio – Processo de modelagem

38

Análise de requisitos do domínio – Utilizando o método


39

BG: Meta de negócio Sg: Meta de serviço Ss: Cenário de serviçoIAg: Meta de interaçãoIAs: Cenário de interação INg: Meta interna INs: Cenário interno

Meta de negócio do SGCMTBG: "Ser o principal e o melhor sistema de gestão de crise de meios de transportes para o estado de São Paulo"

Metas de serviçosSg1: "Fornecer gestão de crise para acidentes rodoviários“ Sg2: “Fornecer gestão de crise para acidentes ferroviários“[alternativo]Sg3: "Fornecer gestão de crise para acidentes aéreos“[alternativo]



40

Nível de negócio

• Sg1: "Fornecer gestão de crise para acidentes rodoviários“• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a

Urgências) para uma ocorrência de crise via centro de controle. [comum]

• Sg2: “Fornecer gestão de crise para acidentes ferroviários“• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a

Urgências) para uma ocorrência de crise via centro de controle. [comum]• Ss2: Coordenador pode alocar unidades da polícia ferroviária para acidentes de trens

via centro de controle [opcional]

• Sg3: "Fornecer gestão de crise para acidentes aéreos“• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a

Urgências) para uma ocorrência de crise via centro de controle [comum] • Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para

acidentes de aviões via centro de controle [opcional]

Nível de serviçoAnálise de requisitos do domínio – Utilizando o método


41

• Sg1: "Fornecer gestão de crise para acidentes rodoviários“Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências) para uma ocorrência de crise via centro de controle [comum]

IAg1: “Alocar unidades GRAU para o local da crise “• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]• IAs2: Coordenador deve acionar unidades GRAU para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida [comum]• IAs3: Coordenador pode acionar unidades do GATE (Grupo de Ações Táticas Especiais da

PM) para o local da crise por meio das unidades GRAU [opcional]



42

Nível de interação

• Sg1: "Fornecer gestão de crise para acidentes rodoviários“Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências) para uma ocorrência de crise via centro de controle [comum]

IAg1: “Alocar unidades GRAU para o local da crise “• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]• IAs2: Coordenador deve acionar unidades GRAU para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida [comum]• IAs3: Coordenador pode acionar unidades do GATE (Grupo de Ações Táticas Especiais da

PM) para o local da crise por meio das unidades GRAU [opcional]



43

Nível interno

INg2: “Encaminhar informações da ocorrência e procedimentos para a central da GRAU“

• INs1: Módulo de comunicação SGC deve transmitir um pacote com informações sobre a ocorrência para a central da GRAU [comum]

• INs2: Módulo de comunicação SGC deve aguardar confirmação da central da GRAU [comum]

• INs3: Módulo de comunicação SGC pode retransmitir um pacote com informações sobre ocorrência para a central da GRAU [opcional]

• Sg3: "Fornecer gestão de crise para acidentes aéreos“• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências)

para uma ocorrência de crise via centro de controle [comum] • Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para acidentes de

aviões pelo centro de controle [opcional]

IAg2: “Alocar unidades da FAB para o local da crise “• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]• IAs2: Coordenador deve acionar unidades da FAB para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida [comum]



44

Nível de interação

• Sg3: "Fornecer gestão de crise para acidentes aéreos“• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências)

para uma ocorrência de crise via centro de controle [comum] • Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para acidentes de

aviões pelo centro de controle [opcional]

IAg2: “Alocar unidades da FAB para o local da crise “• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]• IAs2: Coordenador deve acionar unidades da FAB para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida [comum]



45

Nível interno

INg2: “Encaminhar informações da ocorrência e procedimentos ao centro de controle da FAB “

• INs1: Módulo de comunicação SGC deve transmitir um pacote com informações sobre ocorrência para o centro de controle de desastres aéreos da FAB [comum]

• INs2: Módulo de comunicação SGC deve aguardar a confirmação para o centro de controle de desastres aéreos da FAB [comum]

• INs3: Módulo de comunicação SGC pode retransmitir um pacote com informações sobre ocorrência para o centro de controle de desastres aéreos da FAB [opcional]

Fornecer gestão de crise para acidentes

rodoviários

Fornecer gestão de crise para acidentes

ferroviários

Fornecer gestão de crise para acidentes aéreos

Ser o principal e o melhor sistema de gestão de crise de meios de transportes para o estado de São Paulo

Alocar unidades GRAU para o local da crise

Encaminhar informações da ocorrência e

procedimentos a central da GRAU.







SGCMT

Alocar unidades da FAB para o local da crise


procedimentos ao centro de controle de desastres

aéreos da FAB.

Árvore de metas


46


47



48

Representação dos requisitos do domínio – Visão geral

- Metas e cenários no nível de interação dos requisitos de domínio são usados para ajudar a construir casos de usos.

- Uma meta no nível de interação é alcançada através de cenários e um caso de uso contém o conjunto de cenários possíveis para alcançar a meta

Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment

49

Representação dos requisitos do domínio – Regras-guia de transferência

Regras Definição

R1 Metas no nível de interação tornam-se casos de uso

R2 Um agente que necessita interagir com a meta torna-se o ator primário

R3Cenários tornam-se especificações textuais de casos de uso e um agente ou sujeito do cenário pode se tornar um ator. Caso um agente não se torne um ator primário o mesmo deve ser considerado como secundário

R4

Metas com requisitos variantes no nível de interação tornam-se casos de uso com tipo variante. Se uma meta tem um relacionamento como “alternativo”, um caso de uso com o estereótipo “<<alternative>>” é representado no diagrama. Se uma meta tem um relacionamento como “opcional”, um caso de uso com o estereótipo “<<opcional>>” é representado no diagrama.

R5 Metas e cenários no nível interno são descritos em cada especificação textual de caso de uso


50

Representação dos requisitos do domínio – Diagrama de casos de uso

Coordenador

<<comum>>Alocar unidades GRAU

para o local da crise

<<opcional>>Alocar unidades da FAB


SGCMT


51

Representação dos requisitos do domínio – Diagrama de casos de uso

Coordenador

<<comum>>Alocar unidades GRAU


<<opcional>>Alocar unidades da FAB


SGCMTR1

META DE INTERAÇÃO > CASO DE USO

R2AGENTE > ATOR

R4ESTEREÓTIPOS DE

VARIAÇÃO


52

Representação dos requisitos do domínio – Especificação de caso de uso

Nome do caso de uso: Alocar unidades GRAU para o local da criseAtores: CoordenadorDescrição do caso de uso:

1. Coordenador deve definir a estratégia de mitigação da crise <<comum>>2. Coordenador deve acionar unidades GRAU para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida <<comum>>1. Encaminhar informações da ocorrência e procedimentos para a central da

GRAU1. Módulo de comunicação SGC deve transmitir um pacote com informações

sobre a ocorrência para a central da GRAU <<comum>>2. Módulo de comunicação SGC deve aguardar confirmação da central

da GRAU <<comum>>3. Módulo de comunicação SGC pode retransmitir um pacote com informações

sobre ocorrência para a central da GRAU << opcional >>3. Coordenador pode acionar unidades do GATE para o local da crise por meio das

unidades GRAU <<opcional>>Tipo de variação: Comum


53

Nome do caso de uso: Alocar unidades GRAU para o local da criseAtores: CoordenadorDescrição do caso de uso:

1. Coordenador deve definir a estratégia de mitigação da crise <<comum>>2. Coordenador deve acionar unidades GRAU para o local da crise por meio dos

procedimentos da estratégia de mitigação escolhida <<comum>>1. Encaminhar informações da ocorrência e procedimentos para a central da

GRAU1. Módulo de comunicação SGC deve transmitir um pacote com informações

sobre a ocorrência para a central da GRAU <<comum>>2. Módulo de comunicação SGC deve aguardar confirmação da central

da GRAU <<comum>>3. Módulo de comunicação SGC pode retransmitir um pacote com informações

sobre ocorrência para a central da GRAU << opcional >>3. Coordenador pode acionar unidades do GATE para o local da crise por meio das

unidades GRAU <<opcional>>Tipo de variação: Comum

Representação dos requisitos do domínio – Especificação de caso de usoR1

META DE INTERAÇÃO > CASO DE USO

R2AGENTE > ATOR

R3CENÁRIOS DE INTERAÇÃO

> ESPECIFICAÇÃOAGENTES > ATOR

R4ESTEREÓTIPOS DE

VARIAÇÃOR5

METAS E CENÁRIOS DO NÍVEL INTERNO SÃO DESCRITOS NA

ESPECIFICAÇÃO DE CASO DE USO


54


55

Pontos fortes1. Uma boa abordagem para a derivação do escopo das metas de negócios2. Os níveis de metas propostos auxiliam nas definições dos requisitos de

acordo com cada perspectiva3. Existe uma rastreabilidade total entre metas, cenários, requisitos e

especificação4. Existe uma rastreabilidade parcial entre planos de marketing e de produto

com as metas de negócio5. Bom entendimento sobre a variabilidade das características do produto em

uma linha de produto6. Facilidade em escalar a produção de novos produtos utilizando-se do reuso

do software

Modelagem de domínioApresentar uma avaliação a respeito da viabilidade de aplicação prática do métodoArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment

56

Pontos fracos1. Dificuldade em se aplicar o método sem um documento visão bem

definido2. Dificuldade em se criar metas de serviços sem um plano de marketing bem

definido3. Dificuldade na derivação de cenários para as metas dos níveis

subsequentes4. Dificuldade no uso do método sem um conhecimento prévio de uma

abordagem dirigida à características como o FODA e o FeaturSEB5. Necessidade dos papéis de analista do domínio e especialista do domínio.

E segundo o FODA de uma equipe contendo um analista de requisitos , usuários e projetista de software.

6. Não encontrado nenhum papel relacionado à gerente de produto ou gerente grupo-produto (linha de produto).


57

Oportunidades1. Adaptar os papéis do FODA com uma metodologia ágil

Ex: Em equipes usando metodologia Scrum, tentar adequar os papeis da equipe que possam de fato suprir um analista de domínio e um especialista do domínio.

2. Considerar na abordagem FODA os conceitos de Lean StartupEx: Para criar produtos MVP (Mínimo produto viável) tentar utilizar um processo de análise de domínio mais enxuto e tentar adaptar os métodos de modelagem para a criação de linhas de produtos que possam responder bem a mudanças.


58

Rastreabilidade dos requisitos de softwareConsiderando a solução proposta na primeira parte:• Definir a Estratégia de Rastreabilidade dos requisitos de software para a

linha de produtos definida.• Considerando a estratégia definida:

– Elaborar alguns fragmentos de matrizes de rastreabilidade considerando os requisitos de domínio identificados como requisitos comuns e variantes.

– Definir os principais atributos dos requisitos de software a serem utilizados na gerência dos requisitos. Justificar.

Objetivo 2 59

Rastreabilidade dos requisitos de software 60Estratégia de rastreabilidade

- As características dirigem o MCU (Spence, I.; Probasco, L. , 2000)- Pré-rastreabilidade: das origens à especificação dos requisitos

- Método proposto no artigo Kim, J. et al - Rastreabilidade das características do software à especificação de

casos uso através de metas e cenários.- Rastreabilidade da ERS alinhadas à prática IEEE 830-1998.

- Rastreamento para trás (estágios anteriores do desenvolvimento).


Quais as relações que têm interesse para a gerência de requisitos?- Identificar o conjunto de objetos (Ramesh,B.; Jarke, M., 2001) exigidos

para definir os itens de rastreabilidade.

• Necessidade e característica• RF e RNF• Itens do glossário• Caso de uso e Seção de caso de uso• Ator

Spence e Probasco (2000)


As características dirigem o MCU

(Spence, I.; Probasco, L. , 2000)

Rastreabilidade dos requisitos de software 63Matrizes de rastreabilidade


Necessidade

Características

Alocação de recursos GRAU

Alocação de recursos da Polícia

Rodoviária

Alocação de recursos da

Polícia FerroviáriaAlocação de

recursos da FAB

Fornecer gestão de crise para acidentes rodoviários

X X

Fornecer gestão de crise para acidentes ferroviários

X X

Fornecer gestão de crise para acidentes aéreos X X

Rastreabilidade dos requisitos de software 64Matrizes de rastreabilidade


Características

Casos de uso

Encaminhar procedimentos de mitigação para as

unidades da GRAU

Encaminhar procedimentos de mitigação para as unidades da FAB


Alocar unidades da FAB para o local da crise

Alocação de recursos GRAU X X

Alocação de recursos da FAB X X

Alocação de recursos da Polícia Rodoviária

Alocação de recursos da Polícia Ferroviária

Rastreabilidade dos requisitos de software 65Atributos dos requisitos de software a serem gerenciados

Fatores críticos de sucesso

• Prioridade o Alta, Média e Baixa

• Dificuldade o Alta, Média e Baixa

• Status o Apontado, Aprovado, Em desenvolvimento, Implementado e

Validado• Valor de negócio (Baseado em ROI )

o Alto, Médio e Baixo

Cohn, Mike, Agile Estimating and Planning, 2006

Rastreabilidade dos requisitos de software 66Atributos dos requisitos de software a serem gerenciados

Matriz de atributos

CaracterísticasAtributos

Prioridade Dificuldade Status Valor de negócio

Alocação de recursos GRAU Alta Média Implementado Alto

Alocação de recursos da FAB Baixa Alta Apontado Baixo

Alocação de recursos da Polícia Rodoviária Alta Média Em

desenvolvimento Alto

Alocação de recursos da Polícia Ferroviária Média Alta Apontado Médio

Referências1) Kim, J.; Kim, M.; Park, S. Goal and scenario based domain requirements analysis environment. In:

The Journal of Systems and Software, 79 (2006) p. 926-938 2) Kang, K.C. et al, Feature-oriented domain analysis feasibility study. CMU/SEI-TR- 21, 1990. 3) Pohl, K. et al. Software Product Line Engineering – Foundations, Principles, and Techniques.

Springer-Verlag, 20054) Arango, G. A brief introduction to domain analysis. In Proc. of the 1994 ACM Symposium on Applied

Computing, Phoenix, AZ USA, 1994, pp. 42-46.5) Evermann, J.; Wand, Y. Toward formalizing domain modeling semantics in language syntax. IEEE

Transactions on Software Engineering, vol. 31 (1), 2005.6) Guizzardi, G., Herre, H., Wagner G. On the general ontological foundations of conceptual modeling.

In Proc. of 21st Intl. Conf. on Conceptual Modeling (ER 2002), Springer-Verlag, Berlin, LNCS n. 2503,2002, pp. 65-78.

7) Spence, I.; Probasco, L. Traceability strategies for managing requirements with use cases.IBM/Rational, 2000.

8) Gottesdiener , E; Use Cases: Best Practices . IBM, 2003 9) Cohn, Mike, Agile Estimating and Planning Prentice Hall, 2006

67

Obrigado :)André Rocha [email protected]/aagostinho

68

mailto:[email protected]

https://www.scrumalliance.org/community/profile/aagostinho