Tec. Em Analise e desenvolv. De Sistemas Análise e projeto de sistemas Aula 13

20/04/23 Professor Leomir J. Borba- [email protected] –http://professorleomir.wordpress.com 1

Tec. Em Analise e desenvolv. De Sistemas

Análise e projeto de sistemas Aula 13


GERENCIAMENTO DE PROJETOSTecnicas e conhecimentos (PMI)

Testes de software & QualidadeCMM / CMMI

Bibliografia

AGENDA


Questões importantes• Por que as organizações usam gerenciamento

de projetos ?

• O que é um projeto ?

• O que Gerenciamento de Projetos ?

• Quais são os principais papéis desempenhados em um projeto e como eles se inter-relacionam ?

• Quais são os principais elementos de um projeto e como eles se inter-relacionam ?

• O que é o corpo de conhecimento de gerenciamento de projetos ?


Por que as organizações usam Gerenciamento de Projetos ?• Melhor comunicação entre os participantes do projeto• Melhor compreensão sobre o projeto e seus objetivos• Capacidade de definir e controlar o escopo do projeto• Capacidade de identificar, monitorar e acompanhar os

marcos do projeto• Projeção correta das necessidades de recursos• Melhor avaliação e mitigação dos riscos do projeto• Capacidade e mecanismos para medir a performance• Identificação e comunicação das áreas de problemas• Esclarecimento e alinhamento com os objetivos da

organização• Priorização das atividades funcionais e do projeto


O que é um Projeto ?

Um projeto é um esforço temporário empreendido para criar um produto ou serviço único

Os gerentes de projeto devem identificar eaprender sobre as similaridades dos projetos


O que é Gerenciamento de Projetos ?

A aplicação de técnicas, habilidades, ferramentas etécnicas às atividades do projeto paraatender os requisitos do projeto

As atividades tipicamente envolvem:• Demandas exigentes para : escopo, tempo,

custo, riscos, qualidade• Interessados no projeto com necessidades e

expectativas diferentes• Requisitos identificados e muitas vezes

evolutivos


Quais são os principais papéis em um projeto ecomo eles se inter-relacionam ?

Participantes do projeto

Gerentes Funcionais

PatrocinadorGerenteProjeto

InteressadosMembros da equipe


InteressadosMembros da equipe

Quais são os elementos principais de um Projeto como eles se inter-relacionam ?

ESCOPO TEMPO

CUSTO

QUALIDADE

RISCOS

O que estamos entregando

Como e quanto tempo seránecessário para gerar os produtos?

Seguindo quais padrões de qualidadeestamos produzindo os resultados ?

Quem é necessário para completaro projeto ? Quanto precisamos de cada recurso ?Quanto custará cada recurso ?

O quão seguros estamos dascondições e eventos que envolvemo projeto e que conseguimoscompleta-lo de acordo com o planejado ?


Interessados no Projeto

Clientes Usuários finais Acionistas Departamentos de suporte

e manutenção Representantes de

serviços a clientes

Grupo de pessoas e/ou corporações envolvidas no projeto ouafetadas pelas atividades do projeto

Departamentos de produção e operaçãoMembros da equipe do projetoPatrocinadoresGerentes funcionaisGerentes de projeto

Qualquer um que tenha algum interesse...


O que é o Corpo de Conhecimento emGerenciamento de Projetos ?

O PMBOK é um termo abrangente e que descreve a soma de conhecimentos inerentes à profissãode gerenciamento de projetos. Como em muitasoutras profissões, o corpo de conhecimento dependedos praticantes e estudiosos para aplicá-lo e evoluí-lo.O corpo de conhecimento completo abrange práticasjá aprovadas e de uso comum, além de outras inovadorase avançadas, que possam até ter sido menos utilizadas.


O que é o Guia do Corpo de Conhecimentoem Gerenciamento de Projetos ?

• Identifica a descreve o sub-sistema do corpo de conhecimento em gerenciamento de projetos que é geralmente aceito


O que é o Guia do Corpo de Conhecimentoem Gerenciamento de Projetos ?

