Aula 02 - Processos de software
15 pág.

Aula 02 - Processos de software


DisciplinaGerência de Projetos de Software87 materiais563 seguidores
Pré-visualização2 páginas
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 
\uf0b7 Processos de Desenvolvimento 
o IRUP, XP, Scrum 
\uf0b7 Modelos de Capacidade 
o CMMI, MPS.BR 
\uf0b7 Sintomas de Imaturidade 
Processos de Desenvolvimento 
O que é processo? 
\uf0b7 \u201cUm 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\u201d (PAULA 
FILHO, 2001, p. 17) 
Processo de Desenvolvimento 
\uf0b7 Ciclo de vida 
\uf0b7 Fundamentação de várias atividades 
\uf0b7 Podem ser sequenciais 
o Uma etapa totalmente dependente do término da etapa anterior 
\uf0b7 Ou não sequenciais 
Ciclos de Vida 
\uf0b7 Codifica-Remenda 
 
Especificação 
(???) 
Produto 
 
 
 
 
 
 
 
 
2 / 15 
 
Ciclos de Vida 
\uf0b7 Cascata 
 
Ciclos de Vida 
\uf0b7 Cascata com Realimentação 
 
3 / 15 
 
Ciclos de Vida 
\uf0b7 Espiral 
 
Ciclos de Vida 
\uf0b7 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 
\uf0b7 Pedido do Usuário 
\uf0b7 Avaliação da Solicitação 
\uf0b7 Formalização da Solicitação 
2. Viabilização da Solicitação 
\uf0b7 Estudo do Problema 
\uf0b7 Disponibilidade de Recursos 
\uf0b7 Relação Custo/Benefício 
\uf0b7 Relatório Formal do \u201cEstudo de Viabilidade\u201d 
3. Proposta de Sistema 
\uf0b7 Planejamento do Projeto 
\uf0b7 Levantamento Preliminar 
\uf0b7 Análise dos Dados 
\uf0b7 Estratégia de Desenvolvimento 
\uf0b7 Definições gerais sobre as regras de negócio 
\uf0b7 Relatório Formal \u2013 Proposta do Sistema (* Pontos de Verificação - PV) 
\uf0b7 Apresentação da Proposta 
\uf0b7 Aprovação 
4. Projeto do Sistema 
\uf0b7 Avaliação da Proposta 
\uf0b7 Planejamento do Projeto (* PV) 
\uf0b7 Levantamento Detalhado 
\uf0b7 Análise dos Dados (* PV) 
\uf0b7 Procedimentos Especiais (recursos de Bando de Dados e Telecom, por 
ex.) (* PV) 
\uf0b7 Elaboração do Relatório Formal (* PV) 
\uf0b7 Apresentação do Projeto 
\uf0b7 Aprovação 
5. Desenvolvimento do Sistema 
\uf0b7 Revisão de Procedimento 
\uf0b7 Planejamento das Atividades (* PV) 
5 / 15 
 
\uf0b7 Consolidação da Estrutura de Dados (* PV) 
\uf0b7 Definição das rotinas de processamento 
\uf0b7 Programação 
\uf0b7 Elaboração dos Manuais Operacionais 
\uf0b7 Rotina de Conversão 
\uf0b7 Simulação (* PV) 
\uf0b7 Treinamento 
\uf0b7 Implantação (* PV) 
6. Manutenção do Sistema 
\uf0b7 Avaliação 
\uf0b7 Pedido de Alteração 
\uf0b7 Diagnóstico da Solicitação 
\uf0b7 Manutenção Preventiva 
\uf0b7 Manutenção Corretiva 
\uf0b7 Acréscimo de recursos 
Processos de Software 
\uf0b7 Desenvolvimento 
\uf0b7 Manutenção 
\uf0b7 Aquisição 
Processos Formais de Desenvolvimento 
\uf0b7 IRUP 
\uf0b7 Scrum 
\uf0b7 XP 
\uf0b7 Iconix 
\uf0b7 Fusion 
\uf0b7 Praxis 
\uf0b7 etc... 
IRUP \u2013 IBM Rational Unified Process 
\uf0b7 Idealização e marca registrada da Rational e posteriormente adquirido 
pela IBM 
\uf0b7 Guia para uso ideal da UML \u2013 Unified Modeling Language 
\uf0b7 Técnicas que enfatizam 
o Gerência de riscos 
o Modelagem de arquitetura de software 
IRUP \u2013 Fases 
6 / 15 
 
