Segurança da Informação - Vulnerabilidade

É um termo normalmente utilizado para designar um ponto fraco ou falha existente num determinado sistema ou recurso, que poderá ser explorada, propositada ou inadvertidamente, causando prejuízo ao sistema ou recurso em questão.

Tipos de vulnerabilidades

Vulnerabilidade física: meio onde se localiza a construção da infra-estrutura da TI (prédio, sobrado, galpão), sala cofre ou sala subterrânea.

Vulnerabilidade natural: tufão, furacão, raio, trovão, tsunami, terremoto.

Vulnerabilidade de hardware e software: problema no desenvolvimento dos softwares, incompatibilidade de hardware com software, software mal instalado, software mal configurado.

Vulnerabilidade de comunicação: switches e pontos de rede cabeado, sem fio e portas de máquinas ao dispor de qualquer um que se interessar a entrar na rede são vulnerabilidades de comunicação que devem ser bastante analisadas e asseguradas.

Vulnerabilidade humana: falhas humanas.

Vulnerabilidade é um termo importante na gestão de risco, dentro do contexto da segurança da informação, pois fragilidade de um ativo ou grupo de ativos que pode ser explorada por uma ou mais ameaças e nem sempre é possível controlar as ameaças que a organização pode está exposta, porém e importante reduzir a vulnerabilidade para diminuir o risco.

Análise e Gestão do Risco em Segurança da Informação. Disponível em: <http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=24868l>. Acesso em 2 de Novembro de 2016.

Segurança da Informação - Incidentes

Incidente de segurança pode ser definido como qualquer evento não esperado, confirmado ou sob suspeita, podendo atingir pelo menos um dos princípios básicos de segurança da informação, ou seja, confidencialidade, integridade e disponibilidade.

Exemplos de incidentes:

Tentativas de ganhar acesso não autorizado a sistemas ou dados;
Ataques de negação de serviço;
Uso ou acesso não autorizado a um sistema;
Modificações em um sistema, sem conhecimento, instruções ou consentimento prévio do dono do sistema;
Desrespeito à política de segurança ou à política de uso aceitável de uma empresa ou provedor de 

acesso


Algumas sugestões para responder a incidentes com êxito:

Minimizar o número e a gravidade dos incidentes de segurança.

• Estabelecer claramente e aplicar todas as diretivas e procedimentos.
• Obter o suporte da gerência a respeito das diretivas de segurança e do tratamento de incidentes.
• Avaliar regularmente as vulnerabilidades do seu ambiente.
• Verificar regularmente todos os sistemas de computadores e dispositivos de rede para garantir que todos eles tenham os patches mais recentes instalados.
• Estabelecer programas de treinamento em segurança para a equipe de TI e os usuários finais.
• Postar faixas de segurança que lembrem os usuários de suas responsabilidades e restrições, além de um aviso sobre a possibilidade de ações em caso de violação.
• Desenvolver, implementar e aplicar uma diretiva que exija senhas fortes.
• Monitorar e analisar regularmente o tráfego da rede e o desempenho do sistema.
• Verificar regularmente todos os logs e mecanismos de registro, inclusive logs de eventos do sistema operacional, logs de aplicativos específicos e logs do sistema de detecção de intrusões.
• Verificar seus procedimentos de backup e restauração.
• Criar uma CSIRT para lidar com incidentes de segurança.

Montar a base da CSIRT (equipe de resposta a incidentes de segurança em computadores).

• Monitorar os sistemas em busca de violações de segurança.
• Funcionar como um ponto central de comunicação, tanto para receber relatórios dos incidentes de segurança quanto para disseminar informações vitais a respeito do incidente para as entidades adequadas.
• Documentar e catalogar os incidentes de segurança.
• Promover a percepção da segurança dentro da empresa para ajudar a impedir que os incidentes ocorram em sua organização.
• Oferecer suporte à auditoria do sistema e da rede por meio de processos como, por exemplo, a avaliação da vulnerabilidade e o teste de penetração.
• Saber mais sobre novas vulnerabilidades e estratégias de ataque empregadas pelos invasores.
• Pesquisar novos patches de software.
• Analisar e desenvolver novas tecnologias para minimizar vulnerabilidades e riscos de segurança.
• Prestar serviços de consultoria em segurança.
• Refinar e atualizar sempre os sistemas e os procedimentos atuais.

