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
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”
Adicionar, Modificar e remover “features”
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
Modelagem de domínioPremissas estabelecidas
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
Modelagem de domínioPremissas estabelecidas
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.
Modelagem de domínioPremissas estabelecidas
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.
Modelagem de domínioPremissas estabelecidas
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.
Modelagem de domínioPremissas estabelecidas
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
Modelagem de domínioPremissas estabelecidas
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
Modelagem de domínioPremissas estabelecidas
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
Modelagem de domínioPremissas estabelecidas
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)
Modelagem de domínioPremissas estabelecidas
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
• 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
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
• 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
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)
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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.
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Escrevendo metas e cenários em características de produtos
36
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Características da abordagem
37
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Análise de requisitos do domínio – Processo de modelagem
38
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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.
Alocar unidades GRAU para o local da crise
Encaminhar informações da ocorrência e
procedimentos a central da GRAU.
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
Encaminhar informações da ocorrência e
procedimentos ao centro de controle de desastres
aéreos da FAB.
Árvore de metas
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
46
Modelagem de domínioIdentificação de requisitos comuns e variantes Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
47
• 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
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
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
para o local da crise
SGCMT
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
51
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
para o local da crise
SGCMTR1
META DE INTERAÇÃO > CASO DE USO
R2AGENTE > ATOR
R4ESTEREÓTIPOS DE
VARIAÇÃO
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
54
Modelagem de domínioEspecificação de requisitos comuns e variantesArtigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
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).
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
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.
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
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).
Rastreabilidade dos requisitos de software 61Estratégia de rastreabilidade
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)
Rastreabilidade dos requisitos de software 62Estratégia de rastreabilidade
As características dirigem o MCU
(Spence, I.; Probasco, L. , 2000)
Rastreabilidade dos requisitos de software 63Matrizes de rastreabilidade
As características dirigem o MCU
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
As características dirigem o MCU
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 GRAU para o local da crise
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