\uf0b7 Concepção 
o Os requisitos são identificados e avaliados 
o Pode-se fazer uso de prototipação, e ferramentas CASE 
\uf0b7 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 
\uf0b7 Construção 
o Codificação do produto final 
\uf0b7 Transição 
o Disponibilizar o sistema aos usuários 
IRUP \u2013 Tarefas das fases 
\uf0b7 Modelagem do Negócio 
o Avaliação dos requisitos do usuário 
o Modelo do ambiente de execução do cliente 
\uf0b7 Requisitos 
o Levantamento detalhado de todas as funcionalidades do sistema 
\uf0b7 Análise e Projeto 
o Conhecer detalhadamente a realidade do ambiente 
\uf0b7 Testes 
o Executados de maneira cíclica, à medida que um produto parcial 
fica pronto 
IRUP \u2013 Visão Geral 
 
7 / 15 
 
Scrum \u2013 Visão Geral 
 
Fonte: http://desenvolvimentoagil.com.br/scrum 
XP \u2013 Visão Geral 
 
Fonte: http://desenvolvimentoagil.com.br/xp 
E agora?! 
\uf0b7 Engenharia de Processos 
o Como trabalhar 
o Metodologia 
8 / 15 
 
\uf0b7 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 
\uf0b7 Projetos não definidos com clareza 
\uf0b7 Atividades de desenvolvimento disfarçadas de manutenção 
\uf0b7 Indefinição de responsabilidades no projeto 
\uf0b7 Clientes não sabem exatamente a quem se dirigir 
\uf0b7 Gerentes com dúvidas sobre o que cobrar de quem 
\uf0b7 Os usuários não recebem o treinamento necessário 
\uf0b7 Sem tempo para treinamento de pessoal 
\uf0b7 Avaliação dos treinamentos avaliados apenas com a satisfação dos 
treinandos 
\uf0b7 Sem planos claros de recrutamento, remuneração e avaliação do 
desempenho 
\uf0b7 Não existe boa comunicação entre as pessoas 
\uf0b7 Sem acesso a ferramentas compatíveis com o estado-da-arte da 
tecnologia 
\uf0b7 Uso de ferramentas que os usuários bem entendem 
\uf0b7 Escolha de ferramentas de forma política, sem considerar avaliações 
técnicas e necessidades de padronização 
\uf0b7 Procedimentos e padrões, quando existem, seguidos de forma 
burocrática 
\uf0b7 Processo oficial de documentação escrita 
\uf0b7 Rígido demais e dinâmico de menos 
\uf0b7 Processo real praticado diferente do processo oficial (mais relaxado, 
logicamente) 
\uf0b7 Gerente não leva a sério os processos 
\uf0b7 Crença em Mágicas 
\uf0b7 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 
\uf0b7 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 
\uf0b7 Compromissos 
\uf0b7 Forças Caóticas 
\uf0b7 Problemas de Comunicação 
\uf0b7 Problemas de Escala 
Alguns dos Problemas de Escala 
\uf0b7 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 
\uf0b7 Os programas têm a vida muito mais longa do que aquela que se 
imaginou inicialmente 
\uf0b7 Ausência de desenho torna os programas frágeis. Pequenos defeitos 
localizados podem ter consequências graves quanto ao funcionamento 
de um sistema 
\uf0b7 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 
\uf0b7 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 
\uf0b7 É muito difícil convencer os leigos em informática da gravidade ou 
mesmo da existência de problemas de Engenharia de Software 
\uf0b7 É difícil convencer alguns leigos em informática de eles são leigos em 
informática 
Tipos de erros 
\uf0b7 Relativos a Processos 
\uf0b7 Relativos a Pessoas 
\uf0b7 Relativos a Tecnologia 
Modelos de Capacidade 
\uf0b7 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 \u2013 Capability Matury Model Integration 
\uf0b7 Foi produzido pelo SEI (Software Engineering Institute) da Universidade 
Carnegie Mellon (CMU), em Pittsburgh, EUA, sendo a 1ª versão lançada