Category Archives: Engenharia de Software

Gestão de Riscos

clip_image002

A Gestão de Riscos é definida como as atividades coordenadas para direcionar e controlar uma organização no que se refere ao risco (ABNT ISO/IEC Guia 73:2005). A gestão de risco deve ser um processo que inclui a identificação, análise, avaliação, tratamento, aceitação, comunicação, monitoramento e revisão do risco, onde se deve analisar todos os riscos inerentes às atividades de uma organização.

O processo de melhoria continua conhecido como Plan – Do -Check – Act (PDCA) é um ciclo de análise e melhoria dos processos gerenciais necessários para o sucesso da organização e para a área de segurança da informação. O PDCA deve ser utilizado para estruturar os processos do Sistema de Gestão da Segurança da Informação (SGSI) e alinhar os processos de gestão de risco.

A primeira etapa do processo (Planejar) inicia com a definição das estratégias e a forma como elas vão ser alcançadas, ou seja, a definição de políticas, controles e procedimentos para garantir a segurança das informações. É de extrema importância que a direção da organização esteja de acordo e comprometida com os processos estratégicos definidos. Segundo a norma ISO 27005, na fase de planejamento são tratados os processos de Definição do Contexto, Análise / Avaliação de Riscos, Definição do Plano de Tratamento do Risco e Aceitação do Risco.

Na segunda etapa (Executar), os processos definidos são implementados e executados. Também é necessária a coleta de informações para utilização na próxima etapa. Alinhando com a norma ISO 27005 é implementado o plano de Tratamento do Risco.

Na terceira etapa (Checar) é feita a avaliação dos processos implementados para verificar se o planejado foi realmente executado de forma adequada para alcançar as metas. Nessa fase são identificados os desvios de execução e apresentados os resultados para uma análise critica da direção. Nessa etapa, segundo a norma ISO 27005, é realizado o Monitoramento Contínuo e Análise Crítica do Risco.

Na quarta etapa (Agir) são realizadas ações corretivas e preventivas baseadas na identificação de desvios de execução e nas considerações apresentadas pela direção da organização. A norma 27005 orienta manter e melhorar o processo de Gestão de Riscos de Segurança da Informação (BRANDÃO 2008; HARUNARI apud GUARAGNA, 1992, p 79).

Comunicação do Risco => Na fase de Comunicação do Risco as partes envolvidas, ou seja, os stakeholders, e as partes interessadas, pessoa ou grupo que tem interesse no desempenho ou no sucesso da organização, devem ser identificadas e os seus papéis e responsabilidades devem ser definidos. Um plano de comunicação é criada para conhecimento das partes do andamento do processo de gestão de risco.

Definição do Contexto => Define o escopo da gestão de riscos que será utilizado para a identificação, avaliação, impacto e aceitação dos riscos. Nessa etapa são coletadas todas as informações relevantes sobre a organização, mas principalmente para a gestão de riscos de segurança.

Os principais resultados da definição do contexto devem ser a descrição dos objetivos da gestão do risco e dos ambientes nos quais eles estão contextualizados. Também são definidos os critérios que serão utilizados na determinação dos riscos, isto é, a determinação das conseqüências de segurança e os métodos usados para a análise e avaliação dos riscos.

Identificação de Riscos => O papel da identificação de riscos é identificar junto aos gestores os eventos de cada processo de negócio existente na organização que possam afetar o funcionamento das atividades essenciais e causar perdas potenciais. São respondidas as perguntas: “O que pode acontecer?”, “Quando pode acontecer?”, “Quando e onde?” e “Como e por quê?”.

É necessário identificar as ameaças, os controles existentes, as vulnerabilidades e as conseqüências para cada propriedade da segurança da informação, ou seja, confidencialidade, integridade e disponibilidade.

Estimativa de Riscos => Analisa a origem dos riscos, suas conseqüências e as probabilidades da ocorrência dos riscos. Os dados devem ser mensurados através de uma metodologia qualitativa ou quantitativa. Como exemplo pode ser adotada a metodologia Common Vulnerability Scoring System (CVSS) para cálculo do impacto das vulnerabilidades.

A norma ISO 27005 orienta estimar o risco de duas formas. Qualitativamente, onde é utilizada uma escala com atributos como, por exemplo, baixa, média e alta. Quantitativamente deve ser usada uma escala de valores numéricos para estimar o risco.

Avaliação de Riscos => são definidos como os mesmos serão tratados tomando como base os resultados obtidos nas fases de identificação e estimativa de riscos. Algumas organizações definem que todos os riscos serão tratados e outras focam somente nos riscos que afetam os principais processos de negócio da organização. Os riscos devem ser ordenados por prioridade e associados aos processos de negócio.