• Identifica a descreve o sub-sistema do corpo de conhecimento em gerenciamento de projetos que é geralmente aceito

Conhecimentos epráticas aceitas paraGerenciamento de

Projetos

São conhecimentos epráticas aplicáveis

na maioria dosprojetos de todos

os tipos

Há um consenso geralsobre os seus valores

e benefícios

Conhecimentos epráticas de

GerenciamentoÉ composto peloplanejamento, organização,recrutamento,

execução e controledas operações da empresa

Conhecimentos epráticas das

Áreas deConhecimento

Conhecimentos necessários para

executar o projeto na suaarea específica

(industrial, técnica,serviços, construção,

etc)


Grupos de processos e áreas de conhecimento

INICIAÇÃO PLANEJAMENTO EXECUÇÃO CONTROLE ENCERRAMENTOGERENCIAMENTOINTEGRAÇÃO Desenv. Plano Proj Execução Plano Proj Controle Integrado Mudanças

Iniciação Planej. Escopo Verificação EscopoDefinição Escopo Controle Mudanças Escopo

Definição Atividades Controle do CronogramaSequenciamento Atividades

Estimativa Duração AtividadesDesenv. Cronograma

Planejamento Recursos Controle de CustosEstimativa CustosOrçamento Custos

QUALIDADE Planejamento Qualidade Garantia Qualidade Controle de QualidadePlanejamento Organizacional Desenvolvimento Equipe

Recrutamento da EquipeCOMUNICAÇÃO Planejamento Comunicação Distribuição Informações Relatórios de Performance Fechamento Adm.

Planej. Gerenciam. Riscos Monitoração e Controle RiscosIdentificação Riscos

Análise Qualitativa RiscosAnálise Quantitativa Riscos

Planej. Respostas aos RiscosPlanejamento Aquisições Solicitação Encerram.Contrato

Planejamento de Solicitações Seleção de Fornecedores

RISCOS

AQUISIÇÕES

ESCOPO

TEMPO

CUSTOS

RECURSOS HUMANOS


Processo baseado em PMI

Exemplo de processo Praxis (Desenvolvimento de software)

Gestao de Projetos tem quatro atividades principais:

Planejamento de ProjetoControle de ProjetoResolução de ProblemasAquisição



Ativação do ProjetoAções necessarias para começar : Dados iniciais, lista de funções, beneficios esperados

Planejamento preliminarDeterminar viabilidade atraves de estimativa alto nivel de tamanho, custos esforços e prazos

Planejamento Geral do ProjetoVisa o escopo do projeto, equipe, recursos tecnicos, custos, prazos, tratamento de riscos



Controle de Projeto

Gestão detalhadaGerir dia a dia das tarefas

Retrospectiva Reunião para revisão de problemas, pontos positivos e proposição de resolução

Relato Criar e manter relatorio do projeto para acompanhamento executivo.



Resolução de problemas

Identificação

Análise

Negociação

Execução de ação

Verificação de resolução

05/08/2011 Professor Leomir J. Borba- [email protected] –http://professorleomir.wordpress.com

Validação e Qualidade estão profundamente relacionados.

Validação objetiva garantir aderencia aos requisitos, inexistencia de erros, confiabilidade, disponibilidade ou seja muito mais do que achar erros através de testes

QualidadeSatisfazer especificaçõesAssegurar fácil manutençãoÉ agregada durante todo o processo

Testes & Qualidade de Software


Independencia GerencialNecessaria existir entre desenvolvimento e SQA

TestesGarantem que software atenda os requisitos especificados, usa estrategia de testes aplicada por todo o ciclo de vida do projeto (unitario, sistema,integração, regressão e de aceitação do usuario (UAT))



Testes & Qualidade de SoftwareTestes que nao se baseiam em execução.

WalkthroughsTecnica de RevisãoBaseia-se na revisao por diferentes individuos que nao sejam autores do documento (projeto de software)Equipe formada por 4 a 6 individuos, pelo menos um representante da equipe de elaboração das especificações, gerente responsavel pelo fluxo de trabalho, cliente ou area de negocios, SQA deve presidir o grupo

