- Centro de Ciências Exatas, Naturais e de Saúde Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução aos Sistemas de Informação COM06852 - Introdução aos SI Prof. Marcelo Otone Aguiar marcelo.aguiar@ufes.br www.marceloaguiar.pro.br
- - Visão geral do processo de desenvolvimento de software O ciclo de vida de software; Etapas de um processo de software; Modelos de processo de software; 2 Conteúdo Programático C.H. Prevista 6 horas
- O CICLO DE VIDA DE SOFTWARE E ETAPAS DE 3 UM PROCESSO DE SOFTWARE
4 Metodologias x Processo x Ciclo de Process o Vida Ciclo de Vida Projeto Metodologia
5 Ciclo de Vida Fonte: Adaptado de PMBOK (2008)
6 Ciclo de Vida do Projeto Fonte: Adaptado de PMBOK (2008)
7 Ciclo de Vida Cascata Modelo Preditivo
8 Ciclo de Vida Iterativo Modelo Preditivo Ou Adaptativo
- MODELOS DE PROCESSO 9 DE SOFTWARE
CMM, CMMI E MPS.BR 10
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 11 desenvolvimento de software
CMM (Capability Maturity Model for Processos Ad-hoc Nível Inicial 12 Processos disciplinados Nível Gerenciado Software) Processos padronizados Nível Definido Processos Medidos e Controlados quantitativamente Nível Gerenciado Quantitativa mente Processos Melhorados continuamente Nível Otimizado
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 as KPAs 13 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 14 da habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços
Engenharia de Sistemas 15 Disciplinas do CMMI Engenharia de Software CMMI Desenvolvimento Integrado do Produto e do Processo Fontes de Aquisição
Nível de maturidade 1 Nível de maturidade 2 Nível de maturidade 5 16... Estrutura do CMMI Área de processo 1 Área de processo n Compromisso com Execução Objetivos Específicos Objetivos Genéricos Características Comuns Habilidade para Execução Direção da Implementação Práticas Genéricas Práticas Específicas Verificação da Implementação
17 Áreas de Processo Nível de Maturidade 2 Nível de Maturidade 3 Gerência de requisitos Planejamento do projeto Gerência e controle do projeto Gerência de acordos com fornecedores Medição e análise Garantia da qualidade do processo e do produto Gerência de configuração Desenvolvimento de requisitos Solução técnica Integração do produto Verificação Validação Foco no processo organizacional Treinamento organizacional
18 Áreas de Processo Nível de Maturidade 3 Nível de Maturidade 4 Nível de Maturidade 5 Gerência de projeto integrada Gerência de riscos Análise de decisão e resolução Desempenho do processo organizacional Definição do processo organizacional Desempenho do processo organizacional Gerência quantitativa do projeto Inovação e implementação na organização Análise e resolução de causas
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 modelo propõe a engenharia de software de forma adequada ao contexto brasileiro 19
MPS.BR: Melhoria de Processo de Software Brasileiro O modelo baseia-se em três guias: 20 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 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
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 Avaliação bienal das empresas Forte interação Universidade-Empresa 21
MPS.BR: Melhoria de Processo de 22 Software Brasileiro
23 Níveis de maturidade e Processo A B C D Inovação e implantação na organização Análise de Causas e Resolução Desempenho do processo organizacional Gerência quantitativa do projeto Análise de decisão e resolução Gerência de riscos Desenvolvimento de requisitos Solução técnica Integração de produto Instalação de produto Liberação de produto Verificação Validação
24 Níveis de maturidade e Processo E F G Treinamento Avaliação e melhoria do processo organizacional Definição do processo organizacional Adaptação do processo para gerência de projeto Medição Gerência de configuração Aquisição Gerência de requisitos Gerência de projeto
NORMAS ISO 25
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: 26 É internacional É composta de cinco partes É genérica (não é exclusiva a software) Introduziu o conceito de modelo de referência de processo
ISO/IEC 15504 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: 27 1: conceitos e vocabulário 2: estrutura (framework) do processo de avaliação 3: recomendações para realização de uma avaliação 4: recomendações para melhoria de processos e determinação de capacidade 5: contém um exemplo de aplicação
Níveis de Capacitação da ISO/IEC 15504 Nível Nome Descrição 0 Incompleto 1 Executado 2 Gerenciado O processo não é implementado ou falha em atingir seus objetivos O processo essencialmente atinge os objetivos, mesmo se de forma pouco planejada ou rigorosa O processo é implementado de forma controlada (planejado, monitorado e ajustado); os produtos por ele criados são controlados e mantidos de forma apropriada 3 Estabelecido O processo é implementado de forma sistemática e consistente 4 Previsível 5 Otimizado 28 O processo é executado e existe um controle que permite verificar se ele se encontra dentro dos limites estabelecidos para atingir os resultados O processo é adaptado continuamente para, de uma forma mais eficiente, atingir os objetivos de negócio definidos e projetados
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 29 métodos, técnicas, modelos e normas que tratam da qualidade
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, 30 a partir do qual cada organização deve definir os seus próprios processos
ISO/IEC 12207: Processos de ciclo de vida Os processos são classificados em três categorias: Primá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 respeito à operação da organização em si, tais como gerência e treinamentos. 31
ISO/IEC 12207: Processos de 32 ciclo de vida Primários De apoio Organizacionais Aquisição Documentação Gerenciamento Fornecimento Gerência de configuração Infraestrutura Desenvolvimento Garantia de qualidade Melhoramentos Operação Verificação Treinamento Manutenção Validação Revisão conjunta Auditoria Solução de problemas
METODOLOGIAS ÁGEIS 33
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
35 Metodologias Ágeis Requisitos e Análise Projeto Codificação Teste Implantaçã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 planos 36
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 simples e enxuto 37
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 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 38
Extreme Programming (XP) 39 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 em pares: a implementação do código é feita em dupla, um desenvolvedor implementa 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
Extreme Programming (XP) 40 Refatoração: focaliza o aperfeiçoamento do projeto do software e está presente em todo o desenvolvimento. Deve ser feita sempre que for possível simplificar sem perda Propriedade coletiva: o código do projeto pertence a todos os membros da equipe. Qualquer membro da equipe que percebe a necessidade pode adicionar valor ao código, desde que realize a bateria de testes necessária Integração contínua: uma vez testado e validado, o código produzido por uma equipe deve ser integrado ao sistema e este, por sua vez, também deve ser testado. Deve existir uma máquina de integração de livre acesso a todos os membros
Extreme Programming (XP) 41 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. Código-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 Iterações curtas (sprints de até 30 dias) Reuniões de acompanhamento diárias 42
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-game phase): os requisitos são descritos em um documento 43 chamado backlog, depois são ordenados pro prioridade e é feita a estimativa de esforço
44 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 Pós-planejamento (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.
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 Não se adapta bem em equipes geograficamente dispersas Não se adapta bem em equipes grandes 45
- - Pensamento Sistêmico Conceitos de sistemas; Elementos de um sistema; Natureza dos sistemas; Propriedades e classificação de sistemas; Aplicação do pensamento Sistêmico na área de computação; 46 Próximo Conteúdo C.H. Prevista 6 horas