Tratamento dos Riscos => inicia com a priorização entre os riscos encontrados, levando em conta os riscos que têm maior probabilidade de se concretizar, tornando-se um incidente. Os riscos devem estar relacionados conforme as opções de tratamento, que são: redução, retenção, evitação e transferência.

Aceitação de Riscos => os riscos residuais devem ser formalmente aceitos pela organização levando em conta o escopo elaborado na definição do contexto.

Monitoramento e análise crítica dos riscos => A fase de monitoramento e analise crítica dos riscos é de extrema importância para a gestão de riscos, pois é necessário que os riscos sejam monitorados e os processos revisados para identificar oportunidade de melhoria no tratamento dos riscos. Tendo em vista que o ambiente computacional é dinâmico, revisões e auditorias periódicas devem ser realizadas para identificar modificações internas e externas que possam alterar o contexto do processo de negócio da organização.

Advertisements

Processos de Software

Um processo de software é um conjunto de atividades que leva à produção de um produto de software. Essas atividades podem envolver o desenvolvimento de software propriamente dito. Embora existam muitos processos de software diferentes, algumas atividades fundamentais são comuns a todos eles, como:

  1. Especificação de Software;
  2. Projeto e Implementação;
  3. Validação de Software;
  4. Evolução de Software.

Os processos de software podem ser aprimorados por meio da padronização de processo, na qual a diversidade de processos de software ao longo da organização é reduzida. Isso promove o aprimoramento da comunicação e redução no tempo de treinamento e faz com que o processo automatizado seja mais econômico. A padronização é também um passo inicial importante na introdução de novos métodos e técnicas de engenharia de software e também na boas práticas de engenharia de software.

1 – Modelos de processo de software

Um modelo de processo de software é uma representação abstrata de um processo de software. Cada modelo de processo representa um processo sob determinada perspectiva e, dessa forma, fornece informações parciais sobre esse processo.
Os principais modelos são:

  1. Modelo em Cascata;
  2. Desenvolvimento Evolucionário;
  3. Engenharia de Software baseada em componentes.

1.1 – Modelo em Cascata

O primeiro modelo de processo de desenvolvimento de software publicado originou-se de processos mais gerais de engenharia de sistema. Devido ao encadeamento de uma fase com a outra, esse modelo é conhecido como modelo em cascata ou ciclo de vida do software. Os principais estágios desse modelo representam as atividades fundamentais de desenvolvimento.

  1. Análise e definição de requisitos;
  2. Projeto de sistema e software;
  3. Implementação e teste de unidade;
  4. Integração e teste de sistema;
  5. Operação e manutenção.

modelo em cascata

1.2 – Desenvolvimento Evolucionário

O desenvolvimento evolucionário baseia-se na idéia de desenvolvimento de uma implementação inicial, expondo o resultado aos comentários do usuário e refinando esses comentários por meio de várias versões até que seja desenvolvido um sistema adequado. Existem dois tipos fundamentais de desenvolvimento evolucionário:

  1. Desenvolvimento Exploratório;
  2. Prototipação Throwaway.

O desenvolvimento evolucionário possui duas desvantagens: O processo não é visível e os sistemas são frequentemente mal estruturados. Essa abordagem é mais indica para sistemas de pequeno e médio porte.

modelo evolucionario

1.3 – Engenharia de software baseada em componentes

A abordagem orientada ao reuso depende de uma grande base de componentes de softwares reusáveis e algum framework de integração desses componentes. Algumas vezes, esses componentes são sistemas comerciais independentes que podem fornecer funcionalidade especifica, como a formatação de texto ou algum calculo numérico. Estágios da Engenharia de software baseada em componentes:

  1. Analise de componentes;
  2. Modificação de requisitos;
  3. Projeto de sistema com reuso;
  4. Desenvolvimento e integração.

2 – Iteração de processo

2.1 – Entrega Incremental

É uma abordagem intermediária que combina as vantagens do modelo em cascata e do modelo evolucionário. Em um processo de desenvolvimento incremental, o cliente identifica, em linhas gerais, os serviços a serem fornecidos pelo sistema. O processo de desenvolvimento incremental tem uma série de vantagens:

  1. Os clientes não precisam esperar até a entrega do sistema inteiro para se beneficiarem dele. O primeiro incremento satisfaz os requisitos mais críticos e, dessa forma, é possível usar o software imediatamente.
  2. Os clientes podem usar os incrementos iniciais como protótipo e ganhar experiência, obtendo informações sobre os requisitos dos incrementos posteriores do sistema.
  3. Existe um risco menor de falha geral no projeto.
  4. Os serviços mais importantes recebem mais testes.