InspeçõesMais complexa que Walkthroughs com cinco etapas formais:

Visao Geral do documento inspecionadoPreparação – Participantes devem entender o documentoInspeção - Encontrar e documentar imperfeiçõesReformulação – resolve imperfeições e problemas achados.Acompanhamento – Moderador garante que questões levantadas sejam resolvidas.


Comparação entre Inspeções e WalkthroughsWalktroughs – Duas etapas, preparação seguida de analise do documento pela equipe.Inspeções processo de 5 etapas ( Visao Geral, preparação, inspeção reformulação e acompanhamento)

Testes baseados em execuçãoBaseiam-se na execução do sistema com verificação de seu comportamento e resultados obtidos.Apesar dos esforços com esse tipo nao garante 100% de inexistencia de erros.



O que deve ser testado?UtilidadeConfiabilidadeRobustezDesempenhoCorreção


23

CMM -Histórico• O SW-CMM (Capability Maturity Model for Software) é

um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software deste último.

• Início dos trabalhos deu-se em 1986, tendo sido publicada a versão 1.0 do SW-CMM em agosto de 1991.

• Em fevereiro de 1993, foi publicada a versão 1.1.

24

CMM – Histórico cont.

• Por ser específico para a área de software, o SW-CMM não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas.

• Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas, tais como Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM).

• Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.

25

SoftwareCMM

SoftwareCMM

SystemsSecurity

Engineering CMM

SystemsSecurity

Engineering CMM

SystemsEngineering

CMM

SystemsEngineering

CMM

PeopleCMM

PeopleCMM

SECM (EIA 731)

SECM (EIA 731)

Integrated Product

DevelopmentCMM

Integrated Product

DevelopmentCMM

SoftwareAcquisition

CMM

SoftwareAcquisition

CMM

• Diferentes estruturas, formatos, termos, maneiras de medir maturidade

• Causa confusão, especialmente quando mais de um modelo é utilizado

• Difícil de integrar em um único programa de melhoria

Histórico

• Proliferação de Modelos e Padrões em diversas áreas

26

CMMI - Histórico• O CMMI (Capability Maturity Model Integration) foi

criado, então, com a finalidade de integrar os diversos modelos CMM.

• Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated – System / Software Engineering).

• Versões do CMMI:– Versão 1.0: Agosto de 2000– Versão 1.1: Março de 2002– Versão 1.2: Agosto de 2006 (CMMI for Development)

27

SW-CMM

• Modelo de Maturidade de Capacitação para Software• Objetivo Principal: guiar organizações a conhecerem e

melhorarem seus processos de software.• Identifica práticas para um processo de software

maduro, definindo as características de um processo de software efetivo.

• Descreve como as práticas de engenharia de software evoluem sob certas condições.

• Organiza os estágios de evolução da melhoria dos processos em cinco níveis de maturidade.

28

SW-CMM: Estrutura• Cada nível de maturidade, com exceção do primeiro, é

composto por áreas-chave de processo (Key Process Areas – KPAs).

• Cada KPA identifica atividades relacionadas que, quando executadas adequadamente, atingem determinados objetivos considerados importantes para o aumento da capacidade do processo.

• As KPAs são os requisitos para a obtenção de um nível no CMM.

• As KPAs são cumulativas, isto é, para uma organização atingir um determinado nível de maturidade, ela deve satisfazer todas as KPAs daquele nível e de seus inferiores.

Tópicos Especiais - Qualidade de Software 2008/2

29

SW-CMM: Estrutura

• Cada KPA é descrita em termos de práticas-chave (Key Practices).

• Uma prática-chave descreve as atividades e a infra-estrutura necessárias para a efetiva implementação e institucionalização de uma KPA.

• Uma prática-chave descreve “o quê” deve ser feito, e não “como” deve ser feito.

30

SW-CMM: Estrutura• Para cada KPA há metas a serem alcançadas, que

caracterizam o seu conteúdo, escopo e limite. • Metas são usadas para determinar se a organização ou

projeto efetivamente implantou a KPA em questão. • Em uma avaliação de conformidade com o CMM, o mais

