Aula 02 - Processos de software

Prévia do material em texto

1 / 15 
 
Gerência de Projetos de Software 
Prof. Ítalo Flexa Di Paolo, Me. Eng. 
Universidade do Estado do Pará (UEPA) 
Processos de Software 
 
Roteiro 
 Processos de Desenvolvimento 
o IRUP, XP, Scrum 
 Modelos de Capacidade 
o CMMI, MPS.BR 
 Sintomas de Imaturidade 
Processos de Desenvolvimento 
O que é processo? 
 “Um conjunto de passos parcialmente ordenados, constituídos por 
atividades, métodos, práticas e transformações, usado para atingir uma 
meta [que está] geralmente associada a um ou mais resultados 
concretos finais, que são os produtos da execução do processo” (PAULA 
FILHO, 2001, p. 17) 
Processo de Desenvolvimento 
 Ciclo de vida 
 Fundamentação de várias atividades 
 Podem ser sequenciais 
o Uma etapa totalmente dependente do término da etapa anterior 
 Ou não sequenciais 
Ciclos de Vida 
 Codifica-Remenda 
 
Especificação 
(???) 
Produto 
 
 
 
 
 
 
 
 
2 / 15 
 
Ciclos de Vida 
 Cascata 
 
Ciclos de Vida 
 Cascata com Realimentação 
 
3 / 15 
 
Ciclos de Vida 
 Espiral 
 
Ciclos de Vida 
 Prototipagem Evolutiva 
 
Fases Genéricas de Qualquer Processo de 
Desenvolvimento* 
1. Solicitação do Usuário 
2. Viabilização da Solicitação 
3. Proposta do Sistema 
4 / 15 
 
4. Projeto do Sistema 
5. Desenvolvimento do Sistema 
6. Manutenção do Sistema 
(OLIVEIRA, 1997) 
1. Solicitação do Usuário 
 Pedido do Usuário 
 Avaliação da Solicitação 
 Formalização da Solicitação 
2. Viabilização da Solicitação 
 Estudo do Problema 
 Disponibilidade de Recursos 
 Relação Custo/Benefício 
 Relatório Formal do “Estudo de Viabilidade” 
3. Proposta de Sistema 
 Planejamento do Projeto 
 Levantamento Preliminar 
 Análise dos Dados 
 Estratégia de Desenvolvimento 
 Definições gerais sobre as regras de negócio 
 Relatório Formal – Proposta do Sistema (* Pontos de Verificação - PV) 
 Apresentação da Proposta 
 Aprovação 
4. Projeto do Sistema 
 Avaliação da Proposta 
 Planejamento do Projeto (* PV) 
 Levantamento Detalhado 
 Análise dos Dados (* PV) 
 Procedimentos Especiais (recursos de Bando de Dados e Telecom, por 
ex.) (* PV) 
 Elaboração do Relatório Formal (* PV) 
 Apresentação do Projeto 
 Aprovação 
5. Desenvolvimento do Sistema 
 Revisão de Procedimento 
 Planejamento das Atividades (* PV) 
5 / 15 
 
 Consolidação da Estrutura de Dados (* PV) 
 Definição das rotinas de processamento 
 Programação 
 Elaboração dos Manuais Operacionais 
 Rotina de Conversão 
 Simulação (* PV) 
 Treinamento 
 Implantação (* PV) 
6. Manutenção do Sistema 
 Avaliação 
 Pedido de Alteração 
 Diagnóstico da Solicitação 
 Manutenção Preventiva 
 Manutenção Corretiva 
 Acréscimo de recursos 
Processos de Software 
 Desenvolvimento 
 Manutenção 
 Aquisição 
Processos Formais de Desenvolvimento 
 IRUP 
 Scrum 
 XP 
 Iconix 
 Fusion 
 Praxis 
 etc... 
IRUP – IBM Rational Unified Process 
 Idealização e marca registrada da Rational e posteriormente adquirido 
