Aula 02 - Processos de software
15 pág.

Aula 02 - Processos de software


DisciplinaGerência de Projetos de Software87 materiais565 seguidores
Pré-visualização2 páginas
em agosto de 1991 
\uf0b7 Surgiu da necessidade de atender a uma demanda do Governo Federal 
dos EUA, de criação de um método para avaliar a capacitação de seus 
fornecedores de software. 
\uf0b7 Origem na década de 1980 com a necessidade do departamento de 
defesa dos EUA em avaliar a aquisição de produtos de software. 
\uf0b7 Evolução dos modelos: 
o SW-CMM (Departamento de Defesa dos EUA) 
o EIA SECM (Electronic Industries Alliances's Systems Engineer 
Capability Model) 
o IPD-CMM (Integrated Product Development CMM) 
\uf0b7 Objetiva integrar as dimensões: 
o Pessoas 
o Ferramentas 
o Procedimentos 
 
11 / 15 
 
Visão Geral \u2013 CMMI 
 
Nível 0 ou 1: Inicial 
\uf0b7 Utilização de processos informais (caóticos) 
\uf0b7 Sem capacidade de estimar custos e de cumprir todos os planos 
\uf0b7 Ferramentas não integradas com os processos, e não se aplicam 
uniformemente nos projetos 
\uf0b7 Codificação é a única fase dos processos de desenvolvimento que 
merece atenção 
\uf0b7 Engenharia de Requisitos e desenho fracos ou inexistentes 
\uf0b7 Mudanças de requisitos ou de outros artefatos ocorrem sem controle 
\uf0b7 Instalação e manutenção como atividades de pouca importância 
\uf0b7 Gerentes muitas vezes não entendem os verdadeiros problemas 
\uf0b7 Gerentes sem formação técnica apropriada 
\uf0b7 Processos seguidos apenas em fases tranquilas. 
o Em crise, codificação desenfreada! 
\uf0b7 Marketing oculta deficiências técnicas, além da pouca competição 
existente neste mercado 
\uf0b7 Apesar de ad hoc e caótico, o processo do nível 0 nas organizações 
12 / 15 
 
frequentemente desenvolve produtos utilizados. Porém, o sucesso 
depende da competência e heroísmo das pessoas e não pode ser 
repetida a menos que os mesmos indivíduos competentes sejam 
designados para o próximo projeto. 
\uf0b7 Capacidade é uma característica das pessoas, não das organizações. 
Nível 2: Gerenciado 
\uf0b7 Capaz de cumprir compromissos referentes a requisitos, prazos e 
custos com alta probabilidade de sucesso 
\uf0b7 A necessária disciplina do processo existe para repetir sucessos 
anteriores em projetos com aplicações similares 
\uf0b7 Disciplinada em nível de projeto, capaz de estimar e controlar projetos 
semelhantes com a experiência de projetos anteriores. Os gerente do 
projeto definem custos, cronogramas, funcionalidades e identificam os 
problemas nas reuniões da equipe quando eles aparecem (os 
problemas) 
\uf0b7 Os requerimentos e os produtos desenvolvidos para satisfazê-los são 
estabelecidos e sua integridade é controlada. Os padrões do projeto 
são definidos e a organização assegura que eles sejam fielmente 
seguidos 
\uf0b7 Para concluir com êxito o Nível 1, uma organização precisa ter políticas 
que ajudem os gerentes do projeto a estabelecer processos de 
gerenciamento apropriados. 
\uf0b7 Domínio das seguintes áreas chave: 
\u2022 A gestão de requisitos permite definição e controle dos requisitos em que se 
baseiam os compromissos 
\u2022 O planejamento de projetos prevê prazos e custos para cumprimento dos 
compromissos, com bases técnicas e não intuitivas 
\u2022 A supervisão e acompanhamento de projetos confere o atendimento dos 
compromissos, comparando o conseguido com o planejamento e acionando 
providências corretivas sempre que haja desvios significativos em relação aos 
compromissos 
\u2022 Existe um grupo de garantia de qualidade que confere o cumprimento dos 
compromissos, de forma independente em relação aos projetos 
\u2022 A gestão de configurações garante a consistência permanente dos resultados 
dos projetos, entre si e com os requisitos, ao longo do projeto, mesmo quando 
ocorrem alterações nos compromissos 
\u2022 A medição verifica o esforço realizado pela equipedo projeto. 
13 / 15 
 
