Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1

Tamanho: px
Começar a partir da página:

Download "Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1"

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1 1

2 UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE SISTEMAS DE INFORMAÇÃO Implantação do MPS.BR Nível G Thais Oliveira Bergmann Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação Florianópolis - SC 2008/1 2

3 Thais Oliveira Bergmann Implantação do MPS.BR Nível G Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof, Roberto C. S. Pacheco Banca examinadora: Professor José Salm Jr. Professor Nikolai Dimitri 3

4 Dedicatória Dedico este trabalho aos meus pais, in memoriam. 4

5 Agradecimentos Agradeço ao Marcos pela compreensão e paciência, à minha família e a todos que estiveram de alguma forma presentes e me apoiaram nesta caminhada. Agradeço também à Ilog Tecnologia, empresa onde este trabalho foi desenvolvido e ao professor João Bosco da Motta Alves, pelas conversas orientadoras no começo do curso. 5

6 LISTA DE FIGURAS Figura 1 - Estrutura da Norma ISO/IEC Figura 2 - Modelo de Ciclo de Vida em Cascata...20 Figura 3 - Modelo de Ciclo de Vida Incremental...21 Figura 4 - Modelo de Ciclo de Vida Iterativo...22 Figura 5 - Modelo de Ciclo de Vida em Espiral...23 Figura 6 - Modelo de Ciclo de Vida Espiral...24 Figura 7 - Modelo V...25 Figure 8 Níveis de Classificação dos Processos ISO/IEC Figura 9 - Estrutura da norma ISO/IEC Figura 10 - Estrutura da Documentação do MPS.BR...34 Figura 11 - Organograma Ilog Fonte Ilog...43 Figura 12 - Processo de Fornecimento...48 Figura 13 - Template Checklist Aceitação de Requisitos...53 Figura 14 - Template para Estimativas de Esforço...54 Figura 15 - Processo de Planejamento de Projeto...56 Figura 16 - Template para Plano de Gerência de Dados...57 Figura 17 - Template para Plano de Comunicação Organizacional...58 Figura 18 - Template para Descrição de Papéis...65 Figura 19 - Template para Mapa de Habilidades e Competências...65 Figura 20 - Template para Ata de Reunião de Comprometimento...67 Figura 21 - Processo de Gerência de Mudança de Requisitos...69 Figura 22 - Template para Requisição de Mudança de Requisitos...72 Figura 23 - Processo de Monitoração de Projetos...75 Figura 24 - Estrutura de Dados de Desenvolvimento de Processo...81 Figura 25 - Relatório de Alocação de Recursos...82

7 Lista de Tabelas Tabela 1 Vantagens de desvantagens dos modelos de ciclo de vida...26 Tabela 2 - Comparação entre níveis de maturidade e níveis capacidade...30 Tabela 3 - Comparação entre níveis de maturidade CMMI e MPS.BR Tabela 4 - Estrutura de processos e níveis do MPS.BR

8 Lista de Reduções MPS.BR Melhoria de Processo do Software Brasileiro CMMI - Capability Maturity Model Integration SEI Software Engineering Institute AP Atributo de Processo RAP Resultados de Atributo de Processo GRE Resultado Esperado para o Processo de Gerência de Requisitos GPR Resultado Esperado para o Processo de Gerência de Projetos EAD Ensino a Distância ACATE Associação Catarinense de Empresas de Tecnologia PERT - Program Evaluation and Review Technique WBS - Work Breakdown Structure ISO International Organization for Standardization 8

9 Sumário 1 Introdução Apresentação Objetivo Geral Objetivos Específicos Motivação Justificativa Organização deste documento Engenharia de Software O que é software Crise do Software ISO/IEC Processos do Ciclo de Vida do Software Processo Fundamental Processo Organizacional Processo de Apoio Modelos de Ciclo de Vida Modelo de Ciclo de Vida Cascata Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3] Modelos de Ciclo de Vida Evolucionário Modelos de Ciclo de Vida V Vantagens e Desvantagens dos Modelos de Ciclo de Vida Padrões de Qualidade de Processo de Software ISO/IEC Avaliação do Processo de Software CMMI [10] Abordagem Contínua MPS.BR Melhoria de Processo do Software Brasileiro Guias e Documentação MPS.BR Conceitos Importantes no MPS.BR Níveis de Maturidade no MPS.BR Processo Estrutura de Processos e Níveis do MPS.BR Implantação do MPS.BR na Ilog Tecnologia Ilog Tecnologia Atividades para Implantação do MPS.BR Primeira Atividade - Conscientização

10 4.2.2 Segunda Atividade Diagnosticação da Situação Atual Terceira Atividade Treinamento Quarta Atividade Mapeamento dos Processos Quinta Atividade Detalhamento dos Processos Mapeados Sexta Atividade Treinamento do Processo Organizacional Sétima Atividade Avaliação Interna nos Projetos da Empresa Oitava Atividade Simulados Preparação para Avaliação Oficial Descrição dos Processos Processo de Fornecimento Planejamento do Projeto Encerrar o Projeto Gerência de Mudanças de Requisitos Monitoração do Projeto Atributos de Processo Avaliação Ferramentas Utilizadas Eclipse Process Framework EPF JExpChannel SVN Pacote Microsoft Office Enterprise Architect Conclusões Trabalhos Futuros

11 Resumo Este trabalho relata a implantação do MPS.BR nível G na empresa Ilog Tecnologia. Além disso, revisa os principais conceitos de engenharia de software e padrões de qualidade de processo de software como a ISO/IEC 15504, CMMI e MPS.BR. Abstract This document describes the deployment of MPS.BR level G at Ilog Technology company. Moreover, it reviews the main concepts about software engineering and quality standard of software process as ISO/IEC 15504, CMMI and MPS.BR. E palavras-chave: ISO/IEC 12207, ISO/IEC 15504, MPS.BR, CMMI, Engenharia de Software e Melhoria de Software. 11

12 1 Introdução 1.1 Apresentação O desenvolvimento de software está entre as mais promissoras atividades realizadas em Santa Catarina. Estimam-se 1500 empresas de Tecnologia em Santa Catarina, cujo faturamento é de 1 bilhão de reais 1. Nesse contexto pode ser percebida a importância de se ter um processo de desenvolvimento de software para que a produção seja potencializada no estado e conseqüentemente no país. Dentre os principais fatores limitadores do crescimento das empresas de desenvolvimento de software está o caos em que essas operam, na maioria das vezes. Freqüentemente essas empresas até tem processos informais de desenvolvimento que são abandonados sempre que ocorre algum problema como, por exemplo, atraso no cronograma ou mudança de prioridade do projeto na empresa. Para esse contexto foi criado o MPS.BR, que é o programa de melhoria de processos de software. O MPS.BR é mais adequado a realidade brasileira se comparada ao CMMI por exemplo. Uma vez que é dividido em sete níveis, equivalentes ao CMMI, porém mais adequado a realidade das empresas de micro e pequeno porte, que podem implantar o modelo em etapas menores. Além disso, o MPS.BR custa em torno de quatro vezes menos que a certificação CMMI. O MPS.BR é coordenado pela Associação para Promoção da Excelência do Software Brasileiro, a Softex, que vem realizando esforços para obter o reconhecimento internacional do MPS.BR como garantia de qualidade, uma vez que é um modelo equivalente ao CMMI. 1.2 Objetivo Geral Implantar o MPS.BR nível G na empresa Ilog Tecnologia. 1.3 Objetivos Específicos Estudar o MPS.BR; Mapear os processos necessários para a implantação do MPS.BR nível G; 1 Mercado Brasileiro de Software - Panorama e Tendências - Abes