pela IBM 
 Guia para uso ideal da UML – Unified Modeling Language 
 Técnicas que enfatizam 
o Gerência de riscos 
o Modelagem de arquitetura de software 
IRUP – Fases 
6 / 15 
 
 Concepção 
o Os requisitos são identificados e avaliados 
o Pode-se fazer uso de prototipação, e ferramentas CASE 
 Elaboração 
o Inicia-se a identificação e a avaliação dos riscos 
o Modelo que permita avaliar o negócio como um todo 
 Construção 
o Codificação do produto final 
 Transição 
o Disponibilizar o sistema aos usuários 
IRUP – Tarefas das fases 
 Modelagem do Negócio 
o Avaliação dos requisitos do usuário 
o Modelo do ambiente de execução do cliente 
 Requisitos 
o Levantamento detalhado de todas as funcionalidades do sistema 
 Análise e Projeto 
o Conhecer detalhadamente a realidade do ambiente 
 Testes 
o Executados de maneira cíclica, à medida que um produto parcial 
fica pronto 
IRUP – Visão Geral 
 
7 / 15 
 
Scrum – Visão Geral 
 
Fonte: http://desenvolvimentoagil.com.br/scrum 
XP – Visão Geral 
 
Fonte: http://desenvolvimentoagil.com.br/xp 
E agora?! 
 Engenharia de Processos 
o Como trabalhar 
o Metodologia 
8 / 15 
 
 Maturidade 
o Métricas para aferir maturidade de pessoas e da equipe 
o Definição de parâmetros a serem alcançados para fazer com que 
a equipe melhore 
o Melhoria de Processos 
o Evolução 
Sintomas de Imaturidade 
 Projetos não definidos com clareza 
 Atividades de desenvolvimento disfarçadas de manutenção 
 Indefinição de responsabilidades no projeto 
 Clientes não sabem exatamente a quem se dirigir 
 Gerentes com dúvidas sobre o que cobrar de quem 
 Os usuários não recebem o treinamento necessário 
 Sem tempo para treinamento de pessoal 
 Avaliação dos treinamentos avaliados apenas com a satisfação dos 
treinandos 
 Sem planos claros de recrutamento, remuneração e avaliação do 
desempenho 
 Não existe boa comunicação entre as pessoas 
 Sem acesso a ferramentas compatíveis com o estado-da-arte da 
tecnologia 
 Uso de ferramentas que os usuários bem entendem 
 Escolha de ferramentas de forma política, sem considerar avaliações 
técnicas e necessidades de padronização 
 Procedimentos e padrões, quando existem, seguidos de forma 
burocrática 
 Processo oficial de documentação escrita 
 Rígido demais e dinâmico de menos 
 Processo real praticado diferente do processo oficial (mais relaxado, 
logicamente) 
 Gerente não leva a sério os processos 
 Crença em Mágicas 
 Gurus 
o são considerados infalíveis 
o aceitam compromissos cada vez maiores, até não darem conta 
o não escrevem nada 
9 / 15 
 
o um dia a casa cai 
 Heróis 
o usam processos informais que não são transferíveis 
o até certo ponto, suprem com esforço a falta de técnicas e de 
organização 
o dificilmente são substituíveis 
o tendem a ser sobrecarregados até seu limite 
Prejuízos da Imaturidade 
 Compromissos 
 Forças Caóticas 
 Problemas de Comunicação 
 Problemas de Escala 
Alguns dos Problemas de Escala 
 Falta de documentação adequada do código dificulta a localização dos 
defeitos, principalmente quando os codificadores não estão mais 
disponíveis 
 Os programas têm a vida muito mais longa do que aquela que se 
imaginou inicialmente 
 Ausência de desenho torna os programas frágeis. Pequenos defeitos 
localizados podem ter consequências graves quanto ao funcionamento 
de um sistema 
 Mesmo pequenos sistemas têm enorme complexidade. Cada linha de 
código é como se fosse uma peça móvel de um mecanismo: pode 
abrigar um defeito fatal para o sistema 
 Além de seus próprios defeitos, um aplicativo pode falhar por causa de 
