SafeSecRETS - Tutorial: SafeSec IoT Canvas

Tutorial: Instanciando e utilizando o SafeSec IoT Canvas

Introdução

O objetivo do artefato SafeSec IoT Canvas é permitir a definição do escopo de um projeto de sistema IoT que depende de requisitos de safety e security, de forma a evidenciar as informações essenciais ao projeto e também as conexões existentes entre elas. A abordagem canvas facilita a definição, visualização e compreensão dessas informações e como elas se relacionam no contexto do projeto.

Passo a passo para preenchimento do SafeSec IoT Canvas

Os Componentes de Propósito Geral (e Específicos de Domínio) estão agrupados em Questões Fundamentais (QF), que serão descritas na próxima seção. As QF norteiam a lógica de criação do modelo mental para o projeto e levantamento das informações essenciais que compõem o canvas. Além disso, as QF e seus componentes são apresentadas na própria construção do SafeSec IoT Canvas de forma a sugerir a sua ordem de preenchimento, que será discutida a seguir.

Seguindo a metodologia proposta pelo Project Model Canvas (PMC), existe uma lógica para o preenchimento e validação do SafeSec IoT Canvas. A sequência lógica indicada para o preenchimento do SafeSec IoT Canvas é a seguinte:

Componentes da QF1: Justificativas, Objetivos e Benefícios;
Componentes da QF2: Produto, Requisitos e Componentes Específicos do Domínio;
Componentes da QF3: Stakeholders e Equipe;
Componentes da QF4: Premissas, Grupos de Entregas e Restrições;
Componentes da QF5: Riscos, Linha do Tempo e Custos.

Componentes de Propósito Geral

QF1 (Por que?): Justificativas, Objetivos e Benefícios

"Por quê" o projeto deve ser realizado?

Justificativas: tem como objetivo descrever os problemas e demandas ("dores") que representam a situação atual. Que tipo de problema precisa ser resolvido? O que justifica a realização deste projeto? Devem ser analisadas as demandas não atendidas e oportunidades não exploradas.
Objetivos: é/são aquilo que o projeto permitirá atingir; a finalidade de todos os esforços e recursos que serão mobilizados. Deve ser: específico, mensurável, alcançável, realista e delimitado no tempo.
Benefícios: valores (tangíveis e intangíveis) que serão obtidos após a implantação do projeto. Devem estar efetivamente associados à resolução dos problemas ou demandas levantadas nas Justificativas. Se possível, descrever os Benefícios de maneira que eles sejam quantificáveis, para facilitar a futura mensuração do êxito do projeto.

Juntos, estes 3 componentes devem responder à QF: Por quê este projeto deve ser realizado? Se não há necessidade identificada para realização de um projeto, isso indica que talvez ele não seja relevante.

QF2 (O que?): Produto e Requisitos (e Componentes Específicos do Domínio)

"O que" o projeto deve realizar/produzir?

Produto: deve descrever aquilo que será entregue ao final do projeto (no caso do SafeSec IoT Canvas o produto final será um sistema IoT: este produto deve ser descrito objetivamente para o entendimento da equipe).
Requisitos: são a forma que o cliente ou os demais stakeholders irão comunicar para a equipe aquilo que lhes parece necessário ou desejável no produto que irão receber ao final do projeto. Para isso é importante listar os componentes ou subsistemas que compõem o produto do projeto, englobando todos aqueles que são relevantes (essenciais).

Esses componentes, em conjunto, devem responder à seguinteQF: O que o projeto realiza? Todo projeto gera produto(s) serviço(s) ou resultado(s) que devem atender as reais necessidades dos clientes/stakeholders. Os Componentes Específicos de Domínio (seção a seguir) também fazem parte do escopo dessa questão fundamental.

QF3 (Quem?): Stakeholders e Equipe

"Quem" irá participar/trabalhar no projeto e qual o seu papel?