13 Institucionalizar, ou seja, descrever e implantar, os processos de gerência de projetos e gerência de requisitos, requeridos para obter o nível G do MPS.BR; Realizar simulados de avaliação do MPS.BR; Obter o nível G do MPS.BR; 1.4 Motivação A falta de metodologia para desenvolvimento de software é certamente o principal fator de fracasso nos projetos de desenvolvimento de software em pequenas e micro empresas. Na maioria das vezes, o projeto tem um dono na empresa, que diz o que deve ser feito. Porém se o dono do projeto for substituído o projeto será executado de uma forma diferente. A execução das atividades dos projetos acontece de forma caótica, com o cronograma apertado, muitas vezes impossível para ser mantido mas que foi imposto pelo cliente. Freqüentemente o software resultante desses projetos tem baixa qualidade, difícil manutenção e nenhuma documentação. A motivação é mostrar que é possível uma micro empresa seguir uma metodologia de desenvolvimento de software, que produza um produto com qualidade levando em conta as características de uma micro empresa. 1.5 Justificativa Haja vista o imenso potencial brasileiro no mercado de software, produzir um produto com qualidade e com preços acessíveis são características imprescindíveis para manter-se competitivo neste mercado. Estas características: qualidade e competitividade podem ser obtidas desde que a empresa adote uma metodologia de desenvolvimento de software que a permita detectar oportunidades de melhorias e pontos fortes do seu processo. A razão para adotar uma metodologia conhecida como o CMMI ou MPS.BR é que essas metodologias já se mostraram eficientes, o que reduz o tempo de implantação de um processo para desenvolvimento de software. Além da qualidade e competitividade, seguir uma metodologia conhecida é um diferencial competitivo em relação a empresas que seguem metodologias próprias, que não são conhecidas ou que não tem metodologias/processos. 13

14 1.6 Organização deste documento Este trabalho está organizado em 5 capítulos. O primeiro capítulo traz a introdução ao conteúdo a ser apresentado neste documento, como a apresentação do tema, o objetivo geral, os objetivos específicos, motivação e justificativa. O segundo capítulo traz informações sobre a Engenharia de Software e Ciclo de Vida do Software, assuntos introdutórios para melhor entendimento dos demais temas abordados neste documento. O terceiro capítulo discorre sobre os principais padrões de qualidade para processo de desenvolvimento de software. No quarto é relatado como ocorreu a implantação do MPS.BR na Ilog Tecnologia. O quinto capítulo traz as conclusões obtidas a partir deste trabalho assim como os trabalhos futuros. 2 Engenharia de Software 2.1 O que é software Software é: (1) Instruções (programas de computador) que quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que permitem que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e ouso dos programas. Pressman, Segundo Pressman, para entender o que é software é necessário que sejam verificadas as características que o difere de outros produtos criados pelo homem. O software como sendo o resultado de um sistema lógico, não toma forma física quando pronto como é o caso do hardware, por exemplo. As principais características que diferem o software dos demais produtos são as seguintes: O software é desenvolvido por engenharia: Assim como os demais produtos manufaturados, o software precisa ser projetado. A diferença está na forma de construção deste uma vez que não é físico não é trivial saber exatamente o que se tem pronto ou quanto ainda falta para finalizá-lo. Enfim, uma das grandes dificuldades na construção do software é para obter as métricas do projeto. O software não se desgasta: Diferente dos demais produtos produzidos pelo homem, o software não desgasta com o passar do tempo. Porém, ainda segundo Pressman, o software deteriora, pois ao longo da vida o software sofre modificações que são como pontos de inserção de defeitos, o 14

15 que ao passar do tempo aumenta o número de falhas que o software poderá apresentar. A maioria dos softwares é feita sob medida: Na maioria das vezes a construção de um software parte do zero, ou seja, não existem componentes que simplesmente combinados formam o software. 2.2 Crise do Software No início dos anos 80 a crise do software atraiu a atenção das empresas e governo americano. Nessa época o congresso americano verificou o impacto que a tecnologia tinha sobre a economia americana e na competitividade global dos Estados Unidos. O congresso verificou que o impacto da desordem vivida na época seria desastroso uma vez que a tecnologia dava forma ao futuro. A conclusão foi de que a melhor forma de se ter um futuro em ordem seria organizar o presente. A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos, isso se tornou um problema pequeno e agora que temos computadores gigantescos, programar tornou-se um problema gigantesco. Edsger Dijkstra na sua apresentação The Humble Programmer, Em 1984, o congresso americano fundou uma organização chamada Software Engineering Instituite (SEI), com uma equipe formada pelos mais importantes centros de pesquisa sobre o assunto nos EUA. Essa equipe ficou hospedada na Universidade Carnegie- Mellon em Pittsburgh. O objetivo do SEI é trabalhar para estabelecer normas e metodologias no campo de desenvolvimento de software para ajudar a América a manter a competitividade frente aos esforços tecnológicos no mundo. O SEI cumpriria esse objetivo através de programas de pesquisa, treinamentos e desenvolvimento profissional [11]. A primeira definição de engenharia de software foi proposta por Fritz Bauer em 1969, que é a seguinte: O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Segundo Pressman (1995), a engenharia de software deriva da engenharia de sistemas e de hardware, e que abrange um conjunto de três elementos fundamentais que possibilitam o controle do processo de desenvolvimento de software e oferecem 15

16 uma base para a construção de software de alta qualidade, produtivamente. Os três elementos fundamentais da engenharia de software, também chamados como Paradigmas da Engenharia de Software, são: Métodos: Proporcionam orientações sobre como construir o software; Ferramentas de Engenharia de Software: automatizam os métodos para construção de software; Processos de Engenharia de Software: que formam a ligação entre métodos e ferramentas para que o software seja construído. Ainda segundo Pressman, esses três elementos fundamentais passam por três fases genéricas, a saber: Definição: identificar a função do software a ser desenvolvido. Nessa fase acontecem a análise de requisitos e análise e projeto do software. Desenvolvimento: executa o que foi planejado, nessa fase ocorrem os testes e codificação do software. Manutenção: correções, adaptação e melhorias no software. 2.3 ISO/IEC Processos do Ciclo de Vida do Software A ISO/IEC Standard for Information Technology Software life cycle process guia como estruturar e gerenciar o todo ciclo de desenvolvimento de software, proporcionando assim a visão geral de todo o processo. Essa norma contém um conjunto de processos, atividade e tarefas que podem ser adaptadas a cada tipo de projeto de software. Esse conjunto de processos, atividades e tarefas cobrem o software desde a sua criação até sua aposentaria. Ciclo de vida é a estrutura que contém processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até o término de seu uso. NBR ISO/IEC Uma passagem completa por quatro fases: concepção, elaboração, construção e transição. O espaço de tempo entre o início da fase de concepção e o final de transição. IBM/Rational, Glossário do RUP A norma ISO/IEC 12207, crida em 1995 revisada em 2002 e 2004 estabelece um 16

17 framework padrão para definição do ciclo de vida de software. O objetivo da ISO/IEC é que cliente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e desenvolvedores utilizem a mesma estrutura de processos, com terminologias bem definidas, que podem ser referenciadas pela indústria de software. Para isso foram definidos três macro processos: o processo fundamental, processo organizacional e processo de apoio. [1] Processo Fundamental O processo fundamental contempla a contratação, desenvolvimento, operação e manutenção dos produtos de software ao longo do ciclo de vida do software. O processo Fundamental abrange as atividades de aquisição, fornecimento, desenvolvimento, operação e manutenção [1]. Aquisição: atividades para contratar a organização que desenvolveu o sistema, software ou serviço. Fornecimento: atividades dos fornecedores, da organização que provem o sistema ou o serviço que precisa ser adquirido. Desenvolvimento: papéis e atividades para desenvolvimento do software. Operação: atividades para operação do produto de software e suporte operacional aos usuários; Manutenção: atividades de manutenção do software. Isso inclui a gestão de mudanças, migração e fim do ciclo de vida do software Processo Organizacional O processo organizacional auxilia o desenvolvimento de processos, produtos e recursos a serem utilizados nos projetos para que a organização atinja seus objetivos de negócio. No processo organizacional, encontram-se as seguintes atividades: gestão, infraestrutura e recursos, melhoria e treinamento. Gestão: atividades básicas de gestão, incluindo gestão de projetos relacionada ao ciclo de vida do software. Infra-estrutura e Recursos: os recursos e infra-estrutura para os processos realizados pela organização ao longo do ciclo de vida do software. 17