importante é verificar se todas as metas da KPA foram atingidas

31

SW-CMM – Níveis de Maturidade• Um nível de maturidade é um patamar evolutivo bem

definido, que visa a alcançar um processo de software maduro.

• Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de software.

• No nível 2 por exemplo, são focados aspectos gerenciais dos projetos.

32

• O conceito de maturidade é baseado na noção de que alguns processos provêem mais estrutura e controle do que outros.

SW-CMM – Níveis de Maturidade

Processo continuamente melhorado

Processo previsível e controlado

Processo consistente e padronizado

Processo disciplinado

1- Inicial

2- Repetível

3- Definido

4- Gerenciado

5- Otimizado

Processo imprevisível e sem controle

33

SW-CMM: Nível 1 (Inicial)

entrada saída

• O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico.

• Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heróicos.

• O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.

34

SW-CMM: Nível 1• Organizações no nível 1 apresentam deficiências de planejamento

e enfrentam dificuldades ao realizarem previsões.• Cronogramas e planos são irrealistas.• Como não há credibilidade no planejamento, mesmo aquilo que foi

planejado não é seguido.• Não há controle de requisitos e o cliente só os avalia na entrega do

produto.• É comum passar diretamente dos requisitos à codificação.• A documentação é encarada como algo inútil.• São comuns reações intransigentes à coleta de dados e ao uso de

padrões, documentação e ferramentas.

35

SW-CMM: Nível 2 (Repetível)

entrada saída

• Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo.

• É possível repetir sucessos de projetos anteriores em aplicações similares.

• Ao invés do processo ser uma única caixa preta, ele passa a ser uma seqüência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

36

SW-CMM: Nível 2• Neste nível, organizações têm maior probabilidade de cumprir

compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente.

• A organização é disciplinada, mas não está bem preparada para mudanças.

• Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise.

• Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos.

• Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.


37

SW-CMM: KPAs do Nível 2• Gerência de Requisitos

• Planejamento de Projetos

• Supervisão e Acompanhamento de Projetos

• Gerência da Subcontratação de Software

• Garantia da Qualidade de Software

• Gerência de Configuração de Software


38

SW-CMM: Nível 3 (Definido)

entrada saída

• Um processo de software, composto por atividades de gerência e engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização.

• Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software.

• A organização interna das tarefas está definida e visível

39

SW-CMM: Nível 3• Processos utilizados são estabelecidos e padronizados em toda a

organização.• Os processos pertencem à organização e não aos projetos.• O Grupo de Processos (Software Engineering Process Group - SEPG) é

responsável pelos processos da organização.• Apesar da padronização, é possível adaptar os processos para as

necessidades particulares de um projeto.• Processos de engenharia de software são considerados ao lado dos

processos gerenciais.• Há treinamento técnico e gerencial.• A organização consegue se manter dentro do processo mesmo em

períodos de crise.• Como o processo é bem definido, caso um desenvolvedor abandone o

projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores.

• Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores práticas existentes na organização.

40

SW-CMM: KPAs do Nível 3• Foco no Processo da Organização

• Definição do Processo da Organização

• Programa de Treinamento

• Gerência de Software Integrada

• Coordenação entre grupos

• Engenharia de Produtos de Software

• Revisão por Pares

41

SW-CMM: Nível 4 (Gerenciado)

entrada saída

• Métricas detalhadas do processo de software e da qualidade do produto são coletadas.

• Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.

42

SW-CMM: Nível 4• A organização estabelece metas quantitativas de qualidade e

produtividade para as atividades do processo e para os produtos produzidos são estabelecidas para cada projeto.

• Medidas de qualidade e produtividade são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento e a ocorrência de problemas.

• Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída.

• É estabelecido o controle estatístico de processos.• Uma organização no nível 4 passa a ter uma gestão feita com

bases quantitativas.

43

SW-CMM: KPAs do Nível 4• Gerência Quantitativa dos Processos

• Gerência da Qualidade de Software

SW-CMM: Nível 5 (Otimizado)

entrada saída

