CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

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

Download "CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO"

Transcrição

1 CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE EM UMA EQUIPE DE DESENVOLVIMENTO Christian Canalli Orientador Prof. Marcos Danilo Chiodi Martins RIBEIRÃO PRETO 2011

2 CHRISTIAN CANALLI GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE EM UMA EQUIPE DE DESENVOLVIMENTO Trabalho de conclusão de curso apresentado ao Centro Universitário UNISEB de Ribeirão Preto, como parte dos requisitos para obtenção do grau de Bacharel em Ciência da Computação. Orientador: Prof. Marcos Danilo Chiodi Martins RIBEIRÃO PRETO 2011

3 ii Ficha Catalográfica C224g Canalli, Christian. Gerência de Configuração de Software em uma Equipe de Desenvolvimento. Christian Canalli. - Ribeirão Preto, f., il.. Orientador: Prof. Me. Marcos Danilo Chiodi Martins. Trabalho de conclusão de curso apresentado ao Centro Universitário UNISEB de Ribeirão Preto, como parte dos requisitos para obtenção do Grau de Bacharel em Ciência da Computação sob a orientação do Prof. Me. Marcos Danilo Chiodi Martins. 1. Engenharia de Software. 2. Qualidade de Produto e de Processo. 3. Gerenciamento de Configuração de Software. 4. Controle de Alterações. I. Título. II. Martins, Marcos Danilo Chiodi. CDD

4 iii TRABALHO DE CONCLUSÃO DE CURSO Aluno: Christian Canalli Código: 5876 Curso: Ciência da Computação Semestre/Ano: 8º/2011 Tema: Gerência de Configuração de Software em uma Equipe de Desenvolvimento. Objetivos pretendidos: Mostrar que ao adotar o processo de Gerência de Configuração de Software um uma equipe de desenvolvimento garante-se maior controle das alterações, podendo diminuir o impacto na entrega do software. / / Marcos Danilo Chiodi Martins Professor Orientador / / Christian Canalli Aluno / / Paulo César de Carvalho Dias Coordenador do Curso / / Prof. Reginaldo Arthus Vice-Reitor

5 iv TRABALHO DE CONCLUSÃO DE CURSO FORMULÁRIO DE AVALIAÇÃO - FATCC Tema do trabalho: Gerência de Configuração de Software em uma Equipe de Desenvolvimento. Data da apresentação: / / Horário: Local: Comissão Julgadora: 1) Professor Orientador: 2) Professor da Área: 3) Professor Convidado:

6 v Fatores de Avaliação Pontuação (0.0 a 2.0) 1. Atualidade e relevância do tema proposto. 2. Linguagem técnica utilizada em relação ao tema e aos objetivos, e competência lingüística. 3. Aspectos metodológicos e formais da editoração do trabalho escrito - seqüência lógica e coerência interna. 4. Revisão Bibliográfica realizada em relação ao tema pesquisado. 5. Apresentação oral segurança e coerência em relação ao trabalho escrito. Média: ( ) Assinaturas dos membros da Comissão Julgadora: 1) / / 2) / / 3) / /

7 vi Aos meus pais e irmão pelo apoio e conselhos.

8 vii AGRADECIMENTOS Ao meu orientador, Prof. Ms. Marcos Danilo Chiodi Martins, por compartilhar de sua experiência e contribuir para a conclusão deste trabalho. A Prof. Ms. Patrícia Magna, pelo auxílio na parte escrita e atenção a todas as dúvidas e idéias para a conclusão deste trabalho. Aos professores do curso de Ciência da Computação do Centro Universitário UNISEB por passar todo o conhecimento necessário para a formação acadêmica e profissional.

9 viii A simplicidade é o último grau de sofisticação. Leonardo Da Vinci

10 ix CANALLI, Christian. Gerência de Configuração de Software em uma Equipe de Desenvolvimento. Trabalho de Conclusão de Curso. Curso de Ciência da Computação. Centro Universitário UNISEB. Ribeirão Preto, f. RESUMO Com o atual processo de software aplicado pelas empresas na busca de um ciclo de desenvolvimento ágil, tem-se encontrado grandes problemas na qualidade dos produtos oferecidos. Além disso, a quantidade de mudanças solicitadas faz com que o processo de desenvolvimento de software exija um gerenciamento controlado para evitar o caos. Dessa maneira, a Gerência de Configuração de Software vem para controlar as mudanças inevitáveis no software e minimizar a confusão que possa haver entre os desenvolvedores envolvidos em um projeto. Palavras-chave: processo de software, qualidade dos produtos, mudanças inevitáveis de software, gerência e controle de software.

11 x CANALLI, Christian. Gerência de Configuração de Software em uma Equipe de Desenvolvimento. Trabalho de Conclusão de Curso. Curso de Ciência da Computação. Centro Universitário UNISEB. Ribeirão Preto, f. ABSTRACT With the current process implemented by software companies in the search of an agile development cycle, it has been found big problems with the quality of products offered. Besides, the amount of requested changes makes the software development process require a controlled management to avoid chaos. Thus, the Software Configuration Management comes to control the inevitable changes in software and minimize the confusion that may exist between developers involved in a project. Keywords: software process, product quality, inevitable software changes, software and management control.

12 xi SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS... xiv LISTA DE QUADROS... xv LISTA DE ILUSTRAÇÕES... xvi LISTA DE GRÁFICOS... xvii INTRODUÇÃO... 1 Contexto... 1 Motivação e Objetivo... 2 Organização do Trabalho... 3 CAPÍTULO 1. ENGENHARIA DE SOFTWARE Considerações Iniciais Engenharia de Software Principais Conceitos Processo de Software Modelos de Processo de Software Modelo em Cascata Modelo Incremental Modelo RAD Prototipação Espiral Conclusões sobre Processo e Modelos de Processo Considerações Finais CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO Considerações Iniciais Padrões de Qualidade Qualidade de Produto e de Processo Principais Conceitos MPS.BR Melhoria de Processo do Software Brasileiro Níveis de maturidade do MPS.BR Considerações Finais CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE Considerações Iniciais Definição... 18

13 xii 3.3. Atividades da Gerência de Configuração de Software Planejamento do processo da Gerência de Configuração de Software (PGCS) Plano de Gerência de Configuração Ferramenta de apoio de controle das alterações Fechamento do Plano de Gerência de Configuração Identificação da Configuração do Software Itens de Configuração de Software Baselines (Linhas Básicas) Repositório de Dados (Biblioteca de Software) Controle da Configuração do Software Análise e Aprovação de uma Solicitação de Mudança (SM) Implementação das SMs previstas Controle de Versões Controle de Mudanças Informação do Status da Configuração do Software O Relato do Status da Configuração Auditoria na Configuração do Software Gerenciamento de Liberação do Software e Entrega (Release) Geração de Build do Software Gerência de Configuração de Software segundo MPS.BR Considerações Finais CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO Considerações Iniciais Caracterização da Empresa Caracterização do Estudo de Caso Caracterização do Produto Papéis e Responsabilidades Ferramenta Utilizada Considerações Finais CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO Considerações Iniciais Fluxo do Processo Atividade: Planejar Atividades da GCO Atividade: Auditorias Periódicas Atividade: Auditorias de Baseline Atividade: Controlar Não Conformidades Atividade: Registrar Lições Aprendidas... 49

14 xiii 5.3. Diretrizes de Gerência de Configuração para Projetos de Desenvolvimento Repositório de Dados Critérios e Níveis de Controle dos Itens de Configuração Identificação dos Itens de Configuração Ferramenta de Controle de Versão Controle de Acesso e Alterações Considerações Finais CAPÍTULO 6. ESTUDO DE CASO Considerações Iniciais Organização da Equipe Definição das Atividades de Controle Controle de Solicitações de Mudança Controle e Versionamento das Baselines Aplicação do processo de Gerência de Configuração Definição do Projeto Atividade: Planejar Atividades da GCO Atividade: Auditorias Periódicas Atividade: Auditorias de Baseline Atividade: Controlar Não Conformidades Atividade: Registrar Lições Aprendidas Resultados obtidos com a aplicação do processo Considerações Finais CAPÍTULO 7. CONCLUSÕES Considerações do Trabalho Contribuições Limitações Oportunidades de Melhoria Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A - Template do Plano de Configuração do Projeto APÊNDICE B - Checklist de Auditoria Periódica APÊNDICE C - Acompanhamento de Não Conformidades APÊNDICE D - Checklist de Auditoria de Baseline de Desenvolvimento e Release APÊNDICE E - Checklist de Auditoria de Baseline de Documentação... 79

15 xiv LISTA DE ABREVIATURAS E SIGLAS SCM: Software Configuration Management. MPS.BR: Melhoria de Processo do Software Brasileiro. SOFTEX: Associação para Promoção de Excelência do Software Brasileiro. SWEBOK: Guide to the Software Engineering Body of Knowledge. IEEE: Institute of Electrical and Electronics Engineers. RAD: Rapid Aplication Development. ISO: International Organization for Standardization. MCT: Ministério da Ciência e Tecnologia. FINEP: Financiadora de Estudos e Projetos. SEBRAE: Serviço de Apoio às Micro e Pequenas Empresas. BID: Banco Interamericano de Desenvolvimento. IEC: International Electrotechnical Commission. CMMI: Capability Maturity Model Integration. CMMI-SE/SW: Capability Maturity Model Integration for Systems Engineering and Software Engineering. MR-MPS: Modelo de Referência para Melhoria de Processo de Software. MA-MPS: Método de Avaliação para Melhoria de Processo de Software. MN-MPS: Modelo de Negócio para Melhoria de Processo de Software. AP: Atributo de Processo. RAP: Resultado do Atributo de Processo. SQA: Software Quality Assurance. PGCS: Planejamento da Gerência de Configuração de Software. IC: Item de Configuração. SM: Solicitação de Mudança. CCB: Control Configuration Board. NC: Não Conformidade. Vrs: Versão.

16 xv LISTA DE QUADROS Quadro 1 Níveis de maturidade do MPS.BR Quadro 2 Símbolos de fluxo de processo da ferramenta Bizagi Quadro 3 Estrutura do Repositório de Documentos Quadro 4 Estrutura do Repositório de Desenvolvimento Quadro 5 Estrutura do Servidor de Release Quadro 6 Itens de Configuração identificados Quadro 7 Controle de Acesso ao Repositório de Documentos Quadro 8 Controle de Acesso ao Repositório de Desenvolvimento Quadro 9 Organização da Equipe de Desenvolvimento Quadro 10 Versionamento para baselines de desenvolvimento e release Quadro 11 Baselines estabelecidas Quadro 12 Cronograma de atividades Quadro 13 Plano de comunicação... 64

17 xvi LISTA DE ILUSTRAÇÕES Figura 1 Camadas da Engenharia de Software... 4 Figura 2 Modelo em Cascata... 7 Figura 3 Modelo Incremental... 8 Figura 4 Modelo RAD... 9 Figura 5 Modelo de Prototipação Figura 6 Modelo Espiral Figura 7 Definição de um processo de qualidade Figura 8 Organização do Modelo MPS Figura 9 Níveis de Maturidade do MPS.BR Figura 10 Atividades de Gerenciamento de Configuração de Software Figura 11 Características de ferramentas de Gerência de Configuração e seus procedimentos Figura 12 Mecanismo de alteração em uma baseline Figura 13 Controle de Versões com Desenvolvimento em Paralelo Figura 14 Processo de check-out no repositório de código fonte Figura 15 Processo de check-in no repositório de código fonte Figura 16 Fluxo principal do processo de Gerência de Configuração Figura 17 Fluxo de execução de Auditorias Periódicas Figura 18 Fluxo de execução de Auditorias de Baseline Figura 19 Fluxo de execução de Auditoria de Baseline de Release Figura 20 Fluxo de execução de Auditoria de Baseline de Desenvolvimento 48 Figura 21 Fluxo de execução de Controle de Não Conformidades Figura 22 Fluxo de controle de Solicitações de Mudança no produto Figura 23 Fluxo de controle de Solicitações de Mudança em documentos... 60