18 Melhoria: atividades básicas que a organização necessita para controlar, medir e melhorar seu processo de ciclo de vida do software. Treinamento: define as atividades para prover um treinamento adequado Processo de Apoio O processo de apoio auxilia e contribui para o sucesso e qualidade dos outros processos envolvidos no ciclo de vida do software. No processo de Apoio encontram-se as seguintes atividades [1]: documentação, gestão de configuração, garantia da qualidade, verificação, validação, auditoria e resolução de problemas. Documentação: atividades para registrar as informações produzidas ao longo do ciclo de vida do software. Gestão de Configuração: define as atividades de gestão de configuração. Garantia da Qualidade: atividades objetivamente para garantir que o software produzido está de acordo com as especificações de requisitos e aderente aos planos estabelecidos. As técnicas de revisões compartilhadas, auditorias, verificação e validação podem ser usadas para garantia da qualidade. Verificação: atividades para verificação do software e serviços em diferentes profundidades de acordo com o projeto do software. Validação: atividades para validação do software de acordo com o projeto do software. Auditoria: atividade para determinação da conformidade com os requisitos, planos e contrato. Este processo pode ser empregado pela equipe auditora e equipe auditada. Resolução de Problemas: processo de análise e remoção dos problemas, inclusive não-conformidades, independente da causa raiz, descobertos durante a execução dos processos ao longo do ciclo de vida do software. Abaixo está a ilustração de como está estruturada a norma ISO/IEC 12207: 18

19 Figura 1 Estrutura da Norma ISO/IEC Fonte: NBR ISO/IEC Modelos de Ciclo de Vida O modelo de ciclo de vida do software consiste de todas as atividades desde a criação até a aposentadoria deste. A escolha do modelo de ciclo de vida é uma das mais influentes decisões para o sucesso do projeto em questão, pois se adequada contribui para que o processo de desenvolvimento do software seja eficiente, seja obtido um produto com mais qualidade além de minimizar os riscos inerentes ao processo. Assim como a escolha de um modelo de ciclo de vida inadequado ou a falta de um pode fazer que haja muito atividades desnecessárias e frustração ao longo do ciclo de vida do software. [31] Modelo de Ciclo de Vida Cascata Ainda que largamente desprezado como ineficiente, o modelo cascata é o mais antigo e usado até hoje. Pois é fácil para ser entendido, explicado e demonstrado. Para projetos que tem um cronograma seqüencial, é um modelo de ciclo de vida eficiente. Porém quando os riscos do projeto são altos o suficiente para requerer mais flexibilidade no cronograma o modelo cascata é desfavorável quando comparado com outros modelos de ciclo de vida mais sofisticados [1]. No modelo cascata, o projeto é planejado em uma seqüência de fases (Figura 2). Cada fase é definida em termos de entradas, saídas e 19

20 tarefas. No final de cada fase, a fase é revista em uma reunião que deve ser conduzida para verificar quais tarefas foram executadas, e que saídas estão prontas para a próxima fase [1]. É aconselhado o uso do modelo de ciclo de vida cascata nas seguintes ocasiões [3]: O contrato de trabalho está completo, correto e não-ambíguo. Os requisitos e critérios de aceitação são completos, corretos e não ambíguos. O trabalho pode ser completado sem restrições. Mudanças nos requisitos ou projeto não acontecerão a necessidade do cliente é estática. O problema e solução são bem entendidos e claramente definidos. Não serão cometidos erros durante a identificação de requisitos ou planejamento do projeto. Figura 2 Modelo de Ciclo de Vida em Cascata Fonte: [1] Modelos de Ciclo de Vida Incremental, Iterativo e Espiral [3] Existem vários modelos de ciclo de vida das famílias incrementais e iterativas que foram desenvolvidos nos anos 80, para progressivamente resolver os problemas do 20

21 modelo cascata. Isto inclui incrementos em mini-cascatas, modelos iterativos e espirais e modelos evolucionários. Ciclo de Vida Incremental [3] O modelo de ciclo de vida incremental é similar ao modelo cascata, porém o trabalho é agrupado em pequenos ciclos seqüenciais, e cada ciclo segue o modelo cascata conforme Figura 3. Esse modelo é eficiente quando o conjunto de requisitos do projeto tem alto risco de sofrer mudanças, assim se os requisitos tiverem de ser modificados o orçamento ficaria menos comprometido do que se tivesse sido utilizado um modelo seqüencial. [19] Figura 3 - Modelo de Ciclo de Vida Incremental - Fonte: [1] 21

22 Ciclo de Vida Iterativo No modelo iterativo (Figura 4), o projeto é dividido em ciclos que são repetidos, permitindo que o trabalho seja revisto e refinado [3]. Dessa forma o software é liberado em forma de uma série de implementações que são gradualmente mais completas, uma vez que as disciplinas de desenvolvimento, entendimento dos requisitos e planejamento da arquitetura são percorridas várias vezes (uma vez a cada iteração). [20] Figura 4: Modelo de Ciclo de Vida Iterativo. Fonte [36] Ciclo de Vida Espiral [1] No modelo de ciclo de vida espiral (Figura 5) são permitidas múltiplas interações entre atividades similares do projeto [1]. O progresso é representado como um espiral iniciando no centro. A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma fase do desenvolvimento. No modelo original foram propostas as seguintes quatro fases [21]: Determinação de objetivos, alternativas e restrições: fase onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Avaliação de alternativas identificação e solução de riscos: feita a análise de risco. Desenvolvimento do produto: neste quadrante pode-se considerar o modelo cascata; 22

23 Avaliação do produto para iniciar um novo ciclo [21] Figura 5 Modelo de Ciclo de Vida em Espiral - Fonte [1] Modelos de Ciclo de Vida Evolucionário O modelo evolucionário (Figura 6) foi desenvolvido para ajudar a quebrar o software em pedaços que podem ser entregues para o cliente o mais cedo possível. Nesse modelo o software é desenvolvido em ciclos do modelo cascata. Nas fases de operação e manutenção ocorre a sobreposição dessas fases com o desenvolvimento da nova fase. [21] 23

24 Figura 6: Modelo de Ciclo de Vida Espiral. - Fonte: [1] Modelos de Ciclo de Vida V O modelo de ciclo de vida em V descreve revisões nas atividades como um teste antecipado, com objetivo de detectar erros precocemente ao longo do ciclo de desenvolvimento. [3] No modelo de ciclo de vida V existem avaliações, verificações, validações e testes em todas as etapas do processo de desenvolvimento de software, conforme ilustra a figura 7. O trabalho pode ser prosseguido quando todos os produtos de uma fase do projeto se encontrem em conformidade com as exigências de verificação e validação da organização. [22] 24

25 Figura 7 - Modelo V - Fonte: [3] Vantagens e Desvantagens dos Modelos de Ciclo de Vida A tabela abaixo apresenta algumas das vantagens de desvantagens dos modelos de ciclo de vida de desenvolvimento de software apresentados anteriormente [3]. Modelo de Ciclo de Vida Cascata Incremental Vantagens Passos bem definidos fazem a gerência do projeto e gestão de recursos mais fáceis. Permite que grandes problemas sejam quebrados em problemas menores para serem entregues a uma equipe. Desvantagens Erros nos requisitos e projeto não são encontrados até a fase de teste, se torna caro para reparar. Não permite mudanças nos requisitos. Não resolve problemas do modelo cascata, a menos que combinado com os modelos de ciclo de vida iterativo, espiral ou evolucionário. 25