Definir um plano de resposta a incidentes.

• Fazer uma avaliação inicial.
• Comunicar o incidente.
• Conter os danos e minimizar os riscos.
• Identificar o tipo e a gravidade do comprometimento.
• Proteger as evidências.
• Notificar órgãos externos, se apropriado.
• Recuperar sistemas.
• Compilar e organizar a documentação do incidente.
• Avaliar os danos e os custos do incidente.
• Examinar as políticas de resposta e atualização. 

Conter os danos e minimizar os riscos.

• Proteger a vida humana e a segurança das pessoas. 
• Proteger dados secretos e confidenciais. 
• Proteger outros dados, inclusive proprietários, científicos e administrativos. 
• Proteger o hardware e o software contra ataques.
• Minimizar a interrupção dos recursos computacionais (inclusive processos). 

O que é Segurança da informação. Disponível em: <http://www.tic.ufrj.br/index.php/o-que-sao-incidentes>. Acesso em 30 de Outubro de 2016.

Respondendo a incidentes de segurança de TI. Disponível em: <https://technet.microsoft.com/pt-br/Library/cc700825.aspx>. Acesso em 2 de Novembro de 2016.

Metodologia Ágil - Scrum

Scrum é um método de desenvolvimento ágil, foi desenvolvido por Jeff Sutherland na década de 90. No Scrum os projetos são divididos em ciclos chamados sprints. Seus princípios são consistentes ao manifesto ágil e são usados para orientar o processo de desenvolvimento. A construção  do software é dividido em quatro fases: Requisitos, Analise, Projeto, Evolução e Entrega.

O trabalho realizado no Scrum é altamente moldável e as atividades dentro de um sprint se modificam em tempo real, tentando se adaptar ao problema. Ele adota padrões que auxiliam esse ambiente dinâmico de mudança, no qual, é comum prazos curtos e requisitos mutáveis.

• Backlog

Uma lista com prioridades dos requisitos do projeto. A lista pode ser modificada a qualquer momento. É gerenciada pelo gerente de produto, que atualiza os itens de acordo com sua importância.

• Sprints

Unidade de trabalho selecionada para cumprir as tarefas registradas no backlog, são ajustadas em um prazo tipo de trinta dias.

• Alterações

As alterações fazem parte do modelo Scrum, a filosofia de mudança estar atrelada as atividades do mesmo. Entretanto, as alterações são freadas quando estar sendo realizado um trabalho de urgência.

• Reuniões

São realizadas diariamente, e costumam ter uma duração máxima de quinze minutos. Na reunião é realizada perguntas a cerca do projeto, sobre as dificuldades e o progresso do mesmo. A reunião é conduzida pelo líder da equipe.

Além dos princípios e padrões mencionados, o Scrum divide bem suas equipes de desenvolvimento. Cada uma delas é dividida em três papeis:

1. Product Owner = Será o responsável por decidir o que será construído e a ordem na qual essas tarefas será feita.
2. ScrumMaster = É o responsável por disseminar os valores do Scrum na equipe, aplicando a filosofia do método na equipe.
3. Time Scrum = É o time de desenvolvimento responsável pela construção do sistema. Além dos tradicionais programadores, a equipe conta com profissionais de diversas áreas, como designers, testadores, administradores de banco, etc.

Fig.1: Fluxo de desenvolvimento Scrum.

Referências:

Scrum: A Metodologia Ágil Explicada de forma Definitiva Disponível em:<http://www.mindmaster.com.br/scrum/> Acessado em 02 de Novembro de 2016.