18 xvii LISTA DE GRÁFICOS Gráfico 1 Número de problemas registrados na liberação da versão... 68

19 INTRODUÇÃO 1 INTRODUÇÃO Contexto Segundo Pressman (2006), as mudanças em um produto de software são inevitáveis. Tais mudanças aumentam o nível de confusão entre os envolvidos em um projeto de desenvolvimento. Essa confusão ocorre devido à falta de análise e controle nas mudanças pretendidas. Esse conceito foi introduzido por Babich (1986, apud PRESSMAN, 2006) onde declara que: A arte de coordenar desenvolvimento de software para minimizar... confusão é chamada de gerência de configuração, que é a arte de identificar, organizar e controlar modificações no software que está sendo construído por uma equipe de programação. O objetivo é maximizar a produtividade pela minimização dos erros. (PRESSMAN, 2006, p. 599) Dessa maneira, ainda segundo o autor, para auxílio ao processo de engenharia de software no ciclo de desenvolvimento, o gerenciamento de configuração de software (Software Configuration Management SCM) vem para manter controle sobre as mudanças. Para tal, o processo define um conjunto de atividades que vão desde planejamento, controle das alterações e aviso a quem possa ter interesse nas mudanças. Assim, é possível facilitar o modo como as alterações ocorrem e o esforço necessário para sua realização. Para o controle das alterações realizadas no produto, o processo de Gerência de Configuração deve ser muito rigoroso em relação aos problemas descobertos e reparados. Como as correções e alterações solicitadas precisam ser liberadas aos clientes, acaba-se gerando uma série grande de versões do sistema, que precisam ser bem gerenciadas, para a garantia da presença das alterações solicitadas. (SOMMERVILLE, 2003) O gerenciamento de alterações por meio de versões deve ser muito cuidadoso, pois um único erro pode ocasionar o funcionamento inadequado do software. Dessa maneira, o uso de uma ferramenta para apoio ao controle de versões é essencial para a garantia da evolução das mudanças durante o ciclo de vida do software tanto que, desde a década de 70, vem sendo desenvolvidas várias ferramentas voltadas para esse objetivo. (SOMMERVILLE, 2003) Todo esse apoio ao processo busca a qualidade do software, um fator crítico para grande parte das organizações. Portanto, é necessário que os setores de software se atentem para a qualidade de seus produtos. Para garantia de qualidade e obtenção de um setor de software competitivo no mercado, as empresas de desenvolvimento de software passaram a

20 INTRODUÇÃO 2 seguir seu fluxo de desenvolvimento de software e serviços relacionados conforme padrões de qualidade em modelos de melhoria de processo, como o MPS.BR. (SOFTEX, 2009) O modelo segue os princípios da engenharia de software de acordo com o contexto das empresas brasileiras, para avaliação e melhoria de seus processos de software. Para isso, baseia-se nos conceitos de maturidade e capacidade de processo na melhoria da qualidade. Dessa maneira, é possível concluir que o uso dessa atividade é tão importante a ponto de melhorar o controle das alterações e garantir menor impacto na entrega da versão do software. Motivação e Objetivo De acordo com Oliveira et al. (2001), o processo de desenvolvimento de software é uma das atividades mais desafiadoras na área de tecnologia da informação. Tal atividade tem sido cada vez mais desafiadora atualmente devido à qualidade que o cliente espera em um produto oferecido. Portanto, o profissional que preza pela qualidade tem preferência de escolha no mercado de trabalho. Ainda segundo o autor, um produto de software não permanece inalterável. A alta demanda por mudanças para correções de erros ou melhoria de trabalho pode fazer com que as entregas de versões gerem muita instabilidade e grande impacto, podendo causar desconfiança do usuário no produto oferecido. Todos esses problemas ocorrem pela dificuldade que se tem atualmente em controlar as alterações do produto. Para melhorar esse cenário, as empresas precisam pensar na importância da implantação e execução de um processo de Gerência de Configuração de Software. Portanto, o objetivo deste trabalho é realizar um estudo de caso em uma pequena empresa de desenvolvimento de software de Ribeirão Preto, definindo e aplicando um processo de Gerência de Configuração de Software, mostrando os resultados obtidos antes e após a aplicação do processo, enfocando os aspectos de controle das alterações e impacto de instabilidade na entrega da versão final do software.

21 INTRODUÇÃO 3 Organização do Trabalho Para apresentar este trabalho a monografia está organizada em sete capítulos. No Capítulo 1 são apresentados os principais conceitos de engenharia de software, com a presença da Gerência de Configuração de Software como uma das principais atividades de apoio, uma vez que o foco deste trabalho é justamente essa atividade guarda-chuva. No Capítulo 2 são apresentados os conceitos relacionados à qualidade de produto e de processo junto aos padrões de qualidade que devem ser seguidos. Também é apresentada a importância do modelo de melhoria MPS.BR, uma vez que essa teoria será utilizada para a definição e aplicação do processo, já que a empresa onde o estudo de caso será realizado aplica este modelo de melhoria. No Capítulo 3 são apresentados os conceitos relacionados à Gerência de Configuração de Software. São apresentadas as atividades do processo, com base na visão estabelecida no SWEBOK (2004) Guide to the Software Engineering Body of Knowledge documento criado sob o patrocínio do IEEE com o objetivo de servir de base para os assuntos voltados para a área de engenharia de software. No Capítulo 4 é apresentada a metodologia aplicada para o mapeamento e o estudo de caso do processo de Gerência de Configuração. No Capítulo 5 o processo de Gerência de Configuração é mapeado de acordo com suas atividades e padrões de qualidade do modelo de melhoria MPS.BR. Esse mapeamento servirá de base para a aplicação do estudo de caso do processo em uma equipe de desenvolvimento. No Capítulo 6 é apresentado o estudo de caso aplicado em uma equipe de uma pequena empresa de desenvolvimento de software com os resultados obtidos na aplicação do processo. No Capítulo 7 são apresentadas as conclusões do trabalho, como as principais contribuições e limitações encontradas na realização do mesmo, além das oportunidades de melhoria e trabalhos futuros. Além dos capítulos descritos acima a monografia contém cinco Apêndices, que apresentam checklists de auditoria e um template do documento de planejamento do processo.

22 CAPÍTULO 1. ENGENHARIA DE SOFTWARE 4 CAPÍTULO 1. ENGENHARIA DE SOFTWARE O objetivo deste capítulo é apresentar os principais conceitos da engenharia de software, com base em suas etapas e atividades de apoio Considerações Iniciais A engenharia de software, segundo Sommerville (2003), é uma disciplina que abrange todos os aspectos relacionados à produção de software, desde o início com a especificação do sistema, até sua manutenção após entrar em operação. Dessa maneira, essa disciplina está voltada exclusivamente para os problemas encontrados na produção do software. Para controlar e resolver esses problemas, os engenheiros de software adotam técnicas que facilitam a produção do software resultando em um produto de alta qualidade. No contexto da engenharia de software, o processo é dividido em cinco etapas principais, apoiadas por atividades denominadas atividades guarda-chuva, que auxiliam no processo de desenvolvimento de software com qualidade. Dessa maneira, segundo Pressman (2006), ao seguir o fluxo das etapas do processo e apoio de suas atividades, é possível que o engenheiro de software tenha base para a construção do software com qualidade, diminuindo o impacto de instabilidade na entrega ao cliente. Portanto, estudar a teoria associada aos principais conceitos dessa disciplina é de fundamental importância para este trabalho Engenharia de Software Principais Conceitos De acordo com as definições da engenharia de software, Pressman (2006) encara essa disciplina como uma tecnologia dividida em camadas, conforme ilustrado na Figura 1. Sua base tem foco total na qualidade, com uma busca contínua no aperfeiçoamento de suas etapas. Figura 1 Camadas da Engenharia de Software FONTE: PRESSMAN, 2006, p. 17

23 CAPÍTULO 1. ENGENHARIA DE SOFTWARE 5 Para buscar a garantia da qualidade, a engenharia de software possui como alicerce de sua atividade a camada de processo. Essa camada une as camadas da tecnologia fazendo com que seja possível o desenvolvimento organizado de software. A camada dos métodos tem como objetivo descrever como será realizada a construção do software, ou seja, determina como as etapas da engenharia de software seguirão durante o ciclo de desenvolvimento. Na camada superior da Figura 1, a camada de ferramentas apóia as camadas métodos e processo na automatização de suas atividades. Abaixo, serão apresentadas as atividades da camada de processo na engenharia de software além dos modelos de processo existentes para aplicação dessas atividades, conforme seções e Processo de Software Segundo Pressman (2006), a camada processo é responsável por organizar o ciclo de desenvolvimento de software. É definido um esboço de processo, responsável pela identificação do número de atividades que podem ser aplicadas a qualquer projeto. Portanto, cada atividade da camada de processo define uma etapa importante do ciclo de desenvolvimento de software. Os nomes aplicados para cada atividade diferem de autor para autor, porém refletem o mesmo objetivo. Pressman (2006) define cinco atividades na camada de processo: Comunicação: etapa em que os requisitos para o software são levantados junto ao cliente. É também conhecida como engenharia de requisitos. Planejamento: etapa em que um plano para o trabalho da engenharia de software é elaborado. Nele, são descritas as atividades que serão executadas, os riscos, os recursos que serão necessários no projeto, os produtos de trabalho que serão produzidos e um cronograma de como o trabalho será realizado. Modelagem: etapa em que são criados modelos dos requisitos levantados para que o cliente e o desenvolvedor possam entender o que será implementado. Construção: etapa em que os requisitos levantados são codificados para geração do software. Envolve também a atividade de testes para revelar se existem erros no sistema desenvolvido. Implantação: etapa em que o software (completo ou parcial) é entregue ao cliente para avaliação se o que foi desenvolvido atende o que foi pedido. Nessa etapa também está

24 CAPÍTULO 1. ENGENHARIA DE SOFTWARE 6 presente a atividade de manutenção para novas solicitações que o cliente possa vir a pedir. Além das atividades principais, existem as atividades de apoio que completam o ciclo da engenharia de software, denominadas atividades guarda-chuva. As principais atividades dessa categoria, segundo Pressman (2006) são: Acompanhamento e controle de projeto de software: permite que a equipe de desenvolvimento possa acompanhar o andamento do projeto de acordo com o plano estabelecido. Dessa maneira, é possível antecipar algum problema que possa ocorrer e aplicar uma ação corretiva para manter o cronograma estabelecido para o projeto. Gerenciamento de risco: atividade que avalia os riscos que possam vir a atrapalhar o decorrer do projeto. Garantia de qualidade de software: são aplicadas as atividades necessárias para garantir a qualidade do software durante todo o ciclo de desenvolvimento. Revisões técnicas formais: atividade que avalia as alterações realizadas no produto visando corrigir os erros existentes, evitando que eles se mantenham durante os próximos projetos de desenvolvimento. Medição: são aplicadas medidas para o processo, projeto e produto visando entregar um produto com qualidade que satisfaça as necessidades do usuário. Gerenciamento de configuração de software: controla as alterações realizadas durante o ciclo de vida do software e diminui a confusão entre os envolvidos, por meio do relato contínuo de status do projeto. Gerenciamento de reusabilidade: define procedimentos para reutilização de produtos de trabalho para novos projetos. Incluem principalmente componentes de software ou funções específicas genéricas. As pessoas que possam ter interesse nesses ativos de reuso devem ser informadas da existência dos mesmos. Produção e preparação de documentos: inclui a criação de documentos e registros para os produtos de trabalho gerados no projeto. Conforme etapas e atividades de apoio descritas até aqui, é possível alcançar o real objetivo da engenharia de software, de entregar um produto final com alta qualidade. Para isso, as etapas do processo e suas atividades guarda-chuva devem se relacionar de forma lógica com um modelo de processo de software definido. A definição dos principais modelos de processo de software, bem como o modelo adotado para a atual metodologia de desenvolvimento ágil está presente na próxima seção.