26 Iterativo/Espiral Evolucionário Modelo V Permite mudanças e o cliente é envolvido ao longo do ciclo de vida; Alguns usuários acham fácil de gerenciar o tempo; Permite o refinamento dos planos e idéias; Teste acontece cedo falhas podem ser encontradas mais cedo. Áreas importantes podem ser testadas primeiro; Assim como o modelo de ciclo de vida iterativo e espiral, mais adequado aos marcos, menor tempo entre início e produção, entregas para áreas importantes primeiro. Fácil de gerenciar, de acordo com os critérios da ISO Teste é contínuo e custo benefício em termos de defeitos encontrados e facilidade para consertar. Tempo para testar e fazer testes de regressão são elevados; Bastante tempo entre o início e produção; Alguns usuários acham que não é tão fácil para gerenciar por estágios; Pode ser difícil controlar custos e tempo; Menos clareza nos marcos do projeto; Assim como os modelos de ciclo de vida iterativo/ espiral, riscos por falhas podem continuar se propagando se os testes forem insuficientes. Necessita de muitos recursos para testar todos os derivados do projeto; No começo o ciclo de vida pode parecer caro e burocrático; Tabela 1 Vantagens de Desvantagens dos Modelos de Ciclo de Vida - Fonte [3] 3 Padrões de Qualidade de Processo de Software Os padrões de qualidade de processo de software mais conhecidos são a ISO/IEC 15504, CMMI e MPS.BR. Foram utilizados como base para o MPS.BR, foco deste trabalho, a ISO/IEC 12207, ISO/IEC e CMMI como base para sua concepção. 3.1 ISO/IEC Avaliação do Processo de Software A ISO/IEC Standard for Information Technology Software process assessment foi publicada em 2004, com base no projeto SPICE (Software Process Improvement and Capability determination). Essa 1 A ISO/IEC define um modelo referência de processos considerados essenciais para a engenharia de software no mundo [6]. A ISO/IEC 15504, cuja estrutura pode ser vista na (Figura 9), descreve duas dimensões a serem consideradas para avaliar a evolução e capacidade dos processos, a primeira dimensão define os processos que devem ser 26

27 avaliados e a segunda dimensão define as escalas utilizadas para medição da capacidade dos processos avaliados [6]. Na primeira dimensão estão os processos: cliente-fornecedor, engenharia, suporte, gestão e organização [6]. Cliente-Fornecedor consiste dos processos que afetam clientes, suporte ao desenvolvimento e transição do software ao cliente. Engenharia - consiste dos processos para especificar, implementar, fazer manutenções no sistema e produzir documentação aos usuários. Suporte consiste dos processos que podem ser empregados por qualquer outro processo ao longo do ciclo de vida do software. Gestão consiste do processo que contêm práticas de natureza genérica, que podem ser usadas por qualquer gestor em qualquer projeto ao longo do ciclo de vida do software. Organização consiste do processo que estabelece as metas do negócio da organização e desenvolvimento dos processos, produtos, recursos e bens que quando usando por projetos, ajudam a organização a atender suas metas. Na segunda dimensão da norma ISO/IEC 15504, estão os critérios para classificar os processos em cada nível [6]: Nível 0 Incompleto: produtos de trabalho e saídas dos processos não são identificados facilmente; Nível 1 Executado: execução pode não ser rigorosamente planejada e executada. Porém indivíduos da organização reconhecem que o processo deve ser executado e existe a aceitação de que o processo é executado e necessário. Existem produtos de trabalhos do processo identificados e declaração de realização do que foi proposto; Nível 2 Gerenciado: execução do acordo especificado nos procedimentos planejada e executada. Produtos de trabalho estão conforme as especificações nas normas e requisitos. A distinção primária do nível 1 Executado é que a execução do processo é planejada e gerenciada e os progressos acontecem de acordo com o processo definido. Nível 3 Estabelecido: processo estabelecido de acordo com um processo padrão definido e eficiente, baseado em boas práticas de 27

28 engenharia de software. A distinção principal do Nível 2 Gerenciado é que o processo no Nível 3 Estabelecido é planejado e gerenciado usando processos normalizados baseado em boas práticas de engenharia de software Nível 4 Repetível Medições detalhadas de desempenho são coletadas e analisadas. Conduzindo para o entendimento quantitativo da capacidade do processo e melhoria da habilidade de repetição. Desempenho é fortemente gerenciado. A qualidade dos produtos de trabalho é qualitativamente sabida. A principal distinção em relação ao Nível 3 Estabelecido é que o processo é quantitativamente entendido e controlado; Nível 5 Otimizado processo quantitativamente efetivo e metas eficientes para desempenho são estabelecidas, baseadas nas metas de negócio da organização. Contínuo processo de monitoração, metas são estabelecidas para gerar um feedback quantitativo, melhorias são alcançadas através de análises de resultados. Processo otimizado envolve idéias inovadoras, tecnologias e mudanças em processo ineficazes para atingir as metas ou objetivos da organização. A avaliação de acordo com a ISO/IEC provê um modelo para medição em desenvolvimento de software. Os dados reunidos das avaliações podem ser usados para guiar o processo de melhoria contínua, conduzindo ganhos em produtividade, qualidade de produtos e entregas [6]. Classificação dos processos da ISO/IEC avaliados em seis níveis, conforme a Figura 8, abaixo: Figure 8: Níveis de Classificação dos Processos ISO/IEC Fonte: [6] 28

29 A figura abaixo contém a estrutura da norma ISO/IEC 15504: Figura 9 Estrutura da norma ISO/IEC Fonte: ISO/IEC [9] 3.2 CMMI [10] O CMMI foi criado pelo SEI no ano 2000 e teve a versão 1.1 lançada em O CMMI foi criado para integrar e evoluir os modelos: SW-CMM - Capability Maturity Model for Software, IPD-CMM Integrated Product Development e CMM SECM EIA 731, System Engineering Capability Model. Além de tornar-se compatível com a norma ISO/IEC [10]. Os principais objetivos alcançados ao criar o CMMI foram: eliminar inconsistências entre os modelos existentes, implementar melhorias no modelo CMM, estar compatível com a norma ISO/IEC e contemplar a forma de representação contínua. O CMMI permite duas representações, por estágios e contínua. A representação contínua utiliza os níveis de capacidade para[10] avaliação. A tabela 2 ilustra as duas representações, por estágios e contínua. Pode-se perceber que as duas 29

30 representações são muito parecidas. As duas contém os mesmos componentes e estes componentes têm a mesma hierarquia e configuração. A diferença principal é que na representação contínua o foco é na capacidade de processo como forma de mensurar o nível de capacidade. Já na representação por estágios o foco é na maturidade da organização, medida por níveis de maturidade [10]. Níveis de capacidade são aplicáveis em organizações em busca de melhoria de processo em Áreas de Processos individuais. Estes níveis são o meio para incrementar a melhoria dos processos correspondendo a uma determinada área de processo [10]. Existem seis níveis de capacidade numerados de 0 a 5. Níveis de Maturidade são aplicáveis a organizações cujo processo de melhoria deve ser alcançado através de múltiplas áreas de processo. Estes níveis são a base para prever os resultados para os próximos projetos da organização [10]. Existem cinco níveis de maturidade, numerado de 1 a 5. A tabela a seguir mostra a comparação dos 6 níveis de capacidade com os 5 níveis de maturidade: Representação Contínua Nível de Capacidade Representação por Estágios Nível de maturidade Nível 0 Incompleto Não aplicável Nível 1 Repetível Inicio Nível 2 Gerenciado Gerenciado Nível 3 Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente Gerenciado Quantitativamente Gerenciado Quantitativamente Nível 5 Otimizado Otimizado Tabela 2 - Comparação entre Níveis de Maturidade e Níveis Capacidade Fonte: [10] Na representação contínua preocupa-se com a seleção de uma área de processo particular para melhoria e o nível de capacidade desejado para aquela área de processo. Neste contexto, se o processo é repetível ou incompleto é importante. Então, o nome incompleto é o ponto de partida para a representação contínua [10]. 30

