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

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

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

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

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

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

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

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

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

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

MUDANÇAS NA ISO 9001: A VERSÃO 2015

MUDANÇAS NA ISO 9001: A VERSÃO 2015 MUDANÇAS NA ISO 9001: A VERSÃO 2015 Está em andamento o processo de revisão da Norma ISO 9001: 2015, que ao ser concluído resultará na mudança mais significativa já efetuada. A chamada família ISO 9000

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

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

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

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

Leia mais

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Processo de Implementação de um Sistema de Gestão da Qualidade

Processo de Implementação de um Sistema de Gestão da Qualidade 3 Processo de Implementação de um Sistema de Gestão da Qualidade Não existe um jeito único de se implementar um sistema da qualidade ISO 9001: 2000. No entanto, independentemente da maneira escolhida,

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

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

Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013)

Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013) Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013) Professor Gledson Pompeu gledson.pompeu@gmail.com Acesse nosso site em WWW.DOMINANDOTI.COM.BR Versões atualizadas de notas de aula e listas de

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

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

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

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Implantação do Processo Aquisição na Synapsis Brasil. Carlos Simões Ana Regina Rocha Gleison Santos

Implantação do Processo Aquisição na Synapsis Brasil. Carlos Simões Ana Regina Rocha Gleison Santos Implantação do Processo Aquisição na Synapsis Brasil Carlos Simões Ana Regina Rocha Gleison Santos Data: 20/10/2009 Agenda Empresa Problema Alternativas Implementação Forma de contratação Processo Aquisição

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

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

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

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

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

Leia mais

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

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1 Qualidade Plácido A. S. Neto 1 1 Gerência Educacional de Tecnologia da Informação Centro Federal de Educação Tecnologia do Rio Grande do Norte 2006.1 - Planejamento e Gerência de Projetos Agenda Introdução

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

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

PMONow! Serviço de Implantação de um Escritório de Projetos

PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos As organizações em torno do mundo estão implantando processos e disciplinas formais

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

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

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

Leia mais

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Resumo. Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Autor: Danilo Humberto Dias Santos Orientador: Walteno Martins Parreira Júnior Bacharelado em Engenharia da Computação

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

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

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

Leia mais

Gestão de Modificações. Fabrício de Sousa

Gestão de Modificações. Fabrício de Sousa Gestão de Modificações Fabrício de Sousa Introdução Inevitáveis quando o software é construído Confusão As modificações não são analisadas antes de serem feitas Não são registradas antes de serem feitas

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

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

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

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

Leia mais

Gerenciamento da Integração (PMBoK 5ª ed.)

Gerenciamento da Integração (PMBoK 5ª ed.) Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Gestão da Qualidade em Projetos

Gestão da Qualidade em Projetos Gestão da Qualidade em Projetos Você vai aprender: Introdução ao Gerenciamento de Projetos; Gerenciamento da Integração; Gerenciamento de Escopo- Declaração de Escopo e EAP; Gerenciamento de Tempo; Gerenciamento

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Recursos e Cronograma

Ciência da Computação ENGENHARIA DE SOFTWARE. Recursos e Cronograma Ciência da Computação ENGENHARIA DE SOFTWARE Recursos e Cronograma Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Recursos; Pessoal; Software; Hardware; Outros recursos;

Leia mais

Rede TSQC / SOFTEX Workshop de Aquisição de software Guia de Aquisição MPS.BR

Rede TSQC / SOFTEX Workshop de Aquisição de software Guia de Aquisição MPS.BR Rede TSQC / SOFTEX Workshop de Aquisição de software Guia de Aquisição MPS.BR Danilo Scalet dscalet@yahoo.com.br Editor do Guia de Aquisição 1 2 1 MPS.BR: Desenvolvimento e Aprimoramento do Modelo Realidade

Leia mais

UM CASE DE IMPLANTAÇÃO DA GERÊNCIA DE CONFIGURAÇÃO E MUDANÇA (NÍVEL F) DO MPS.BR UTILIZANDO PADRÕES ABERTO PARA O DESENVOLVIMENTO CORPORATIVO

UM CASE DE IMPLANTAÇÃO DA GERÊNCIA DE CONFIGURAÇÃO E MUDANÇA (NÍVEL F) DO MPS.BR UTILIZANDO PADRÕES ABERTO PARA O DESENVOLVIMENTO CORPORATIVO Nome do Pesquisador(Aluno): Thiago Magalhães Zampieri Nome do Orientador: Simone Tanaka Titulação do Orientador: Especialista Instituição: null Curso para apresentação: SISTEMAS DE INFORMAÇÃO / CIÊNCIA

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

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

ISO 9001:2015 Nova versão porque e quando?

ISO 9001:2015 Nova versão porque e quando? ISO 9001:2015 Nova versão porque e quando? A publicação prevista para Novembro de 2015 tem como propósito refletir as mudanças no ambiente em que a norma é usada e garantir que a mesma mantenha-se adequada

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software FACULDADE MAURÍCIO DE NASSAU Jessé de Souza da Silva, José Arnaldo de Oliveira Almeida, Gabriel Pereira da Silva Gerenciamento de Configuração de Software Uma Abordagem Conceitual João Pessoa 2015 FACULDADE

Leia mais

Conhecimento em Tecnologia da Informação. CobiT 5. Apresentação do novo framework da ISACA. 2013 Bridge Consulting All rights reserved

