Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof. Marcelo Otone Aguiar professor@marceloaguiar.pro.br www.marceloaguiar.pro.br -Visãogeraldoprocessodedesenvolvimentodesoftware Ociclodevidadesoftware; Etapasdeumprocessodesoftware; Modelosdeprocessodesoftware; 2 Conteúdo Programático C.H. Prevista 6horas 1
O CICLO DE VIDA DE SOFTWARE E ETAPAS DE UM 3 PROCESSO DE SOFTWARE Metodologias x Processo x Ciclo de Vida 4 Processo Ciclo de Vida Metodologia Projeto 2
5 Ciclo de Vida Fonte: Adaptado de PMBOK (2008) Ciclo de Vida do Projeto 6 Fonte: Adaptado de PMBOK (2008) 3
7 Ciclo de Vida Cascata Modelo Preditivo 8 Ciclo de Vida Iterativo Modelo Preditivo Ou Adaptativo 4
9 MODELOS DE PROCESSO DE SOFTWARE CMM, 10 CMMI E MPS.BR 5
CMM (Capability Maturity Model for Software) É um modelo de capacitação de processo patrocinado pelo departamento de defesa dos EUA para avaliação de capacidade dos seus fornecedores de software Tem foco nos processos para obter melhoria no curto prazo Determina cinco níveis para avaliar a maturidade da empresa no processo de de software 11desenvolvimento CMM (Capability Maturity Model for disciplinadosprocessos Software) Inicial Nível Gerenciado Nível Definido Nível Quantitativa Gerenciado Nível Otimizado Nível Processos Ad-hoc padronizadosquantitativamente Controlados Processos Medidos e continuamente Melhorados Processos 12 6
CMM (Capability Maturity Model for Software) Cada nível, com exceção do primeiro, é composto de várias áreas chave de processo (key process areas, KPAs) Cada KPA identifica um grupo de atividades correlatas que realizam um conjunto de metas As KPAs de um nível identificam objetivos que devem ser cumpridos Os objetivos são cumulativos, ou seja, uma empresa que atinja o nível 5 satisfaz todas 13as KPAs dos níveis anteriores CMMI (Capability Maturity Model Integration) O CMMI integra o modelo CMM e outros modelos para: gestão de recursos humanos (P-CMM), aquisição de software (SA-CMM) e engenharia de sistemas (SE-CMM) O objetivo do CMMI é servir de guia para a melhoria de processos na organização e também da habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de 14produtos ou serviços 7
Disciplinas do CMMI CMMI Engenharia Sistemasde Engenharia Softwarede Desenvolvimento Integrado Produto Processo e do Aquisição Fontes de 15 Estrutura 1 Área de processo 1 Específicos Objetivos Específicas Práticas do CMMI Nível de maturidade 2 Área de processo n Genéricos Objetivos Nível de maturidade 5 Compromisso Execuçãocom Habilidade Características Execuçãopara Implementação Direção Comuns da Verificação Implementação da... 16 Genéricas Práticas 8
17 Gerência Planejamentodo Gerência e controle de requisitos projeto do projeto Garantia Gerência de Medição acordos e análise com fornecedores Desenvolvimento daqualidade Gerência de configuração processo e produto Integração Solução técnica do de produto requisitos Foco Verificação Treinamento no processo Validação organizacional Nível velde Áreas Maturidade 2 de Processo Nível de Maturidade 3 Nível velde Áreas Maturidade 3 de Análise Gerência Gerência Processo de de decisão projetointegrada riscos e resolução Desempenhodo Definição organizacional Nível de Maturidade 45 Inovação Gerência processoorganizacional Análisee e implementação quantitativa resolução na de do organização causas projeto 18 9
MPS.BR: Melhoria de Processo de Software Brasileiro Foi criado por pesquisadores brasileiros O seu foco é em pequenas e médias empresas Empresas que possuem poucos recursos, mas precisam fazê-lo O 19 modelo propõe a engenharia de software de forma adequada ao contexto brasileiro MPS.BR: Melhoria de Processo de Software Brasileiro O modelo baseia-se em três guias: Guia geral: contém a descrição geral do MPS.BR e detalha o modelo de referência (MR-MPS) Guia de aquisição: contém recomendações para a condução de compras de software e serviços correlatos 20 Guia de avaliação: contém a descrição do processo de avaliação, os requisitos para o avaliador e para a avaliação, o método e os formulários para guiar a avaliação 10
MPS.BR: Melhoria de Processo de Software Brasileiro Outras características são: Sete níveis de maturidade, o que possibilita uma implantação mais gradual e adequada a pequenas empresas Compatibilidade plena com o CMMI e a norma ISSO/IEC 15504 Custo acessível 21 Avaliação bienal das empresas Forte interação Universidade-Empresa MPS.BR: Melhoria de Processo de Software Brasileiro 22 11
Inovação Níveis de maturidade Desempenho o e implantação na organização e Processo Gerência Análise de Causas Resolução Análise do quantitativa processo organizacional do projeto A Desenvolvimento Gerência de decisão riscos e resolução B Integraçãode de requisitos C Instalação Solução técnica Liberaçãode Verificação produto 23 Validação D Avaliação Treinamento Níveis de maturidade e Processo Adaptação Definição e do melhoria do processo do processo organizacional organizacional Gerência processo Medição para gerência de projeto E de configuração Gerência Aquisição de de requisitos projeto F G 24 12
NORMAS 25 ISO ISO/IEC 15504 A versão inicial foi publicada em 1998 e se baseou no projeto SPICE A versão de 1998 tratava exclusivamente de software A versão atual apresenta várias mudanças: É internacional É composta de cinco partes 26 É genérica (não é exclusiva a software) Introduziu o conceito de modelo de referência de processo 13
ISO/IEC 15504 1: 2: 3: conceitos e vocabulário 4: estrutura (framework) do processo de determinação recomendações de capacidade para realização melhoria de de processos uma avaliação e 27 5: contém um exemplo de aplicação Para ser aplicada a software, a norma deve ser complementada pela ISO/IEC 12207 e, mais especificamente pelas extensões AMD1 e AMD2 A norma é dividida da seguinte forma: Nível Níveis de Capacitação da 0 Nome Descrição 1 Incompleto Executado ISO/IEC O processo essencialmente forma não éimplementadoou pouco objetivosfalha em atingir seus 15504 planejada atinge os ou objetivos, rigorosamesmo de 32 Gerenciado O monitorado processo éimplementadode e ajustado); produtos forma controlada por ele criados (planejado, são 4 EstabelecidoO Previsível processo O processo controlados éimplementado éexecutado e mantidos e de existe forma de um sistemáticae forma controle apropriada que consistente permite 5 verificar se ele se para encontra atingir dentrodos os resultados limites estabelecidos 28Otimizado O processo eficiente,atingir éadaptado os continuamente objetivos projetados para, negócio de uma definidos forma mais e 14
ISO/IEC 12207: Processos de ciclo de vida Esta norma não define objetivos, níveis de maturidade organizacional ou de capacidade de processo Provê uma estrutura para que uma organização defina os seus processos Um dos propósitos é definir um linguajar comum em meio ao grande número de métodos, técnicas, modelos e normas que da qualidade 29tratam ISO/IEC 12207: Processos de ciclo de vida A ISO/IEC 12207 cobre todo o ciclo de vida, de requisitos até a manutenção e retirada de uso de um produto, além de outros processos associados, como aquisição de componentes Cobre a garantia da qualidade, de produtos e processos Ela não define um ciclo de vida, foi concebida como um modelo, algo como uma meta de ciclo de vida, a partir do qual cada organização deve definir os seus próprios 30processos 15
ISO/IEC 12207: Processos de ciclo de vida Os processos são classificados em três categorias: Primários: rios: são os processos básicos que se relacionam aos produtos de software. De apoio: os processos dessa categoria tem lugar, em geral, depois que um processo primário é iniciado. Exemplos são revisões, auditorias e soluções de problemas Organizacionais: são os processos que dizem 31 respeito à operação da organização em si, tais como gerência e treinamentos. ISO/IEC 12207: Processos de Fornecimento Aquisição Primários rios De apoio Organizacionais ciclo Gerência Documentação de Gerenciamento de configuração vida Desenvolvimento Garantia de qualidade Infraestrutura Manutenção Operação Verificação Melhoramentos Revisão Validação conjunta Treinamento Solução Auditoria de problemas 32 16
METODOLOGIAS 33 ÁGEIS Metodologias Ágeis São adequadas em situações em que a mudança de requisitos é frequente Neste caso, a metodologia deve aceitar a mudança em vez de tentar prever o futuro São também adequadas quando a complexidade é alta e os requisitos 34 desconhecidos 17
35 Metodologias Ágeis Requisitos e Análise ProjetoCodificaçãoTesteImplantação Metodologias Ágeis Metodologias Clássicas Metodologias Ágeis Em geral tem desenvolvimento iterativo e incremental A comunicação é muito importante Há a redução de produtos intermediários como documentação extensiva Enfatiza-se a colaboração do cliente ao invés de negociação de contratos Respostas rápidas a mudanças em vez de seguir 36planos 18
Extreme Programming (XP) É aplicável a equipes pequenas e médias Útil quando os requisitos são vagos e há muita mudança O feedback deve ser constante, a abordagem é incremental e a comunicação é encorajada As suas práticas não trazem sucesso se aplicadas isoladamente, apenas em conjunto Enfatiza-se também a implementação de código 37simples e enxuto Extreme Programming (XP) Outro ponto importante é fazer apenas o necessário A XP baseia-se em 12 práticas: Planejamento: decidir o que é necessário fazer e o que pode ser adiado, prazos, estimativas e o processo Entregas frequentes: construir um software simples, atualizado à medida que novos requisitos 38 surgem e devem ser entregues versões a cada mês Metáfora: são as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento 19
Extreme Programming (XP) Projeto simples: o programa deve ser o mais simples o possível e satisfazer aos requisitos atuais, sem se preocupar com requisitos futuros Testes: validação do projeto durante todo o processo. Os programadores desenvolvem o software criando primeiramente os casos de testes Programação o em pares: a implementação do código é feita em dupla, um desenvolvedor implementa 39 enquanto o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando estrategicamente em como melhorar o código Refatora Refatoração:focaliza o aperfeiçoamento do projeto do Extreme Propriedade software e estápresente em todo o desenvolvimento. Deve Programming (XP) todos ser feita os membros sempre coletiva:o que equipe. for código possível Qualquer do simplificar projeto membro pertence da sem equipe perda a Integra que código, percebe desde a necessidade que realize pode a bateria adicionar de testes valor necessária ao sistema Deve Integração contínua: nua:uma vez testado e validado, o todos existir os produzido e membros este, uma por máquina por sua uma vez, de equipe integração também deve deve ser de ser integrado livre testado. acesso ao a 40 20
Extreme Programming (XP) Trabalho semanal de 40 horas: sem horas extras constantes. Se há a necessidade de por uma segunda semana fazer horas extras então o planejamento está errado Cliente presente: participação do cliente durante todo o desenvolvimento. Disponibilidade para sanar dúvidas. 41 Código digo-padr padrão: adoção de regras de escrita de código Scrum O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente de constante mudança Equipes pequenas (até 10 pessoas) Requisitos instáveis 42 Iterações curtas (sprints de até 30 dias) Reuniões de acompanhamento diárias 21
Scrum As reuniões devem ter curta duração (em torno de 15 minutos) O ciclo de vida é baseado em três fases principais: Pré-planejamento (pre pre-game phase): os requisitos são descritos em um documento chamado backlog, depois são ordenados pro prioridade e é feita a estimativa de esforço 43 Scrum Desenvolvimento (game phase): o software é desenvolvido em ciclos (sprints). Cada ciclo é desenvolvido de forma tradicional, ou seja, primeiro análise, depois projeto, em seguida implementação e testes. Os riscos identificados no planejamento são observados e controlados. A duração é entre 1 semana e 1 mês 44 Pós-planejamento (post post-game phase): fazemse a integração do software, os testes finais a documentação do usuário. É feita a demonstração para o cliente. 22
Desvantagens Codifica-remenda A informalidade nos requisitos pode não ser bem vista pelos clientes A refatoração do código pode ser vista como amadorismo e incompetência Programadores que não se adaptam com trabalho em equipe podem não se adaptar 45 Não se adapta bem em equipes geograficamente dispersas Não se adapta bem em equipes grandes -SistemasdeInformaçãonaeradigital Ossistemasdeinformaçãoempresariaisnasua carreira;próximo Conteúdo 46 C.H. Prevista 6horas 23