Stakeholders: são todas as pessoas ou organizações envolvidas ou afetadas pelo projeto. Devem ser listados todos os stakeholders considerados essenciais ao projeto, tais como: clientes, patrocinadores, especialistas de domínio, fornecedores, departamentos externos, órgãos regulatórios, governo, etc.
Equipe: são todos aqueles que produzem algo no projeto. Devem ser listados de forma associadas com seus papéis. Podem ser delimitadas fronteiras virtuais a partir do gerente do projeto, que é elemento central da equipe. É desejável que membros da equipe que são responsáveis por entregas importantes ou críticas no projeto sejam listados de maneira mais conectada ao gerente do projeto, formando uma esfera de controle. Os demais membros da equipe formarão uma esfera de influência, uma vez que não são diretamente controlados pelo gerente do projeto mas são influenciados por ele indiretamente.

Os componentes citados acima devem responder à QF: Quem irá trabalhar e produzir algo para o projeto? A resposta a essa questão é importante pois ajuda a entender os limites do problema que se quer atacar. Possuir uma visão clara de quem faz parte da equipe e quem não faz ajuda a diferenciar o que faz parte do projeto e deve ser controlado, e o que é externo ao projeto e pode ser apenas monitorado.

QF4 (Como?): Premissas, Grupos de Entregas e Restrições

"Como" o projeto deve ser realizado/entregue?

Premissas: o planejamento do trabalho no projeto é feito muitas vezes em condições de incerteza; por esse motivo, é necessário formular algumas suposições sobre o cenário futuro e relativamente incerto. Quando essas suposições são dadas como certas no plano do projeto elas são chamadas de premissas. As premissas protegem o gerente do projeto e fornecem uma base para o planejamento.
Grupos de Entregas: para gerar o produto final do projeto, é necessário pensar primeiro nos seus componentes, as partes menores que serão integradas para que o projeto seja concluído. Essas partes são as entregas do projeto, que devem ser sempre ações concretas e tangíveis (mensuráveis e verificáveis) a serem produzidas pela equipe. Todo trabalho realizado no projeto deve estar a serviço de alguma entrega.
Restrições: são limitações de qualquer origem impostas ao trabalho realizado pela equipe, que diminuem sua liberdade de opções. Podem ser originadas em entidades externas ao projeto ou mesmo por membros da equipe ou componentes internos ao projeto. As restrições em geral estão ligadas a motivos pelos quais não se pode entregar o trabalho antes, na metade do prazo, por exemplo (por limitações de qualquer natureza).

Esse conjunto de componentes deve responder à QF: Como vamos entregar o projeto? Existe um problema em se pensar o trabalho em termos de atividades: uma vez que o projeto avança, novas atividades se fazem necessárias, surgem como desdobramentos de outras atividades ou emergem de uma nova lista de prioridades. Portanto, a experiência em gerenciamento de projetos mostra que é melhor pensar e planejar o trabalho em termos de entregas e não de atividades. As premissas e restrições são as condições nas quais o trabalho será feito.

QF5 (Quando e quanto?): Riscos, Linha do Tempo e Custos

"Quando" o projeto será concluído e "quanto" vai custar?