31 A representação por estágio é focada na maturidade da organização, se os processos estão repetíveis ou incompletos, esse não é o foco principal. Então, o nome início é o ponto de início da representação por estágios [10]. O nível de capacidade e nível de maturidade provém o caminho para medir o quão bem a organização pode e faz a melhoria dos seus processos Abordagem Contínua Nível de Capacidade 0 - Incompleto Um processo incompleto é um processo não repetível ou parcialmente repetível. Um ou mais objetivos específicos das áreas de processo não estão satisfeitos [10]. Nível de capacidade 1 Repetível No nível de capacidade 1 o processo é caracterizado como um processo repetível. O processo repetível é o processo que satisfaz os objetivos específicos da área de processo, isto é, suporta e habilita o trabalho necessário para adquirir capacidades. [10] Nível 2 de capacidade Gerenciado[10] No nível de capacidade 2 o processo é caracterizado como um processo gerenciado. Um processo gerenciado é repetível (nível 1), tem a infra-estrutura básica para suportar o processo, isto é, planejado e executado em acordo com políticas, por trabalhadores competentes e pessoas que tem recursos adequados para produzir saídas controladas. Envolve stakeholders relevantes, é revisado, monitorado e controlado e é avaliado se está aderente aos processos. A disciplina no processo, refletida pelo nível de capacidade 2 ajuda a assegurar que práticas existentes são retidas mesmo durante os momentos de pressão. [10] Nível de capacidade 3 - Definido[10] O nível de capacidade 3 é caracterizado como o processo definido. Um processo definido é gerenciado (nível 2 de capacidade) faz parte da cultura da organização, o conjunto de processos padrão está de acordo com os demais processos da organização, como guias, produtos de trabalho, medições e outros processo de melhoria. [10] A principal diferença entre os níveis de capacidade 2 e 3 é o escopo das normas, descrições de processo e procedimentos. No nível de capacidade 2, a norma, descrição de processo e procedimentos podem ser um pouco diferentes em cada instância específica dos processos. No nível de capacidade 3, os padrões, descrições de processo e procedimentos para o 31

32 planejamento de projeto estão de acordo com os processos padrão da organização. Outra crítica distinção é que no nível de capacidade 3, processos são tipicamente descritos mais rigorosamente que no nível de capacidade 2. O processo definido deixa mais claros o estados das propostas, entradas, critérios de entrada, atividades, papéis, medições, passos de verificação, saídas, e critérios de saída. No nível de capacidade 3, processos são gerenciados com mais pró- atividade usando um entendimento das inter-relações entre as atividades de processo e detalhadas medições dos processos, produtos de trabalho e seus serviços. [10] Nível de Capacidade 4 Gerenciado Quantitativamente [10] No nível de capacidade 4 o processo é caracterizado como processo gerenciado quantitativamente. Processo gerenciado quantitativamente é definido (nível de capacidade 3) e é controlado usando estatística e outras técnicas quantitativas. Objetivos quantitativos para a qualidade e desempenho do processo são estabelecidos e usados como critério no processo gerenciado. Qualidade e desempenho do processo são entendidos em termos estatísticos e são gerenciados por toda a vida do processo. [10] Nível de Capacidade 5 Otimizado [10] No nível de capacidade 5 o processo é caracterizado como um processo otimizado. Um processo otimizado é gerenciado quantitativamente (nível de capacidade 4) e é melhorado sistematicamente. O foco de um processo otimizado é a melhoria contínua do desempenho do processo através de melhorias incrementais e inovações [10]. 3.3 MPS.BR Melhoria de Processo do Software Brasileiro O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Guia Geral Dentre os objetivos do MPS.BR está o de definir e aprimorar um modelo de melhoria e avaliação do processo de software apropriado ao contexto das micro, pequenas e médias empresas, uma vez que o CMMI, que é o principal modelo de melhoria de software existente, não é o mais adequado em termos de estrutura e custos às empresas deste porte, que são maioria no Brasil. Um outro objetivo do MPS.BR é ser reconhecido nacional e 32

33 internacionalmente como modelo de melhoria de processos para a indústria de software. O MPS.BR além do processo de melhoria, estabelece o método de avaliação das empresas e processo de aquisição. Foi desenvolvido baseado nas normas ISO/IEC Processos de Ciclo de Vida de Software, suas emendas 1 e 2, na ISO/IEC Avaliação de Processo e CMMI. Dessa forma está de acordo com o conteúdo do CMMI-DEV [12]. A equivalência entre os modelos CMMI, representação por estágios e MPS.BR pode ser verificada na tabela abaixo: Comparação entre Níveis de Maturidade CMMI e MPS.BR CMMI MPS.BR 5 A 4 B 3 C -- D -- E 2 F -- G 1 Não é definido Tabela 3 - Comparação entre níveis de maturidade CMMI e níveis de maturidade MPS.BR A documentação do MPS.BR está dividida em três componentes: o Modelo de referência, Método de Avaliação e Modelo de Negócio, que são documentados através de guias, conforme figura abaixo [12]. 33

34 Figura 10 Estrutura da Documentação do MPS.BR Fonte: Guia Geral MPS.BR [12] Guias e Documentação MPS.BR No Guia Geral está descrito o Modelo de Referência do MPS.BR. Ou seja, os processos e em função de seus resultados esperados, os níveis de maturidade e capacidades. Esses elementos descrevem a estrutura a ser implementada pela organização que deseja ter seus processos em conformidade com o MPS.BR [12]. O Guia de Aquisição contém as boas práticas para a aquisição de software e serviços correlatos [12]. O Guia de Avaliação contém o método e descrição dos papéis participantes de uma avaliação de maturidade no MPS.BR [12]. O Modelo de Negócios contém as regras para tornar-se uma instituição implementadora do MR-MPS, assim como para tornar-se uma instituição avaliadora. Além disso, contém orientações para organização de grupos de empresas para implementação e avaliação no MPS.BR, chamado de projeto cooperado e informações para obter a certificação de consultores de aquisição e treinamentos. [12] Guias de Implementação: faz parte do conjunto de documentos de apoio ao MPS.BR. Estes guias fornecem orientações para implementar nas organizações os níveis de maturidade descritos no modelo de referência, detalhando os processos contemplados nos respectivos níveis de 34

35 maturidade e os resultados esperados com a implementação dos processos. Para cada nível de maturidade existe uma guia de implementação. [13] Todos os guias do MPS.BR estão disponíveis no website da Softex: Conceitos Importantes no MPS.BR Atributo de processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC , 2004]. Perfil do processo é um conjunto de pontuação de atributos de processo para um processo avaliado [ISO/IEC , 2004]. Resultado esperado do processo é resultado observável do sucesso do alcance do propósito do processo [ISO/IEC 12207:1995/Amd 1:2002]. A capacidade do processo é representada por um conjunto de atributos de processo descritos em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização. No MPS, à medida que a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização [12]. No MPS.BR existem cinco atributos de processo. Cada atributo de processo (AP) está detalhado em termos de resultados esperados deste atributo de processo (RAP) [12]. Para o nível G devem ser contemplados dois atributos de processo, o AP 1.1 e AP 2.1. AP 1.1 O processo é executado RAP1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado 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)7. A execução do processo é monitorada e ajustes são realizados para atender aos planos; RAP 5. Os recursos necessários para a execução do processo são identificados e disponibilizados; 35