25 CAPÍTULO 1. ENGENHARIA DE SOFTWARE Modelos de Processo de Software Para a execução das etapas do processo de engenharia de software existem modelos de processo que se encaixam em cada contexto organizacional. Segundo Pressman (2006), esses modelos são considerados modelos prescritivos, que definem como cada etapa do processo se inter-relaciona às outras. Dessa maneira, a escolha de qual modelo de processo seguir varia de situação para situação. O foco principal ao se escolher um modelo de processo é o controle sobre as alterações que devem ser aplicadas. Assim, a seguir serão descritos os principais modelos de processo de software segundo visão de Pressman (2006) e na Seção será apresentada a conclusão de qual modelo de processo é mais indicado para o atual contexto das empresas de desenvolvimento Modelo em Cascata Considerado o modelo mais antigo da engenharia de software, conhecido como ciclo de vida clássico. Sugere a aplicação de uma abordagem seqüencial em cada etapa da engenharia de software. A Figura 2 apresenta o modelo com cada etapa definida da engenharia de software. Figura 2 Modelo em Cascata FONTE: PRESSMAN, 2006, p. 39 Visto que o modelo segue seqüencialmente cada etapa da engenharia de software, pode-se inicialmente considerá-lo como um modelo seguro. Porém, no atual contexto das empresas de desenvolvimento, acaba se tornando um modelo difícil de ser seguido, pela dificuldade de se estabelecer todos os procedimentos no começo do projeto. Outro fato que o torna inviável na atual metodologia de desenvolvimento ágil é o fato de que uma versão só seria entregue em um período tardio, gerando insatisfação do cliente quanto ao prazo.

26 CAPÍTULO 1. ENGENHARIA DE SOFTWARE Modelo Incremental Esse modelo une os elementos do modelo em cascata, porém com uma aplicação iterativa. São aplicadas seqüências lineares de entregas de funcionalidade visando atender as etapas do processo de engenharia de software dentro de um prazo aceitável. Dessa maneira, após a entrega, o trabalho na expansão das funcionalidades desenvolvidas continua. A Figura 3 apresenta o modelo com o fluxo de trabalho das atividades de engenharia de software realizadas em todos os incrementos definidos. Figura 3 Modelo Incremental FONTE: PRESSMAN, 2006, p. 40 Um exemplo de aplicação desse modelo é o método que a maioria das empresas atuais adotou, denominado Scrum. Segundo Ken Schwaber e Jeff Sutherland (2010), o Scrum tem sido usado pelas empresas para apoio no desenvolvimento de produtos complexos. Porém, Scrum não é considerado um processo, e sim um framework que auxilia em trabalhos onde não é possível prever tudo que irá ocorrer de imediato. Então, por ser utilizado nas atuais empresas de desenvolvimento, que visam à entrega rápida de versões com as funcionalidades melhoradas por iterações, o modelo incremental deve ser aplicado corretamente para que a entrega do produto não gere instabilidade Modelo RAD O modelo RAD (Rapid Application Development Desenvolvimento Rápido de Aplicação) enfatiza o desenvolvimento rápido de alterações. Para isso, a construção dos sistemas é baseada em componentes. Porém, para sua aplicação é necessário um ambiente onde os requisitos são bem definidos.

27 CAPÍTULO 1. ENGENHARIA DE SOFTWARE 9 A Figura 4 apresenta o modelo onde o trabalho é dividido em componentes e cada equipe executa a modelagem e a construção para no fim ser feita a integração. Figura 4 Modelo RAD FONTE: PRESSMAN, 2006, p Prototipação Esse modelo permite que seja criado um protótipo do software que será construído. Dessa maneira, esse protótipo servirá para que se definam junto ao cliente os requisitos desejados do software. É sugerida sua utilização quando o cliente sabe o que deseja de funcionalidades no sistema, porém não identificou os procedimentos de entrada e saída. Portanto, seu funcionamento se dá pela obtenção das informações do sistema junto ao cliente, construção do protótipo com base nas informações e com visão voltada para o processamento do sistema. Uma vez pronto, o protótipo é mostrado ao cliente para validação das alterações solicitadas e refinamento. Com o protótipo refinado e fechado, o sistema pode ser construído. A Figura 5 ilustra o modelo conforme informações apresentadas para definição de um protótipo refinado para a construção do sistema.

28 CAPÍTULO 1. ENGENHARIA DE SOFTWARE 10 Figura 5 Modelo de Prototipação FONTE: PRESSMAN, 2006, p Espiral Esse modelo une a idéia da prototipação com os aspectos do modelo em cascata, visando o desenvolvimento rápido de versões. Em cada loop considera-se uma fase de desenvolvimento, que contém quatro etapas: planejamento, análise de riscos, construção, liberação e avaliação do cliente. No fim de um loop não é gerado necessariamente o produto, pode ser gerado um protótipo do que deve ser feito. Deve-se ter uma preocupação muito grande quanto à análise de riscos em cada loop visando garantir o fechamento no prazo. A Figura 6 apresenta o modelo com o loop que é aplicado na execução de suas quatro etapas. Figura 6 Modelo Espiral FONTE: PRESSMAN, 2006, p. 45

29 CAPÍTULO 1. ENGENHARIA DE SOFTWARE Conclusões sobre Processo e Modelos de Processo De acordo com as informações apresentadas neste capítulo, segundo visão de Pressman (2006), sobre o processo de software e modelos de processo de software, conclui-se que para atender as etapas da engenharia de software no atual contexto de desenvolvimento das empresas, o modelo de processo mais indicado é o incremental, pois visa à entrega de versões de maneira iterativa, sendo possível assim atender o prazo e em caso de problemas trabalhar na manutenção das funcionalidades. Porém, deve-se ter atenção quanto ao controle dessas mudanças, para que não gere instabilidade em uma transição de versão. Para esse controle organizado, qualidade é um item primordial. Assim, as atividades guarda-chuva do processo de engenharia de software apóiam de maneira sustentável o processo de desenvolvimento de software. Dentre as atividades guarda-chuva do processo, a que se encaixa no contexto de controle de mudanças é o Gerenciamento de Configuração de Software. Seu funcionamento é descrito no Capítulo 3 junto ao objetivo deste trabalho de aplicá-la em um processo de desenvolvimento Considerações Finais Neste capítulo foram apresentados os principais conceitos relacionados à engenharia de software, como o processo em si e os modelos de processo de software segundo visão estabelecida por Pressman (2006). Dentre os modelos de processo descritos e segundo metodologia aplicada pelas organizações, apoiou-se o uso do modelo incremental com atenção para a qualidade do produto, cujos conceitos serão apresentados no Capítulo 2 e o controle das mudanças no software com o gerenciamento de configuração de software, melhor explicado no Capítulo 3.

30 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO 12 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO O objetivo deste capítulo é apresentar os conceitos relacionados à qualidade de produto e de processo no contexto da engenharia de software, segundo visão de Sommerville (2003). Estas informações são de fundamental importância para o trabalho, pois para a definição de um processo de qualidade como a Gerência de Configuração é necessário o entendimento dessa teoria Considerações Iniciais Segundo Sommerville (2003), atualmente as organizações buscam atingir um alto nível de qualidade em seus produtos oferecidos. Produtos com baixa qualidade aumentam a desconfiança do cliente. Não é mais aceitável a entrega de produto com problemas. Para evitar problemas na entrega, é necessário um trabalho organizado para melhora de todas as atividades relacionadas ao processo de engenharia de software. Essa atividade é denominada Gerenciamento de Qualidade e é dividida, segundo Sommerville (2003), em três atividades: Garantia de Qualidade: definição de procedimentos a padrões que devem ser seguidos pela organização, buscando um software com qualidade. Planejamento de Qualidade: seleção dos procedimentos definidos na primeira atividade adequando ao projeto específico. Controle de Qualidade: verificar se os procedimentos e padrões estabelecidos estão sendo seguidos. A aplicação dessa atividade não depende do processo de desenvolvimento de software. A relação existente é a de garantia que o processo de desenvolvimento está sendo seguido de acordo com os padrões estabelecidos pela organização. Um processo de gerenciamento de qualidade pode seguir padrões já estabelecidos. Um dos padrões que pode ser utilizado é chamado de ISO 9001, considerado, segundo o autor, um padrão geral para as organizações que se preocupam com o processo de qualidade. Por não ser um padrão específico, as organizações que desejarem aplicar esse método devem definir e documentar um manual de qualidade. Uma melhor definição de padrões de qualidade é apresentada em próxima seção.

31 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO Padrões de Qualidade Segundo Sommerville (2003), as atividades do Gerenciamento de Qualidade definem padrões para que a qualidade nos produtos da organização seja atingida. Dessa maneira, esses padrões devem ser aplicados tanto no processo de desenvolvimento quanto no produto de software. Para isso, existem dois padrões definidos no processo de Gerenciamento de Qualidade, segundo visão do autor: Padrões de produto: aplicados no produto de software envolvido no processo de desenvolvimento. Entre seus procedimentos temos a elaboração de padrões de documentação e codificação. Padrões de processo: aplicados nos processos a serem seguidos durante o ciclo de desenvolvimento. Entre seus procedimentos temos a maneira como é feita a definição da especificação, o processo de validação das alterações e os documentos que precisam ser gerados no decorrer do projeto. Para garantia de que esses padrões estão sendo seguidos, os responsáveis pelo gerenciamento de qualidade devem sempre revisar se os envolvidos estão seguindo o que foi estabelecido. Em caso de dificuldade de seguir tais padrões, podem ser propostas revisões e modificações Qualidade de Produto e de Processo Principais Conceitos Qualidade de produto e de processo são itens altamente relacionados. Segundo Sommerville (2003), a qualidade no processo de desenvolvimento de software está relacionada com a qualidade dos produtos gerados. Dessa maneira, é possível verificar a importância da aplicação do processo de qualidade no ciclo de desenvolvimento de software. Mas para aplicação desse processo, é necessário identificar produtos que possuam um alto nível de qualidade e analisar os processos que são aplicados durante o ciclo de desenvolvimento, podendo assim aplicá-los para os projetos de desenvolvimento de produtos em que se deseja melhorar a qualidade. Para melhor entendimento, a Figura 7 mostra a definição de um processo de qualidade. Inicialmente o processo que será aplicado deve ser definido. Após isso, o produto deve ser desenvolvido seguindo os padrões estabelecidos no processo. A qualidade do produto depois é avaliada e no caso de bom resultado o processo é padronizado, caso não o processo deve ser melhorado voltando à fase de definição.

32 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO 14 Figura 7 Definição de um processo de qualidade FONTE: SOMMERVILLE, 2003, p MPS.BR Melhoria de Processo do Software Brasileiro Ter um processo de qualidade definido é essencial para que a organização garanta maior confiança de seus clientes em relação ao produto oferecido. Isso tem se tornado tão importante nos últimos tempos a ponto das empresas seguirem suas atividades de acordo com padrões internacionais de qualidade em modelos de melhoria de processo. (SOFTEX, 2009) Para isso, o MPS.BR (Melhoria de Processo do Software Brasileiro) vem para adequar o perfil das organizações de pequeno e médio porte na definição de seus processos. Criado em 2003 pela Associação para Promoção de Excelência do Software Brasileiro (SOFTEX), o modelo MPS.BR possui apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP), do Serviço de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID). Sua base de construção é composta pela norma ISO/IEC criada pela ISO International Organization for Standardization e o IEC International Electrotechnical Commission e segue o conteúdo do CMMI-SE/SW modelo de qualidade de software internacional. Além disso, o modelo visa avaliar as atividades de engenharia de software aplicadas pelas organizações para melhoria contínua do processo de software. Como avaliação, o MPS.BR aplica um modelo de processos de software e um método, fazendo com que as avaliações sejam padronizadas e aplicadas de maneira conforme. Além disso, também é aplicado um modelo de negócio que apóia a adoção pelas organizações. Dessa maneira, a Softex (2009) divide o modelo de avaliação MPS em três componentes, com definição por meio de documentos e com organização ilustrada na Figura 8 a seguir:

33 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO 15 Modelo de Referência (MR-MPS): apresenta o que se deve atender para cada processo da organização; Método de Avaliação (MA-MPS): apresenta o que os avaliadores do modelo devem avaliar para cada processo; Modelo de Negócio (MN-MPS): apresenta as regras de negócio para atender o modelo em cada processo da organização. Figura 8 Organização do Modelo MPS FONTE: SOFTEX, 2009, p Níveis de maturidade do MPS.BR O modelo MPS.BR é distribuído em níveis de maturidade de acordo com a capacidade de implantação de cada processo. (SOFTEX, 2009) Baseado no conteúdo do CMMI (modelo de qualidade de software internacional), que possui cinco níveis de maturidade, o MPS.BR aumentou a quantidade de níveis de maturidade para sete com o objetivo de possibilitar sua implementação pelas micro, pequenas e médias empresas. Além disso, a evolução dos níveis visa fornecer à organização a capacidade de saber como será seu desempenho ao executar um ou mais processos. A Figura 9 mostra a divisão dos níveis de maturidade do MPS.BR do A ao G, iniciando a implantação pelo nível G e terminando no nível A.

34 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO 16 Figura 9 Níveis de Maturidade do MPS.BR FONTE: Quanto à distribuição dos processos por nível, a Softex (2009) define o termo Capacidade do Processo formado por atributos de processo (AP) e resultados esperados (RAP). Portanto, todos os processos de um nível de maturidade possuem AP e RAP e a certificação por níveis é acumulativa, ou seja, ao certificar-se no nível F, além dos AP e RAP desse nível, os AP e RAP do nível G também devem ser revistos. Isto significa que os processos do nível G devem ser executados no nível de capacidade esperado no nível F. Existem nove atributos de processo (AP) distribuídos nos sete níveis de maturidade, de acordo com a Softex (2009): 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.

35 CAPÍTULO 2. QUALIDADE DE PRODUTO E DE PROCESSO 17 O Quadro 1 a seguir apresenta os níveis de maturidade do modelo MR-MPS, com os processos e atributos de processo que o compõem, conforme definição da Softex (2009). Quadro 1 Níveis de maturidade do MPS.BR Nível Processos Atributos de Processo A B C D E F G 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 Gerência de Projetos GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 Gerência de Riscos GRI AP 1.1, AP 2.1, AP 2.2, Desenvolvimento para Reutilização DRU AP 3.1 e AP 3.2 Gerência de Decisões GDE Verificação VER AP 1.1, AP 2.1, AP 2.2, Validação VAL AP 3.1 e AP 3.2 Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) AP 1.1, AP 2.1, AP 2.2, Gerência de Reutilização GRU AP 3.1 e AP 3.2 Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional - AMP Medição MED AP 1.1, AP 2.1 e AP 2.2 Garantia da Qualidade GQA Gerência de Portfólio de Projetos GPP Gerência de Configuração GCO Aquisição AQU Gerência de Requisitos GRE AP 1.1 e AP 2.1 Gerência de Projetos GPR FONTE: SOFTEX, 2009, p Considerações Finais Neste capítulo foram apresentados os principais conceitos relacionados à qualidade de produto e de processo, bem como a importância da definição de um processo de qualidade e sua relação com os modelos de melhoria de processo, como o MPS.BR. Como processo importante do modelo, temos a definição da Gerência de Configuração, com sua importância na gerência dos produtos de trabalho. No próximo capítulo será apresentada essa atividade e no Capítulo 5 o processo será mapeado, de acordo com os padrões do próprio modelo MPS.BR.

36 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 18 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE O objetivo deste capítulo é apresentar a teoria e as atividades do processo de Gerência de Configuração de Software, segundo visão do SWEBOK (2004), Pressman (2006) e Sommerville (2003): três das mais importantes fontes de pesquisa na área. Além disso, serão apresentados os resultados esperados pela Gerência de Configuração segundo o modelo de melhoria de processo MPS.BR. Com base nesta teoria é possível entender o processo de acordo com as atividades apresentadas, além da possibilidade de mapeá-lo para atender os resultados esperados pelo modelo de melhoria de processo MPS.BR, o que será feito no Capítulo Considerações Iniciais Segundo Pressman (2006), o software pode ser dividido em três amplas categorias de informações: Programas de computador: em forma de executável ou de código fonte; Documentos: com a descrição das implementações (voltado tanto a profissionais como a usuários); Estruturas de dados: existentes no programa. Os itens que unem os resultados dessas categorias são considerados como configuração de software. Portanto, a configuração de software pode ser descrita como uma coleção de versões específicas de software, com seus itens combinados segundo procedimentos específicos de um propósito particular. (SWEBOK, 2004) 3.2. Definição Segundo o SWEBOK (2004), o Gerenciamento de Configuração de Software é a atividade responsável por identificar a configuração de um sistema em diferentes pontos do seu ciclo de vida a fim de controlar as alterações, mantendo a integridade e possibilitando a rastreabilidade da configuração. O conceito de Gerência de Configuração é formalmente definido pelo IEEE (1990, apud SWEBOK, 2004) como uma disciplina que aplica direção técnica e administrativa para identificar e documentar as características funcionais de um item de configuração. Controla as

37 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 19 mudanças que ocorrem no produto de software e reporta aos interessados a mudança realizada e o status da implementação de acordo com o requisito especificado Atividades da Gerência de Configuração de Software O processo de Gerência de Configuração de Software possui um grande controle de qualidade, por isso, está proximamente relacionado à Garantia de Qualidade de Software (Software Quality Assurance SQA) Para melhor explicar o funcionamento da Garantia de Qualidade de Software, o SWEBOK (2004) define esse modelo como um conjunto de tarefas que indicam como o planejamento de software (por exemplo, a Gerência de Configuração) está sendo executado e se os produtos finais gerados possuem os requisitos especificados. Dessa maneira, os resultados dessas tarefas são reportados aos interessados para gerenciamento antes que uma ação corretiva seja tomada. Assim, a Gerência de Configuração de Software possui atividades para atender os objetivos da Garantia de Qualidade de Software. Segundo o SWEBOK (2004) as atividades de Gerenciamento de Configuração de Software são divididas em: Planejamento do processo da Gerência de Configuração de Software. (PGCS) Identificação da Configuração do Software. Controle da Configuração do Software. Informação do Status da Configuração do Software. Auditoria na Configuração de Software. Gerenciamento de Liberação do Software e Entrega (Release). A Figura 10 mostra cada uma dessas atividades. Cada uma delas será apresentada no decorrer dessa seção. A atividade Planejamento do processo da Gerência de Configuração de Software (PGCS) é o marco inicial do processo de Gerência de Configuração, seguida da Identificação da Configuração do Software, considerada a base para as outras atividades. A atividade Controle da Configuração do Software (Controle) checa se as alterações previstas serão autorizadas. Já a atividade Informação do Status da Configuração do Software é responsável por reportar o status à Gerência de Projeto, Equipe de Desenvolvimento e Garantia de Qualidade do Produto durante o ciclo de desenvolvimento. Quando o fluxo de

38 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 20 desenvolvimento e validação das alterações termina, a Auditoria na Configuração do Software é realizada, onde a integridade física e funcional do produto é verificada. Por último, temos o Gerenciamento de Liberação do Software e Entrega (Release), realizado no fim do projeto de desenvolvimento, onde o software é liberado para que possa ser entregue ao cliente. Figura 10 Atividades de Gerenciamento de Configuração de Software FONTE: SWEBOK, 2004, p Planejamento do processo da Gerência de Configuração de Software (PGCS) Segundo o SWEBOK (2004), para que o planejamento da Gerência de Configuração de um projeto ocorra de maneira correta é necessário um gerenciamento com cautela. Para tal, é necessário conhecer o contexto organizacional e as restrições existentes sobre o processo. Portanto, para planejar o processo de Gerência de Configuração em um projeto é necessária a interação com as atividades e os elementos organizacionais, pois ajudam nos processos de Engenharia de Software. Dessa maneira, a Gerência de Configuração interage principalmente com a atividade de Garantia de Qualidade em relação a registros de itens não conforme no processo de desenvolvimento. Geralmente, gerenciar itens não conforme é uma tarefa da Garantia de Qualidade, porém, a Gerência de Configuração ajuda nesse contexto rastreando e reportando aos envolvidos os itens de configuração de software que se inserem nessa situação.

39 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE Plano de Gerência de Configuração Para o SWEBOK (2004), a organização de um plano de Gerência de Configuração para um projeto de desenvolvimento deve ser de acordo com o contexto organizacional. O plano deve descrever como as atividades seguintes do processo serão realizadas: Identificação, Controle, Status, Auditoria e Liberação da Configuração do Software. Os resultados da atividade de planejamento devem ser registrados no plano de Gerência de Configuração, sujeito a análise e auditoria pela Garantia de Qualidade. A organização do plano não pode gerar confusão sobre a atividade de cada pessoa envolvida no projeto Ferramenta de apoio de controle das alterações Para uma boa atividade de Planejamento da Gerência de Configuração, deve-se ter definida uma ferramenta de apoio ao processo e aos procedimentos de utilização. Dessa maneira, segundo o SWEBOK (2004), o uso de ferramentas automatizadas no processo de Gerência de Configuração facilita ainda mais o processo, que requer um gerenciamento cuidadoso em cada tarefa. Geralmente, existem ferramentas grátis no mercado de apoio a algumas atividades e outras podem ser desenvolvidas, abrangendo todo o processo. As principais funcionalidades que devem estar presentes em ferramentas de apoio devem fornecer suporte para: Biblioteca da gerência de configuração. Solicitação de mudança e os procedimentos de aprovação. Código fonte (e produtos de trabalho relacionados). Relatórios do estado da gerência de configuração e coleta de medições. Auditorias na configuração do software. Acompanhamento da configuração do software. Liberação de releases. Gerenciamento de releases de software e distribuição. A Figura 11 apresenta as funcionalidades que devem existir em ferramentas automatizadas para as atividades do Gerenciamento de Configuração ilustradas na Figura 10. Para a atividade Controle em específico já há disponível no mercado várias ferramentas grátis para controle das alterações realizadas no código fonte e documentos do produto,

40 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 22 conhecidas como ferramentas de Controle de Versão. Para os outros procedimentos, é possível automatizar as funcionalidades em ferramenta de apoio. Figura 11 Características de ferramentas de Gerência de Configuração e seus procedimentos FONTE: SWEBOK, 2004, p. 7 4 Os sistemas de gerenciamento de código apóiam no controle de alterações no código fonte do produto por meio de bibliotecas de software (também chamado de repositório de software). Dessa maneira, segundo Pressman (2006), quando algum envolvido no projeto desejar implementar uma mudança na biblioteca de código fonte, é feita uma cópia desses dados para a área de trabalho do responsável. O mesmo pode trabalhar em sua cópia até que a mudança esteja finalizada. Assim, para que ela seja integrada novamente a biblioteca, ela deve estar aprovada. Para isso, os procedimentos de controle da solicitação de mudança devem ser seguidos. Tais procedimentos serão descritos ainda nessa seção, na atividade de Controle da Configuração do Software Fechamento do Plano de Gerência de Configuração Dadas as fases descritas anteriormente, os resultados do planejamento de Gerência de Configuração para um projeto devem ser registrados um Plano de Gerência de Configuração, que servirá como referência no processo. Conforme as mudanças no processo de Gerência de Configuração ocorrem o é atualizado. (SWEBOK, 2004)