PRESSMAN, R.S. Engenharia de Software. 7ª Edição. Rio de Janeiro: McGraw-Hill, 2011

Segurança da Informação

A segurança da informação se refere a proteção de determinados dados, com a intenção de preservar seus respectivos valores para uma organização ou um indivíduo.
Devido este aspecto, existe três princípios básicos em segurança da informação:

Confidencialidade

Acesso a informação a quem tem direito, ou seja, apenas as entidades autorizadas pelo proprietário da informação.

Integridade

Manter a informação armazenada com todas as suas características originais estabelecidas pelo proprietário da informação,  além da atenção com o seu ciclo de vida (criação, manutenção e descarte).


Disponibilidade

A informação deve está sempre disponível para uso quando usuários autorizados necessitarem.

O que é Segurança da informação. Disponível em: <http://segurancadainformacao.modulo.com.br/seguranca-da-informacao> Acesso em 30 de Outubro de 2016.

Gestão de Risco

A gestão de risco auxilia as organizações a alcançar seu potencial, através do controle das incertezas e ameaças. A eficácia da gestão dos riscos ajuda a maximizar as oportunidades e minimizar as ameaças para atingir o objetivo da organização.
A palavra risco se relaciona com a possibilidade de algo não ocorrer como esperado, mas na atualidade envolve a quantificação e a qualificação da incerteza, tanto para perdas quanto para ganhos.

Existem muitas metodologias de implantação para se trabalhar com a gestão de risco, a metodologia abordada nesta postagem é sugerida pelo modelo GRCorp, desenvolvido pelo IBGC (Instituto Brasileiro de Governança Corporativa). Desta forma, as metodologias são:

Identificação e classificação do risco

Definição do conjunto de eventos, externos ou internos, que podem impactar os objetivos estratégicos da organização.

Avaliação

Definir qual o tratamento que será dado a determinado risco, o primeiro passo consiste em determinar o seu efeito potencial, ou seja, o grau de exposição da organização àquele risco.

Mensuração

Cálculo do impacto financeiro consolidado, envolve detalhar as receitas e as despesas operacionais, os custos, investimentos e o fluxo de caixa projetado.

Tratamento

Alinhar a estrutura de controles internos aos objetivos estratégicos e ao nível de exposição desejado pela organização, considerando seus efeitos, grau de aversão e resposta, complementada por uma análise de custo-benefício. 

Monitoramento

O objetivo é assegurar a presença e o funcionamento de todos os seus componentes ao longo do tempo.

Informação e Comunicação

Possui finalidade de permitir avaliações mais rápidas e objetivas a respeito dos riscos a que está exposta a organização.

Guia de Orientação para Gerenciamento de Riscos Corporativos. Disponível em: <http://www.ibgc.org.br/userfiles/3.pdf> Acesso em 29 de Outubro de 2016. 

Métodos Ageis

A metodologia ágil é combinação de valores e princípios. Ela se desenvolveu em um esforço de sanar fraquezas dos métodos convencionais  de engenharia de software. A insatisfação com abordagens pesadas em projetos pequenos e médios motivou um numero de programadores a iniciar a metodologia.

No mercado moderno atual é quase impossível prever como um sistema computacional irá evoluir. As condições mudam rapidamente, as necessidades de usuários se alteram e novas ameaças competitivas emergem sem aviso. Dessa forma, os métodos ágeis contam com uma abordagem iterativa para especificação, desenvolvimento e entrega de software. A metologia procura uma aproximação maior com o cliente, onde é feito pequenas entregas do sistema para que o cliente possa o quanto antes ter posse do seu sistema. Uma estrategia atrelada a um feedback que propicia um alinhamento maior entre o que o cliente pediu e o que foi entregue.

As metodologias ágeis possuem princípios que seguem a maioria de suas especificações, Sommerville (2007) descreve alguns.

• Envolvimento do Cliente

Os clientes devem estar envolvidos com o desenvolvimento do sistema. Provendo informações para construção dos requisitos e dando feedback sobre o que já foi criado.