36 RAP 6. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência; RAP 7. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto; RAP 8. O estado, atividades e resultados do processo são revistos com os níveis adequados de gerência (incluindo a gerência de alto nível) e problemas pertinentes são tratados Níveis de Maturidade no MPS.BR O MPS.BR estabelece sete níveis de maturidade que mostram os patamares da evolução dos processos da organização, caracterizados pelos estágios de implementação de melhorias nos processo da organização[12]. Os níveis de maturidade são os seguintes: A Em otimização Equivalente ao nível 5 CMMI; B Gerenciado Quantitativamente Equivalente ao nível 4 do CMMI; C Definido Equivalente ao nível 3 do CMMI; D Largamente Definido Parcialmente de acordo com o nível 3 do CMMI; E Parcialmente Definido - Parcialmente de acordo com o nível 3 do CMMI; F Gerenciado Equivalente ao nível 2 do CMMI; G Parcialmente Gerenciado - Parcialmente de acordo com o nível 2 do CMMI; A organização obtém determinado nível de maturidade quando atende aos propósitos de todos os resultados esperados nos processos e atributos de processo do respectivo nível de maturidade. A divisão em estágio, baseada no CMMI-SE-SW, tem graduação diferente para possibilitar mais etapas durante a implementação, mais adequado ao contexto das micro, pequenas e médias empresas. Além disso, ter mais níveis possibilita que os resultados de melhorias sejam visualizados mais rapidamente [12] Processo Os processos no MPS.BR são descritos em termos de propósito, resultados esperados e informações adicionais. O propósito descreve o objetivo geral a ser atingido durante a execução do processo [12]. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação dos processos em determinado nível. Estes 36

37 resultados podem ser evidenciados por um artefato produzido ou uma mudança significativa de estado ao se executar o processo [12] Estrutura de Processos e Níveis do MPS.BR Nível Processo Atributo de Processo A B C D E Análise de Causas de Problemas e Resolução-ACP Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Análise de Decisão e Resolução ADR Gerência de Reutilização GRU (evolução) Verificação VER Validação - VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP

38 Medição MED AP 1.1, AP 2.1 e AP 2.2 F Garantia da Qualidade - GQA Gerência de Configuração GCO G Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos - GPR AP 1.1 e AP 2.1 Tabela 4 - Estrutura de Processos e Níveis do MPS.BR - [MR-MPS.BR] Fonte: [12] Cada processo tem um propósito e seus resultados esperados. No nível G, estão os processos Gerência de Projetos e Gerência de Projetos. Os atributos de processo a serem atendidos nesse nível são o AP 1.1 e AP 2.1 [12], conforme citado anteriormente. O propósito do processo Gerência de Projetos é: O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, no contexto dos requisitos e restrições do projeto. [12] Guia Geral Os resultados esperados para o Processo de Gerência de Projetos são [12]: GPR 1. O escopo do trabalho para o projeto está definido Espera-se que a organização tenha artefatos que mostrem o trabalho a ser realizado para criar o produto que satisfaça as necessidades especificadas para o projeto. Um exemplo de artefato que atenderia a esse resultado seria a EAP do projeto. GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados Espera-se que a complexidade das tarefas a serem executadas tenha sido estimada através de métodos adequados. GPR 3. O modelo e as fases do ciclo de vida do projeto são definidas 38

39 Espera-se que a organização tenha adotado um modelo de ciclo de vida para seus projetos de desenvolvimento de software. 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 Este resultado espera que a organização estime o esforço para as atividades do projeto baseada em métodos estatísticos adequados e que essas estimativas tenham sido documentadas. GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos Espera-se que tenha sido estabelecido o orçamento e cronograma para o projeto. Espera-se ainda que o cronograma e orçamento sejam mantidos atualizados ao longo da execução do projeto. 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 Espera-se que os riscos aos quais o projeto está exposto sejam identificados, e que o impacto, probabilidade de ocorrência e prioridade no tratamento tenham sido documentados e monitorados ao longo do projeto. GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo Esperam-se nesse resultado artefatos que mostrem que os recursos humanos que executarão as atividades do projeto tenham sido escolhidos baseados no perfil e conhecimentos necessários para executar a atividade do projeto. GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados. Nesse resultado são esperados artefatos que mostrem que a infra-estrutura necessária 39

40 para executar cada atividade do projeto tenha sido planejada e disponibilizada ao longo do projeto. 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 Nesse resultado esperam-se artefatos que mostrem que os dados do projeto sejam gerenciados ao longo da execução dos projetos. GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto Nesse resultado esperam-se artefatos que mostrem o planejamento da execução do projeto, por exemplo, um plano de projeto que relacione as informações deste entre si. 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 Nesse resultado esperam-se artefatos que mostrem que a viabilidade para atingir as metas do projeto tenha sido avaliada. GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido Nesse resultado espera-se que todos os envolvidos com a execução do projeto conheçam e se comprometam com o Plano de Projeto. GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados Nesse resultado espera-se que haja um documento que registre as monitorações do projeto, ou seja, se existe um controle entre as diferenças do que foi planejado e o que está sendo realizado no projeto. 40

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

MPS.BR. O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro. A proposta MPS.BR nasceu com base nos moldes CMMI.

MPS.BR. O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro. A proposta MPS.BR nasceu com base nos moldes CMMI. MPS.BR O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro. A proposta MPS.BR nasceu com base nos moldes CMMI. ISO - 12207 para desenvolvimento de software. ISO - 15504 para avaliação

Leia mais

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo

Leia mais

Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro

Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Realidade das Empresas Brasileiras ISO/IEC 12207 ISO/IEC 15504 CMMI Softex Governo Universidades Modelo de Referência para

Leia mais

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL Porto Alegre, Agosto de 2008. Sumário Apresentação Programa MPS.BR Reutilização no MPS.BR Gerência de reutilização Desenvolvimento para reutilização

Leia mais

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade IV QUALIDADE DE SOFTWARE introdução As mudanças que estão ocorrendo nos clientes e nos ambientes de negócios altamente competitivos têm motivado as empresas a modificarem

Leia mais

Qualidade de Processo de Desenvolvimento de Software

Qualidade de Processo de Desenvolvimento de Software Qualidade de Processo de Desenvolvimento de Software DAS 5316 Integração de Sistemas Corporativos DAS 5316 Integração de Sistemas Corporativos Prof. Ricardo J. Rabelo Conteúdo Introdução & Problemática

Leia mais

Melhoria do Processo de Software MPS-BR

Melhoria do Processo de Software MPS-BR Melhoria do Processo de Software MPS-BR Fabrício Sousa Pinto fabbricio7@yahoo.com.br O que é Qualidade? O problema da gestão da qualidade não é que as pessoas não sabem a respeito dela. O problema é que

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 2-26/04/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Estudo de caso para implantação do modelo MR-MPS-SV

Estudo de caso para implantação do modelo MR-MPS-SV Estudo de caso para implantação do modelo MR-MPS-SV Giovani Hipolito Maroneze 1, Jacques Duílio Branches 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.001 86.057-970

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

Programa MPS.BR Melhoria de Processo do Software Brasileiro: principais resultados, avanços e fatores críticos de sucesso (FCS)

Programa MPS.BR Melhoria de Processo do Software Brasileiro: principais resultados, avanços e fatores críticos de sucesso (FCS) Programa MPS.BR Melhoria de Processo do Software Brasileiro: principais resultados, avanços e fatores críticos de sucesso (FCS) SUMÁRIO 1. Introdução: programa MPS.BR 2. Principais resultados: modelo MPS,

Leia mais

Objetivos. Histórico. Out/11 2. Out/11 3