41 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 23 A orientação das informações que devem estar presentes em um Plano de Gerência de Configuração é descrita segundo IEEE (1998, apud SWEBOK, 2004) por meio seis itens, a saber: Introdução (abrangência, finalidade). Gerenciamento (responsabilidades, políticas aplicáveis, diretrizes e procedimentos). Atividades seguintes do processo (identificação da configuração, controle da configuração, e assim por diante). Agendamentos Horários (coordenação com outras atividades do projeto). Recursos (ferramentas, recursos físicos e humanos). Manutenção. Dessa maneira, após executado o planejamento, as atividades impostas devem ser acompanhadas, verificando se estão sendo devidamente realizadas. Os problemas encontrados devem ser gerenciados por meio de não conformidades, até que a ação corretiva para a mesma seja tomada. Seguidas as tarefas descritas anteriormente, o Plano de Gerência de Configuração gerado obterá todas as informações necessárias para a execução da Gerência de Configuração no projeto e as atividades seguintes poderão ser seguidas Identificação da Configuração do Software Segundo o SWEBOK (2004), a atividade de Identificação da Configuração do Software é responsável pela identificação dos itens que serão controlados durante o ciclo de desenvolvimento do projeto. Além da importância da atividade de Planejamento, a Identificação da Configuração também é muito importante, tanto que é considerada base para as demais atividades do processo de Gerência de Configuração de Software. Por sua importância, o marco de início se dá junto ao processo de planejamento, pois os itens que serão controlados pelo processo precisam ser identificados. Esses itens que estarão sob o controle de configuração são considerados como itens de configuração e possuem relação com linhas base (baselines). (SOMMERVILLE, 2003) Além dos itens de configuração e baselines, descritos acima e melhor explicados nas próximas seções, o SWEBOK (2004) descreve a importância de se estabelecer as ferramentas e técnicas que serão utilizadas para o gerenciamento e controle do processo.

42 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE Itens de Configuração de Software Segundo Pressman (2006), um item de configuração de software é uma informação criada no processo de engenharia de software. Um item de configuração (IC) é parte de uma união de software voltada para a Gerência de Configuração. Segundo o SWEBOK (2004), vários itens podem ser considerados Itens de Configuração de Software, entre eles: Planos de Execução. Especificações e Documentação do Projeto. Ferramentas de Software. Código Fonte e Executáveis. Documentação de Instalação, Manutenção, Operação e Uso de Software. Do ponto de vista obtido por Oliveira et al. (2001), dividir um produto de software em itens de configuração e a definição do ciclo de vida de cada um desses itens é considerado uma decisão de projeto, e não do processo de Gerência de Configuração. As relações entre os Itens de Configuração e as partes que os constituem afetam algumas tarefas do processo de Gerência de Configuração, como a análise de impacto nas solicitações de mudanças previstas. Dessa maneira, controlar essas relações é de extrema importância para apoiar a rastreabilidade da alteração, ou seja, identificar para a mudança solicitada, quais itens são impactados. Para isso, deve ser aplicada uma atividade de identificação da rastreabilidade para cada Item de Configuração mapeado. (SWEBOK, 2004) Concluindo, é importante salientar que os itens considerados itens de configuração, devem ser armazenados em bibliotecas de código (repositórios), para controle das mudanças. O funcionamento do controle de mudanças será descrito ainda neste capítulo Baselines (Linhas Básicas) Segundo Pressman (2006), a mudança é um fato no ciclo de desenvolvimento. Isso ocorre pelo conhecimento e afinidade que se adquire com o passar do tempo no uso de um produto de software. Essas mudanças, quando controladas por um processo de Gerência de Configuração, são fixadas em uma linha básica (baseline). Uma baseline é composta por um conjunto de itens de configuração presentes em um tempo específico durante o ciclo de vida do software. Pode-se usar essa identificação para se

43 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 25 referir a uma versão específica de um Item de Configuração. Porém, independente do caso, uma alteração só pode ocorrer na baseline por meio de aprovação da solicitação de mudança, de acordo com o que está estabelecido nos procedimentos da tarefa de Controle de Mudanças. Assim, uma baseline, com suas alterações representa a configuração atual no dado momento do ciclo de vida do software. (SWEBOK, 2004) Oliveira et al. (2001) também segue esse mesmo raciocínio quanto a definição de baseline e descreve o mecanismo do controle de mudanças como a geração de uma nova configuração de software da baseline, baseada na baseline anterior, fixada no tempo do ciclo de vida do software, onde todas as alterações anteriores realizadas estão presentes. A Figura 12 explica melhor o funcionamento do mecanismo de alteração em uma baseline, mediante solicitações de novas mudanças segundo descrito anteriormente. Nessa figura, temos a configuração-base, contendo a configuração do software no tempo específico. A partir do momento que novos itens forem solicitados para desenvolvimento, uma nova configuração-base do software deve ser gerada, baseada na configuração antiga, seguindo o fluxo de evolução das alterações, porém mantendo a configuração de software presente no tempo específico do ciclo de vida. Figura 12 Mecanismo de alteração em uma baseline FONTE: OLIVEIRA et al, 2001, p. 27 saber: O SWEBOK (2004) considera quatro tipos de baselines comuns para um produto, a

44 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 26 Baseline Funcional: corresponde aos requisitos da especificação; Baseline Alocada: corresponde a revisão dos requisitos da especificação do software; Baseline de Desenvolvimento: representa a configuração do software em questão, em um tempo específico selecionado durante o ciclo de vida do software; Baseline de Produto: corresponde ao produto de software entregue preenchido para integração de sistemas. Dessa maneira, as baselines que serão usadas em determinado projeto, como o nível de controle necessário para a aprovação da mudança são identificados no Plano de Gerência de Configuração de Software Repositório de Dados (Biblioteca de Software) Segundo o SWEBOK (2004), uma biblioteca de software, também conhecida como repositório de dados contém os itens de configuração mapeados para o processo de Gerência de Configuração. Dessa maneira é possível unir em local comum todos os itens de configuração para acesso dos envolvidos, facilitando o processo de desenvolvimento. Não existe restrição quanto à quantidade de repositórios que podem ser utilizados no processo de Gerência de Configuração e a organização de seus diretórios. O SWEBOK (2004) sugere para o repositório de código fonte um diretório para manter a baseline de evolução da codificação e um diretório para manter as baselines de manutenção. Quanto aos produtos fechados, também se mantém um diretório para armazenamento dessas baselines, com controle de identificação por versionamento. O funcionamento do controle de mudanças será descrito ainda neste capítulo. Manter e controlar a configuração desses conjuntos de itens agrupados em uma baseline do repositório exige um nível de controle de acesso e privilégios determinado de acordo com a participação de cada envolvido no processo de desenvolvimento, sem contar a importância de se manter um backup desses dados. Assim, existem ferramentas de controle de alterações que apóiam o processo de Gerência de Configuração quanto às alterações realizadas e o versionamento aplicado nas baselines com controle por meio de permissão de acesso. Para o SWEBOK (2004), além dos benefícios descritos, o uso de ferramentas de controle de alterações gera informação para acompanhamento e medição do trabalho.

45 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE Controle da Configuração do Software Identificadas as configurações de software é necessário descrever como controlá-las. Segundo o SWEBOK (2004), o controle da configuração do software está voltado para as mudanças inevitáveis que ocorrem durante o ciclo de vida do software. Essa atividade deve determinar se as mudanças não impactarão na baseline do produto e controlar o acesso aos itens de configuração de acordo com os envolvidos no processo de desenvolvimento de software em um projeto. Pressman (2006) descreve o controle de mudanças na configuração do software como uma atividade que deve garantir a qualidade e integridade da baseline após a alteração realizada nos itens de configuração. Dessa maneira, essa atividade se inicia a partir do momento em que uma solicitação de mudança (SM) é sugerida, fazendo com que o responsável pela Gerência de Configuração analise o impacto que essa alteração pode gerar na atualização do item de configuração da baseline. Para melhor explicar essa atividade, as seções seguintes descrevem as tarefas que estão relacionadas ao controle de configuração e o funcionamento de cada uma Análise e Aprovação de uma Solicitação de Mudança (SM) Segundo o SWEBOK (2004), a primeira tarefa para gerenciar as mudanças que são realizadas nos itens de configuração mapeados é determinar quais mudanças estão previstas. O processo de solicitação de alteração no software é feito por meio de um procedimento formal, onde a SM gerada é analisada e, dependendo do resultado, será aceita, modificada ou rejeitada. Uma SM pode ser originada por qualquer pessoa a qualquer momento no ciclo de vida do software e pode ter como informação a proposta de solução e a prioridade solicitada. A geração de SMs é uma ação corretiva em resposta a problemas existentes no produto em questão. Dessa maneira cabe ao responsável pela Gerência de Configuração analisar se essa SM poderá ser desenvolvida na baseline. Tendo uma SM cadastrada para cada tipo de alteração (correção ou melhoria) facilita acompanhar a situação de cada item, bem como coletar medidas das atividades para cada tipo de alteração. Ao receber uma SM para o produto, uma atividade análise de impacto deve ser realizada para verificar se a alteração será realizada na baseline naquele tempo do ciclo de vida do software. Para realizar a atividade de análise de impacto, no entanto, é necessário os

46 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 28 responsáveis terem um bom conhecimento nos itens de software que são relacionados à funcionalidade. O resultado dessa análise irá definir se a implementação da SM na baseline afetada será aceita, modificada, recusada ou adiada para que sejam feitas alterações na descrição da alteração. Para avaliar se a SM será implementada ou não, o SWEBOK (2004) também define uma entidade responsável denominada CCB (Control Configuration Board Controle de Configuração). A aplicação dessa tarefa é de grande importância em projetos de desenvolvimento, pois avalia e escolhe as SMs que serão implementadas. Para tal, são avaliados os níveis de criticidade para implementação da alteração e o impacto que a mesma causará, portanto o responsável pela Gerência de Configuração deve estar presente para conhecimento do que está previsto para alteração na baseline. Por sua importância, essa tarefa é sujeita à Auditoria de Qualidade de Software Implementação das SMs previstas Segundo o SWEBOK (2004), uma SM deve ser registrada por meio de formulário ou ferramenta de apoio ao processo para registro do que pode ser mudado na baseline. Dessa maneira, após aprovação das SMs que irão ser implementadas na baseline pelo CCB, vinculam-se as mesmas ao projeto, garantindo controle do que é implementado e dando suporte à próxima atividade do processo de Gerência de Configuração, a Auditoria na Configuração do Software. Assim, tendo registrado as SMs previstas para desenvolvimento no projeto, o controle é feito para garantia que elas possam ser implementadas em simultâneo pelos envolvidos na baseline. Fechadas as alterações previstas para o projeto, a próxima atividade descrita é a auditoria na configuração. Esta é realizada para assegurar que somente as alterações aprovadas foram aplicadas. Para acompanhamento no desenvolvimento das alterações, a ferramenta de Controle de Versões garante a implementação efetiva dessas mudanças, por meio de rastreamento dos itens de configuração alterados para cada SM, garantindo a integridade das alterações Controle de Versões Segundo Pressman (2006), o controle de versões utiliza ferramentas de apoio para gerenciar versões de baselines de desenvolvimento criadas durante o ciclo de vida do software.

