Plano de Gerenciamento de Riscos

Risco é um evento, positivo ou negativo, que tem impacto sobre o projeto. Um plano de risco, lista e classifica-os de acordo com a probabilidade e o impacto. Para identificar os riscos é importante realizar brainstorming, analisar premissas, restrições e consultar especialistas.

Deve conter:
1. Condição
2. Data Limite (até quando existe preocupação)
3. Consequência (impactos)
4. Ação (como será tratado)
5. Responsável (quem monitora)
6. Probabilidade
7. Impacto
8. Classificação (Impacto x Probabilidade)

 

Riscos Comuns em Desenvolvimento de Software

Podemos considerar como riscos comuns:

1. Deficiência de capacidade técnica
2. Excesso de mudança nos requisitos
3. Requisitos pouco precisos
4. Indisponibilidade de Recursos Humanos
5. Decisões externas que causam mudanças no projeto
6. Não consegue atingir requisitos de desempenho
7. Cronograma não realista
8. Uso de novas tecnologias de hardware e software
9. Conhecimento insuficiente do negócio
10. Falhas de comunicação (hardware) ou baixa performance

Gráfico de GANTT

O Gráfico de GANTT mostra a seqüencia de atividades e quando cada atividade está programada para ocorrer. Utilizado tanto para planejamento como para acompanhamento.

Deve conter:
1. Lista de Atividades
2. Precedência entre Atividades
3. Esforço de Atividades
4. Recursos das Atividades

A duração de uma atividade é consequencia direta do esforço que foi despendido com a alocação de recursos para tal.

O esforço para execução de uma atividade nunca muda. A duração é alterada de acordo com a quantidade de recurso (homens).

A divisão de esforço segundo RUP é:
1. Iniciação 5%
2. Elaboração 10%
3. Construção 65%
4. Transição 10%

 

Diagrama PERT

O diagrama PERT inclui informações não só da duração das atividades, mas também das datas mais cedo e mais tarde em que certa atividade deve acontecer. Permite demonstrar quais são as atividades "críticas", ou seja, as que devem ser concluídas exatamente dentro do tempo alocado para que não haja atraso no projeto.

O caminho crítico é a rota de maior duração ao longo da rede.

Plano de Gerenciamento de Projeto - PGP

Uma diretriz para a coordenação, dizendo o que fazer e quando fazer, permitindo ao gerente do projetos controlar o andamento das atividades.

Deve conter:
1. Plano de Gerenciamento de Cronograma (Atividades)
2. Plano de Gerenciamento de Custos
3. Plano de Gerenciamento de Comunicações
4. Plano de Gerenciamento de Riscos
5. Outros Planos (RH, Qualidade, Aquisições, ...)

Plano de Atividades deve considerar:
1. Lista de Atividades
2. Tempo para Realizar
3. Recursos Necessários
4. Precedência entre atividades

Utilizar como sugestão o WBS (Work Breakdown Structure)

Declaração de Escopo de Projeto

Descreve detalhadamente as "entregas" do projeto e o trabalho necessário para gerar as "entregas".