Objetivos. Histórico. Out/11 2. Out/11 3 Objetivos Histórico Evolução da Qualidade Princípios de Deming CMMI Conceitos Vantagens Representações Detalhamento Gerenciamento Comparação Out/11 2 Histórico SW-CMM (Software Capability Maturity Model):

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE MODULO 3 SISTEMA DE GARANTIA DA QUALIDADE CONTEÚDO 3.1 A ABORDAGEM NBR ISO 9000 3.2 MODELOS DE QUALIDADE DE PRODUTO DE SOFTWARE 3.2.1 NBR ISO/IEC 9126 (SOFTWARE) 3.2.2 NBR ISO/IEC

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

QUALIDADE DE SOFTWARE AULA N.7

QUALIDADE DE SOFTWARE AULA N.7 QUALIDADE DE SOFTWARE AULA N.7 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 CMM: DEFINIÇÃO Capability Maturity Model Um modelo que descreve como as práticas

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail. Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura O Modelo Wesley Torres Galindo wesleygalindo@gmail.com Agenda O que é? Motivação Organização do MPS.BR Estrutura

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 Este guia contém orientações para a implementação do nível

Leia mais

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

Qualidade de software com MPS.BR nos níveis de maturidade G e F

Qualidade de software com MPS.BR nos níveis de maturidade G e F Qualidade de software com MPS.BR nos níveis de maturidade G e F Marcelo Augusto Resende Cunha Graduado em Sistemas de Informação pela Libertas Faculdades Integradas Alysson Alexander Naves Silva Mestre

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

Introdução a Engenharia de Software

Introdução a Engenharia de Software Introdução a Engenharia de Software Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 Histórico 1968: Crise do Software Nasce a Engenharia de Software 1970s:

Leia mais

Engenharia de Software

Engenharia de Software UFES - Universidade Federal do Espírito Santo Engenharia de Software Notas de Aula PARTE I E-mail: falbo@inf.ufes.br Curso: Engenharia da Computação (Atualizadas por e Monalessa Perini Barcellos - 2011)

Leia mais

MPS.BR Melhoria de Processo do Software Brasileiro

MPS.BR Melhoria de Processo do Software Brasileiro Melhoria de Processo do Software Brasileiro (MPS.BR) SUMÁRIO 1. Introdução 2. Implantação do Programa MPS.BR: 2004 2007 3. Consolidação do Programa MPS.BR: 20082010 4. Conclusão Kival Weber Coordenador

Leia mais

Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR

Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR SCIENTIA PLENA VOL 6, NUM 3 2010 www.scientiaplena.org.br Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR F. G. Silva; S. C. P. Hoentsch, L. Silva Departamento

Leia mais

MPS.BR: Melhoria de Processo do Software Brasileiro e dos Resultados de Desempenho

MPS.BR: Melhoria de Processo do Software Brasileiro e dos Resultados de Desempenho l MPS.BR: Melhoria de Processo do Software Brasileiro e dos Resultados de Desempenho SUMÁRIO 1. Introdução Programa MPS.BR e Modelo MPS 2. Programa MPS.BR Resultados Esperados, Resultados Alcançados e

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro

MPS.BR - Melhoria de Processo do Software Brasileiro MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 9: Implementação do MR-MPS em organizações do tipo Fábrica de Software Este guia contém orientações para a implementação

Leia mais

Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev

Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev Artigos técnicos selecionados Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev Rosana Fernandes Osório, Guilherme Tavares Motta Coordenação Geral de Qualidade de Software

Leia mais

A Experiência na Implantação do Processo de Gerência de Reutilização no Laboratório de Engenharia de Software da COPPE/UFRJ

A Experiência na Implantação do Processo de Gerência de Reutilização no Laboratório de Engenharia de Software da COPPE/UFRJ A Experiência na Implantação do Processo de Gerência de Reutilização no Laboratório de Engenharia de Software da COPPE/UFRJ Reinaldo C. Silva Filho 1, Anne Elise Katsurayama 1, Gleison Santos 1, Leonardo

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

Mapeamento GRH. 1. Introdução

Mapeamento GRH. 1. Introdução Mapeamento GRH 1. Introdução 1.1. Finalidade Este documento tem duas finalidades principais: a) Averiguar semelhanças e diferenças entre modelos, normas e guias de boas práticas para gestão de recursos

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 8: Implementação do MR-MPS em organizações que adquirem software Este guia contém orientações para a implementação do Modelo

Leia mais

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais

Programa MPS.BR e Modelo MPS: A Evolução da Qualidade de Software no Brasil

Programa MPS.BR e Modelo MPS: A Evolução da Qualidade de Software no Brasil Programa MPS.BR e Modelo MPS: A Evolução da Qualidade de Software no Brasil 1. Qualidade de Software: motivação para o foco no processo, características dos processos de software e abordagens para melhoria

Leia mais

APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR

APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR Fonte: http://www.softex.br/mpsbr/_home/default.asp Apostilas disponíveis no site 1 NORMAS: NBR ISO NBR ISO/IEC CMM SPICE Continuação... 2 NORMAS VISÃO GERAL NBR

Leia mais

Gerenciamento de Qualidade. Paulo C. Masiero Cap. 24 - SMVL

Gerenciamento de Qualidade. Paulo C. Masiero Cap. 24 - SMVL Gerenciamento de Qualidade Paulo C. Masiero Cap. 24 - SMVL Introdução Melhoria nos níveis gerais de qualidade de software nos anos recentes. Diferenças em relação ao gerenciamento da qualidade na manufatura

Leia mais

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE 1 VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE Elvis Ferreira da Silva* Msc. Marta Alves de Souza** Msc. Helder

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE - 02 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software.

Leia mais

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados

Leia mais

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto Gerais Processo Produto Propostas NBR ISO 9000:2005 define principios e vocabulário NBR ISO 9001:2000 define exigências para sistema de gerência de qualidade NBR ISO 9004:2000 apresenta linha diretivas

Leia mais

Qualidade de software

Qualidade de software Qualidade de software É cada dia maior o número de empresas que buscam melhorias em seus processos de desenvolvimento de software. Além do aumento da produtividade e da diminuição do retrabalho, elas buscam

Leia mais

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com

CAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com CAPABILITY MATURITY MODEL FOR SOFTWARE Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com 1. Introdução Após décadas de incontáveis promessas sobre como aumentar à produtividade e qualidade de software,

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Riscos

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Riscos Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Riscos Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Análise dos Riscos Atividades Princípios da Análise Especificação

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Introdução CMMI. Qualidade e Teste de Software CMMI 1

Introdução CMMI. Qualidade e Teste de Software CMMI 1 Introdução CMMI O propósito da qualidade é estabelecer um diferencial competitivo, através de contribuições como redução de defeitos, redução de custos, redução de retrabalho e aumento da produtividade,

Leia mais

Da Pesquisa em Engenharia de Software à Melhoria da Qualidade de Software no Brasil

Da Pesquisa em Engenharia de Software à Melhoria da Qualidade de Software no Brasil Da Pesquisa em Engenharia de Software à Melhoria da Qualidade de Software no Brasil Autores: Marcos Kalinowski (COPPE/UFRJ), Gleison Santos (PPGI - UNIRIO), Rafael Prikladnicki (PUCRS), Ana Regina Rocha

Leia mais

Definição do Framework

Definição do Framework Definição do Framework 1. Introdução 1.1. Finalidade Este documento tem por finalidade apresentar o mapeamento dos processos de Definição de Processo Organizacional e Avaliação e Melhoria do Processo dos

Leia mais

FACULDADE SENAC GOIÂNIA

FACULDADE SENAC GOIÂNIA FACULDADE SENAC GOIÂNIA NORMA ISO 12.207 Curso: GTI Matéria: Auditoria e Qualidade de Software Professor: Elias Ferreira Acadêmico: Luan Bueno Almeida Goiânia, 2015 CERTIFICAÇÃO PARA O MERCADO BRASILEIRO

Leia mais

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação 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.

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral Este guia contém a descrição geral do Modelo MPS e detalha o Modelo de Referência (MR-MPS) e as definições comuns necessárias para seu entendimento

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