47 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 29 Ainda segundo o autor, o controle de versões pode ser definido como uma tarefa que permite alterações em configurações específicas com versões apropriadas. Utilizando um processo de gerenciamento de versões, é possível que se recupere a configuração de uma versão anterior quando necessário e também garantir que não ocorram alterações que não sejam planejadas e executadas de maneira correta. (SOMMERVILLE, 2003) Para melhor entendimento do que é uma versão de sistema, Sommerville (2003) a define como uma instância do produto de software que difere das outras instâncias. Dessa maneira, uma versão nova do sistema possui diferentes funcionalidades em relação às outras versões. Ainda, segundo o mesmo autor, é definido o termo release no controle de versões, considerado como uma versão do software que pode ser distribuída a clientes. Portanto, entregas desses releases são marcadas pela presença de novas funcionalidades. Porém a versão com essas novas funcionalidades não pode gerar instabilidade no funcionamento das funcionalidades já presentes, como perda da alteração. Essa distinção descrita pelo autor entre o termo versão e release no Controle de Versões serve para conhecimento do que pode ou não ser liberado para clientes, caso esse do release. Já, uma versão do sistema criada serve para controle da organização no processo de desenvolvimento e validação. As ferramentas de apoio disponíveis para o controle de versão geram, segundo descrito por Oliveira et al. (2001), um melhor controle do desenvolvimento em paralelo pelos integrantes da equipe de desenvolvimento. Para esse desenvolvimento descrito, caminhos paralelos são gerados a um caminho principal definido, também conhecido como tronco principal. Com esse recurso, é possível atender a demanda específica de SMs de determinado cliente com o desenvolvimento em determinadas versões e não em outras. Além disso, versões de teste para alterações podem ser geradas, podendo essas alterações ser ou não integradas às versões seguintes. A Figura 13 exemplifica o funcionamento do controle em paralelo do desenvolvimento das alterações, por meio de caminhos principais definidos.

48 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 30 Figura 13 Controle de Versões com Desenvolvimento em Paralelo FONTE: OLIVEIRA et al, 2001, p. 46 Conforme a figura, a numeração de versões é a técnica mais usada para identificação das versões. Geralmente, o versionamento aplicado pode mudar de acordo com o contexto de cada organização. (SOMMERVILLE, 2003) Controle de Mudanças Para controle de mudanças nas baselines de desenvolvimento identificadas por versionamento por meio de ferramenta de controle de versões são definidos os processos de check-out e check-in, com o controle de sincronização e acesso, considerados dois elementos muito importantes. (PRESSMAN, 2006) Para Oliveira et al. (2001), cada um desses processos no controle de mudanças tem o seguinte funcionamento: Check-out: uma cópia dos dados de trabalho do repositório de código fonte é obtida para que o usuário possa fazer as alterações previstas. A Figura 14 mostra o funcionamento do processo de check-out onde as alterações do repositório são sincronizadas com a área de trabalho do usuário.

49 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 31 Figura 14 Processo de check-out no repositório de código fonte FONTE: OLIVEIRA et al, 2001, p. 47 Check-in: depois de realizadas as alterações previstas após o processo de check-out, essas alterações precisam ser passadas ao repositório para que os outros usuários possam acessá-las em sua sincronização, portanto uma nova versão do arquivo é criada no repositório a partir do que foi alterado na cópia de trabalho do usuário. A Figura 15 mostra o funcionamento do processo de check-in onde as alterações realizadas na área de trabalho do usuário são atualizadas no repositório de código fonte.

50 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 32 Figura 15 Processo de check-in no repositório de código fonte FONTE: OLIVEIRA et al, 2001, p. 47 Os itens de configuração que podem fazer parte da baseline possuem apenas um nível de controle informal para mudanças. Portanto, o responsável pelas alterações pode realizar as alterações que forem necessárias no mesmo, sempre garantindo que essas alterações não gerem impacto no produto. Porém, se esse item de configuração, após alteração, passar a fazer parte da baseline, deve ser implementado o controle de mudanças na configuração, sendo possível realizar novas alterações nesse item somente por meio de SMs que serão analisadas antes de aceitação. (PRESSMAN, 2006) Informação do Status da Configuração do Software Segundo o SWEBOK (2004), essa atividade é responsável pela transmissão das informações sobre o produto durante seu ciclo de vida. Uma das principais informações geradas durante o processo é o status da configuração na evolução das alterações. Tais informações sobre a configuração do software devem ser identificadas, coletadas e mantidas. Entre essas informações, considera-se a identificação e o atual estágio de implantação das mudanças. Essas informações podem ser geradas em relatórios principalmente por meio de ferramentas automatizadas que apóiam o processo.

51 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE O Relato do Status da Configuração Segundo o SWEBOK (2004), as informações coletadas durante o processo de Gerência de Configuração no desenvolvimento das alterações podem ser usadas por vários elementos da organização ou do projeto, como a equipe de desenvolvimento e manutenção, o Gerente de Projeto e a atividade de qualidade de software. Pressman (2006, p. 612) define o relato de status da configuração como uma tarefa de SCM que responde às seguintes questões: (1) O que aconteceu? (2) Quem fez? (3) Quando aconteceu? (4) O que mais será afetado? Portanto, a atividade de informação do status da configuração é responsável por gerar relatórios que respondem essas questões para todos os envolvidos no projeto. Algumas dessas informações podem se tornar registros da Garantia de Qualidade. O resultado dessas informações pode servir como medidas para a equipe de desenvolvimento, facilitando o processo de desenvolvimento de alterações nos itens de configuração mapeados Auditoria na Configuração do Software Segundo Pressman (2006), as tarefas de identificação, controle de versão e de mudanças ajudam de maneira significativa o processo de desenvolvimento de alterações em uma baseline sem gerar uma situação crítica. Porém, para garantir que a SM foi implementada de maneira adequada, é necessária a execução das tarefas de revisão técnica e auditoria na configuração do software. Para a tarefa de revisão técnica, Pressman (2006) a define como uma análise técnica nos itens de configuração alterados em cada SM, avaliando a integridade da funcionalidade após a alteração. Já, para a tarefa de auditoria na configuração do software, o SWEBOK (2004) a define como uma atividade que avalia de forma independente a conformidade do produto alterado de acordo com os regulamentos e procedimentos definidos pela organização. É uma tarefa composta de várias atribuições e responsabilidades aplicadas ao auditor. Para facilitar esse processo podem ser desenvolvidas ferramentas de apoio na condução da auditoria. O fato de se aplicar essas tarefas para a atividade de Auditoria na Configuração do Software está relacionado com a importância de garantir que os itens de software alterados satisfaçam as características físicas e funcionais exigidas. Dessa maneira, conforme características descritas, as seguintes auditorias podem ser executadas no processo de

52 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 34 Gerência de Configuração: Auditoria de Configuração Funcional e Auditoria de Configuração Física. Existe também a Auditoria de Baseline, realizada após as duas primeiras auditorias descritas. O objetivo de cada auditoria é definido, segundo a visão do SWEBOK (2004), a saber: Auditoria de Configuração Funcional: seu objetivo é garantir que o item de software (também conhecido como artefato de software) alterado está em conformidade com a rastreabilidade aplicada na atividade de Identificação da Configuração do Software. É uma análise muito importante no processo e essencial para auditoria. Auditoria de Configuração Física: seu objetivo é garantir que a documentação gerada no processo de desenvolvimento do projeto está consistente com o produto de software fechado. Auditoria de Baseline: ao contrário das auditorias relatadas anteriormente, que são realizadas durante o processo de desenvolvimento para garantia e verificação do estado dos itens de software, a Auditoria de Baseline é aplicada para assegurar um desempenho de acordo com as SMs implementadas e garantir que a documentação contínua siga consistente desde o marco inicial no processo de desenvolvimento do projeto. Portanto, segundo visão de Pressman (2006), a atividade de Auditoria na Configuração do Software complementa a tarefa de revisão técnica, onde várias perguntas são respondidas para garantia da conformidade do processo. Essas perguntas variam de acordo com o processo de cada organização, mas o objetivo da atividade é garantir a integridade de uma baseline e diminuir o impacto na liberação ao cliente Gerenciamento de Liberação do Software e Entrega (Release) Segundo o SWEBOK (2004), a atividade de liberação do software é responsável pela distribuição dos itens de configuração de software de uma baseline fora da atividade de desenvolvimento. Essas liberações não são só relacionadas à entrega ao cliente, podendo também ser liberações internas para validação ou fechamento do ciclo de desenvolvimento do projeto. É uma atividade que tem relação com a tarefa de Controle de Versões. Um release entregue ao cliente deve possuir alguns itens importantes, conforme estabelecido pelo Sommerville (2003): Código executável: o código fonte da versão que será disponibilizada é compilado e o executável gerado.

53 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 35 Arquivos de configuração: definem como deve ser feita a configuração para utilização do sistema. Arquivos de dados: arquivos necessários para que o sistema seja executado sem problemas. Instalador: objetivo de ajudar o cliente a instalar o sistema em seu ambiente de utilização. Documentação: contendo a descrição do sistema. No caso de um release para um cliente que já utiliza o sistema, aconselha-se gerar um documento que descreva as alterações que foram realizadas na versão Geração de Build do Software O termo build descrito refere-se à construção do software, que consiste na compilação do código fonte e geração do executável do sistema. Dessa maneira, segundo o SWEBOK (2004), essa tarefa consiste na combinação dos itens de configuração de código fonte para build do software e entrega ao cliente, ou até para a equipe de teste, para validação das SMs implementadas. Para facilitar o processo, um build do sistema é gerado por meio de ferramentas de apoio, como compiladores. Através deles é possível gerar o executável de qualquer versão gerenciada pelo Controle de Versões. O uso de compiladores para construção do software também facilita o processo em grandes projetos, onde ocorre o desenvolvimento em paralelo. Além disso, é possível atribuir o versionamento para identificação do executável pelos clientes ou pela equipe de teste. Por ser responsável por transformar o código fonte com todas as alterações desenvolvidas em uma baseline, essa atividade também está sujeita a verificação de qualidade. Essa última atividade do processo de Gerência de Configuração tem grande importância, pois une todo o trabalho realizado em forma de código executável. Nesse marco do processo temos a liberação das SMs desenvolvidas, as quais foram devidamente planejadas, identificadas, controladas e auditadas. Assim, a informação da liberação pode ser passada a todos que venham a ter interesse nela.

54 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE Gerência de Configuração de Software segundo MPS.BR Segundo a Softex (2009), o processo de Gerência de Configuração de Software no modelo MPS.BR tem como principal objetivo estabelecer e manter a integridade do produto de software em um projeto e disponibilizá-lo às pessoas que têm interesse nele. Para atingir esse objetivo, o processo de Gerência de Configuração segundo o MPS.BR (GCO) possui um conjunto de resultados esperados, que precisam refletir no processo mapeado. A seguir é apresentado o conjunto de sete resultados esperados que a Softex (2009) define: GCO 1 Um Sistema de Gerência de Configuração é estabelecido e mantido. GCO 2 Os itens de configuração são identificados com base em critérios estabelecidos. GCO 3 Os itens de configuração sujeitos a um controle formal são colocados sob baseline. GCO 4 A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada. GCO 5 Modificações em itens de configuração são controladas. GCO 6 O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados. GCO 7 Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes. Com base nesses resultados o processo de Gerência de Configuração foi mapeado, atendendo o nível F de maturidade do modelo MPS.BR, o que será apresentado nos próximos capítulos Considerações Finais Neste capítulo foram apresentados os conceitos que envolvem a Gerência de Configuração de Software, bem como todas as atividades relacionadas desse processo e como elas devem ser executadas, segundo visão estabelecida pelo SWEBOK (2004). Também foram apresentados os resultados esperados pela Gerência de Configuração segundo o modelo de melhoria de processo MPS.BR.

55 CAPÍTULO 3. GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE 37 Com todas essas informações foi possível mapear o processo de Gerência de Configuração para realização do estudo de caso, conforme apresentado nos capítulos a seguir.