Deve conter:
1. Descrição do escopo do produto
2. Critério de aceitação do produto
3. Entregas do projeto (produto, relatórios e documentações)
4. Exclusões do projeto
5. Restrições do projeto (questões que limitam o trabalho")
6. Premissas do projeto (hipóteses consideradas verdadeiras para o planejamento)

 

Termo de Abertura

Também chamado de carta de projeto, consiste no desenvolvimento de um documento que formalmente autoriza o início de um projeto ou uma fase. São mensionados os requisitos iniciais que satisfaçam as partes interessadas.

Deve conter:

1. Justificativa do Projeto
2. Requisitos de Alto Nível
3. Riscos de Alto Nível
4. Resumo de cronograma de marcos
5. Resumo de orçamento
6. Gerente de Projeto, responsabilidades e nível de autoridade do projeto
7. Nome dos patrocinadores e pessoas que autorizam o projeto

Modelos de Dimensionamento para um Sistema

LOC (Lines of Code): Baseado no número de linhas. É pouco preciso.

PF - Análise por Ponto de Função
1. Baseia-se em características visíveis do sistema
2. Ponto de vista do usuário
3. Permite medir o tamanho do produto no início do processo de desenvolvimento
4. Independe da tecnologia utilizada

É uma técnica que permite medir a funcionalidade de uma software, sob a visão do usuário, a partir da descrição dos requisitos.

PCU - Análise por Pontos de Casos de Uso
Semelhante ao PF, mas baseia-se na análise orientada a objetos.

Os objetivos da Análise por Pontos de Função são:
1. Medir a funcionalidade dos sistemas independentemente da tecnologia utilizada
2. Avaliar com base nas funções que o sistema executa, independentemente da tecnologia
3. Identificar um padrão de medida para qualidade e produtividade
4. Fornecer uma ferramenta para auxiliar nas estimativas de desenvolvimento de software
5. Possibilitar o uso em diferentes projetos, empresas e ambientes.
6. Ser compreensível pelo pessoal não técnico
7. Ser utilizável em todo o ciclo de desenvolvimento de software
8. Ser um processo de simples mensuração
9. Conciso e consistente

Etapas da análise por Pontos de Função:
1. Identificação do Objeto (sistema, ou parte do sistema)
2. Definição do Escopo (funcionalidades)
3. Contagem de PFNA (Pontos de Função não ajustados)
4. Cálculo de FCT (Fator de complexidade técnica) FCT = 0,65 + 0,01*(somatório)
5. Contagem dos PFA (Pontos de Função ajustados) PFA = PFNA*FCT

Os PF obtidos servem para referência na estimativa de esforço para as atividades de desenvolvimento.

Etapas da análise por Pontos de Caso de Uso:
1. Relacionar atores e classificá-los de acordo com seu nível de complexidade.
2. Relacionar casos de uso e classificá-los de acordo com seu nível de complexidade.
3. Calcular PCUs não ajustados (PCUNA)
4. Determinar fator de complexidade técnica (FCT)
5. Determinar fator de complexidade ambiental (FCA)
6. Calcular PCUs ajustados (PCUA)

TPNAA (Total de Pesos Não Ajustados de Atores) 1-simples 2-médio 3-complexo
TPNAUC (Total de Pesos não Ajustados dos Casos de Usos) 1-simples 2-médio 3-complexo
PCUNA = TPNAA + TPNAUC
FCT = 0,6 + (0,01*Soma)
FCA = 1,4 + (-0,3*Soma)
PCUA = PCUNA*FCT*FCA

RUP

RUP é um modelo de processo de desenvolvimento de software que descreve um conjunto de atividades para transformar requisitos do usuário em um software. É composto por diversas disciplinas que fornecem diretrizes para definição das tarefas e atribuição das responsabilidades em um projeto de software. Baseado em UML. Desenvolvimento Iterativo.

O ciclo de vida RUP é composto por 4 fases. Ao final de cada ciclo um release é entregue ao cliente.
1. Iniciação (Enteder os requisitos e definir escopo do projeto)
2. Elaboração (Definição de arquitetura e planejamento da construção)
3. Construção (Implementação do produto operacional)
4. Transição (Transferência do produto para o cliente)

Cada fase termina com um marco (milestone) que é definido com um artefato (documento). Cada fase é dividida em iterações, que podem ser consideradas como um mini-projeto.

Modelos Tradicionais de Processos de Engenharia de Software

Modelo Linear Sequencial (Cascata ou Ciclo de vida classico)
Análise -> Projeto (design) -> Codificação -> Teste -> Suporte

Problemas: Projetos reais normalmente não seguem uma ordem sequencial, o que pode causar confusão na equipe de projeto. Existe dificuldade dos usuários (clientes) definirem todos os requisitos inicialmente. A versão visível do projeto somente será vista no final do projeto.

Modelo de Prototipação
Definição dos Requisitos -> Projeto Rápido (versão visível ao cliente)
Natureza Iterativa. Permite que o usuário "perceba" o software antes do fim do projeto.

Problemas: O cliente não vê uma versão funcional do sistema. Possibilita práticas indesejáveis de programação. O software nunca está pronto.

Modelos Evolucionários

Modelo Evolucionário Incremental
Combina elementos do modelo Cascata com a filosofia iterativa da prototipação. Cada sequência linear produz uma versão "entregável" do software.

Modelo Evolucionário Espiral
O software é desenvolvido em uma série de "releases" incrementais. Nas primeiras iterações o resultado pode ser apenas um modelo em papel. Não termina quando o software é entregue.

Problemas: Dificuldade de provar que é uma abordagem controlável. Modelo pouco testado.

Engenharia de Software

A Engenharia de software pode ser visto em camadas:
Qualidade,  Processos, Métodos e Ferramentas

As fases genéricas da Engenharia de Software são: Definição "o que?", Desenvolvimento "como?" e Suporte.

Um modelo de processo de engenharia de software é a estratégia utilizados nos controles e entregas de requisitos.

Atividades que devem existir independentemente da abordagem utilizada:
1. Garantia de Qualidade de Software
2. Gerenciamento de Configuração de Software
3. Mensuração de Software

 

Conceito de Projeto

Projeto é um esforço temporário empreendido para criar um produto ou serviço específico. É desenvolvido em fases, possui ciclo de vida e difere das atividades contínuas.

São empreendimentos independentes, tem objetivos e duração limitada.

Gerenciamento de Projeto é a aplicação de conhecimentos, habilidades e técnicas nas atividades do projeto, para atender os requisitos do projeto (PMBOK).

Um gerente de projetos é o centro, onde gira toda a atividade. Funciona como um elo entre os steakholders. É comunicador e negociador. Deve planejar e controlar as atividades e o andamento do projeto.

O ciclo de vida de um projeto são as fases que um projeto passa, desde sua concepção até sua conclusão. Ao fim de cada fase um artefato (documento) é gerado. As principais fases de um projeto são:
1.Iniciação
2.Planejamento
3. Execução
4. Controle
5. Fiscalização

Um processo é um conjunto de atividades inter-relacionadas que são realizadas para produzir um conjunto pré-definido de produtos, resultados ou serviços.

O guia PMBOK é o padrão para gerenciar a maioria dos projetos. Descreve processos, ferramentas e técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem-sucedido. Criado pelo PMI.

Os principais grupos de processos do PMBOK são Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento. Os grupos de processos não são as fases do projeto.

As áreas de conhecimento no PMBOK são a Integração do Projeto, Tempo, Escopo, Custos, Qualidade, RH, Comunicações, Riscos e Aquisições.

 

 

 

Model Driven Architecture - MDA

É uma metodologia de desenvolvimento de software criada pela OMG (Object Management Group). A chave para o MDA é a importância da modelagem no processo de desenvolvimento de software. É uma arquitetura dirigida ao modelo.

A MDA permite integração com processos de engenharia de software, ganho de produtividade, portabilidade e interoperabilidade.

As principais etapas para MDA são:
1. Modelos
2. MetaModelos
3. PIM e PSM
4. Mapeamento entre modelos

O PIM (Platform Independent Model) é a primeira etapa do desenvolvimento que especifica a funcionalidade do cliente e do servidor.

O PIM Base é feito com a colaboração entre especialistas de modelagem e de negócio, expressa somente as funcionalidades e o comportamento do negócio. Não tem vínculo com a tecnologia.

O PIM Segundo nível possui aspectos da tecnologia, permitindo fazer um mapeamento mais preciso do PIM para o PSM.

O PSM (Platform Specific Model) é onde os aspectos tecnológicos feitos no PIM, são convertidos para a forma requerida na plataforma específica.

Existem 4 formas de passar o modelo PIM para o PSM.
1. Transformação totalmente manual sem padrão
2. Transformação totalmente manual com padrão
3. Utilizando padrões estabelecidos com uso de algoritmos
4. Utilizando uma ferramenta que produz um PSM completo a partir de um PIM

Gerenciamento de Riscos em Projetos de Software

Segundo o PMBOK, são 6 os processos na área de gerenciamento de riscos:
1. Planejamento da gerência de risco (Responsabilidades)
2. Identificação do risco (causas)
3. Análise qualitativa do risco (prioridades, impactos)
4. Análise quantitativa do risco  (probabilidades)
5. Planejamento de resposta a riscos (estratégia)
6. Monitoramento e controle dos riscos

Segundo RUP:
Concepção: Riscos relacionados aos casos de negócio
Elaboração: Riscos de requisitos, tecnológicos, de habilidade e políticos
Construção: Riscos técnicos
Transição: Riscos de logística

 

Computação em Nuvem

Cloud Computing é um conjunto de recursos (capacidade de processamento, armazenamento, conectividade, plataforma, aplicações e serviços) disponibilizados na Internet.

Como principais características estão:
1. Atendimento sob-demanda
2. Pagamento proporcional a quantidade de uso
3. Garantia do Serviço

Um importante conceito é Saas (Software as a Service): Software implementado como um serviço hospedado e acessado pela Internet. Alugando um espaço, não é necessário se preocupar com investimentos em servidores e licenças.

Outro conceito é "Pay as you go": Pagar apenas o que consumir.

Para o programador, o que muda é somente o local onde será hospedado o aplicativo.

As principais vantagens do desenvolvimento nas nuvens são:

1. Capacidade de alocar recursos de acordo com a dimensão de usabilidade do aplicativo.
2. A segurança é uma preocupação para quem fornece o serviço.
3. Disponibilidade, pois o funcionamento da plataforma é de responsabilidade de quem fornece.

As principais vantagens para o usuário de serviços nas nuvens é:

1. Portabilidade
2. Baixo investimento com hardware
3. Utilização de aplicativos em qualquer dispositivo que possua browser
4. Redução da pirataria
5. Aplicativos com preço reduzido

As principais desvantagens são:

1. Base de dados fica alocada no provedor de serviços
2. Risco de indisponibilidade dos serviços
3. Uso em internet de baixa qualidade prejudicado
4. Riscos de segurança

Engenharia de Requisitos

A Engenharia de Requisitos é uma abordagem de Engenharia de Software, que busca controlar os requisitos para que não existam falhas e inconsistência no projeto. Visa diretamente a qualidade. É um conjunto de atividades que auxilia a identificar, controlar e rastrear os requisitos, bem como suas alterações (Roger Pressman).

É dividida em:
1. Estudo de Viabilidade (interação entre analistas e clientes para um levantamento de requisito inicial)
2. Levantamento e Análise (definir necessidade e expectativa do cliente e o escopo do projeto)
3. Especificação (descrição detalhada das características que um produto deverá apresentar)

Técnicas de levantamento de requisitos:
1. Entrevista: conjunto de perguntas que levam ao entendimento do problema
2. Reuniões: Envolvem todas as partes que fazem parte do projeto (analistas, desenvolvedores, usuários,...)
3. Observação: Observar a rotina diária dos usuários, áreas de uma empresa para entender as atividades executadas e o fluxo de trabalho.

A especificação dos requisitos devem conter:
1. Refinamento detalhado de todas as funções do software
2. Características de interface
3. Identificação das restrições de projeto
4. Especificação dos critérios de validação
5. Detalhamento das regras de negócios

A análise de impacto permite avaliar o impacto da mudança no produto.
Existem requisitos estáveis e voláteis (se modificam com frequencia)

Padrões de Projetos de Software

Vantagens de se utilizar padrões:
1. Aprender com experiência de outros
2. Desenvolver softwares de melhor qualidade
3. Vocabulário comum
4. Ajuda na documentação e na aprendizagem

Elementos de um padrão de projeto segundo a GoF:
1. Nome
2. Problema (quando aplicar o padrão)
3. Solução (descrição abstrata de um problema e como usar os elementos disponíveis (classes e objetos)
4. Consequencias (custos e benefícios de se aplicar, impactos na flexibilidade, extensibilidade, portabilidade e eficiência)

Padrões para Interface/Estrutura:
1. Adapter: para adaptar a interface de uma classe para outra que o cliente espera
2. Facade: oferecer uma interface simples para uma coleção de classes
3. Composite: definir uma interface comum para objetos individuais e composição de objetos
4. Bridge: desacoplar uma abstração de sua implementação para que ambos possam variar independentemente.

 

Elaboração de artigo

Para elaboração de um artigo, procurar:

1. Utilizar português formal
2. Nunca utilizar primeira pessoa (eu, nós), e sim terceira pessoa (entende-se, verificou-se)
3. As fontes de pesquisa devem ser livros, artigos científicos, artigos de revistas comerciais
4. A informação deve ser transcrita para o artigo com suas palavras, de forma mais sucinta e consolidada, sempre citando a fonte.
5. Se não há citação, presume-se ser um texto do próprio autor que deve ser provado no artigo. Caso contrário é considerado plágio.

Formas de citação:

Segundo Fulano (2010), a informação é subjetiva.
A informação é subjetiva (Fulano, 2010).

Todo artigo deve conter:
1. Introdução: relevância do tema
2. Desenvolvimento: exploração do tema
3. Considerações Finais: síntese do que foi feito

Scrum

O Scrum é uma metodologia ágil de desenvolvimento que segue a filosofia iterativa e incremental. Sendo oposta ao modelo cascata , inicia-se a análise assim que alguns requisitos estiverem disponíveis. O projeto trabalha num pedaço pequeno de cada vez.

Cada iteração consiste em:
1. Captura de requisitos
2. Um pouco de análise
3. Um pouco de design (projeto)
4. Mais alguma programação e testes

Backlog é uma lista de ítens priorizados, composta por requisitos e funcionalidades que precisam ser construídas.
Cada iteração é chamada de Sprint

O processo Scrum é resumido em 6 passos:
1. Backlog do Produto (lista de requisitos e funcionalidades que precisam ser construídas)
2. Backlog do Sprint (items da lista que podem ser concluídos ao fim da iteração)
3. Tarefas do Backlog distribuidas na equipe
4. Sprint (trabalho da equipe)
5. Reuniões Diárias (trabalho mostrado aos stakeholders)
6. Funcionalidade

A estrutura Scrum é formada por 3 papéis, 4 cerimônias e 3 artefatos.

Os papéis são:
1. Product Owner (cliente do projeto ou representante - responsável por definir o valor do negócio e aprovar o resultado do trabalho)
2. Scrum Master (gerente do projeto - responsável por assegurar a funcionalidade e a produtividade do time)
3. Team (equipe de desenvolvimento)

As cerimônias são:
1. Sprint Planning Meeting: reunião em que o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que serão executadas no proximo Sprint (passo 2).
2. Daily Scrum: reunião diária que visa disseminar o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia (passo 5).
3. Sprint Reviews: Uma demonstração do time ao Product Owner do que foi completado durante o Sprint.
4. Sprint Retrospectives: O time analisa o Sprint e procura maneiras para melhorar o produto e processo.

Os artefatos são:
1. Product Backlog: Relação de atividades a serem realizadas no projeto, ordenadas por prioridade e duração.
2. Burdown Chart: gráfico que mostra o esforço restante de um sprint (diário) para controlar o desenvolvimento da equipe
3. Sprint Backlog: Conjunto de tarefas retiradas a partir do Product Backlog, a serem realizadas no Sprint

 

Metodologias Ágeis de Desenvolvimento

Os métodos ágeis são:

1. Adaptativos e não preditivos: os planos dos métodos são elaborados ao longo do projeto, permitindo mudanças
2. Orientado a pessoas, e não a processos.
3. O cliente tem função crítica
4. As equipes são auto-organizadas, encorajando o intercâmbio de papeis (funções)
5. Baseado em liderança e colaboração, diferentemente do comando e controle.

As principais metodologias ágeis são: XP, Scrum, Crystal Methods, DSDM, FDD, LD, ASD, APM.