• Entrega Incremental

O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos.

• Pessoas, não processos

As habilidades da equipe devem ser exploradas.

• Aceite Mudanças

Aceitar as mudanças de requisitos que irão ocorrer.

• Simplicidade

Trabalhe ativamente para eliminar a complexidade do sistema.

Referências:

PRESSMAN, R.S. Engenharia de Software. 7ª Edição. Rio de Janeiro: McGraw-Hill, 2011

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Métodos Ágeis - XP

A Extreme Programming, ou simplesmente XP, é uma metodologia de software ágil, foi criada nos Estados Unidos por Kent Beck em 1997. Sua abordagem abusa do desenvolvimento iterativo e conta com uma aproximação do cliente com o projeto. Nele todos os requisitos são descritos em histórias, que são implementados como tarefas. O desenvolvimento das tarefas é realizadas em pares e antes da codificação das mesmas é criado testes.

O XP é formado fundamentalmente por princípios e valores, são características que moldam o desenvolvimento de software sobre o escopo dessa metodologia. São ao todo cinco valores e quatorze princípios. Vejamos cada um a seguir.

Valores do XP

• Comunicação

O XP prima pela comunicação ativa entre os clientes e a equipe de desenvolvimento, com o intuito de reduzir requisitos equivocados e assim construir um software mais próximo do que o cliente espera. Além disso o XP prioriza uma comunicação presencial com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreender da melhor maneira possível.

• Coragem

No XP acredita-se que o erro vai acontecer, o diferencial seria como tratar a ocorrência do mesmo. Assim, impedir mudanças e frear a criatividade do cliente não são consideradas no XP. Nessa metodologia a equipe deve se adaptar as modificações e está confiantes nos mecanismos do XP.

• Feedback

Os desenvolvedores procuram entregar as tarefas o mais rápido possível, para que assim o cliente possa usufruir das funcionalidades e prover informações a respeito delas.

• Respeito

Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

• Simplicidade

Nesse aspecto a equipe XP se concentra, primeiramente, em desenvolver as tarefas essências para o funcionamento do sistema, evitando desenvolver funcionalidades que talvez nunca cheguem a ser utilizadas.

Princípios

1. Auto-semelhança: Soluções que funcionem em diferentes contextos
2. Benefício Mútuo: Estrutura que proporciona benefícios para as diferentes partes do projeto
3. Diversidade: Equipes com profissionais de varias áreas, arquiteto, designer, programadores etc. 
4. Economia: Priorizar módulos que gerem receita mais rápido e controle de gastos no desenvolvimento
5. Falha: Testar soluções sem medo de falhas.
6. Fluidez: O objetivo é fazer com que o sistema seja desenvolvido de forma evolutiva e vá crescendo em funcionalidades a cada nova iteração.
7. Humanismo: Compreender a natureza humana para que possamos potencializar o que ela tem de melhor e suprimir o que tem de pior
8. Melhoria: Aprimoramento continuo do software.
9. Oportunidade: Enxergar problemas como oportunidades.
10. Passos de Bebê: Realizar pequenas modificações por vez.
11. Qualidade: Desenvolver visando a melhor qualidade possível
12. Redundância: Os problemas críticos devem ser resolvidos com varias soluções
13. Reflexão: A equipe analisa seu processo durante a construção do software, discutindo falhas e acertos.
14. Responsabilidade Aceita: A responsabilidade não deve ser atribuída, ela deve ser aceita.

Referencia:

EXTREME PROGRAMMING Disponível em:<http://www.desenvolvimentoagil.com.br/xp/> Acessado em 30 de Outubro de 2016.

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Information Technology Infrastructure Library (ITIL)

É uma biblioteca de gerenciamento de TI criada pelo governo britânico. Na sua criação foi levado em consideração a experiência de organizações públicas e privadas, atualmente está disponibilizado na versão 3.0.

O ITIL é dividido em torno de ciclo de vida do serviço e possui cinco volumes:

• Estratégia do Serviço: Definição dos requisitos e necessidades do negócio
• Projeto de Serviço: Definição da solução a ser adotada
• Transição de Serviço: Relacionado ao gerenciamento de mudanças
• Operação do Serviço: Assegura que os serviços estão sendo atendidos baseado nos SLAs
• Melhoria Contínua do Serviço: Manter a constante melhoria dos serviços baseando-se no ciclo PDCA.

Dentre os principais benefícios do uso do modelo ITIL V3 podemos mencionar:

• Alinhamento de TI, seus serviços e riscos com as necessidades do negócio
• Níveis de Serviço (SLA) negociáveis
• Processos consistentes e previsíveis
• Eficiência na entrega de serviço
• Serviços e Processos mensuráveis e passíveis de melhorias
• Otimização da experiência do cliente
• Uma linguagem comum

Catálogo

O Catálogo de Serviço traz uma visão clara de quais serviços a TI oferece e como a TI agrega valor para os recursos financeiros alocados. Ele oferece um método para requisitar ou pedir os serviços publicados. O Catálogo de Serviço viabiliza a boa governança em que os principais termos, condições e controles definidos nele estejam integrados aos processos de prestação de serviço da organização. Ele permite que a organização melhore o planejamento, a entrega e o suporte aos serviços, enquanto avalia de forma correta os custos e preços do serviço.

O “Catálogo de Serviços”, como definido na diretriz Service Delivery da ITIL, é uma lista de serviços que uma organização oferece, em geral, para os funcionários e clientes. Normalmente, cada serviço dentro do catálogo inclui:

• Uma descrição do serviço;
• Cronogramas ou acordo de nível de serviço para a finalização do serviço;
• Quem tem direito de solicitar/ver o serviço;
• Custos (se houver);
• Como realizar o serviço.

Referências:

O QUE É ITIL Disponível em:<http://www.mundoitil.com.br/> Acessado em 30 de Outubro de 2016.

Catálogo de Serviço Disponível em:<http://www.apmg-international.com/br/qualificação/catálogo-serviço/catálogo-serviço.aspx/> Acessado em 30 de Outubro de 2016.

Rational Unified Process (RUP)

O RUP é um processo proprietário criado pela Rational Software Corporation, e posteriormente adquirido pela IBM, para gerenciar de maneira eficiente as diversas ações no processo de software, para isso o RUP adota três premissas básicas:

• Uso de iterações para evitar o impacto no projeto
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

A estrutura do RUP é dividido em 4 fases e 8 disciplinas, como mostrado na figura abaixo.

Fig. 1: Esquema de Iterações

Sua distribuição apresenta duas dimensões bem definidas:

• Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.

• Eixo Y - Componentes de processo: produção de um conjunto específico de artefatos (produtos) com atividades bem definidas.

Cada fase tem um conjunto bem definido de objetivos e pode conter uma ou mais iterações, são elas:

• Iniciação - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema.

Agrupamento lógico dos elementos do processo (atividades, artefatos e papéis). Corresponde às disciplinas essenciais do processo.

• Modelagem do negócio - Descreve o negócio através de casos de uso de negócio.
• Requisitos - Narrativa da visão do sistema. Descrição das funções do sistema.
• Análise e Projeto - Descrição de como o sistema será realizado na etapa de implementação.
• Implementação - Produção do código que resultará em um sistema executável.
• Testes - Verificar a integração entre todos os componentes de software, identificar e corrigir erros de implementação.
• Gestão de projetos - Especifica um conjunto de princípios a aplicar na gestão de projetos a nível de alocação de recursos, planejamento, identificação e gestão de riscos, etc.
• Gestão de configuração e mudança - Controla as mudanças e mantém a integridade dos artefatos do projeto.
• Definição do ambiente - Cobre a infra-estrutura necessária para desenvolver um sistema (seleção de ferramentas, definição das regras de negócio, interface, testes, etc.).

Referência:

Conheça o Rational Unified Process (RUP) Disponível em:<http://www.linhadecodigo.com.br/artigo/79/conheca-o-rational-unified-process-rup.aspx> Acessado em 30 de Outubro de 2016.

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Risk reduction with the RUP phase plan Disponível em:<http://www.ibm.com/developerworks/rational/library/1826.html> Acessado em 30 de Outubro de 2016.

Processo de Software - Interação

No processo iterativo várias fases do sistema é desenvolvido de forma conjunta. Com o intuito de se adequar mais rapidamente a mudanças, o sistema é desenvolvido com a presença ativa do usuário. Alguns modelos fazem uso de iteração mais efetivamente, dos quais temos:

• Incremental

É identificado os serviços mais importantes e os menos importantes. Com a quantidade de incrementos definida, o sistema é desenvolvido com os serviços de maior prioridade sendo entregues primeiro. Portanto, o cliente tem acesso a funcionalidades do sistema antes mesmo deste ser finalizado.

Fig. 1: Modelo Incremental

• Desenvolvimento em Espiral

No modelo em espiral cada fase do processo é descrita como um loop. Cada loop está dividido em quatro setores: Definição de objetivos, Avaliação e redução de risco, Desenvolvimento e validação e Planejamento.

Fig. 2: Modelo espiral

Referências

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Modelos Incremental, Espiral e de Prototipação. Disponível em: <http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html> Acessado em 30 de Outubro de 2016.

Figura 2

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Modelos

Os modelos de software são descrições do processo de software, no qual possuem uma estrutura genérica. Embora não sejam respostas definitivas de processo são uteis para exemplificar abstrações diferentes no desenvolvimento de software. Sommerville (2007), discuti quatro destes modelos:

Modelo em cascata

Consiste do princípio que as etapas avançam  conforme sua aprovação. Portanto, a fase seguinte não deve ser iniciado antes que atual esteja terminada.

Fig. 1: Esquema de processo em cascata

Modelo Evolucionário

O desenvolvimento evolucionário baseia-se na proposta de mudança constante do projeto, expondo o resultado ao cliente e refinando as versões até que seja desenvolvido um sistema adequado.

Fig. 2: Esquema de Processo Evolucionário

Desenvolvimento Formal de Sistema

Nessa modelo é utilizado uma especificação formal matemática, onde a verificação dos componentes seguem uma argumentação matemática para demonstrar que os componentes atendem sua especificação.

Fig. 3: Desenvolvimento Formal

Desenvolvimento Orientado a Reuso

Nessa abordagem os componentes possuem uma característica de reutilização. O processo de software se concentra na integração desses componentes, ao contrario de desenvolver um sistema do zero.

Referências:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figuras 1,2 e 3:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Introdução

O processo de software é um conjunto de atividade que leva a produção de um produto de software. Não existe um processo ideal de desenvolvimento, mas sim várias abordagens diferentes que atendem necessidades especificas. Suas atividades principais se mantêm semelhantes:

• Especificação de Software.

A especificação de software é a fase do processo na qual é identificado os requisitos do sistema. Esta atividade é realizada juntamente com os stakeholders do sistema, problemas nessa fazem possuem um custo elevado de manutenção pois afetam todas as fases seguintes do processo.

• Projeto e Implementação.

Processo no qual é desenvolvido a aplicação propriamente dita. O projeto de software é uma descrição dos componentes do sistema, sendo eles: interface, algoritmo e arquitetura.

• Validação de Software.

A validação destina-se a verificar se o sistema estar em conformidade com o que foi prometido. A verificação ocorre em todo processo de software, desde a definição de requisitos até o desenvolvimento do sistema. Os testes são feitos em três etapas, sendo elas:

1. Teste de Componente – Os componentes são testados individualmente, eles podem ser entidades simples como classes ou grupos de entidades.
2. Teste de Sistema – Os componentes são testados quando integrados. É feito uma varredura para detectar erros de interação não prevista ou erros de interface.
3. Teste de Aceitação – O sistema é testado com os dados fornecidos pelo cliente. O teste exercita o sistema de maneira diferente e pode expor erros não identificados anteriormente.

