defesa becker
TRANSCRIPT
Método para aplicação de modelos de melhoria e avaliação do processo de desenvolvimento de software em sistemas críticos de segurança.
Eng. Christian Becker Bueno de Abreu
Prof. Dr. Paulo Sérgio Cugnasca
EP-USP
São Paulo 2008
Agenda
• Introdução, objetivo, motivação • Segurança, sistemas críticos • Qualidade de software
– Processo de Desenvolvimento x (Produto)
• Modelos de Desenvolvimento – SOFTEX MPS.BR, (CMU/SEI CMMi-DEV)
• Extensão de Segurança – ADD/DMO CMMi-DEV +SAFE x (FAA, RAMS)
• Modelo de Decisão por Múltiplos Critérios – AHP
Agenda
• Descrição do método proposto
• Estudo de caso e resultados obtidos
• Conclusões
• Propostas de trabalhos futuros
Introdução
• Avanço em modelos de melhoria de processos de desenvolvimento software;
• Avanço de tecnologia em aplicações de segurança crítica;
• Uso comum de critérios e julgamentos qualitativos e subjetivos;
• Ferramentas de auxílio à decisão.
Introdução
• Avanço em modelos de melhoria de processos de desenvolvimento software;
• Avanço de tecnologia em aplicações de segurança crítica;
• Uso comum de critérios e julgamentos qualitativos e subjetivos;
• Ferramentas de auxílio à decisão.
Objetivo O objetivo deste trabalho de
investigação científica é propor um método para aplicação de
um modelo de melhoria e avaliação do processo de
desenvolvimento de software com extensão em aspectos de segurança, para aplicação em sistemas críticos, utilizando
como critério de priorização das atividades prescritas nesse modelo a experiência de especialistas desta área.
Objetivo O objetivo deste trabalho de
investigação científica é propor um método para aplicação de um modelo de melhoria e avaliação do processo de
desenvolvimento de software com extensão em aspectos de segurança, para aplicação em sistemas críticos, utilizando
como critério de priorização das atividades prescritas nesse modelo a experiência de especialistas desta área.
Motivação/Justificativa
• Emprego intensivo de software para a realização de funções de segurança.
• Desafios práticos encontrados nos projetos de sistemas críticos.
• Produção acadêmico-científica, no seu estado atual da arte. M
oder
niz
ação
Segurança
• Functional Safety – IEC 61508 – ausência de risco inaceitável
• dano físico, ou à saúde de pessoas
• dano ao patrimônio ou ao meio ambiente
• RAMS – CENELEC 50126 – nenhum sistema é absolutamente seguro
– projetar um sistema de forma a atender ao nível de segurança apropriado.
Segurança
• Functional Safety – IEC 61508 – ausência de risco inaceitável
• dano físico, ou à saúde de pessoas
• dano ao patrimônio ou ao meio ambiente
• RAMS – CENELEC 50126 – nenhum sistema é absolutamente seguro
– projetar um sistema de forma a atender ao nível de segurança apropriado.
Segurança
• A determinação de um
nível de segurança apropriado:
envolve opiniões e julgamentos pessoais;
é afetada por fatores emocionais.
(STOREY, 1996)
Segurança de Sistema
• probabilidade do sistema
– efetuar suas operações de forma correta, ou
– descontinuar seu funcionamento de forma a não comprometer a operação de outros sistemas ou comprometer a segurança
(JOHNSON, 1989)
Software
• componentes ou arranjos com modos de falha conhecidos. • maior complexidade microprocessadores não comprometer a segurança do processo controlado em caso de falhas.
Software
• componentes ou arranjos com modos de falha conhecidos. • maior complexidade microprocessadores levantamento de modos de falha proibitivo possibilidade de prever efeitos inseguros?
Qualidade
Qualidade é a totalidade das
características de um produto ou serviço que se baseia na sua habilidade de satisfazer uma dada necessidade.
(GUSTAFSON 2003)
Qualidade
• Qualidade dos Processos – NBR ISO 9000-3
– ISO/IEC 12207, ISO/IEC 15504
– CMU/SEI CMMi-DEV, FAA iCMM
– MR-MPS, MA-MPS
• Qualidade dos Produtos – ISO/IEC 9126-1
– Fatores e sub-fatores comuns aos modelos de qualidade e segurança
(PÁSCOA, 2002)
Processo x Produto
• Processo de Software: seqüência de etapas executadas para realizar um determinado objetivo e que envolve métodos, ferramentas e pessoas.
(HUMPHREY, 1989)
• Produto de software: conjunto completo de programas de computador, procedimentos e documentação correlata, assim como dados designados para entrega a um usuário;
(ISO/IEC 90003)
Modelo de Processo
• Modelo de processo de software: descreve os processos realizados para atingir o desenvolvimento de software.
Pode ser utilizado para descrever o processo padrão de desenvolvimento de software (prescritivo).
(GUSTAFSON, 2003)
MR-MPS
• MR-MPS rev. 1.2 – Compatível com SEI/CMU CMMI-DEV
– Aderente às normas:
• ISO/IEC 12207 “Information Technology - Software Life Cycle Processes”; e
• ISO/IEC 15504 “Information Technology - Process Assessment”
Maturidade MR-MPS
• Representação “em estágios”
• Cada nível de Maturidade
possui um conjunto de Áreas de Processo
• Os Atributos do Processo
definidos para cada nível devem ser aplicados às Áreas de Processo dos
níveis inferiores.
Capacidade MR-MPS
• Representação
“contínua”
• Áreas de Processo escolhidas livremente
• Os níveis de capacidade são definidos para cada Área de Processo através do atendimento
aos Atributos de Processo esperados.
Níveis de Capacidade
• Os níveis de capacidade são definidos para cada Área de Processo através do atendimento
aos Atributos de Processo esperados.
Extensão CMMI
• CMMI-DEV – Segurança não é mencionada nos componentes necessários ou esperados, apenas poucas vezes em componentes informativos do CMMI
– As atividades relacionadas à segurança podem ser inseridas no modelo CMMI (ex. IPPD)
• Extensões de Segurança CMMI
– FAA Safety and Security extensions for iCMM – RAMS/CENELEC 50128 (FONSECA, 2005) – ADD/DMO CMMI-DEV +SAFE
CMMI-DEV +SAFE
• Duas Áreas de Processo – Engenharia de Segurança
– Gerenciamento de Segurança
• Definidas em níveis de capacidade – Representação “contínua”
(metas genéricas ou atributos do processo)
+SAFE em níveis
• S1 - Projeto classificado como de segurança, porém não há ameaça identificada.
Gerenciar fornecedores relacionados à segurança. SG3 / GSEG 3
Monitorar incidentes de segurança. SG2 / GSEG 2
Desenvolver planos de segurança. SG1 / GSEG 1
Viabilizar aceitação de segurança. SG5 / ESEG 5
Identificar ameaças, acidentes e fontes de ameaças. SG1 / ESEG 1
+SAFE em níveis
• S2 - Projeto classificado como de segurança, porém todas as ameaças são aceitáveis.
Gerenciar fornecedores relacionados à segurança. SG3 / GSEG 3
Monitorar incidentes de segurança. SG2 / GSEG 2
Desenvolver planos de segurança. SG1 / GSEG 1
Viabilizar aceitação de segurança. SG5 / ESEG 5
Analisar ameaças e realizar análise de riscos. SG2 / ESEG 2
Identificar ameaças, acidentes e fontes de ameaças. SG1 / ESEG 1
+SAFE em níveis
• S3 - Projeto classificado como de segurança,
e inclui ameaças não aceitáveis.
Gerenciar fornecedores relacionados à segurança. SG3 / GSEG 3
Monitorar incidentes de segurança. SG2 / GSEG 2
Desenvolver planos de segurança. SG1 / GSEG 1
Viabilizar aceitação de segurança. SG5 / ESEG 5
Projeto voltado à segurança. SG4 / ESEG 4
Definir e manter requisitos de segurança. SG3 / ESEG 3
Analisar ameaças e realizar análise de riscos. SG2 / ESEG 2
Identificar ameaças, acidentes e fontes de ameaças. SG1 / ESEG 1
MDMC (método de decisão por múltiplos critérios)
• Estabelecer o domínio do problema – A necessidade ou objetivo de obter decisões
• Relacionar um conjunto de alternativas – Possíveis soluções para o problema
• Escolher critérios de decisão – Relevantes para o objetivo
– Pelos quais as alternativas serão avaliadas
AHP (Método de Análise Hierárquica)
• Campo de aplicação variado – Pesquisa aponta para 150+ artigos publicados nas áreas social,
pessoal, política, educação, fabricação, engenharia, industrial e governamental.
(VAIDYA; KUMAR, 2004)
• Aplicação em planejamento, alocação de recursos e solução de conflitos.
(SAATY, 2006)
• Exemplos (Eng. de Software): – Melhorar a precisão de estimativas subjetivas realizadas por
especialistas em estágio inicial de desenvolvimento; – Seleção de ferramenta de projeto de software COTS com base
em critérios baseados em características oferecidas pela maior parte das soluções.
Método Proposto
Definir Escalas
Preparação para o AHP
Definir Áreas de Processo
MR-MPS
+SAFE
Definir Objetivo
Definir Critérios
Obter Julgamento dos Especialistas
Aplicar o AHP
Elaborar Hierarquia
Prioridades
Perfil de Capacidade Desejado
Questionário
Áreas de Processo
• GSEG Gerenciamento de Segurança (+SAFE); • AQU Aquisição (nível F); • GQA Garantia da Qualidade (nível F); e • GPR Gerenciamento de Projetos (nível G). • ESEG Engenharia de Segurança (+SAFE); • DRE Desenvolvimento de Requisitos (nível D); • ITP Integração de Produto (nível D); • PCP Projeto e Construção do Produto (nível D); • VAL Validação (nível D); e • VER Verificação (nível D).
Preparação para o AHP
Definir Escalas
Definir Áreas de Processo
MR-MPS
+SAFE
Definir Objetivo
Definir Critérios
Obter Julgamento dos Especialistas
Aplicar o AHP
Elaborar Hierarquia
Prioridades
Perfil de Capacidade Desejado
Questionário
Método Proposto
Método Proposto
Definir Escalas
Preparação para o AHP
Definir Áreas de Processo
MR-MPS
+SAFE
Definir Objetivo
Definir Critérios
Obter Julgamento dos Especialistas
Aplicar o AHP
Elaborar Hierarquia
Prioridades
Perfil de Capacidade Desejado
Questionário
Método Proposto
Definir Escalas
Preparação para o AHP
Definir Áreas de Processo
MR-MPS
+SAFE
Definir Objetivo
Definir Critérios
Obter Julgamento dos Especialistas
Aplicar o AHP
Elaborar Hierarquia
Prioridades
Perfil de Capacidade Desejado
Questionário
Método Proposto
Definir Escalas
Preparação para o AHP
Definir Áreas de Processo
MR-MPS
+SAFE
Definir Objetivo
Definir Critérios
Obter Julgamento dos Especialistas
Aplicar o AHP
Elaborar Hierarquia
Prioridades
Perfil de Capacidade Desejado
Questionário
Método Proposto
• Obtenção matemática de um perfil de capacidade a partir do vetor prioridades resultante do uso do método AHP. – Estipular um valor de ajuste k arbitrário, que pode ser
manipulado livremente, e é proporcional ao nível de esforço ou à expectativa de melhoria de processos na organização
– Multiplicar o vetor de prioridades pelo valor de ajuste k e arredondar para números inteiros compreendidos entre 0 e 5, correspondentes aos níveis de capacidade das Áreas de Processo
Perfil de Capacidade 1
• AQU Aquisição (nível F); • DRE Desenvolvimento de Requisitos (nível D); • ESEG Engenharia de Segurança (+SAFE); • GQA Garantia da Qualidade (nível F); • GSEG Gerenciamento de Segurança (+SAFE); • GPR Gerenciamento de Projetos (nível G); • ITP Integração de Produto (nível D); • PCP Projeto e Construção do Produto (nível D); • VAL Validação (nível D); e • VER Verificação (nível D)
• Valor de k=20 • Perfil de capacidade atual – não verificado
• 5 Otimizados • 4 Quantitativamente Gerenciados • 3 Institucionalizados • 2 Gerenciados • 1 Executados ao acaso (ad hoc) • 0 Incompletos
• AQU Aquisição (nível F); • DRE Desenvolvimento de Requisitos (nível D); • ESEG Engenharia de Segurança (+SAFE); • GQA Garantia da Qualidade (nível F); • GSEG Gerenciamento de Segurança (+SAFE); • GPR Gerenciamento de Projetos (nível G); • ITP Integração de Produto (nível D); • PCP Projeto e Construção do Produto (nível D); • VAL Validação (nível D); e • VER Verificação (nível D)
• Valor de k=35 • Perfil de capacidade atual – MR-MPS F
Perfil de Capacidade 2
• 5 Otimizados • 4 Quantitativamente Gerenciados • 3 Institucionalizados • 2 Gerenciados • 1 Executados ao acaso (ad hoc) • 0 Incompletos
• AQU Aquisição (nível F); • DRE Desenvolvimento de Requisitos (nível D); • ESEG Engenharia de Segurança (+SAFE); • GQA Garantia da Qualidade (nível F); • GSEG Gerenciamento de Segurança (+SAFE); • GPR Gerenciamento de Projetos (nível G); • ITP Integração de Produto (nível D); • PCP Projeto e Construção do Produto (nível D); • VAL Validação (nível D); e • VER Verificação (nível D)
• Valor de k=60 • Perfil de capacidade atual – MR-MPS C
Perfil de Capacidade 3
• 5 Otimizados • 4 Quantitativamente Gerenciados • 3 Institucionalizados • 2 Gerenciados • 1 Executados ao acaso (ad hoc) • 0 Incompletos
Conclusões
– Abordagem da qualidade de software para obtenção de produtos adequados à segurança de sistemas;
– Solução de problemas complexos e de natureza qualitativa com ferramenta de auxílio à decisão;
– Síntese e registro de opiniões de especialistas através de julgamentos qualitativos.
– Possibilidade de aplicação do método em diversos estágios de maturidade das organizações;
– Avaliação e melhoria dos processos de desenvolvimento de software prioritários;
Trabalhos Futuros
– Análise de sensibilidade de opiniões; – Obtenção e discussão de resultados de julgamentos por especialistas: • Em diferentes áreas de aplicação dos sistemas críticos; • Com experiência prática e acadêmica diversa.
– Aplicação da lógica nebulosa (fuzzy) para obtenção mais precisa de opiniões;
– Construir matriz de custo x benefício; – Prescrição do valor de ajuste k; – A aplicação deste método em outras áreas de desenvolvimento de software para uso da representação “contínua” do CMMI / MR-MPS;