2.2 – Desenvolvimento em Espiral

O modelo em espiral foi originalmente proposto por Boehm (1988). Em vez de representar o processo de software como uma seqüência de atividades com algum retorno em uma atividade e outra, o processo é representado como uma espiral. Cada loop na espiral representa uma fase do processo de software. Dessa forma, o loop mais interno pode estar relacionado à viabilidade do sistema: o próximo loop, à definição de requisitos: o próximo, ao projeto de sistema e assim por diante. Cada loop na espiral está dividido em 4 setores:

  1. Definição de objetivos;
  2. Avaliação e redução de riscos;
  3. Desenvolvimento e validação;
  4. Planejamento.

3 – Atividades de Processo

As quatro atividades básicas do processo – especificação, desenvolvimento, validação e evolução – são organizadas de modo diferente nos diversos processos de desenvolvimento.

3.1 – Especificação de Software

A especificação de software ou engenharia de requisitos é o processo para compreender e definir quais serviços são necessários e identificar as restrições de operação e de desenvolvimento do sistema. A engenharia de requisitos é um estagio particularmente critico do processo de software, pois os erros nesse estágio conduzem inevitavelmente a problemas posteriores no projeto e na implementação do sistema. Existem quatro fases principais no processo de engenharia de requisitos:

  1. Estudo de viabilidade;
  2. Elicitação e analise de requisitos;
  3. Especificação de requisitos;
  4. Validação de requisitos.

3.2 – Projeto e Implementação de Software

É o processo de conversão de uma especificação de sistema em um sistema executável. Ele sempre envolve os processos de projeto e de programação de software, mas, se uma abordagem evolucionária for usada, pode também envolver o refinamento da especificação de software. As atividades especificas do processo de projeto são:

  1. Projeto de arquitetura;
  2. Especificação abstrata;
  3. Projeto de interface;
  4. Projeto de componente;
  5. Projeto de estrutura de dados;
  6. Projeto de algoritmo.

3.3 – Validação de Software

Destina-se a mostrar que um sistema está em conformidade com sua especificação e que atende às expectativas do cliente que está adquirindo o sistema. Isso envolve processos de verificação, tais como inspeções e revisões, a cada estágio do processo de software, desde a definição de requisitos de usuário até o desenvolvimento do programa. A maior parte dos custos de validação, no entanto, incorrem após a implementação, quando o sistema operacional é testado.

  1. Teste de componente;
  2. Teste de sistema;
  3. Teste de aceitação.

3.4 – Evolução do Software

Historicamente, sempre existiu uma separação entre o processo de desenvolvimento de software e o processo de evolução de software (manutenção de software). As pessoas pensam no processo de desenvolvimento de software como uma atividade criativa, em que o sistema é desenvolvido a partir de um conceito inicial até um sistema funcional.

4 – RUP

É um exemplo de um modelo de processo moderno que foi derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software associado. Ele traz elementos de todos os modelos genéricos de processo, apóia a iteração e ilustra boas práticas de especificação e projeto. As fases do RUP são:

  1. Concepção;
  2. Elaboração;
  3. Construção;
  4. Transição.

rup

Processos de Software – Uma idéia inicial

Um processo de sotware é um conjunto de atividades que leva à produção de um produto de software. Essas atividades podem envolver o desenvolvimento de software propriamente dito, usando uma linguagem de programação como Java ou C#. Cada vez mais, no entanto, novo software é desenvolvido com a ampliação e a modificação de sistemas existentes e de configuração e integração de software comercial ou componentes de sistema.

Embora existam muitos processos de software diferentes, algumas atividades fundamentais são comuns a todos eles, como:

  • Especificação de software. A funcionalidade do software e as restrições sobre sua operação devem ser definidas.
  • Projeto e implementação de software. O software que atende à especificação deve ser produzido.
  • Validação de software. O software deve ser validado para garantir que ele faça o que o cliente deseja.
  • Evolução do software. O software deve evoluir para atender às necessidades mutáveis do cliente.

Os processos de software podem ser aprimorados por meio da padronização de processo, na qual a diversidade de processos de software ao longo da organização é reduzida. Isso promove o aprimoramento da comunicação e redução no tempo de treinamento e faz com que o apoio ao processo automatizado seja mais econômico. A padronização é também um passo inicial importante na introdução de novos métodos e técnicas de engenharia de software e também nas boas práticas de engenharia de software.

Fonte
Engenharia de Software
SOMMERVILLE – 8º Edição