Leia mais

CAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi

CAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi CAPABILITY MATURITY MODEL INTEGRATION Prof. Késsia R. C. Marchi Modelos de maturidade Um modelo de maturidade é um conjunto estruturado de elementos que descrevem características de processos efetivos.

Leia mais

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana

Leia mais

3. Metodologias de Gerenciamento de Riscos

3. Metodologias de Gerenciamento de Riscos 3. Metodologias de Gerenciamento de Riscos A complexidade que caracteriza a implantação de um sistema ERP é uma das maiores preocupações das organizações que pretendem desenvolver projetos desta natureza.

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

Metodologia de Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

Prof. Vitório Bruno Mazzola INE/CTC/UFSC 1. INTRODUÇÃO

Prof. Vitório Bruno Mazzola INE/CTC/UFSC 1. INTRODUÇÃO Capítulo 6 ENGENHARIA DE SOFTWARE CONCEITOS BÁSICOS Prof. Vitório Bruno Mazzola INE/CTC/UFSC 1. INTRODUÇÃO Nos anos 40, quando se iniciou a evolução dos sistemas computadorizados, grande parte dos esforços,

Leia mais

CLEVERSONTPP@GMAIL.COM

CLEVERSONTPP@GMAIL.COM UM BREVE DESCRITIVO DO MODELO MPS-BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO) E SUAS PERSPECTIVAS PARA O FUTURO CLÉVERSON TRAJANO PRÉCOMA PORTES PÓS-GRADUAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software 2.1 Capítulo 2 QUALIDADE DE SOFTWARE 1. INTRODUÇÃO Como foi mencionado no capítulo anterior, o papel da Engenharia de Software é, principalmente, fornecer métodos e ferramentas para

Leia mais

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software Marcello Thiry 1 2, Christiane Gresse von Wangenheim 1 2, Alessandra Zoucas 12, Leonardo Reis Tristão 1 1 (II-MPS.BR) Incremental

Leia mais

Projeto. Gerenciamento de Projeto de Software. Tópicos abordados. Características básicas de um projeto. Definição

Projeto. Gerenciamento de Projeto de Software. Tópicos abordados. Características básicas de um projeto. Definição Gerenciamento de Projeto de Software Tópicos abordados Atividades de gerenciamento Planejamento do projeto Cronograma do projeto Gerenciamento de riscos Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com

Leia mais

Unidade I Conceitos BásicosB. Conceitos BásicosB

Unidade I Conceitos BásicosB. Conceitos BásicosB à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 1961 a 1963 Surgimento de novos Hardwares 1963-1968 Crise do Software! Incapacidade de se utilizar

Leia mais

Engenharia de Software Processo de Desenvolvimento de Software

Engenharia de Software Processo de Desenvolvimento de Software Engenharia de Software Processo de Desenvolvimento de Software Prof. Edison A. M. Morais prof@edison.eti.br http://www.edison.eti.br Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar

Leia mais

MPS.BR Melhoria de Processo do Software Brasileiro

MPS.BR Melhoria de Processo do Software Brasileiro l MPS.BR Melhoria de Processo do Software Brasileiro SUMÁRIO 1. Introdução 2. Modelo MPS 3. Programa MPS.BR: Resultados Alcançados (2004-2008) e Resultados Esperados (2004-2010) 4. MPS.BR Lições Aprendidas

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso

Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso Programa Brasileiro da Qualidade e Produtividade em Software PBQP SW Melhoria de Processo de Software baseado no Modelo MPS.BR nível G - Um Estudo de Caso Categoria 2.36: Métodos de Gestão Soltin - Soluções

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral (Versão 1.1) Este guia contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR-MPS) e as definições comuns necessárias para

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico

Leia mais

FUMSOFT EDITAL 002/2013 1ª EDIÇÃO

FUMSOFT EDITAL 002/2013 1ª EDIÇÃO FUMSOFT PROGRAMA DE APOIO E INCENTIVO À MELHORIA E QUALIDADE DOS PROCESSOS DE SOFTWARE EM EMPRESAS COM ESTABELECIMENTO EM MINAS GERAIS E DIFUSÃO DO MODELO MPS.BR (MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRO)

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste Este guia contém orientações para a implementação do

Leia mais

O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software

O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software Maria Angela Coser (UTFPR/CEFETES) macoser@cefetes.br Helio Gomes de Carvalho (UTFPR) helio@utfpr.edu.br

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro

MPS.BR - Melhoria de Processo do Software Brasileiro MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 11: Implementação e Avaliação do MR-MPS-SW:2012 em Conjunto com o CMMI-DEV v1.3 Este guia contém orientações para a implementação

Leia mais

Programa MPS.BR e Modelo MPS: Contribuições para a Evolução da Qualidade de Software no Brasil

Programa MPS.BR e Modelo MPS: Contribuições para a Evolução da Qualidade de Software no Brasil l Programa MPS.BR e Modelo MPS: Contribuições para a Evolução da Qualidade de Software no Brasil SUMÁRIO 1. Introdução: Programa MPS.BR e Modelo MPS 2. Programa MPS.BR: Resultados Esperados, Resultados

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br

Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br Modelos de Processo Pessoal e de Equipe na Melhoria da Qualidade em Produção de Software Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br Agenda Importância das Pessoas / Constatações Compromisso

Leia mais

CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR

CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR Leonardo Galvão Daun Universidade Estadual de Maringá leonardo.daun@gmail.com Profª Drª Sandra Ferrari Universidade Estadual de Maringá

Leia mais

Qualidade de Software. Anderson Belgamo

Qualidade de Software. Anderson Belgamo Qualidade de Software Anderson Belgamo Qualidade de Software Software Processo Produto Processo de Software Pessoas com habilidades, treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos

Leia mais

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

MODELO CMM MATURIDADE DE SOFTWARE MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Quem Somos CMM/ CMMI. ISO 9000 PNQ ISO 12207 ISO 15504 ITIL Outros modelos. Gestão Sistêmica da. Alinhamento às Diretrizes Organizacionais.

Quem Somos CMM/ CMMI. ISO 9000 PNQ ISO 12207 ISO 15504 ITIL Outros modelos. Gestão Sistêmica da. Alinhamento às Diretrizes Organizacionais. Quem Somos Missão Promover a melhoria e a busca da excelência na gestão organizacional e o aperfeiçoamento contínuo dos processos dos nossos clientes, por meio de modelos e padrões de qualidade adequados

Leia mais

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

Programa 04/12/2008 05/12/2008. 1. Relato de experiência Integração de modelos CMMI, MPS.BR e ISO 9000 na 7COMm Sergio Esmério (7COMm)

Programa 04/12/2008 05/12/2008. 1. Relato de experiência Integração de modelos CMMI, MPS.BR e ISO 9000 na 7COMm Sergio Esmério (7COMm) Programa 04/12/2008 05/12/2008 1. Relato de experiência Integração de modelos CMMI, MPS.BR e ISO 9000 na 7COMm Sergio Esmério (7COMm) 2. A importância do fator humano no desenvolvimento de software Daniel

Leia mais

Todos nossos cursos são preparados por mestres e profissionais reconhecidos no mercado, com larga e comprovada experiência em suas áreas de atuação.

Todos nossos cursos são preparados por mestres e profissionais reconhecidos no mercado, com larga e comprovada experiência em suas áreas de atuação. Curso Formação Efetiva de Analístas de Processos Curso Gerenciamento da Qualidade Curso Como implantar um sistema de Gestão de Qualidade ISO 9001 Formação Profissional em Auditoria de Qualidade 24 horas

Leia mais

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br)

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br) Obrigado por acessar esta pesquisa. Sei como é escasso o seu tempo, mas tenha a certeza que você estará contribuindo não somente para uma tese de doutorado, mas também para a melhoria das práticas da Comunidade

Leia mais