Conhecimento em Tecnologia da Informação. CobiT 5. Apresentação do novo framework da ISACA. 2013 Bridge Consulting All rights reserved Conhecimento em Tecnologia da Informação CobiT 5 Apresentação do novo framework da ISACA Apresentação Este artigo tem como objetivo apresentar a nova versão do modelo de governança de TI, CobiT 5, lançado

Leia mais

DIRETRIZES DE ORIENTAÇÃO DAS ATIVIDADES DO TRABALHO DE CURSO

DIRETRIZES DE ORIENTAÇÃO DAS ATIVIDADES DO TRABALHO DE CURSO Manual de Orientação das Atividades do Trabalho de Conclusão de Curso INSTITUTO DE ENSINO SUPERIOR DE RIO VERDE - IESRIVER CURSO DE ADMINISTRAÇÃO DIRETRIZES DE ORIENTAÇÃO DAS ATIVIDADES DO TRABALHO DE

Leia mais

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO 1 ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO 2 INFRAESTRUTURA DE TI Para garantir o atendimento às necessidades do negócio, a área de TI passou a investir na infraestrutura do setor, ampliando-a,

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

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010 Engenharia de Software Aula 5 (Versão 2010-02) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br

Leia mais

F.1 Gerenciamento da integração do projeto

F.1 Gerenciamento da integração do projeto Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos

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

Gerenciamento de Problemas

Gerenciamento de Problemas Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar

Leia mais

Trilhas Técnicas SBSI - 2014

Trilhas Técnicas SBSI - 2014 brunoronha@gmail.com, germanofenner@gmail.com, albertosampaio@ufc.br Brito (2012), os escritórios de gerenciamento de projetos são importantes para o fomento de mudanças, bem como para a melhoria da eficiência

Leia mais

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

GERÊNCIA DE INTEGRAÇÃO DO PROJETO GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)

Leia mais

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

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

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

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

PROFESSOR: CRISTIANO MARIOTTI

PROFESSOR: CRISTIANO MARIOTTI PROFESSOR: CRISTIANO MARIOTTI Conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software; Considerado um dos principais mecanismos para se obter software de qualidade

Leia mais

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 Índice 1. Importância do ERP para as organizações...3 2. ERP como fonte de vantagem competitiva...4 3. Desenvolvimento e implantação de sistema de informação...5

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

Metodologia de Gerenciamento de Projetos da Justiça Federal Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...

Leia mais

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

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

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

PPS - Processo de Proposta de Solução Versão 1.3.1

PPS - Processo de Proposta de Solução Versão 1.3.1 PPS - Processo de Proposta de Solução Versão 1.3.1 Banco Central do Brasil, 2015 Página 1 de 13 Índice 1. FLUXO DO PPS - PROCESSO DE PROPOSTA DE SOLUÇÃO... 3 2. SOBRE ESTE DOCUMENTO... 4 2.1 GUIA DE UTILIZAÇÃO...

Leia mais

CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software. Conceitos de Qualidade. CURSO DE GRADUAÇÃO e DE PÓS-GRADUAÇÃO DO ITA

CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software. Conceitos de Qualidade. CURSO DE GRADUAÇÃO e DE PÓS-GRADUAÇÃO DO ITA CURSO DE GRADUAÇÃO e DE PÓS-GRADUAÇÃO DO ITA 2º SEMESTRE 2002 CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software Prof. Dr. Adilson Marques da Cunha Conceitos de Qualidade CES-32 / CE-230

Leia mais

1 2009 CBG Centro Brasileiro de Gestão

1 2009 CBG Centro Brasileiro de Gestão 1 2009 CBG Centro Brasileiro de Gestão ISO 9001:2015 Histórico da série 2 2009 CBG Centro Brasileiro de Gestão Histórico da série REVISÕES DA SÉRIE ISO 9000 2000 2008 2015 1994 1987 3 2009 CBG Centro Brasileiro

Leia mais

Modelos de Qualidade de Produto de Software

Modelos de Qualidade de Produto de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Modelos de Qualidade de Produto de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

Gerência de Configuração. Profº Rômulo César

Gerência de Configuração. Profº Rômulo César Gerência de Configuração Profº Rômulo César Gerência de Configuração Cenário Atual Projetos cada vez mais complexos em relação ao tamanho, sofisticação e tecnologias envolvidas Grandes equipes geograficamente

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

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista )

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Qualidade de Software Aula 8 (Versão 2012-01) 01) Requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Revisando... 1. Qual o

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software Projeto e Desenvolvimento de Sistemas Dr. Fábio Levy Siqueira levy.siqueira@gmail.com Aula 2: Garantia da Qualidade e Padrões Qualidade de software Quais são as atividades de Gestão

Leia mais

Gerência de Configuração em Ambientes de Desenvolvimento de Software Orientados a Organização

Gerência de Configuração em Ambientes de Desenvolvimento de Software Orientados a Organização Gerência de Configuração em Ambientes de Desenvolvimento de Software Orientados a Organização Sávio Figueiredo, Gleison Santos, Ana Regina Rocha COPPE UFRJ {savio, gleison, darocha}@cos.ufrj.br SBQS 2004

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Referência: An Introductory Overview of ITIL v2 Livros ITIL v2 Cenário de TI nas organizações Aumento da dependência da TI para alcance

Leia mais

Sistema de Gestão da Qualidade

Sistema de Gestão da Qualidade Sistema de Gestão da Qualidade Coordenadora Responsável Mara Luck Mendes, Jaguariúna, SP, mara@cnpma.embrapa.br RESUMO Em abril de 2003 foi lançado oficialmente pela Chefia da Embrapa Meio Ambiente o Cronograma

Leia mais