• A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa, e da implantação planejada e controlada de tecnologias e idéias inovadoras.


45

SW-CMM: Nível 5

• A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos.

• O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo.

• Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.

• Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo / benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4.

46

SW-CMM: KPAs do Nível 5

• Prevenção de Defeitos

• Gerência da Evolução dos Processos

• Gerência da Evolução das Tecnologias

47

CMMI• É um modelo que descreve orientações para a definição

e implantação de processos.• O modelo não descreve processo algum, são

orientações definidas através das práticas especificadas.

• Método de avaliação utilizado: SCAMPI (Standard CMMI Assessment Method for Process Improvement)– Método que reúne as melhores práticas do CBA-PI e

SCE (métodos amplamente utilizados pelo SW-CMM e outros modelos de melhoria de processos)

48

CMMI – Cont.• Proposta de um modelo integrado que pode ser utilizado em

várias disciplinas.• Disciplinas do CMMI

– Engenharia de Software – Engenharia de sistemas: abordagem interdisciplinar cujo

objetivo é o desenvolvimento bem-sucedido de sistemas como um todo, envolvendo software ou não.

– Desenvolvimento integrado do produto e processo: abordagem sistemática que utiliza a colaboração dos stakeholders para melhor satisfazer as expectativas e requisitos dos clientes. Usada em conjunto com práticas de produção de um produto específico.

– Fontes de Aquisição: aquisição de produtos de fornecedores.

49

Objetivos do CMMI• Além da integração dos modelos e redução dos custos

com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI:– Aumento do foco das atividades– Integração dos processos existentes– Eliminar inconsistências– Reduzir duplicações– Fornecer terminologia comum– Assegurar consistência com a norma ISO 15504– Flexibilidade e extensão para outras disciplinas

50

CMMI: Conceitos Básicos• Área de Processo (Process Area – PA): práticas

relacionadas em uma área que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria nessa área.

• Metas Específicas: se aplicam a uma PA e tratam de características que descrevem o que deve ser implementado para satisfazer essa PA. São utilizadas nas avaliações para auxiliar a determinar se a PA está sendo satisfeita.

51

CMMI: Conceitos Básicos• Práticas Específicas: atividades que são consideradas

importantes na satisfação de uma meta específica associada.

• Metas Genéricas: aparecem em diversas PAs.• Práticas genéricas: oferecem uma institucionalização que

assegura que os processos associados com a PA serão eficientes, repetíveis e duráveis.

• Produtos de trabalho típicos: exemplos de saídas de uma prática específica ou genérica.

• Sub-práticas: descrições detalhadas que fornecem um direcionamento para a interpretação de práticas específicas ou genéricas.

52

Exemplo: Meta e Prática Específicas

• PA: Gerência de Requisitos• Meta Específica: Gerenciar Requisitos

– Requisitos são gerenciados e inconsistências com planos de projeto e produtos de trabalho são identificados.

• Prática Específica: Manter rastreabilidade bidirecional entre requisitos. – Manter rastreabilidade bidirecional entre os requisitos

e planos de projeto e produtos de trabalho.• Produtos de Trabalho Típicos: Matriz de rastreabilidade,

Sistema de Acompanhamento de Requisitos

53

Exemplo: Meta e Prática Genéricas

• Meta Genérica (do Nível 2 de Capacidade ou Maturidade)– Institucionalizar um processo gerenciado.

• Prática Genérica (do Nível 2 de Capacidade ou Maturidade)– Estabelecer uma política organizacional.

54

CMMI: Conceitos Básicos• Metas específicas e metas genéricas são

componentes exigidos do modelo. Esses componentes devem ser atingidos pelos processos planejados e implementados por uma organização.

• Práticas específicas e práticas genéricas são componentes esperados do modelo. Os componentes esperados descrevem o que uma organização normalmente implementará para satisfazer um componente exigido.

55

CMMI: Conceitos Básicos

• Sub-práticas, produtos de trabalho típicos, entre outros, são componentes informativos do modelo que auxiliam os usuários do modelo a entender as metas e práticas e a maneira como elas devem ser satisfeitas. Os componentes informativos fornecem detalhes que auxiliam os usuários do modelo a começar a pensar em como abordar as metas e práticas.