defeitos de dados, de ambiente de operação e até de hardware 
 É muito difícil convencer os leigos em informática da gravidade ou 
mesmo da existência de problemas de Engenharia de Software 
 É difícil convencer alguns leigos em informática de eles são leigos em 
informática 
Tipos de erros 
 Relativos a Processos 
 Relativos a Pessoas 
 Relativos a Tecnologia 
Modelos de Capacidade 
 Referência para as organizações para sua própria avaliação e 
10 / 15 
 
capacitação 
o SW-CMM, CMMI-SW, Trillium, ISO-9000-3 (Software) 
o MPS.BR SW e SV (Software e Serviços) 
o P-CMM (Recursos Humanos) 
o SE-CMM (Engenharia de Sistemas) 
o SA-CMM (Aquisição de Software) 
o IPD-CMM (Definição de Produtos) 
CMMI – Capability Matury Model Integration 
 Foi produzido pelo SEI (Software Engineering Institute) da Universidade 
Carnegie Mellon (CMU), em Pittsburgh, EUA, sendo a 1ª versão lançadaem agosto de 1991 
 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. 
 Origem na década de 1980 com a necessidade do departamento de 
defesa dos EUA em avaliar a aquisição de produtos de software. 
 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) 
 Objetiva integrar as dimensões: 
o Pessoas 
o Ferramentas 
o Procedimentos 
 
11 / 15 
 
Visão Geral – CMMI 
 
Nível 0 ou 1: Inicial 
 Utilização de processos informais (caóticos) 
 Sem capacidade de estimar custos e de cumprir todos os planos 
 Ferramentas não integradas com os processos, e não se aplicam 
uniformemente nos projetos 
 Codificação é a única fase dos processos de desenvolvimento que 
merece atenção 
 Engenharia de Requisitos e desenho fracos ou inexistentes 
 Mudanças de requisitos ou de outros artefatos ocorrem sem controle 
 Instalação e manutenção como atividades de pouca importância 
 Gerentes muitas vezes não entendem os verdadeiros problemas 
 Gerentes sem formação técnica apropriada 
 Processos seguidos apenas em fases tranquilas. 
o Em crise, codificação desenfreada! 
 Marketing oculta deficiências técnicas, além da pouca competição 
existente neste mercado 
 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. 
 Capacidade é uma característica das pessoas, não das organizações. 
Nível 2: Gerenciado 
 Capaz de cumprir compromissos referentes a requisitos, prazos e 
custos com alta probabilidade de sucesso 
 A necessária disciplina do processo existe para repetir sucessos 
anteriores em projetos com aplicações similares 
 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) 
 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 
 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. 
 Domínio das seguintes áreas chave: 
• A gestão de requisitos permite definição e controle dos requisitos em que se 
baseiam os compromissos 
• O planejamento de projetos prevê prazos e custos para cumprimento dos 
compromissos, com bases técnicas e não intuitivas 
• 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 
• Existe um grupo de garantia de qualidade que confere o cumprimento dos 
compromissos, de forma independente em relação aos projetos 
• 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 
• A medição verifica o esforço realizado pela equipedo projeto. 
13 / 15 
 
• O gerenciamento de contrato com o fornecedor monitora as cláusulas 
contratuais envolvidas no processo. 
 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 
 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. 
 Estabelecimento de infraestrutura de processos que permita a 
adaptação a vários tipos de mudanças. 
 Sabem manter-se dentro dos processos mesmo em tempos de crise 
 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. 
 Conhecimento dos processos basicamente qualitativo. 
Nível 3: Definido 
 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 
 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? 
 Maior utilização e aperfeiçoamento da base de dados construída no 
Nível 3 
 Proficiente em coletar métricas e gerir a base de dados de processos 
Nível 4: Gerenciado Quantitativamente 
 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 
 Processos em melhoria contínua, sendo otimizados para as 
necessidades de cada momento 
 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 
 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