Defesa Becker

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)

Aplicações Ferroviárias

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

• Coordenação:

• Apoio:

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.

Maturidade CMMI

• CMMI-DEV “staged”

Capacidade CMMI

• CMMI-DEV “continuos”

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

• S0 - Projeto não classificado como segurança.

+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.





Analisar ameaças e realizar análise de riscos. SG2 / ESEG 2


+SAFE em níveis

• S3 - Projeto classificado como de segurança,

e inclui ameaças não aceitáveis.





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


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.

AHP - Decomposição do Problema

AHP - Métricas e Escalas

Método Proposto

Estudo de Caso

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).


Definir Escalas


MR-MPS

+SAFE

Definir Objetivo

Definir Critérios


Aplicar o AHP

Elaborar Hierarquia

Prioridades


Questionário

Método Proposto

Preparação AHP (objetivo, critério, escala, hierarquia)

Preparação AHP (objetivo, critério, escala, hierarquia)

Preparação AHP

Preparação AHP

Método Proposto

Definir Escalas



MR-MPS

+SAFE

Definir Objetivo

Definir Critérios


Aplicar o AHP

Elaborar Hierarquia

Prioridades


Questionário

Questionário

Matricial

Questionário

Julgamentos

Método Proposto

Definir Escalas



MR-MPS

+SAFE

Definir Objetivo

Definir Critérios


Aplicar o AHP

Elaborar Hierarquia

Prioridades


Questionário

Aplicar AHP

Método Proposto

Definir Escalas



MR-MPS

+SAFE

Definir Objetivo

Definir Critérios


Aplicar o AHP

Elaborar Hierarquia

Prioridades


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

Método Proposto

Método Proposto

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


• Valor de k=35 • Perfil de capacidade atual – MR-MPS F




• Valor de k=60 • Perfil de capacidade atual – MR-MPS C



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;

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

Documents

Defesa Becker