• Evolução de Software.

A evolução de software trata do potencial de escalabilidade do sistema. Em um processo no qual o desenvolvimento e a manutenção se tornam cada vez mais irrelevante.

Processo de software deve ser aprimorado e padronizado conforme a cultura da empresa, não existe um processo ideal. A padronização e aprimoramento desses processos produzem uma serie de melhorias para a empresa, entre elas, o aprimoramento da comunicação e a redução do tempo de treinamento. Além disso o processo é um passo inicial para introdução de novos métodos de engenharia de software.

Referência:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Os 47 Processos do Guia do PMBok 5ª Edição

Após ter sido apresentados às mudanças ocorridas no do Guia PMBOK 5a edição, iremos agora analisar sucintamente o que acontece em cada processo. 

INTEGRAÇÃO

4.1 Desenvolver Termo de Abertura

      • Processo de desenvolver o documento que formalmente autoriza o projeto ou fase.

4.2 Desenvolver Plano de Gerenciamento do Projeto

     •Processo de documentar as ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares.

4.3 Dirigir e Gerenciar a Execução

     • Processo de executar o trabalho definido no Plano de Gerenciamento do Projeto.

4.4 Monitorar e Controlar o Trabalho

     • Processo de monitorar e controlar o progresso do projeto de acordo com o Plano.

4.5 Realizar Controle Integrado de Mudanças

     • Processo de revisar, aprovar e controlar solicitações de mudança, bem como manter atualizados os documentos do projeto.

4.6 Encerrar Projeto ou Fase

     • Processo de finalizar todas as atividades e encerrar formalmente o projeto ou fase.

ESCOPO

5.1 Planejar Gerenciamento do Escopo

     •Processo de planejar como o escopo será definido, validado e controlado.

5.2 Coletar Requisitos

  • Processo de definir e documentar os requisitos necessários para atender necessidades e expectativas de interessados.

5.3 Definir Escopo

     • Processo de desenvolver uma descrição detalhada do projeto e do produto.

5.4 Criar EAP – Estrutura Analítica do Projeto

     • Estrutura Analítica do Projeto é uma subdivisão hierárquica orientada a entregas. Criar a EAP envolve definir as entregas principais e seus componentes, bem como todo o trabalho do projeto.

5.5 Validar Escopo

     • Processo de formalizar a aceitação das entregas do projeto.

5.6 Controlar Escopo

     • Processo de monitorar e controlar o escopo do projeto.

TEMPO

6.1 Planejar Gerenciamento do Tempo

     • Processo planejar como será definido, gerenciado e controlado o cronograma do projeto.

6.2 Definir Atividades

     • Processo de identificar atividades específicas que precisam ser realizadas para produzir as entregas do projeto.

6.3 Definir Sequência de Atividades

     • Processo de identificar e documentar dependências entre as atividades do cronograma.

6.4 Estimar Recursos das Atividades

     • Processo de estimar tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma.

6.5 Estimar Durações das Atividades

     • Processo de estimar o número de períodos de trabalho necessários para realização das tarefas.

6.6 Desenvolver Cronograma

     • Processo de analisar os recursos necessários, restrições do cronograma, durações e sequências de atividades para criar o cronograma do projeto

6.7 Controlar Cronograma

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do cronograma, tomando medidas corretivas quando necessário.

CUSTO

7.1 Planejar Gerenciamento dos Custos

     • Processo planejar como será definido, gerenciado e controlado o orçamento do projeto.

7.2 Estimar Custos

     • Processo de estimar os custos dos recursos necessários para a execução das atividades.

7.3 Determinar Orçamento

     • Processo de agregar custos estimados de atividades individuais ou pacotes de trabalho para determinar o orçamento do projeto.

7.4 Controlar Custos

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do orçamento, tomando medidas corretivas quando necessário.

QUALIDADE