\u2022 O gerenciamento de contrato com o fornecedor monitora as cláusulas 
contratuais envolvidas no processo. 
\uf0b7 Principais riscos: 
o Mudança de ferramentas e métodos, trazidas pela evolução de 
tecnologia 
o Mudança de tipos de produtos, causadas por variações dos 
mercados 
o Mudança de estrutura organizacional, causadas por diversos 
fatores da dinâmica das organizações 
Nível 3: Definido 
\uf0b7 A capacidade de processos é padrão e consistente porque a engenharia 
de software e o gerenciamento das atividades são estáveis e repetidas. 
Com isto, linhas de produto, custo, cronograma, e funcionalidade estão 
sob controle e a qualidade é traçada. 
\uf0b7 Estabelecimento de infraestrutura de processos que permita a 
adaptação a vários tipos de mudanças. 
\uf0b7 Sabem manter-se dentro dos processos mesmo em tempos de crise 
\uf0b7 Construção e manutenção de uma base de dados povoada com os 
dados colhidos dos projetos, usada para a sua gestão, mas não usada 
de forma sistemática para atingir metas quantitativas de desempenho. 
\uf0b7 Conhecimento dos processos basicamente qualitativo. 
Nível 3: Definido 
\uf0b7 Domínio das seguintes áreas chave: 
o Estabelecimento formal de um grupo de engenharia de 
processos de software responsável pelas atividades de 
desenvolvimento, melhoria e manutenção de processos de 
software 
o Estabelecimento de um processo padrão de software no nível 
da organização, a partir do qual devem ser derivados os 
processos definidos para os projetos 
o Estabelecimento de um programa de treinamento em processos 
de software, no nível da organização 
o Gestão integrada dos projetos, baseada nos processos definidos 
para os projetos, com o uso de procedimentos documentados 
para gestão de tamanho, esforço, prazos e riscos 
o Padronização no nível da organização dos métodos de 
engenharia de produtos de software abrangendo engenharia de 
14 / 15 
 
requisitos, testes, desenho, codificação e documentação de uso 
o Coordenação entre os grupos que participam de projetos de 
sistemas, no nível da organização 
o Coordenação de revisões técnicas, no nível da organização 
o ... 
Nível 4: Gerenciado Quantitativamente 
\uf0b7 Domínio de processos de forma quantitativa 
o Ex: Qual deve ser a fração de recursos (hardware, software ou 
peopleware) dos projetos destinada à garantia da qualidade, 
considerando o nível máximo de defeito que se quer admitir nos 
produtos? 
\uf0b7 Maior utilização e aperfeiçoamento da base de dados construída no 
Nível 3 
\uf0b7 Proficiente em coletar métricas e gerir a base de dados de processos 
Nível 4: Gerenciado Quantitativamente 
\uf0b7 Domínio das seguintes áreas chave: 
o A gestão quantitativa dos processos controla o desempenho dos 
processos usados pelos projetos 
o A gestão de qualidade de software promove o entendimento 
quantitativo da qualidade dos produtos de software, permitindo 
atingir metas quantitativas desejadas 
Nível 5: Em Otimização 
\uf0b7 Processos em melhoria contínua, sendo otimizados para as 
necessidades de cada momento 
\uf0b7 A equipe do projeto analisa defeitos, determina suas causas, avalia os 
processos, previnem contra tipos de defeitos com ocorrências 
periódicas e disseminam lições instruídas de outros projetos 
\uf0b7 Domínio das seguintes áreas chave: 
o Prevenção dos defeitos, através da identificação e remoção de 
suas causas. 
o Gestão de evolução tecnológica, com procedimentos 
sistemáticos de identificação, análise e introdução de tecnologia 
apropriada. 
o Uso dos dados de processo para gestão das mudanças de 
processos, colocando-os em melhoria contínua. 
 
15 / 15 
 
MPS.BR SW