Riscos: são considerados riscos do projeto as incertezas que podem afetar os objetivos do projeto. A melhor proteção contra os risco é gerenciá-lo e, para isso, ele precisa ser identificado. Apesar de parecer deslocado, este componente faz parte dessa questão de pesquisa por que sem dimensionar riscos é impossível dizer de maneira segura quando um projeto vai terminar e quanto ele irá custar. O grau de incerteza das respostas a "quando" e "quanto" é proporcional ao nível de risco do projeto.
Linha do Tempo: os prazos do projeto (de cada entrega planejada), apesar de não visar precisão absoluta, pode ser estimado/estabelecido por meio de uma medição baseada no julgamento das pessoas que estão elaborando o canvas e de acordo com a quantidade de informações que estas já possuem. Medição pode ser definida como um conjunto de observações que reduzem a incerteza.
Custos: deve ser estimado de maneira resumida, identificando os custos por entrega. Pode ser calculado da seguinte forma: 1) deve ser estruturado por entregas; 2) o custo de cada entrega pode ser desdobrado em elementos de custos, como por exemplo mão de obra e insumos; e 3) os riscos precisam ser analisados e, se forem elevados, impactam os custos na forma de reserva de contingência. Outra forma de se decompor os elementos de custo é dividi-los em 3 categorias: trabalho, materiais e contratações. A equipe pode personalizar os seus próprios elementos de custos nos quais as entregas serão decompostas, de acordo com as especificidades de cada projeto e a cultura organizacional.

Os 3 componentes acima devem responder à QF: Quando o projeto será concluído e quanto custará? Essa questão só poderá ser respondida com propriedade após se ter chegado às respostas das demais QFs. É importante que os custos e os cronogramas sejam definidos com a clareza sobre o produto a ser gerado, as motivações, as pessoas envolvidas, quais serão as entregas, etc. O quando e o quanto aparecem juntos no SafeSec IoT Canvas (assim como no PMC) porque tempo e custos não podem ser dissociados em termos de gestão. O cronograma e os custos compartilham uma estrutura comum baseada nas entregas.

Componentes Específicos do Domínio (QF2)

Domínio IoT: Componentes, Ações e Conectividade

"O que" o sistema IoT deve gerenciar?

Componentes: um produto IoT considera diferentes tipos de componentes
- Hardware: dispositivos associados a objetos (coisas) que podem estar ligados à coleta de dados (sensores), realização de ações (atuadores) e processamento de dados (microcontroladores);
- Software: sistemas de software e interfaces de usuário do sistema IoT.
Ações: são ações relevantes executadas pelo sistema IoT, de acordo com o contexto da aplicação, podendo estar ou não ligadas a atuadores.
Dados: tipos de dados coletados através dos sensores do sistema IoT.
Conectividade: informações sobre os aspectos de conectividade do sistema, identificando como o sistema IoT realiza a comunicação de dados interna/intradomínio (dos sensores para o microcontrolador) e externa (do microcontrolador para a aplicação).

Domínio Safety&Security: Ativos, Perdas, Acidentes/Ataques, Perigos/Ameaças, Vulnerabilidades

"O que" o sistema IoT deve proteger e quais riscos estão envolvidos?

Ativos: podem ser qualquer coisa de valor para o sistema que deve ser protegida de uma perda acidental ou maliciosa, incluindo pessoas, recursos, ambiente ou serviços.
Perdas: são danos significativos ou impactos negativos associados a um ativo, inaceitáveis para os stakeholders, causados por um acidente ou ataque.
Acidentes/Ataques: são eventos relacionados a safety e security, respectivamente, que podem resultar em uma perda para um ativo. É realização/concretização de um perigo ou ameaça.
Perigos/Ameaças: um perigo (hazard) é uma situação que aumenta a probabilidade de um ou mais acidentes relacionados, levando o sistema a um potencial risco de safety; uma ameaça (threat) é uma situação que aumenta a probabilidade de um ou mais ataques relacionados, levando o sistema a um potencial risco de security.
Vulnerabilidades: são fraquezas no sistema que aumentam a probabilidade de ocorrer um acidente/ataque e, consequentemente, uma perda. É a raiz do problema, pois toda perda pode ser rastreada até uma vulnerabilidade, que gerou um perigo/ameaça, que resultou em um acidente/ataque, que causou a perda.

Esses componentes fornecem elementos essenciais à análise de safety e security para definição destes requisitos para o projeto em questão. Assim como os demais Componentes Específicos de Domínio eles integram a QF2, que está ligada ao que deve ser realizado no projeto.

Page updated

Google Sites

Report abuse