56 CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO 38 CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO O objetivo deste capítulo é apresentar a metodologia aplicada para o mapeamento e o estudo de caso do processo de Gerência de Configuração realizado na pequena empresa de desenvolvimento de software de Ribeirão Preto. Serão apresentadas as características da empresa, do estudo de caso, do produto, os papéis e responsabilidades no processo e a ferramenta utilizada para apresentação do fluxo. Com base nessas informações o processo é mapeado no Capítulo Considerações Iniciais Para atender o objetivo do trabalho, um estudo de caso foi realizado em uma pequena empresa de desenvolvimento de software de Ribeirão Preto, baseando-se no mapeamento do processo de Gerência de Configuração de Software com base nas atividades estabelecidas pelo SWEBOK (2004) e nos resultados esperados do processo segundo o modelo de melhoria de processo MPS.BR Caracterização da Empresa A pequena empresa de desenvolvimento onde foi realizado o estudo de caso fica localizada na cidade de Ribeirão Preto. Atua no setor de tecnologia e possui várias soluções em sistemas de informação. O processo de Gerência de Configuração foi mapeado na empresa junto à área de Qualidade, no ano de 2011 e atende os padrões estabelecidos pelo modelo MPS.BR em seu nível F de maturidade Caracterização do Estudo de Caso O estudo de caso foi aplicado a partir do mapeamento do processo de Gerência de Configuração com suas atividades e padrões segundo o modelo de melhoria MPS.BR. Após o mapeamento do processo, suas atividades foram aplicadas em um projeto de desenvolvimento e os resultados obtidos foram apresentados, com o intuito de mostrar a importância da aplicação de um processo de qualidade no desenvolvimento de software e seus benefícios. Os papéis envolvidos na aplicação do estudo de caso são apresentados na seção a seguir, bem como a responsabilidade de cada um no projeto de desenvolvimento.

57 CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO Caracterização do Produto O produto envolvido no projeto de desenvolvimento com a aplicação da Gerência de Configuração é um sistema indicado para controle de loja que possui comunicação com vários sistemas de frente de loja. A linguagem de programação utilizada para o desenvolvimento do produto é o Delphi e a manipulação das informações pode ser feita por meio das bases de dados Oracle e Firebird, ficando a critério do cliente a escolha de qual base utilizar. Para clientes que manipulam grande quantidade de dados recomenda-se o banco de dados Oracle, por sua eficiência na comunicação entre o sistema e os dados Papéis e Responsabilidades O processo de Gerência de Configuração para a empresa define os seguintes papéis e suas responsabilidades para projetos de desenvolvimento: Analista de Configuração: executa a Gerência de Configuração com a responsabilidade de manter a integridade dos produtos de trabalho e das baselines geradas. Além disso, realiza as auditorias de configuração de software e verifica o andamento dos processos de liberação da versão do produto. Gerente de Projetos: gerencia as atividades de projetos visando atingir os objetivos e expectativas estabelecidas. É responsável pelo planejamento, atribuição de recursos (humanos e materiais), prazo, custo, comunicação, qualidade e obtenção de aprovação das entregas de projetos. Analista de Projetos: auxilia o Gerente de Projetos na execução de suas atividades e apóia as atividades executadas pela área de desenvolvimento. Auditor de Qualidade: audita os processos mapeados e garante a execução dos mesmos. Identifica as não conformidades existentes, determinando e monitorando as ações corretivas. Coordenador de Desenvolvimento: coordena as equipes de análise e desenvolvimento, a fim de que seja possível realizar as entregas planejadas, de acordo com o plano de trabalho. Coordenador de Qualidade: implementa e gerencia os processos de qualidade com o apoio do responsável por cada área de processo. Acompanha os trabalhos desenvolvidos pela área de teste, garantindo que os prazos sejam obedecidos.

58 CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO 40 Analista de Sistemas: analisa os sistemas da empresa, fazendo as propostas para os projetos de desenvolvimento, com a especificação dos requisitos de melhoria a serem implementados. Equipe de Desenvolvimento: executa as atividades de desenvolvimento, modificação e/ou atualização do produto baseando-se nas informações obtidas, utilizando linguagens de programação específicas e realizando pré-testes das funcionalidades implementadas. Analista de Testes: elabora e executa testes no produto alterado no projeto, mediante verificação da especificação feita pelo Analista de Sistemas, a fim de avaliar a consistência das informações geradas e performance das funcionalidades do produto. Analista de Documentação: cria a documentação necessária do produto, como documentos técnicos, manuais e release notes (Notas de Versão) Ferramenta Utilizada Para mapeamento do fluxo do processo de Gerência de Configuração foi utilizada a ferramenta Bizagi Process Modeler, utilizada para criação de fluxogramas e diagramas em geral. Foi utilizada essa ferramenta para o fluxo do processo pelo fato de ser a mesma utilizada na empresa para a visualização do processo e entendimento do fluxo. Para entender como o fluxo funciona, os objetos presentes estão detalhados no Quadro 2 de acordo com a ferramenta Bizagi Process Modeler. Objeto Quadro 2 Símbolos de fluxo de processo da ferramenta Bizagi Descrição (ferramenta Bizagi Process Modeler) Evento de início: indica onde o processo ou subprocesso inicia. Tarefa: atividade dentro de um processo ou subprocesso. É usada quando o trabalho identificado não é decomposto. Tarefa transformada em subprocesso: é usada quando uma atividade possui subatividades. Nesse caso o trabalho é decomposto.

59 CAPÍTULO 4. METODOLOGIA PARA MAPEAMENTO E ESTUDO DE CASO DO PROCESSO 41 Gateway (decisão): local no processo ou subprocesso onde o fluxo de seqüência pode tomar dois ou mais caminhos alternativos (bifurcação). Gateway (decisão) marcador Paralelo: o marcador indica que as tarefas dos caminhos alternativos são executadas em paralelo no fluxo. Anotação: mecanismo que fornece informações adicionais para o acompanhamento do fluxo. Evento de fim: indica onde o processo termina. Fluxo de seqüência: usado para mostrar a ordem em que as atividades serão executadas no processo. Associação: usada para associar informações e artefatos com os objetos do fluxo Considerações Finais Neste capítulo foi apresentada a metodologia aplicada para mapeamento e estudo de caso do processo de Gerência de Configuração na pequena empresa de desenvolvimento de software de Ribeirão Preto. Tais informações permitem que qualquer pessoa possa replicar o processo na busca de garantir maior qualidade nos produtos de software oferecidos.

60 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 42 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO O objetivo deste capítulo é apresentar o processo de Gerência de Configuração de Software mapeado e customizado na empresa com base nas atividades do SWEBOK (2004) e nos padrões do modelo de melhoria MPS.BR, em seu nível F de maturidade. Definido o processo, é apresentado no capítulo seguinte o Estudo de Caso realizado e os resultados obtidos em sua aplicação Considerações Iniciais Para um processo de software ser aplicado em um projeto de desenvolvimento ele precisa ser mapeado com todas suas atividades para quem aplicá-lo saber em que momento executar cada atividade. Uma vez definido o processo, todas as atividades presentes devem ser executadas da mesma maneira, não sendo permitidas customizações, seja qual for a situação. As seções a seguir apresentam o mapeamento do processo aplicado na empresa para a execução do mesmo em qualquer projeto de desenvolvimento, além da definição das diretrizes necessárias para definição de informações importantes em algumas atividades definidas Fluxo do Processo O fluxo principal do processo é apresentado na Figura 16 a seguir. Cada uma das atividades é detalhada no decorrer da seção conforme aplicação em projetos de desenvolvimento da empresa em questão.

61 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 43 Figura 16 Fluxo principal do processo de Gerência de Configuração Na Figura 16 é possível ver que o processo de Gerência de Configuração é dividido em três fases conforme solicitação da equipe de qualidade da empresa, onde: Planejamento: fase onde as atividades do processo são planejadas para o projeto. Execução e Monitoramento: fase onde o processo é executado e monitorado. Encerramento: fase do fechamento do projeto.

62 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 44 Nas seções a seguir, cada uma das atividades apresentadas no fluxo principal do processo (Figura 16) é detalhada. As atividades que possuem subprocesso também terão o fluxo apresentado na seção além do detalhamento de cada atividade Atividade: Planejar Atividades da GCO A atividade em questão, presente na fase de Planejamento do fluxo principal do processo (Figura 16) tem o objetivo de definir as atividades de GCO para execução no projeto de desenvolvimento. Os requisitos necessários para definição das atividades de GCO em projetos de desenvolvimento são: Definição das baselines estabelecidas para o projeto. Itens de configuração previstos para alteração. Solicitações de Mudança previstas. Definição das áreas dos repositórios para disponibilização dos itens de configuração Definição dos envolvidos no projeto. Com base nos requisitos acima é gerado um documento conhecido como Plano de Configuração do Projeto, que deve conter as informações do template do Apêndice A. Algumas das informações necessárias também estão presentes nas etapas detalhadas abaixo: Mapear itens de configuração: o Analista de Configuração deve mapear os itens de configuração que podem ser alterados e auditados. Identificar baselines: o Analista de Configuração deve definir quais baselines serão geradas. Definir área do repositório onde serão disponibilizados os itens de configuração: as áreas onde serão disponibilizados os itens de configuração devem ser definidas no repositório de dados. Configurar acesso ao repositório: o acesso às áreas dos repositórios deve ser concedido aos responsáveis pela alteração. Definir cronograma de atividades no projeto: o cronograma das atividades de GCO no projeto deve ser definido para as fases de planejamento, execução/monitoramento e encerramento. Definir plano de comunicação: os principais eventos de comunicação de GCO aos interessados são definidos.

63 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 45 Gerar Plano de Configuração do Projeto: o Plano de Configuração do Projeto é gerado de acordo com essas informações. O Plano de Configuração também se apóia em informações de outro documento, conhecido como diretriz, que será apresentada na Seção Atividade: Auditorias Periódicas A atividade em questão, presente na fase de Execução e Monitoramento do fluxo principal do processo (Figura 16) tem o objetivo de acompanhar a configuração da baseline que está sofrendo alterações no projeto de desenvolvimento. É identificada como periódica, pois tem a necessidade de ser realizada durante todo o projeto, conforme cronograma de atividades definido no Plano de Configuração. O objetivo da auditoria é o de assegurar a conformidade dos itens verificados presentes em um checklist de auditoria. Toda vez que essa atividade for executada no projeto, esse checklist deve ser seguido e caso existam não conformidades, elas precisam ser registradas e acompanhadas para correção. O subprocesso dessa atividade, apresentado na Figura 17 ilustra o fluxo das Auditorias Periódicas. Figura 17 Fluxo de execução de Auditorias Periódicas

64 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 46 De acordo com a Figura 17, as atividades apresentadas são executadas da seguinte maneira: Realizar Auditorias Periódicas: para essa atividade, o checklist de Auditoria Periódica, definido conforme Apêndice B é preenchido como registro. Esse checklist possui itens de verificação de conformidade na configuração do software alterada com as solicitações de mudança previstas para o projeto. Registrar Resultado de Auditoria: nessa atividade a auditoria é registrada e é possível verificar o saldo de conformidades e não conformidades na verificação. Registrar Não Conformidade: os itens do checklist registrados com não conformidade devem ser acompanhados para correção. Esse acompanhamento é registrado conforme Apêndice C. Caso não seja resolvida até o prazo estipulado e não haja justificativa, a não conformidade é escalonada (informada) ao líder imediato do responsável para ciência e auxílio na cobrança da correção. É muito importante que todas as não conformidades encontradas nas Auditorias Periódicas executadas sejam resolvidas antes do fechamento do projeto para garantia de integridade dos itens de configuração Atividade: Auditorias de Baseline A atividade em questão, presente na fase de Execução e Monitoramento do fluxo principal do processo (Figura 16) tem o objetivo de auditar a geração de baselines do projeto, com os itens de configuração mapeados, garantindo sua integridade no marco definido no projeto de desenvolvimento. Essa auditoria também assegura a conformidade de itens verificados em um checklist e só pode ser efetivada quando todas as solicitações de mudança do projeto tiverem uma Auditoria Periódica registrada e não houver não conformidades pendentes para resolução. As Auditorias de Baseline devem ser registradas para todas as baselines definidas para o projeto. No Capítulo 3, o SWEBOK (2004) define quatro tipos de baselines, conforme Seção , já para os projetos de desenvolvimento da empresa em questão estão definidas três baselines para armazenamento dos itens de configuração: Baseline de Release: contém os itens de configuração de liberação do produto, como os executáveis, scripts de banco de dados e release notes (Notas de Versão). Baseline de Documentação: contém os itens de configuração relacionados aos documentos importantes gerados no projeto. Em projetos de desenvolvimento que