56

CMMI: Representações

• Contínua

– Níveis de Capacidade– Agrupamento de Áreas de Processo por Categoria– Avaliação da Capacidade nas Áreas de Processo

• Por Estágios– Níveis de Maturidade– Agrupamento de Áreas de Processo por Nível– Avaliação da Organização / Unidade Organizacional

como um todo• As PAs do CMMI são as mesmas para ambas as

representações.

57

Áreas de Processo do CMMI• PAs são organizadas em quatro

categorias de processo: Gerenciamento de Processos, Gerenciamento de Projetos, Engenharia e Suporte.

58

Gerenciamento de Processos• Atividades relativas à definição, planejamento, distribuição

de recursos, aplicação, implementação, monitoramento, controle, avaliação, medição e melhoria de processos.

• Envolve as seguintes PAs:– Foco no Processo Organizacional (básica)– Definição do Processo Organizacional (básica)– Treinamento Organizacional (básica)– Desempenho do Processo Organizacional (avançada)– Inovação e Desenvolvimento Organizacional (avançada)

59

Gerenciamento de Projetos• Atividades de gerência de projetos relacionadas ao

planejamento, monitoramento e controle do projeto. • Envolve as seguintes PAs:

– Planejamento de Projetos (básica)– Monitoramento e Controle de Projetos (básica)– Gerência de Acordos com Fornecedores (básica)– Gerência Integrada de Projetos (avançada)– Gerência de Riscos (avançada)– Integração de Equipes (avançada)

– Gerência Quantitativa de Projetos (avançada)

60

Engenharia

• Atividades de desenvolvimento e manutenção que são compartilhadas entre as disciplinas de engenharia (por exemplo, engenharia de sistemas e engenharia de software).

• Envolve as seguintes PAs:– Gerência de Requisitos – Desenvolvimento de Requisitos – Solução Técnica – Integração de Produtos – Verificação – Validação

61

Suporte

• Atividades que apóiam o desenvolvimento e a manutenção de produtos.

• As PAs de Suporte tratam os processos que são utilizados no contexto da execução de outros processos, a saber:– Gerência de Configuração (básica)– Garantia da Qualidade do Processo e do Produto

(básica)– Medição e Análise (básica)– Ambiente Organizacional para Integração (avançada)– Análise de Decisões e Resoluções (avançada)

– Análise de Causas e Resoluções (avançada)


62

Representação Contínua: Estrutura

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Práticas Genéricas

Metas Genéricas

Área de Processo 2Área de Processo 1 Área de Processo n

Metas Específicas

Práticas EspecíficasNíveis de Capacidade

63

Representação Contínua: Estrutura

• Metas específicas organizam práticas específicas.

• Metas genéricas organizam práticas genéricas • Cada prática (específica / genérica)

corresponde a um nível de capacidade.• Metas e práticas específicas aplicam-se a áreas

de processo individuais.• Metas e práticas genéricas aplicam-se a várias

áreas de processo.

64

Representação Contínua: Níveis de Capacidade

• Um nível de capacidade descreve a capacidade de uma área de processo.

• Há seis níveis de capacidade, cada um representando uma camada na base para a melhoria contínua do processo.

• Assim, níveis de capacidade são cumulativos, ou seja, um nível de capacidade mais alto inclui os atributos dos níveis mais baixos.

• Uma vez que os modelos CMMI são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade provêem uma ordem recomendada para abordar a melhoria de processo dentro de cada área de processo.


65

Representação Contínua

5 Otimizado

4 Gerenciado Quantitativamente

3 Definido

2 Gerenciado

1 Realizado

0 Incompleto

Níveis de Capacidade

66

Representação Por Estágios: Estrutura

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Características Comuns

Process Area 1 Process Area n

Ability Implementation

Verifying to Perform

Commitment Directing Implementation

Specific Goals

Implementation Specific Practices

Níveis de Maturidade

Práticas Genéricas

Metas Genéricas