8.1 Planejar Gerenciamento da Qualidade

     • Processo de identificar padrões, normas ou requisitos de qualidade do projeto e produto, e documentar como o projeto demonstrará concordância.

8.2 Realizar Garantia de Qualidade

     • Processo de auditar requisitos de qualidade e os resultados das medições de controle de qualidade para assegurar que os padrões apropriados de qualidade estão sendo observados.

8.3 Controlar Qualidade

     • Processo de monitorar e controlar os resultados e as atividades do Plano de Gerenciamento da Qualidade.

RECURSOS HUMANOS

9.1 Planejar Gerenciamento de Recursos Humanos do Projeto

     • Processo de identificar e documentar funções, responsabilidades e habilidades requeridas para a criação do Plano de Gerenciamento de Recursos Humanos

9.2 Mobilizar Equipe do Projeto

     • Processo para confirmar a disponibilidade dos recursos humanos e obter a equipe necessária para terminar o projeto.

9.3 Desenvolver Equipe do Projeto

     • Processo de integração e construção da equipe do projeto, bem como melhoria de competências individuais e coletivas da equipe.

9.4 Gerir Equipe do Projeto

     • Processo de acompanhar desempenho de membros da equipe, fornecendo feedback e solucionando conflitos.

COMUNICAÇÃO

10.1 Planejar Comunicação

     • Processo de determinar as necessidades de informações das partes interessadas no projeto para definir abordagens adequadas de comunicação.

10.2 Distribuir Informação

     • Processo de tornar disponíveis as informações necessárias aos interessados.

10.2 Relatar Desempenho

     • Processo de coleta e distribuição das informações sobre o desempenho e performance do projeto.

RISCOS

11.1 Planejar Gerenciamento dos Riscos

     • Processo de definir como serão identificados, analisados e gerenciados os riscos do projeto, incluindo procedimentos e padrão para gestão de riscos.

11.2 Identificar Riscos

     • Processo de determinar quais riscos podem afetar o projeto e documentar suas características.

11.3 Realizar Análise Qualitativa

     • Processo de priorização dos riscos por meio da avaliação subjetiva das suas probabilidades de ocorrência e impactos no projeto.

11.4 Realizar Análise Quantitativa

     • Processo de análise numérica do efeito dos riscos identificados sobre os objetivos gerais do projeto.

11.5 Planejar Respostas aos Riscos

     • Processo de desenvolver estratégias e ações para ampliar oportunidades e reduzir ameaças aos objetivos do projeto.

11.6 Monitorar e Controlar Respostas aos Riscos

   • Processo de monitorar os riscos, implementando as ações do plano de resposta quando necessário.

AQUISIÇÕES

12.1 Planejar Gerenciamento das Aquisições

     • Processo de documentar as decisões de aquisição do projeto, definir tipos de contratos e identificar potenciais fornecedores.

12.2 Conduzir Aquisições

     • Processo de obter propostas de fornecedores, selecionar fornecedor e formalizar contrato.

12.3 Administrar Aquisições

     • Processo de gerenciar as relações contratuais, fiscalizar e monitorar o desempenho dos contratos.

12.4 Encerrar Aquisições

     • Processo de finalizar formalmente todas as aquisições e contratos do projeto.

STAKEHOLDERS

13.1 Identificar Stakeholders

     • Processo de identificar pessoas, grupos ou organizações que poderiam afetar ou serem afetadas pelo projeto.

13.2 Planejar Gerenciamento dos Stakeholders

     • Processo de desenvolver estratégias para engajar efetivamente os stakeholders ao longo do projeto.

13.3 Gerenciar Engajamento dos Stakeholders

     • Processo de gerenciar expectativas e promover o engajamento dos stakeholders em favor do projeto.

     13.4 Controlar Engajamento dos Stakeholders

• Processo de monitorar os relacionamentos com stakeholders do projeto.

Fonte: NÃO TENHA PRESSA – 47 PROCESSOS DO GUIA PMBOK 5 EDIÇÃO