65 CAPÍTULO 5. MAPEAMENTO DO PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO 47 possuírem mais de uma iteração (sprint) essa baseline não precisa ser gerada a cada fim de iteração, como no caso das outras baselines. É somente necessária a geração no fim do projeto. Baseline de Desenvolvimento: contém os itens de configuração relacionados ao código fonte e scripts de banco de dados. É importante esclarecer que o Analista de Configuração apenas audita a geração dessas baselines, não sendo de responsabilidade do mesmo a geração. Dessa maneira, deve ser informado no Plano de Configuração do Projeto o papel e o nome do responsável pela geração para posterior registro de auditoria pelo Analista de Configuração. A Figura 18 apresenta o fluxo do processo da atividade de Auditorias de Baseline. Figura 18 Fluxo de execução de Auditorias de Baseline De acordo com a Figura 18, as atividades possuem a seguinte finalidade: Auditar Baseline de Release: essa auditoria checa se o responsável gerou o release do produto com todos os itens de configuração necessários. O checklist dessa auditoria pode ser visto no Apêndice D e o fluxo dessa atividade na Figura 19. Figura 19 Fluxo de execução de Auditoria de Baseline de Release

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

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. Guia Geral MPS de Software

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

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

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

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

Mini-Curso Gerência de Configuração Visão prática

Mini-Curso Gerência de Configuração Visão prática www.asrconsultoria.com.br Mini-Curso Gerência de Configuração Visão prática Copyright ASR Consultoria e Assessoria em Qualidade 1 Direitos de Uso do Material Material desenvolvido pela ASR Consultoria

Leia mais

MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F:

MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F: MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F: um estudo de caso. Rodrigo Pereira Assunção 1 Fabrício Pires Vasconcellos 2 RESUMO: Muitas empresas têm buscado no modelo de

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

22/10/2012 WAMPS 2012. Implementação do MPS.BR na Informal Informática: Um Relato da Trajetória de Melhoria até o Nível C de Maturidade

22/10/2012 WAMPS 2012. Implementação do MPS.BR na Informal Informática: Um Relato da Trajetória de Melhoria até o Nível C de Maturidade 22/10/2012 WAMPS 2012 Implementação do MPS.BR na Informal Informática: Um Relato da Trajetória de Melhoria até o Nível C de Maturidade Tópicos 1. Institucional 2. Programa de Melhoria de Processos 3. Nível

Leia mais

Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming

Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming T. M. R. Dias 1 ; G. F. Moita 2 ; M. P. Silva 3 ; B. Ferreira 1 ; A. M. Silva 1 1 IFMG Instituto

Leia mais

Melhoria de Processos de Software com o MPS.BR

Melhoria de Processos de Software com o MPS.BR Melhoria de Processos de Software com o MPS.BR Prof. Dr. Marcos Kalinowski (UFF) kalinowski@acm.org Agenda do Curso Motivação para processos de software Visão geral do programa MPS.BR e do modelo MPS-SW

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

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,

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

http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo

http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo Questões O futuro pertence àqueles que acreditam

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

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

Gerência de Configuração de Software. Msc. Ernani Sales Implementador Oficial MPS.BR ernani@webapsee.com

Gerência de Configuração de Software. Msc. Ernani Sales Implementador Oficial MPS.BR ernani@webapsee.com Gerência de Configuração de Software Msc. Ernani Sales Implementador Oficial MPS.BR ernani@webapsee.com Introdução O que é GCS? Terminologia Agenda Modelos, Padrões e Normas Processo de GCS Padrão IEEE

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

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

UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL

UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL UNIVERSIDADE DO SUL DE SANTA CATARINA GUILHERME ANTUNES PASSOS WELLINGTON ANTUNES DANIEL RECOMENDAÇÕES PARA ATINGIR O NIVEL G DO MPS.BR COM BASE EM METODOLOGIAS ÁGEIS: UM ESTUDO DE CASO Palhoça 2013 GUILHERME

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

APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL

APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL Cristiane Machado de Vargas 1 Ana Marcia Debiasi Duarte 2

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 3 http://www.ic.uff.br/~bianca/engsoft2/ Aula 3-29/04/2006 1 Monitoria Marina Albuquerque E-mail: monitoriaes2@yahoo.com.br Horário de Atendimento: Terça e quinta de 09:00

Leia mais

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) LONDRINA - PR 2014 GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

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

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

Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1 UNIVERSIDADE FEDERAL DE SANTA CATARINA Implantação do MPS.BR Nível G Autor: Thais Oliveira Bergmann Florianópolis 2008/1 1 UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA

Leia mais

UNIVERSIDADE DE PASSO FUNDO

UNIVERSIDADE DE PASSO FUNDO 0 UNIVERSIDADE DE PASSO FUNDO Marcelo Teixeira Uma análise do Scrum sob a perspectiva do MPSBR Passo Fundo 2007 1 Marcelo Teixeira Uma análise do Scrum sob a perspectiva do MPSBR Monografia apresentada

Leia mais

LISTA DE EXERCÍCIOS MPS.BR

LISTA DE EXERCÍCIOS MPS.BR LISTA DE EXERCÍCIOS MPS.BR Disciplina: Professor: Qualidade de Software Edison Andrade Martins Morais 01. (FGV 2008 Senado Analista de Sistemas) Considere as assertivas sobre o Modelo MPS do Programa de

Leia mais

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

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

Leia mais

FUMSOFT EDITAL 001/2013 1ª EDIÇÃO

FUMSOFT EDITAL 001/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

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

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

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

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

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

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento Ciência da Computação ENGENHARIA DE SOFTWARE Planejamento e Gerenciamento Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Pessoas, Produto, Processo e Projeto; Gerência de

Leia mais

GERÊNCIA DE CONFIGURAÇÃO. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

GERÊNCIA DE CONFIGURAÇÃO. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com GERÊNCIA DE CONFIGURAÇÃO Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Objetivo Apresentar a GC (Gerencia de Configuração) no contexto da Engenharia de Software Mostrar a importância da GC no controle

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

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO 1 AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br Autor: Julio Cesar Fausto 1 RESUMO Em um cenário cada vez mais competitivo e em franca

Leia mais

Padrões de Qualidade de Software e Métricas de Software

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

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software André Mesquita Rincon Instituto de Informática/Universidade Federal de Goiás (UFG) Goiânia GO Brasil Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas/Fundação

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à 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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

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

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

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 1: Nível G (Versão 1.1) Este guia contém orientações para a implementação do nível G do Modelo de Referência MR-MPS. Julho

Leia mais

Gerência de Configuração. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br

Gerência de Configuração. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br Gerência de Configuração Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br Introdução Mudanças durante o desenvolvimento de software são inevitáveis: os interesses

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

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 1: Nível G MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 1: Nível G (Versão 1.0) Este guia contém orientações para a implementação do Nível G do Modelo de Referência MR-MPS. Dezembro

Leia mais

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

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

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

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

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães A Importância do Controle da Qualidade na Melhoria de Processos de Software Ana Liddy Cenni de Castro Magalhães Agenda Contextualização da Qualidade Dificuldades na construção de software Possíveis soluções

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO JOSE CARLOS GESING

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO JOSE CARLOS GESING UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO JOSE CARLOS GESING MELHORIA DO PROCESSO DE SOFTWARE NO BRASIL: UTILIZAÇÃO DO MODELO MPS.BR

Leia mais

Qualidade de Software

Qualidade de Software Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br A expressão ISO 9000 (International Organization for Standardization) designa um grupo de normas técnicas que estabelecem

Leia mais

Palavras-chaves: SCRUM, Melhoria de Processo de Software, Qualidade de Software.

Palavras-chaves: SCRUM, Melhoria de Processo de Software, Qualidade de Software. Blucher Mechanical Engineering Proceedings May 2014, vol. 1, num. 1 www.proceedings.blucher.com.br/evento/10wccm TECHNICAL SOFTWARE DEVELOPMENT WITH THE ADOPTION OF AGILE METHODOLOGY T. M. R. Dias 1, P.

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

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

Leia mais

Modelos de Maturidade: MPS.BR. Aécio Costa

Modelos de Maturidade: MPS.BR. Aécio Costa Modelos de Maturidade: MPS.BR Aécio Costa Criado em 2003 pela Softex para melhorar a capacidade de desenvolvimento de software nas empresas brasileiras. Objetivo: Impulsionar a melhoria da capacidade de

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

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

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

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

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

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas?

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Fábio Martinho. obtido [on-line] na URL http://www.testexpert.com.br/?q=node/669, em 11/03/2008. Segundo a NBR

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

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Micaelly P. Soares e Silva, Carla I. M. Bezerra, Camilo C. Almendra, Enyo José T. Gonçalves Universidade

Leia mais

UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR

UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR 1 Arthur Mauricio da Silva, 1 Maria Aparecida Denardi 1Curso de Sistemas de Informação - UNIPAR - Universidade Paranaense. CEP 85801-180

Leia mais

Tecnologias Atuais de. Desenvolvimento de Software

Tecnologias Atuais de. Desenvolvimento de Software Tecnologias Atuais de Desenvolvimento de Software volução dos Processos de Desenvolvimento de Software Prof. Luiz Antônio lpereira@uninet.com.br Agenda onceitos volução dos Processos de Software Modelos

Leia mais

Proposta de um processo de gerenciamento de requisitos para uma empresa desenvolvedora de software com foco na satisfação do Nível G do MPS.

Proposta de um processo de gerenciamento de requisitos para uma empresa desenvolvedora de software com foco na satisfação do Nível G do MPS. UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Proposta de um processo de gerenciamento

Leia mais

MPS - Melhoria de Processo de Software e Serviços. Guia Geral MPS de Serviços

MPS - Melhoria de Processo de Software e Serviços. Guia Geral MPS de Serviços MPS - Melhoria de Processo de Software e Serviços Guia Geral MPS de Serviços Este guia contém a descrição geral do Modelo MPS e detalha o Modelo de Referência MPS para Serviços (MR-MPS-SV) e as definições

Leia mais

Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos

Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos Implantação dos Processos Gerência de Projeto e Medição com Auxílio de Ferramenta Baseada em Planilhas Carlos Simões Claudia Lasmar Gleison Santos Agenda: Carlos Simões cs@synapsisbrasil.com.br carlossimoes@cos.ufrj.br

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

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

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

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

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

Leia mais

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de SCE186-ENGENHARIA DE SOFTWARE Módulo 1 Atividades da Engenharia de GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br 2003 DEFINIÇÃO CONSTRUÇÃO SOFTWARE PRODUTO MANUTENÇÃO

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

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Gerência de Configuração de Software

Gerência de Configuração de Software Gerência de Configuração de Software Desenvolvendo software de forma eficiente e disciplinada O Cristine Dantas É bacharel em Informática pela UFRJ e mestre em Engenharia de Sistemas e Computação pela

Leia mais