Área de Processo 2 Área de Processo 1 Área de Processo n

Habilitação Implementation

Verificação da Compromisso Implementação

Metas Específicas

Implementação Práticas Específicas

67

Representação por Estágios: Níveis de Maturidade

• Um nível de maturidade é um plano bem definido de um caminho para tornar a organização mais madura.

• Existem cinco níveis de maturidade.• Cada nível representa uma camada na base para a melhoria

contínua do processo.

68

Representação Por Estágios: Características Comuns

• Agrupamentos que oferecem uma maneira de apresentar as práticas genéricas. São elas:– Compromisso: agrupa as práticas genéricas relacionadas à criação de

políticas e à garantia de patrocínio.

– Habilitação: agrupa as práticas genéricas relacionadas a assegurar que o projeto e/ou organização possuem os recursos que necessitam.

– Implementação: agrupa as práticas genéricas relacionadas à gerência do desempenho do processo, gerência da integridade de seus produtos de trabalho e envolvimento dos stakeholders relevantes.

– Verificação da Implementação: agrupa as práticas genéricas relacionadas a revisões pelo nível mais alto de gerenciamento e a avaliações objetivas de conformidade a descrições de processos, procedimentos e padrões.


69

Processo imprevisível, pouco controlado

Processo caracterizado para projetos e freqüentemente reativo

Processo pró-ativo e caracterizado para a organização

Processo medido e controlado

Foco na melhoria do processo

Gerenciado Quantitativamente

Inicial

Gerenciado

Definido

1

2

3

4

5 Otimizado

Níveis de Maturidade

Representação por Estágios

70

Representação Contínua: Vantagens

• Fornece maior flexibilidade focando em áreas de processo específicas de acordo com metas e objetivos de negócio

• Permite a comparação de áreas de processo entre diferentes organizações

• Estrutura familiar para aqueles que estão migrando da comunidade de engenharia de sistemas

• Foco bem definido nos riscos específicos de cada área de processo• Estrutura compatível com a ISO/IEC 15504

71

Representações Por Estágios: Vantagens• Fornece uma rota de implementação por meio de:

– grupos de área de processo– implementação em seqüência– cada nível funciona como a fundação para o próximo

• Estrutura familiar para aqueles que estão migrando do SW-CMM.• Habilidade de gerenciar processos ao longo da organização.• Em uma avaliação, atribui um nível de maturidade em que a

organização se encontra, permitindo, assim, comparar organizações de forma direta.

72

Comparando as Representações

• A representação contínua tem mais práticas específicas que a representação em estágios, porque tem dois tipos de práticas específicas, básicas e avançadas, enquanto a representação em estágios possui apenas um tipo de prática específica.

• Na representação contínua, as práticas genéricas existem para os níveis de capacitação de 1 a 5, enquanto que na representação em estágios somente aparecem práticas genéricas para os níveis de capacitação 2 e 3; não existem práticas genéricas para os níveis de capacitação 1, 4 e 5.

73

Representação por Estágio: PAs do Nível 2• Gerência de Requisitos• Planejamento de Projeto • Monitoração e Controle de Projeto • Garantia da Qualidade do Processo e do Produto • Gerência de Acordo com Fornecedores • Gerência de Configuração • Medição e Análise

74

CMMI: Objetivos das PAs do Nível 2• Gerência de Requisitos: gerenciar os requisitos dos produtos e

componentes de produtos do projeto e identificar as inconsistências entre estes requisitos e os planos e os produtos de trabalho do projeto. Envolve:– Assegurar que o conjunto de requisitos acordados é gerenciado

para apoiar as necessidades de planejamento e execução do projeto.

– Documentar as mudanças nos requisitos e suas justificativas, e manter a rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos de produtos e componentes de produtos.


75

CMMI: Objetivos das PAs do Nível 2

• Planejamento de Projetos: estabelecer e manter planos que definem as atividades do projeto. Envolve:– Desenvolver o plano do projeto– Interagir com os stakeholders de forma apropriada– Obter compromissos com o plano– Manter o plano


76


