Baixe o app para aproveitar ainda mais
Prévia do material em texto
06/03/2012 1 Modelos Presctivos de Processos Modelo Comerciai Ferramentas de Modelagem de Processos de Software Modelos de Maturidade de Processos de Software 06/03/2012 2 • Um conjunto estruturado de atividades necessárias para desenvolver um sistema de software. • Existem vários processos de desenvolvimento de software diferentes mas a maioria envolve: � especificação – definição do quê o sistema deve fazer; � projeto e implementação – definição da organização do sistema e implementação do sistema; � validação – checagem de que o sistema faz o que o cliente deseja; � evolução – evolução em resposta a mudanças nas necessidades do cliente. • Um modelo de processo de desenvolvimento de software • É uma representação abstrata de um processo. • Ele apresenta uma descrição do processo de uma perspectiva geral. � Modelo e Processo de Software Processo de Sw: o que acontece na realidade Modelo de Processo de Sw: representação abstrata daquilo de como proceder ou do que ocorreu em um processo 06/03/2012 3 5 Atividades Problema Solução dados relatórios restrições procedimentos Software • Quando descrevemos processos, geralmente falamos sobre as atividades desses processos, tais como: • Especificação de modelo de dados, desenvolvimento de interface de usuário, etc. e a organização dessas atividades. • Descrições de processos também podem incluir: �Produtos, que são os resultados de uma atividade do processo; �Papéis, que refletem as responsabilidades das pessoas envolvidas no processo; �Pré e pós-condições �Declarações que devem ser verdadeiras antes e depois de uma atividade do processo ser executada, ou um produto ser produzido. 06/03/2012 4 Processo de Software Relatórios Ferramentas Pessoas Treinamentos Métricas/ Estimativas Contratos Custos Prazos Artefatos Recursos • Processos dirigidos a planos são processos em que todas as atividades do processo são planejadas com antecedência e o progresso é medido em relação a esse plano. • Nos processos ágeis o planejamento é incremental e é mais fácil modificar o processo para refletir alterações nos requisitos do cliente. • Na realidade, os processos mais práticos incluem elementos dos processos ágeis e dirigidos a planos. • Não existe processo de software certo ou errado. 06/03/2012 5 Processo de Software � Processos vem sendo propostos pela indústria, países e academia ◦ Análise Estruturada (Yourdon, Gane) ◦ Objectory (Jacobson) ◦ V-Model (Alemanha) ◦ Rational Unified Process - RUP ◦ XP - eXtreme Programming 06/03/2012 6 � Paradoxo: ◦ Para todos os programas construídos há a necessidade de se entender os requisitos e o processo de negócio do contratante ◦ Na grande maioria das situações não há documentação de como a organização de desenvolvimento de software vai agir para atender a requisição ◦ Se a organização não sabe como trabalha, como vai descrever soluções para terceiros? 12 Porque problemas no processo provavelmente geram defeitos no produto! Por que o foco está no processo? 06/03/2012 7 13 � Qualidade do processo ◦ Aumento da qualidade do produto ◦ Diminuição do retrabalho ◦ Maior produtividade ◦ Redução do tempo para atender o mercado ◦ Maior competitividade ◦ Maior precisão nas estimativas � Fases Genéricas do Processo de Sw ◦ Fase de Definição: o quêo quêo quêo quê � Engenheiro de Software tenta identificar: que informação deve ser processada, que função e desempenho são desejados, que comportamento deve ser esperado do sistema, que interfaces devem ser estabelecidas, quais restrições de projeto, quais critérios de validação � Os requisitos-chave do sistema e do software são identificados 06/03/2012 8 � Fases Genéricas do Processo de Sw ◦ Fase de Desenvolvimento: comocomocomocomo � Definição de como os dados devem ser estruturados, como a função deve ser implementada dentro da arquitetura do software, como os detalhes procedimentais devem ser implementados, como as interfaces devem ser caracterizadas, como o projeto deve ser traduzido em linguagem de programação, e como o teste deve ser realizado ◦ Fase de Manutenção: modificaçõesmodificaçõesmodificaçõesmodificações � Tipos: Corretiva, Adaptativa, Perfectiva e Preventiva � Evolução do desenvolvimento de software (Antigamente) ◦ Atividade solitária, onde o sucesso era determinado por bons analistas/programadores com domínio da tecnologia envolvida ◦ O cliente possuía pouco domínio da tecnologia envolvida ◦ O software desenvolvido normalmente estava relacionado com as atividades-meio do cliente � Exemplos: Folha de pagamento, Controle de Patrimônio ◦ Distribuição de dados e aplicações era limitada ao domínio físico de redes locais ◦ Desenvolvimento de software - “um tipo de Arte” 06/03/2012 9 � Evolução do desenvolvimento de software (Hoje) ◦ Grande quantidade e variedade de profissionais � Ex: Designers, DBA, Especialistas em web, Programação de sistemas distribuídos ◦ O cliente possui domínio acerca da tecnologia ◦ Software desenvolvido para atividades-fim � Aplicações críticas para o negócio do cliente � Exemplo: e-business ◦ Distribuição de dados e aplicações: Internet ◦ Desenvolvimento de software � Exigência de abordagem metodológica por parte do cliente � Empresas espalhadas em diferentes regiões � Evolução da Engenharia de Software ◦ Apesar de processos de software serem estudados e estarem disponíveis há bastante tempo, outros aspectos atraíam a atenção Notações Ferramentas CASE Desenvolvimento Baseado em Reutilização Processos de Software Te cn o lo g ia G er ên ci a A rq u it et u ra A rt ef at o 06/03/2012 10 � Crescente importância de métodos para avaliação da qualidade de software baseados no processo ◦ Capability Maturity Model (SEI-CMM) e SPICE (ISO) � Avalia uma organização segundo: � capacidade de produzir resultados planejados � maturidade, a qual indica o crescimento contínuo da capacidade; � Qualidade na definição do processo é um dos elementos-chave para que uma organização possa atingir melhores níveis de maturidade; 20 CaracterísticasCaracterísticasCaracterísticasCaracterísticas � Ad hoc - Improvisado � Fortemente dependente dos profissionais � Indisciplinado ConseqüênciasConseqüênciasConseqüênciasConseqüências •Pouca produtividade •Qualidade de difícil previsão •Alto custo de manutenção •Risco na adoção de novas tecnologias 06/03/2012 11 � Processo conhecido por todos � Apoio visível da alta administração � Auditagem da fidelidade ao processo � Medidas do produto e do processo � Adoção disciplinada de tecnologias 21 � Papéis e responsabilidades claramente definidos � Acompanhamento da qualidade do produto e da satisfação do cliente � Expectativas para custos, cronograma, funcionalidades e qualidade do produto são usualmente alcançadas 22 06/03/2012 12 Papéis e responsabilidades bem definidos Processo improvisado Existe base histórica Não existe base histórica A qualidade dos produtos e processos é monitorada Qualidade e funcionalidade do produto sacrificadas O processo pode ser atualizado Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu grupo Resolução de crises imediatas Organizações maduras Organizações imaturas Construir software consiste na aplicação de técnicas Construir software é “arte” 06/03/2012 13 Máquina de Processo desenvolvedores gerentes Domínio da Definição do Processo Domínio da Realização do Processo Domínio da Execução do Processo feedback Assistência e suporte à realização do processoModelos de processo Evolução [Dowson 91] � Formar um entendimento comum � Encontrar inconsistências, redundâncias e omissões � Encontrar e avaliar atividades propostas mais adequadas aos objetivos � Fazer um processo geral para uma situação particular na qual ele será utilizado � Benefícios da Execução e outras ferramentas 06/03/2012 14 27 � Atividades guarda-chuva: transversaistransversaistransversaistransversais às demais etapas ◦ Acompanhamento e controle do projeto de software ◦ Revisões técnicas formais ◦ Garantia de qualidade de software ◦ Gestão de configuração de software ◦ Preparação e produção de documentos ◦ Gestão de reutilização ◦ Medição ◦ Gestão de Risco 28 � Caracterização Estrutura comum de processoEstrutura comum de processoEstrutura comum de processoEstrutura comum de processo Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Conjuntos de TarefasConjuntos de TarefasConjuntos de TarefasConjuntos de Tarefas Atividades guardaAtividades guardaAtividades guardaAtividades guarda----chuvachuvachuvachuva 06/03/2012 15 29 � Estrutura Comum de Processo ◦ É estabelecida definindo um pequeno número de atividades que são aplicáveis a todos os projetos de software, independente de seu tamanho ou complexidade Estrutura comum de processo Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Conjuntos de Tarefas Atividades guarda-chuva 30 � Conjuntos de Tarefas ◦ Permite que as atividades da estrutura sejam adaptadas às características do projeto e às necessidades da equipe de projeto Estrutura comum de processo Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Conjuntos de Tarefas Atividades guarda-chuva 06/03/2012 16 31 � Atividades guarda- chuva ◦ Garantia de qualidade ◦ Gestão de configuração de software ◦ Medição Estrutura comum de processo Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Conjuntos de Tarefas Atividades guarda-chuva • Modelo Cascata – Modelo dirigido a planos. Fases de especificação e desenvolvimento separadas e distintas. • Desenvolvimento Incremental – Especificação, desenvolvimento e validação são intercaladas. Pode ser dirigido a planos ou ágil. • Engenharia de software orientada a reúso – O sistema é montado a partir de componentes já existentes. Pode ser dirigido a planos ou ágil. � Na realidade a maioria dos grandes sistemas são desenvolvidos usando um processo que incorpora elementos de todos esses modelos. 06/03/2012 17 � The waterfall model (Cascata) - Modelo Sequencial Linear ◦ Etapas separadas e distintas para especificação e desenvolvimento � Prototipagem � Modelo RAD � Desenvolvimento formal de sistemas ◦ Um modelo de sistema matemático é transformado ou orienta a implementação � Desenvolvimento orientado a reuso ◦ O sistema é construído a partir de componentes existentes � Processos baseados em Iteração ◦ Incremental ◦ Espiral 34 � O processo Cascata está associado às metodologias propostas nas décadas de 1970-1980 ◦ Notadamente as metodologias Estruturadas � Yourdon � Constantine � Chris Gane � Page-Jones 06/03/2012 18 • Existem fases identificadas e separadas no modelo cascata: �Análise e definição de requisitos � Projeto de sistema e software � Implementação e teste de unidade � Integração e teste de sistema �Operação e manutenção • O principal inconveniente do modelo cascata é a dificuldade de acomodação de mudanças depois que o processo já foi iniciado. Em princípio, uma fase precisa ser completada antes de se mover para a próxima fase. 06/03/2012 19 37 � Divisão inflexível do projeto em estágios distintos torna difícil responder às mudanças nos requisitos do cliente. ◦ O cliente precisa ter paciência � Poucos sistemas de negócio possuem requisitos estáveis. ◦ Dificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicas � Projetos reais raramente seguem o fluxo seqüencial � Apropriado quando os requisitos são bem entendidos e as mudanças durante o processo de projeto serão limitadas. ◦ Pode ser usado em trabalhos acadêmicos com etapas bem definidas de “levantamento bibliográfico” 38 � Cliente normalmente: ◦ Define um conjunto de objetivos gerais para o software ◦ Mas não identifica detalhadamente os requisitos de entrada, processamento ou saída 06/03/2012 20 39 listen to customer build/revise mock-up customer test-drives mock-up Ouvir o Cliente Construi ou revisar protótipo Mock-up é a simulação de um módulo funcionando Testes do módulo pelo Cliente 40 � Problemas: ◦ O cliente vê o que parecer ser uma versão executável do software � Ignora que o protótipo funciona de maneira precária ◦ O desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável 06/03/2012 21 41 � Desenvolvimento rápido de aplicação ◦ Incremental, com ciclo curto ◦ É uma adaptação “de alta velocidade” do modelo seqüencial linear, no qual a rapidez é obtida com componentes ◦ Fases � Modelagem do negócio � Modelagem dos dados � Modelagem do processo � Geração da aplicação � Teste e entrega 42 business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover business modeling data modeling process modeling application generation testing & turnover team #1 team #2 team #3 60 - 90 days 06/03/2012 22 43 � Principais desvantagens ◦ Nem todos os tipos de aplicação são apropriados para o RAD. � Se o sistema não puder ser adequadamente modularizado, a construção e seleção de componentes será problemática ◦ Não é adequado quando são enfrentados riscos técnicos elevados � Por exemplo, adoção profunda de uma nova tecnologia 44 � Para a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema ◦ Abordagem híbrida � Iteração ◦ repetir partes do processo à medida que os requisitos do sistema evoluem ◦ Por exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitos ◦ Cada ciclo desenvolve uma versão mais completa 06/03/2012 23 45 Sommerville:Sommerville:Sommerville:Sommerville: Descrição geralDescrição geralDescrição geralDescrição geral 46 � Modelo Incremental ◦ Combina Cascata com Prototipagem ◦ Cada seqüência produz um incremento ◦ Exemplo: Processador de Texto � 1o release: gestão básica de arquivos, edição e produção de documentos (núcleo do produto)(núcleo do produto)(núcleo do produto)(núcleo do produto) � 2o: capacidades mais sofisticadas de edição � 3o: verificação sintática e gramatical � 4o: capacidade avançada de disposição de página 06/03/2012 24 48 � Vantagens ◦ Os clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele. � O primeiro estágio deve satisfazer os requisitos mais importantes e, assim, o software pode ser imediatamente usado ◦ Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posteriores ◦ Existe um risco menor de fracasso completo do sistema ◦ Cada entrega é uma versão funcional do sistema 06/03/2012 25� O custo para acomodar mudanças nos requisitos do cliente é reduzido. � A quantidade de análise e documentação que precisa ser feita, a cada incremento, é bem menor do que o necessária no modelo cascata. � É mais fácil obter feedback do cliente sobre o trabalho de desenvolvimento que tem sido feito. � Os clientes podem comentar demonstrações do software e ver quanto foi implementado. � Possibilidade de mais rapidez na entrega e implantação de software útil para o cliente. � Os clientes podem usar e obter ganhos do software mais cedo do que é possível no processo cascata. 50 � Problemas ◦ Pode ser difícil mapear os requisitos para incrementos específicos ◦ É difícil identificar facilidades comuns que todos os incrementos exijam ◦ A estrutura do sistema tende a degradar conforme novos incrementos são adicionados � As mudanças regulares tendem a corromper a estrutura do sistema � A incorporação posterior de mudanças no software se torna progressivamente mais difícil e cara 06/03/2012 26 51 � Espiral ◦ Proposto Boehm (1988) ◦ O processo é representado como uma espiral, onde cada loop representa uma fase do processo. ◦ O Processo Espiral é similar ao Incremental mas: � Cada ciclo produz algo a ser avaliado não necessariamente código � Gerência de Riscos embutida no processso � Ao final de cada loop é perguntado “Devemos continuar?” • Cada loop na espiral representa uma fase do processo. • Não existem fases fixas como especificação ou projeto • Os loops na espiral são escolhidos de acordo com a necessidade. • Os riscos são avaliados explicitamente e resolvidos no decorrer do processo. 06/03/2012 27 53 � Visão geral do processo O modelo de processo de software espiral de Boehm 06/03/2012 28 • Definição de objetivos �São identificados os objetivos específicos para cada fase. • Avaliação e redução de riscos �Os riscos são avaliados e atividades executadas para reduzir os principais riscos. • Desenvolvimento e validação �Um modelo de desenvolvimento para o sistema é escolhido, pode ser qualquer um dos modelos genéricos. • Planejamento �O projeto é revisto e a próxima fase da espiral é planejada. 56 � Baseado na transformação de uma especificação matemática através de refinamentos sucessivos até um programa executável � Transformações devem “preservar a correção”, isto é, permitem mostrar que o programa está de acordo com a sua especificação � Exemplo mais conhecido: Cleanroom (IBM) ◦ Incremental, onde para cada estágio é demonstrada a correção em relação ao anterior 06/03/2012 29 57 Definição dos Requisitos Especificação Formal Desenvolvimento a Partir da Especificação Teste de Sistema e Integrãção 58 � Problemas ◦ Demanda pessoal especializado ◦ Dificuldade em especificar formalmente alguns aspectos de sistemas � Interface com usuário � Aplicação ◦ Sistemas críticos onde segurança e/ou confiabilidade devem ser garantidas antes mesmo que o sistema entre em operação 06/03/2012 30 59 � Baseia-se na reutilização sistemática onde sistemas são integrados a partir de ◦ Componentes existentes � (in-house) ◦ Componentes de prateleira � [COTS (Commercial-off-the-shelf)] – Software de Prateleira � Estágios do processo: ◦ Análise de componentes; ◦ Modificação de requisitos; ◦ Projeto de sistema com reúso; ◦ Desenvolvimento e integração. Atualmente, o reúso é a abordagem padrão para a construção de vários tipos de sistemas de negócio. 06/03/2012 31 � É um processo genérico moderno, derivado da UML e outros processos associados. � Reúne aspectos dos 3 modelos genéricos discutidos previamente. � Geralmente descrito por 3 perspectivas: ◦ Uma perspectiva dinâmica que mostra fases no tempo; ◦ Uma perspectiva estática que mostra atividades do processo; ◦ Uma perspectiva prática que sugere boas práticas. 06/03/2012 32 • Concepção �Estabelece o business case para o sistema. • Elaboração �Desenvolve um entendimento da extensão do problema e da arquitetura do sistema. • Construção �Projeta o sistema, programa e testa o sistema. • Transição � Implanta o sistema no seu ambiente de operação. Iteração do RUPIteração do RUP • Iteração Intra-fase �Cada fase é iterativa aos resultados desenvolvidos incrementalmente • Iteração Inter-fase �Como mostrado pelo loop no modelo RUP, o conjunto todo de fases pode ser executado incrementalmente. 06/03/2012 33 06/03/2012 34 • Desenvolve software iterativamente � Planeja incrementos baseando-se nas prioridades do cliente e entregar as de prioridade mais alta primeiro. • Gerencia os requisitos � Documenta explicitamente os requisitos do cliente e manter registros de mudanças desses requisitos. • Usa arquiteturas baseadas em componentes � Organiza a arquitetura do sistema como um conjunto de componentes reusáveis. • Modela o processo visualmente � Usa modelos gráficos da UML para representar visões dinâmicas e estáticas do processo e software. • Verifica a qualidade do software � Garante que o software atenda aos padrões de qualidade organizacional. • Controla as mudanças do software � Gerencia as mudanças no software usando um sistema de gerenciamento de mudanças e ferramentas de gerenciamento de configuração. 06/03/2012 35 � Divulgação de processo a ser adotado pela empresa � Repositório com modelos de artefatos � Alguns permitem a edição pelo usuário final � Vantagem: ◦ Fácil adoção � Desvantagem: ◦ Não há garantia que será usado na empresa 69 70 06/03/2012 36 � Divulgação eletrônica do modelo de processo da Rational � Artefatos padronizados � Visões personalizadas � Capacidade de Adaptação do Processo ◦ RUP Builder 71 72 06/03/2012 37 73 74 06/03/2012 38 Software Process Elicitation, Analysis, Reviw and Modeling in an Integrated Environment 76 06/03/2012 39 77 78 06/03/2012 40 79 80 06/03/2012 41 06/03/2012 42 06/03/2012 43 86 06/03/2012 44 06/03/2012 45 06/03/2012 46 06/03/2012 47 94 06/03/2012 48 �Origens ◦Edital FINEP/Software Livre 2003 � Parceria com SERPRO-Belém ◦Programa de P&D Eletronorte 2004 � Laboratório Central 95 06/03/2012 49 97 98 06/03/2012 50 99 Versão PRO Versão Software Livre Versão de Pesquisa (usada internamente e com parceiros) � Elementos do processo ◦ Atividades ◦ Artefatos ◦ Agentes e Grupos ◦ Ferramentas e Recursos ◦ Políticas 10 0 06/03/2012 51 10 1 � Elementos a destacar ◦ Definição do Planejamento de Atividade ◦ Perfil de Recursos Humanos ◦ Gestão de configuração de software 10 2 06/03/2012 52 10 3 10 4 06/03/2012 53 10 5 Perfil de Recursos Humanos 10 6 Perfil de Recursos Humanos 06/03/2012 54 10 7 Plano de Recursos Humanos Processo: Cadastro_Online_Calouros Atividade do Processo Papel Agente Analisar os Requisitos Líder de Projeto Thiago Rubeni Apresentar Avaliação do Projeto e Lições Aprendidas Líder de Projeto Thiago Rubeni Atualizar a Matriz de Rastreabilidade Analista de Requisitos Elaine Gleyce Mira de Figueiredo Analista de Requisitos Elaine Gleyce Mira de Figueiredo Analista de Requisitos Elaine Gleyce Mira de Figueiredo Líder de Projeto Thiago Rubeni Analista de Requisitos Thiago Rubeni Avaliar Final Coordenador da Equipe de Implementaçãoadmin Avaliar Plano do Projeto Líder de Projeto Thiago Rubeni Avaliar Plano do Projeto e Gerar Relatório de Monitoramento Líder de Projeto Thiago Rubeni Líder de Projeto Thiago Rubeni Líderde Projeto Thiago Rubeni Avaliar Requisitos Líder de Projeto Thiago Rubeni Analista de Requisitos Elaine Gleyce Mira de Figueiredo Avaliar Viabilidade do Projeto Líder de Projeto Thiago Rubeni 10 8 Plano de Custos Processo: Cadastro_Online_Calouros Recursos Descrição Quantidade Custo Unitário Custo Total Recursos Humanos Papel Descrição Horas Trabalhadas Elaine Gleyce Mira de Figueiredo Gerente de Requisitos 10,00 Thiago Rubeni Líder de Projeto 13,00 Thiago Rubeni Gerente de Requisitos 25,00 Vanderlene Covre Rocha Implementador de Processo 39,00 Process: Processo SIGDCT Atividade número de dias início fim número de envolvidos MARCO CAMINHO CRÍTICO Planejamento <D> 0 0 Planejamento do Projeto <D> 0 0 Configurar Ambiente 2 24/06/2008 25/06/2008 1 Elaborar Proposta Tecnica 1 24/06/2008 24/06/2008 1 Elicitar Requisitos Iniciais <D> 0 0 Elaborar Lista de Requisitos 3 24/06/2008 26/06/2008 1 * Avaliacao da Lista de Requisitos 2 27/06/2008 28/06/2008 1 Aceitacao dos Requisitos pelo Cliente 1 29/06/2008 29/06/2008 1 * Realizar Estimativas 1 30/06/2008 30/06/2008 TODOS * Planejar o Projeto 2 30/06/2008 01/07/2008 1 * Avaliacao e Comprometimento com o Plano <D> 0 0 Avaliar a Viabilidade do Projeto 1 02/07/2008 02/07/2008 1 Obter Comprometimento com o Plano do Projeto 1 02/07/2008 02/07/2008 TODOS * Analise dos Requisitos <D> 0 0 Analisar Requisitos <D> 0 0 Especificar Requisitos 2 02/07/2008 03/07/2008 1 * Criar Matriz de Rastreabilidade 103/07/2008 03/07/2008 1 * Avaliar Especificacao de Requisitos 1 04/07/2008 04/07/2008 1 Revisar o Plano do Projeto - MARCO 104/07/2008 04/07/2008 TODOS MARCO Projeto e Arquitetura do Software <D> 0 0 Definir Projeto de Arquitetura <D> 0 0 Especificar Arquitetura 1 07/07/2008 07/07/2008 2 * Atualizar Matriz de Rastreabilidade 107/07/2008 07/07/2008 1 * Definir Projeto do Software <D> 0 0 Elaborar Modelo de Analise e Projeto 1 08/07/2008 08/07/2008 2 * Gerenciar Requisitos (atividade continua) <D> 0 0 Gerenciar Mudanças de Requisitos 3 07/07/2008 09/07/2008 1 Atualizar a Matriz de Rastreabilidade 109/07/2008 09/07/2008 1 Cronograma: 06/03/2012 55 10 9 Lucia Lucia Costa 1 Analyst Paulo Paulo Silva 3 Analyst Ana Ana Maria 5 Analyst Lucia Lucia Costa 1 Analyst Paulo Paulo Silva 3 Analyst Ana Ana Maria 5 Analyst 06/03/2012 56 INICIAL REPETÍVEL Organizações Disciplinadas DEFINIDO Organizações Padronizadas GERENCIADO Organizações Previsíveis OTIMIZADO Organizações com Melhoria Contínua Organizações Caóticas Software Engineering Institute-SEI 112 � Processo de desenvolvimento caótico; � Falta de integração; � Sucesso dos projetos se deve a esforços heróicos; � Diante de uma crise, a organização abandona os procedimentos definidos e reverte à codificação e testes. Chega desse negócio de projeto!Chega desse negócio de projeto!Chega desse negócio de projeto!Chega desse negócio de projeto! Estamos atrasados!Estamos atrasados!Estamos atrasados!Estamos atrasados! Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!!Vamos COMEÇAR A PROGRAMAR!!! 06/03/2012 57 113 � Gerência do projeto, segurança do produto e controle de mudanças já estabelecidos; � A organização cumpre seus prazos e orçamentos; � Sucesso através de administração de projetos básica, convencional; � Se o gerente de projetos deixar essa organização, os projetos poderão “cair por terra”. 114 � Estabelecimento de um Grupo de Processo de Engenharia de Software responsável por: ◦ focalizar e cobrir os esforços de melhoria do processo; ◦ manter a gerência informada do estado desses esforços ◦ facilitar a introdução de métodos e técnicas de engenharia de software. � O processo foi codificado e institucionalizado � Existe um processo formal definido que todos seguem � Constante possibilidade de melhoria do processo; � Falta de avaliação da eficiência 06/03/2012 58 115 � Conjunto de métricas de qualidade e produtividade foi estabelecido; � Banco de dados do processo com análises de recursos e experiências disponíveis para consulta; � Ênfase na coleta de métricas para melhorar a qualidade tanto do processo quanto do produto 116 � A organização possui Know-how para identificar seus elementos de processo mais fracos e reforçá- los; � Disponibilidade de dados para justificativa da aplicação da tecnologia; � A gerência preocupa-se com a melhoria do processo ao invés de com os reparos nos produtos; � Análise rigorosa da causa dos defeitos e prevenção de falhas. 06/03/2012 59 Nível CMM Foco Áreas-chave de processo Inicial Pessoas competentes e heróis Repetível Processos de gerenciamento de projetos - Gerenciamento de requisitos - Planejamento do projeto - Visão geral e acompanhamento do projeto - Gerenciamento de subcontratados - Garantia da qualidade do software - Gerenciamento de configuração Definido Processos de engenharia e apoio - Definição do processo organização - Programa de treinamento - Gerenciamento de software integrado - Engenharia de produto de software - Coordenação intergrupos - Revisão conjunta Gerenciado Qualidade do produto e do processo - Gerenciamento quantitativo dos processos - Gerenciamento da qualidade de software Otimizado Melhoramento contínuo do processo - Prevenção de defeitos - Gerenciamento de mudanças tecnológicas - Gerenciamento de mudanças no processo 118Evolução da maturidade 06/03/2012 60 “Melhoria de processosprocessosprocessosprocessos de software nas micromicromicromicro, pequenaspequenaspequenaspequenas e médiasmédiasmédiasmédias empresas, a um custo acessível, em diversos locais do país.” www.softex.br/mpsbr ISO/IEC 12207 Definição de Processos Propósitos e Resultados ISO/IEC 15504 Definição da Capacidade de Processos Requisitos de Avaliação CMMI Complementação de Processos 06/03/2012 61 12 1 Gerenciado Gerenciado Gerenciado Gerenciado QuantitativamentQuantitativamentQuantitativamentQuantitativament e e e e Parcialmente Parcialmente Parcialmente Parcialmente GerenciadoGerenciadoGerenciadoGerenciado GerenciadoGerenciadoGerenciadoGerenciado Parcialmente Parcialmente Parcialmente Parcialmente Definido Definido Definido Definido Largamente Largamente Largamente Largamente Definido Definido Definido Definido Definido Definido Definido Definido Em Otimização Em Otimização Em Otimização Em Otimização 121 MediçãoMediçãoMediçãoMedição ---- MEDMEDMEDMED //// GerênciaGerênciaGerênciaGerência dededede ConfiguraçãoConfiguraçãoConfiguraçãoConfiguração ---- GCOGCOGCOGCO AquisiçãoAquisiçãoAquisiçãoAquisição ---- AQUAQUAQUAQU //// GarantiaGarantiaGarantiaGarantia dadadada QualidadeQualidadeQualidadeQualidade ---- GQAGQAGQAGQA GerênciaGerênciaGerênciaGerência dededede PortfólioPortfólioPortfólioPortfólio dededede ProjetosProjetosProjetosProjetos ---- GPPGPPGPPGPP AvaliaçãoAvaliaçãoAvaliaçãoAvaliação eeee MelhoriaMelhoriaMelhoriaMelhoria dodododo ProcessoProcessoProcessoProcesso OrganizacionalOrganizacionalOrganizacionalOrganizacional ---- AMPAMPAMPAMP DefiniçãoDefiniçãoDefiniçãoDefinição dodododo ProcessoProcessoProcessoProcesso OrganizacionalOrganizacionalOrganizacionalOrganizacional ---- DFPDFPDFPDFP GerênciaGerênciaGerênciaGerência dededede ReutilizaçãoReutilizaçãoReutilizaçãoReutilização ---- GRUGRUGRUGRU GerênciaGerênciaGerênciaGerência dededede RecursosRecursosRecursosRecursos HumanosHumanosHumanosHumanos ---- GRHGRHGRHGRH GerênciaGerênciaGerênciaGerência dededede ProjetosProjetosProjetosProjetos ---- GPRGPRGPRGPR (evolução)(evolução)(evolução)(evolução) DesenvolvimentoDesenvolvimentoDesenvolvimentoDesenvolvimentodededede RequisitosRequisitosRequisitosRequisitos ---- DREDREDREDRE ProjetoProjetoProjetoProjeto eeee ConstruçãoConstruçãoConstruçãoConstrução dodododo ProdutoProdutoProdutoProduto ---- PCPPCPPCPPCP IntegraçãoIntegraçãoIntegraçãoIntegração dodododo ProdutoProdutoProdutoProduto ---- ITPITPITPITP VerificaçãoVerificaçãoVerificaçãoVerificação ---- VERVERVERVER //// ValidaçãoValidaçãoValidaçãoValidação ---- VALVALVALVAL GerênciaGerênciaGerênciaGerência dededede DecisõesDecisõesDecisõesDecisões ---- GDEGDEGDEGDE DesenvolvimentoDesenvolvimentoDesenvolvimentoDesenvolvimento paraparaparapara ReutilizaçãoReutilizaçãoReutilizaçãoReutilização ---- DRUDRUDRUDRU GerênciaGerênciaGerênciaGerência dededede RiscosRiscosRiscosRiscos ---- GRIGRIGRIGRI GGGG FFFF EEEE DDDD CCCC Gerência de Requisitos Gerência de Requisitos Gerência de Requisitos Gerência de Requisitos ---- GREGREGREGRE Gerência de ProjetosGerência de ProjetosGerência de ProjetosGerência de Projetos ---- GPRGPRGPRGPR AAAA BBBB Gerência de ProjetosGerência de ProjetosGerência de ProjetosGerência de Projetos ---- GPR (evolução)GPR (evolução)GPR (evolução)GPR (evolução) (sem processo específico)(sem processo específico)(sem processo específico)(sem processo específico) 12 2 06/03/2012 62 � www.softex.br/mpsbr 12 3 124 Referências: Básicas � ISO/IEC 12207:2008 e ISO/IEC 15504 Complementar � CMMI Objetivo: Descrever de forma detalhada o Modelo de Referência para Melhoria do Processo de Software (MR-MPS) e contém algumas definições comuns aos diversos documentos do MPS.BR Público alvo: Instituições interessadas em aplicar o MR-MPS para melhoria de seus processos de software e Instituições implementadoras e avaliadoras segundo o MR-MPS 06/03/2012 63 12 5 Níveis de maturidade Capacidade Resultado Processo Propósito Resultado Atributo 126 � Atributos de Processo (AP) ◦ AP 1.1: O processo é executado ◦ AP 2.1: O processo é gerenciado ◦ AP 2.2: Os produtos de trabalho do processo são gerenciados ◦ AP 3.1: O processo é definido ◦ AP 3.2: O processo está implementado ◦ AP 4.1: O processo é medido ◦ AP 4.2: O processo é controlado ◦ AP 5.1: O processo é objeto de melhorias e inovações ◦ AP 5.2: O processo é otimizado continuamente 06/03/2012 64 12 7 Processos MPS.BR nível G Fonte: Riosoft/Paulo Santos 2009 128 Nível Processos Capacidade G Gerência de Projetos GPR 1; GPR2; GPR 3; GPR 4 (até F); GPR 5; GPR 6; GPR 7; GPR 8; GPR 9; GPR 10; GPR 11; GPR12; GPR 13; GPR 14; GPR 15; GPR 16 e GPR 17 AP1.1 e AP2.1: RAP 1 RAP 2 RAP 3 RAP 4 (G) RAP 5 (até F) RAP 6 (até F) RAP 7 (até F) RAP 8 RAP 9 (até F) RAP 10 (G) Gerência de Requisitos GRE 1; GRE 2; GRE 3; GRE 4 e GRE 5 06/03/2012 65 � 1) Defina processo de software � 2) Defina modelo de processo de software � 3) Quais são as características de um processo maduro e de um processo imaturo � 4) Quais são os tipos de modelos presctivos � 5) Defina cada modelo presctivo � 6) Apresente exemplos de ferramentas de modelagem de processo de software 06/03/2012 66 � 7) Defina CMM e MPS.BR � 8) Quais são as fases de cada modelo de melhoria de processo apresentado 132 Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR)Gerência de Projetos (GPR) PropósitoPropósitoPropósitoPropósito O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade. 06/03/2012 67 133 Resultados esperados GPR 1. O escopo do trabalho para o projeto é definido; GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados; GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos; 134 Resultados esperados GPR 4. (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas; GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos; 06/03/2012 68 135 Resultados esperados GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados; GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo; 136 Resultados esperados GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados; GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança; 06/03/2012 69 137 Resultados esperados GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos; GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados; GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido; 138 Resultados esperados GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados; GPR 14. O envolvimento das partes interessadas no projeto é gerenciado; GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento; 06/03/2012 70 139 Resultados esperados GPR 16. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas; GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão; 140 Gerência de Requisitos (GRE)Gerência de Requisitos (GRE)Gerência de Requisitos (GRE)Gerência de Requisitos (GRE) PropósitoPropósitoPropósitoPropósito O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. 06/03/2012 71 141 Resultados esperados GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; 142 Resultados esperados GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. 06/03/2012 72 143 Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu Medida do quanto o processo atinge o seu propósitopropósitopropósitopropósito Resultado esperado do Atributo do Processo RAP 1. O processo atinge seus resultados definidos * RAP – Resultado do Atributo de Processo144 Medida do quanto a execução do processo é Medida do quanto a execução do processo é Medida do quanto a execução do processo é Medida do quanto a execução do processo é gerenciadagerenciadagerenciadagerenciada Resultados esperados do Atributo do Processo RAP 2. Existe uma política organizacional estabelecida e mantida para o processo RAP 3. A execução do processo é planejada RAP 4. (Para o Nível G) . A execução do processo é monitorada e ajustes são realizados Processo de Processo de gerência de projetos/proces so de gerência de requisitos 06/03/2012 73 145 Resultados esperados do Atributo do Processo RAP 5. (Até o Nível F) As informações e os recursos necessários para a execução do processo são identificados e disponibilizados RAP 6. (Até o Nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas RAP 7. (Até o Nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência Resultados esperados do Atributo do Processo RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento RAP 9. (Até o Nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização RAP 10. (Para o Nível G) O processo planejado para o projeto é executado
Compartilhar