• Monitoramento e Controle do Projeto: oferecer um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. Envolve:– Monitorar atividades, comunicar status e tomar as ações

corretivas. – O progresso é basicamente determinado pela comparação

dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado.

77


• Gerenciamento de Acordos com Fornecedores: gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal. Envolve:– Determinar o tipo de aquisição que será utilizada para os

produtos a serem adquiridos– Selecionar os fornecedores– Estabelecer e manter acordos com fornecedores– Executar o acordo com o fornecedor– Aceitar a entrega dos produtos adquiridos– Fazer a transição dos produtos adquiridos para o projeto

78

CMMI: Objetivos das PAs do Nível 2• Medição e Análise: desenvolver e sustentar a capacidade de

medições que é utilizada para apoiar as necessidades de gerenciamento de informações. Envolve:– Especificar os objetivos de medições e análises, de forma que

estes estejam alinhados com as necessidades e objetivos de informações identificados

– Especificar as medidas, mecanismos de coleta de dados e armazenamento, técnicas de análises e mecanismos de comunicação e de feedback

– Implementar a coleta, armazenagem, análise e relatórios sobre os dados

– Fornecer resultados objetivos que possam ser utilizados na tomada de decisões bem informadas e na tomada das ações corretivas apropriadas

79


• Garantia da Qualidade do Processo e do Produto: fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Envolve:– Avaliar objetivamente os processos, produtos de

trabalho e serviços executados contra as descrições de processo, padrões e procedimentos aplicáveis

– Identificar e documentar questões de não conformidades– Fornecer feedback para a equipe do projeto e gerentes

sobre os resultados das atividades de garantia da qualidade

– Assegurar que as questões de não conformidades sejam tratadas

80

CMMI: Objetivos das PAs do Nível 2• Gerência de Configuração: estabelecer e manter a integridade dos

produtos de trabalho, utilizando a identificação da configuração, controle da configuração, comunicação do status da configuração e auditorias de configurações. Envolve:– Identificar a configuração de produtos de trabalho selecionados que

compõem as baselines em determinados momentos no tempo

– Controlar as mudanças nos itens de configuração

– Construir ou fornecer especificações para construir produtos de trabalho a partir do sistema de gerenciamento de configurações

– Manter a integridade das baselines

– Fornecer um status preciso e os dados atuais de configurações para desenvolvedores, usuários finais e clientes

81

Representação por Estágio: PAs do Nível 3

• Gerência de Projeto Integrada • Definição do Processo Organizacional • Foco no Processo Organizacional • Treinamento Organizacional • Desenvolvimento de Requisitos • Solução Técnica • Integração do Produto • Verificação• Validação • Gerência de Riscos • Análise de Decisão e Resolução

82

Representação por Estágio: PAs do Níveis 4 e 5

• Nível 4:– Gerência Quantitativa do Projeto – Desempenho do Processo Organizacional

• Nível 5:– Análise de Causas e Resolução – Inovação e Implantação na Organização


BibliografiaBIBLIOGRAFIA BÁSICA

1 PRESSMAN, Roger S. Engenharia de Software, 6ª ed. São Paulo. MakGraw-Hill, 2006.

2 SOMMERVILLE, Ian. Engenharia de Software - 8a edição – Pearson. 2010

3WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2ª Edição. Rio de Janeiro: Campus, 2010.

BIBLIOGRAFIA COMPLEMENTAR

4 ENGHOLM Jr., Hélio. Engenharia de Software na Prática, São Paulo. Novatec. 2010

5LARMAN, Craig. Utilizando UML e Padrões. 3ª Edição. Porto Alegre: Bookman, 2007.

6PAULA FILHO, W. P. Engenharia de Software. Rio de Janeiro: LTC. 2009.

7TONSIG. S. L. Engenharia de Software – Análise e Projeto de Sistemas. 2ª Edição. Rio de Janeiro: Ciência Moderna, 2008.

Tec. Em Analise e desenvolv. De Sistemas Análise e projeto de sistemas Aula 13

Documents

Transcript of Tec. Em Analise e desenvolv. De Sistemas Análise e projeto de sistemas Aula 13