Proposta de um Processo de Gerência de Configuração de Software para o CTIC-UFPA

Transcrição

1 Proposta de um Processo de Gerência de Configuração de Software para o CTIC-UFPA Larissa Fernandes Chagas¹; Daniel Dias de Carvalho¹; Carla Alessandra Lima Reis¹; Antônio Jorge Gomes Abelém¹ ¹ Centro de Tecnologia da Informação e Comunicação (CTIC) Universidade Federal do Pará (UFPA) - Caixa Postal Belém PA Brasil {larissafc, danieldias, clima, abelem}@ufpa.br Resumo. Este artigo visa propor um processo de Gerência de Configuração de Software (GCS) para a Divisão de Desenvolvimento do Centro de Tecnologia da Informação e Comunicação da UFPA (CTIC-UFPA), que atenda os resultados esperados definidos no Modelo de Referência para a Melhoria de Processos do Software Brasileiro (MR-MPS). Para tanto, será apresentado o processo padrão de desenvolvimento de software da organização e uma nova versão incluindo as atividades da GCS. 1. Introdução Empresas de desenvolvimento de software estão cada vez mais interessadas em aumentar a qualidade dos produtos desenvolvidos, para garantir satisfação dos seus clientes e aumentar sua competitividade. Para tanto, tipicamente focam seus esforços em: pessoas, procedimentos/métodos e equipamentos. Contudo, o que mantém esses três elementos unidos são os processos utilizados, que permitem alinhar a maneira pela qual os negócios são realizados e fornecem uma maneira de incorporar o conhecimento de como realizar melhor uma tarefa (SEI, 2006). Por isso, surgiram vários modelos de maturidade, normas de qualidade e guias de boas práticas para a definição de processos de software, como CMMI (CHRISSIS et al., 2003), MPS.BR (SOFTEX, 2009a), ISO/IEC (ISO/IEC, 2008) e ISO/IEC (ISO/IEC, 2003). Tais modelos e normas definem inúmeras diretrizes a serem seguidas por uma organização, dentre as quais se insere o processo de Gerência de Configuração de Software (GCS), considerado um processo de apoio ao desenvolvimento de software. O Centro de Tecnologia da Informação e Comunicação (CTIC) é o órgão da Universidade Federal do Pará (UFPA) responsável por prover serviços e recursos de tecnologia de informação e comunicação, apoiando atividades acadêmicas e administrativas da universidade. No CTIC-UFPA, um projeto chamado Melhoria de Processos de Software do CTIC-UFPA (GRUPO MPS/CTIC) foi aprovado, em 2007, pelo Conselho da unidade organizacional e iniciou, no ano de criação, a implantação de melhorias nos processos de software do CTIC-UFPA seguindo preceitos do MR- MPS. Um dos principais resultados dessa implantação foi a aprovação do CTIC-UFPA ao Nível G do modelo, em dezembro de No CTIC-UFPA ocorrem muitas mudanças nos produtos de trabalho sem a análise do impacto de tal mudança em outros projetos e sem avaliar a situação em que o projeto se encontra. O mesmo acontece para os artefatos que servem de base para os projetos (templates de documentos e templates de processos, por exemplo). Para um controle mais eficiente de tais mudanças, é de grande importância, portanto, a aplicação do processo Gerência de Configuração de Software na organização, alinhado às práticas do MPS.BR, de forma a dar continuidade ao projeto de melhoria. 2. Gerência de Configuração de Software Durante o desenvolvimento de software, uma grande quantidade de informação é produzida: modelos, manuais, software executável, código fonte, planos, entre outros. Esses itens naturalmente sofrem mudanças, sejam elas corretivas, evolutivas ou adaptativas, e pelos mais variados motivos: requisição dos usuários, mudanças nas regras de negócio ou questões internas ao desenvolvimento.

2 Nesse contexto, a Gerência de Configuração de Software (GCS) é a área da Engenharia de Software responsável por manter a integridade dos produtos ao longo do ciclo de vida, possibilitando a identificação de como o software evoluiu ao longo do processo, por que foram realizadas modificações, quem realizou e como as alterações foram realizadas. Portanto, uma disciplina que permite a evolução de sistemas de software de maneira controlada (DART, 1991). Em termos práticos, a GCS é uma disciplina que aplica procedimentos técnicos e administrativos para identificar e documentar características físicas e funcionais de um Item de Configuração 1 (IC), controlar mudanças nessas características, armazenar e relatar o processamento de mudanças e o estágio da implementação, e verificar a conformidade com os requisitos especificados (IEEE, 1990). Em momentos previamente estabelecidos do ciclo de vida de desenvolvimento e manutenção do software, os ICs são agrupados e verificados, constituindo configurações do software voltadas para propósitos específicos, denominadas baselines. Essas configurações representam conjuntos de ICs formalmente aprovados que servem de base para as etapas seguintes de desenvolvimento e que podem ser modificadas apenas através de procedimentos formais de controle de mudanças (IEEE, 1990). Finalmente, ICs devem ser submetidos a um processo de liberação (release), que representa a notificação formal e distribuição de uma versão aprovada do software (IEEE, 2005). 3. MPS.BR O modelo MPS.BR (Programa para a Melhoria do Processo de Software Brasileiro) é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com o apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). A base técnica para a construção e aprimoramento desse modelo é composta pelas normas ISO/IEC 12207:2008 (ISO/IEC, 2008) e ISO/IEC (ISO/IEC, 2003), além de ter sido definido em conformidade com o modelo CMMI-DEV (SEI, 2006). O modelo MPS está dividido em três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS), cada um descrito por meio de guias e/ou documentos do modelo MPS. O Modelo de Referência (MR-MPS) contém os requisitos que os processos das unidades organizacionais devem atender. Ele contém as definições dos níveis de maturidade, processos e atributos do processo e está descrito no Guia Geral do MPS.BR (SOFTEX, 2009a). O MR-MPS define sete (7) níveis de maturidade que são uma combinação entre processos e sua capacidade e estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização (SOFTEX, 2009a). O processo Gerência de Configuração (GCO) faz parte do nível F do MR-MPS e tem como propósito estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos. Para implementar este processo uma organização deve atender o propósito do processo e a sete resultados esperados, que serão apresentados na seção 7 deste trabalho, onde será feito um mapeamento entre o processo proposto a tais resultados. 4. Processo Padrão de Desenvolvimento de Software do CTIC-UFPA O processo de desenvolvimento de software adotado pelo CTIC-UFPA, resultado da implementação de seu projeto de melhoria, baseia-se no Modelo em Cascata (ROYCE, 1970), em que as etapas de desenvolvimento seguem uma seqüência linear, de forma que uma fase só pode ter início quando a anterior tiver terminado. Apesar disso, cada projeto pode adotar um processo adequado a sua realidade. Alguns projetos tem sido executados de forma incremental, a partir do particionamento do escopo em sub-projetos. O processo do CTIC-UFPA é dividido em cinco fases, sendo cada fase decomposta em sub-processos. 1 Um IC é uma agregação de hardware, software, ou ambos, tratados pelo processo de gerência de configuração como uma entidade única (IEEE, 1990).

3 O processo de desenvolvimento do CTIC-UFPA está institucionalizado através de uma Política Organizacional para Desenvolvimento de Software 2, que define que todos os projetos de software conduzidos na organização devem abranger as práticas de Grência de Projetos (GPR) e Gerência de Requisitos (GRE). Além disso, define que um Plano da Organização deve ser mantido e suas alterações devem ser comunicadas aos gerentes de projeto. O Plano da Organização contém informações sobre os cargos organizacionais, habilidades necessárias para ocupar os cargos, as pessoas alocadas em cargos e suas habilidades individuais, e as configurações padrão de hardware e software disponíveis. Tal política também institucionaliza a adoção da ferramenta WebAPSEE (LIMA REIS e REIS, 2007) para auxílio na definição e acompanhamento dos projetos de desenvolvimento de software. A política define ainda que deve ser revisada quando: o nível de maturidade do CTIC-UFPA for alterado para incluir novos processos e capacidades; o regimento interno do CTIC-UFPA for alterado; o organograma do CTIC-UFPA for alterado; algum dos itens que compõem a Política Organizacional do CTIC-UFPA for alterado. 5. Ambiente WebAPSEE O WebAPSEE é um Ambiente de Desenvolvimento de Software Centrado em Processo (Process- Centered Software Engineering Environment - PSEE) que tem como objetivo prover maior flexibilidade na gerência e desenvolvimento de processos de software (LIMA REIS e REIS, 2007; LIMA et al., 2006b). O WebAPSEE é implantado através de uma arquitetura cliente-servidor, onde o servidor provê serviços de persistência, checagem de consistência para modelagem, execução dos processos, gerência de artefatos e gerência dos dados organizacionais (LIMA, LIMA REIS e REIS, 2006). Os clientes são as interfaces de acesso ao servidor e são disponibilizados em duas visões principais: a do gerente (Manager Console) e a do desenvolvedor (Task Agenda). Os artefatos utilizados nas atividades são armazenados em um repositório com controle de versões configurado na instalação do ambiente (CVS Concurrent Version System ou SVN- Subversion). O ambiente WebAPSEE é de grande importância para o projeto de melhoria do CTIC-UFPA, pois possui características de ferramentas de gerência de projetos, como visualização do processo com o Gráfico de Gantt, geração de caminho crítico, Estrutura Analítica do Projeto e emissão de relatórios gerenciais, como acompanhamento de atividades com desvio de esforço/prazos, plano de custos e recursos humanos, dentre outros (FRANÇA et. al, 2009). Além disso, permite a definição de processos através de uma linguagem visual, possui controle de versões dos artefatos integrado (SALES, 2007), possibilita a reutilização de processos (COSTA et. al, 2007), apóia desenvolvedores na execução de suas tarefas, através da Task Agenda e, está em constante evolução. 6. Definição do processo de GCS para o CTIC-UFPA A proposta desse trabalho é fornecer um processo que implemente as práticas de GCS definidas no nível F do MPS.BR e que seja integrado ao processo de software utilizado pela organização. Essa descrição do processo contém as atividades a serem desempenhadas, templates de documentos a serem trabalhados, os procedimentos e toda a infra-estrutura necessária para sua execução. Inicialmente, foram inseridas, na Política Organizacional do CTIC-UFPA as diretrizes da GCS a serem seguidas na organização, onde também foi definido que esse novo processo, além da GPR e da GRE, deve ser seguido em todos os projetos de software da organização. No Plano da Organização, foram definidos papéis e responsabilidades envolvidos no processo de GCS, identificados os colaboradores aptos a desenvolver as atividades sob responsabilidade destes papéis, e identificados recursos e ferramentas de apoio à GCS. 2 Disponível na página principal do CTIC-UFPA e disponibilizada a todos os colaboradores.

4 O processo de GCS definido para a organização foi descrito em um documento (Procedimentos para GCS) disponibilizado como entrada para as atividades de GCS a serem desenvolvidas. Tal documento descreve objetivos da GCS, papéis, responsabilidades, diretrizes a serem seguidas e atividades de GCS a serem executadas na organização. O processo padrão da organização foi alterado para inclusão das atividades, gerando um template de processo no ambiente WebAPSEE que pode ser instanciados para os projetos da organização. O Gerente de Configuração é o responsável por: planejar a Gerência de Configuração, na fase de planejamento do projeto; priorizar as solicitações de mudança; analisar o impacto da mudança; também é responsável pela criação/atualização de baselines e releases. O Comitê de Controle de Configuração (CCC) é o grupo de pessoas responsável por decidir se uma modificação em um IC será implementada, rejeitada ou postergada, devendo analisar a necessidade da alteração, conseqüências, adequação de documentação da modificação e se as atividades planejadas para implementação são satisfatórias. Também é responsável por autorizar a liberação de uma baseline ao cliente. Pode ser formado por uma única pessoa, desde que tenha as competências e mecanismos suficientes para execução das tarefas pertinentes (SOFTEX, 2009b). O Auditor de Configuração é o responsável por verificar se procedimentos e diretrizes de gerência de configuração estão sendo seguidos de forma adequada, bem como se ICs e baselines estão íntegras, corretas e consistentes. Deve ser uma pessoa que não tenha envolvimento direto nas atividades por ela auditadas. De modo geral, seis atividades de GCS devem ser executadas nos projetos de software da organização. Essas atividades são apresentadas nas seções 6.1 a Planejamento da Gerência de Configuração O Planejamento da Gerência de Configuração foi inserido no roteiro da atividade Planejar o Projeto no processo padrão do CTIC-UFPA. A saída dessa atividade é o Plano do Projeto, desenvolvido pelo Gerente do Projeto, em conjunto com o Gerente de Configuração, responsável pela inclusão do Planejamento da GCS para o referido projeto. Devem ser definidos: os artefatos que irão compor a baseline do projeto, nível de controle sobre cada um (versões ou mudanças) e momento em que cada item entra em baseline; pessoas que farão parte do CCC, Gerente de Configuração e Auditor de Configuração do projeto; cronograma das atividades de GCS a serem realizadas; recursos necessários para a realização das atividades de GCS, período de utilização e devem ser obtidos/providos; o responsável por manter o planejamento da GCS, estabelecer a freqüência com que o planejamento da GCS deve ser atualizado, e como as mudanças devem ser avaliadas, aprovadas, feitas e comunicadas Identificação da Configuração Os ICs de um projeto estão identificados no template do Plano de Gerência de Documentos do Plano do Projeto. O(s) responsável(veis) por manter o item atualizado e íntegro é(são) estabelecido(s) no Plano de Comunicação do Plano do Projeto. Na fase de planejamento devem ser identificados os ICs que farão parte de baselines do projeto, o nível de controle requerido No controle de versões, o artefato é apenas versionado, no controle de mudanças, além de ser versionado, são geridas as mudanças solicitadas de acordo com o processo de solicitação de mudança definido na seção 6.7 deste trabalho. Apesar de um artefato estar apenas sob controle de versões, pode participar de processos de mudança se for afetado por rastreabilidade a mudanças solicitadas. Porém, artefatos sob controle de versão são alterados sem necessidade de execução de um processo formal de solicitação de mudanças. No contexto organizacional, são considerados itens de configuração os templates de artefatos, de processos, procedimentos e todos os artefatos padronizados na organização. Templates de documentos e de processos estarão sob controle de mudanças, o Plano da Organização e a Matriz de Rastreabilidade Organizacional estarão sob controle de versões.

5 O código fonte dos projetos estará armazenado no servidor de aplicações, os outros ICs serão armazenados no repositório do WebAPSEE e o número de versões de ICs seguirá o padrão do sistema de controle de versões adotado: CVS para o repositório do WebAPSEE e Subversion para o código fonte armazenado no servidor de aplicações. Apenas ICs disponíveis no repositório do WebAPSEE ou no servidor de aplicações podem ser inseridos na baseline. A planilha Baseline contém um campo para identificar se tal Baseline é uma Release, a identificação da Baseline. Os ICs referenciados pela planilha da baseline devem ser compactados junto com a mesma, compondo o artefato de saída das atividades Gerar baseline, Atualizar baseline e Preparar Release, além do artefato de entrada das atividades de Auditoria de Configuração. Este procedimento não se aplica para o Processo Padrão sob baseline organizacional, que estará apenas referenciado. No contexto organizacional, uma baseline deve ser mantida, referenciando os templates de artefatos, os procedimentos, as políticas, os processos e qualquer outro artefato utilizado não apenas no contexto de um projeto em específico, mas que seja padronizado na organização. A Matriz de Rastreabilidade Organizacional deve ser mantida, identificando impacto da mudança de nome e/ou de conteúdo de um artefato em outro (s). Sempre que houver mudanças em ICs sob baseline organizacional deve ser observada a necessidade de atualização da matriz organizacional, o mesmo procedimento deve ser observado quando ocorrerem inclusões de ICs em tal baseline. Sempre que uma mudança em um IC aprovada é implementada, a baseline deve ser atualizada, para que a evolução do projeto ocorra a partir da versão mais atual de cada artefato e essa atualização deve ser informada aos participantes do projeto em questão, ou aos colaboradores da organização, caso se trate da baseline organizacional. Especificamente para o código fonte, uma tag deve ser criada para identificá-lo na planilha de descrição da baseline do projeto Controle da Configuração Modificações em ICs definidos sob controle de mudanças devem seguir o processo de solicitação de mudança definido. Os outros ICs precisão estar apenas sobre controle de versões no ambiente WebAPSEE ou no servidor de aplicações (caso se trate de código fonte de projeto). Para ICs sob controle de mudanças, é importante observar que partir do momento que o processo de solicitação de mudança é instanciado e chega-se na atividade de implementação da mudança, o(s) IC(s) participante(s) poderá(ão) ser alterado(s) livremente, até que uma nova versão do(s) item(ens) passe(m) a fazer parte da baseline (no final do processo) Auditoria da Configuração Auditorias de baseline acontecem nos marcos definidos para o projeto (antes da atividade Revisar o Plano do projeto) para verificar a completude quanto aos requisitos definidos, também devem ser feitas antes de cada release. As Auditorias ocorrem também para assegurar que os processos e procedimentos de Gerência de Configuração estão sendo seguidos. Os resultados das auditorias devem ser reportados no Relatório de Auditoria de Configuração, disponibilizado no repositório do WebAPSEE. No contexto organizacional, devem ser realizadas auditorias sempre que uma solicitação de mudança em ICs da baseline organizacional for finalizada. Caso o auditor de configuração identifique problemas em ICs da baseline definidos sob controle de mudanças, o processo de solicitações de mudança deve ser seguido para que os problemas encontrados sejam solucionados. Caso identifique problemas em ICs da baseline definidos sob controle de versão, realiza-se um Plano de Ação para solucioná-los Contabilidade da Situação da Configuração O esforço em horas gasto nas atividades de GCS deve ser medido, para identificar possíveis melhorias no processo. Esse esforço pode ser obtido através do Relatório de Acompanhamento de Atividades, que pode ser gerado pelo Manager Console do WebAPSEE automaticamente. O resultado dessa medição deve ser a elaboração do artefato Relatório de Esforço das atividades de

6 GCS que deve ser estabelecido e mantido durante o desenvolvimento do projeto, identificando as atividades de GCS realizadas, responsável, tempo estimado para a atividade e o tempo real gasto. Outra medição do processo referente à GCS que deve ser realizada é relacionada às solicitações de mudança dos ICs que estão sob baseline. O resultado dessa medição é a elaboração do Relatório de Solicitações de Mudança. A atualização desse relatório será realizada sempre que o processo de solicitação de mudança sobre artefatos sob baseline for finalizado, tanto para projetos em específico quanto para a baseline organizacional. Além dessas, outras métricas podem ser adicionadas Gerência de Liberação e entrega Na fase de Codificação e Testes dos projetos uma baseline é selecionada para ser liberada para o cliente (liberação e entrega de ICs). O Gerente de Configuração seleciona ICs que farão parte da release e prepara um build do projeto para disponibilização no servidor de aplicações. Outras releases podem ser planejadas, dependendo das necessidades do cliente e da organização para o projeto. Nessa atividade a planilha Baseline deve ser criada indicando que se trata de uma release e para que seja de fato liberada para o cliente, o Gerente de Configuração deve obter autorização do CCC, após a realização de Auditoria de Configuração sobre tal release Processo de Solicitação de Mudanças Para que um item pertencente a uma baseline possa sofrer mudanças ao longo do processo de desenvolvimento, será utilizado o processo de solicitação de mudanças definido por (SALES, 2009), e adaptado para este trabalho (Figura 1). Figura 1 - Processo de Solicitação de Mudanças (Adaptado de Sales, 2009) O processo de Solicitação de Mudança inicia quando colaborador ou cliente da organização envia o pedido para Gerente de Configuração e Gerente de Projeto, devendo fazer uma descrição sucinta da mudança e justificativa da solicitação. Gerente de Configuração e Gerente de Projeto analisam o pedido, caso considerem improcedente, comunicam ao solicitante da mudança, para decisão sobre o cancelamento do pedido. Caso contrário, o Processo de Solicitação de Mudança deve ser instanciado e disponibilizada a tarefa de Solicitação de Mudança ao agente, que deve preencher o Template de Solicitação de Mudança, informando artefato(s) alvo, versão do artefato afetada, prioridade da mudança, necessidade e descrição da mudança, além da forma de interação com o processo principal (intrusiva ou não-intrusiva). Caso o pedido de mudança seja realizado pelo cliente, o Gerente de Requisitos é o responsável por preencher o artefato Solicitação de Mudança.

7 O Gerente de Configuração faz a análise de impacto da mudança, através do artefato Análise de Impacto da Mudança, relatando impactos em esforço, cronograma e custo, e definindo uma proposta de implementação. Caso a mudança constitua uma mudança nos requisitos do projeto, a análise de impacto deve ser realizada em conjunto com o Gerente de Requisitos. O CCC, por sua vez, avalia a modificação estabelecendo se esta será implementada, rejeitada ou postergada, através do Laudo de Avaliação da Solicitação de Mudança. Caso a decisão seja por implementar, o Gerente de Projetos define um sub-processo para tal tarefa. Após a implementação da modificação, deve ser realizada a verificação desta (através de um sub-processo definido pelo Gerente de Projetos), analisando se a mudança está corretamente implementada (através de revisão e/ou testes) e em conformidade com a mudança solicitada, reportando os resultados no Relatório de Verificação de Mudança. Caso positivo, o Gerente de Configuração atualiza a baseline do projeto e notifica os interessados, caso contrário, retorna-se à atividade implementação. Caso seja necessária a liberação dos produtos de trabalho modificados, ou de parte deles, ao cliente, o planejamento da atividade Preparar Release é necessário, bem como execução da atividade de Auditoria de Configuração, seguida pela autorização do CCC para liberação efetiva. 7. Conformidade com o MR-MPS A seguir são apresentados os resultados esperados do processo GCO, pré-definidos no MR-MPS e os elementos do processo proposto neste trabalho que atendem tais resultados: GCO 1. Um sistema de controle de configuração é estabelecido e mantido: Planejamento da Gerência de Configuração/Estabelecimento de procedimentos a serem seguidos no processo; Processo de Solicitação de Mudanças. GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos: Identificação da Configuração; Controle da Configuração. GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline: Criação e atualização de baselines. GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada: Sistemas de Controle de Versões; Plano de Comunicação; Relatório de Solicitações de Mudança. GCO 5. Modificações em itens de configuração são controladas: Processo de Solicitação de Mudanças GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados: Planejamento das Atividades Gerar/Atualizar Baseline e Preparar Release; Controle do manuseio de tais itens. 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: Atividades de Auditoria de Configuração 8. Conclusões Este trabalho apresentou uma proposta de processo de gerência de configuração de software para o CTIC-UFPA. Foram definidos procedimentos a serem seguidos durante a execução do processo na organização, templates de documentos necessários e todas as atividades a serem realizadas. O processo padrão de desenvolvimento de software da organização foi adaptado para inclusão das atividades referentes à GCS, sendo modelado no ambiente utilizado pela organização para a gerência de processos de software, o WebAPSEE. O processo proposto foi definido para ser aderente ao processo GCO do MR-MPS, essa aderência foi avaliada de forma qualitativa, indicando que atende aos resultados esperados para o tal processo. Estima-se que, através da execução deste processo, a organização possa ter um maior controle de seus produtos de trabalho, não somente dos projetos, mas daqueles que servem de base para a execução de tais projetos, conhecendo todos os detalhes da evolução de tais produtos.

8 9. Referências Bibliográficas CHRISSIS, M.B., KONRAD, M., SHRUM, S. CMMI: Guidelines for Process Integration and Product Improvement. Boston, MA: Addison-Wesley, COSTA, A. et. al. Apoio a Reutilização de Processos de Software através de Templates e Versões, In: 6º Simpósio Brasileiro de Qualidade de Software (SBQS 07). Porto de Galinhas, PE, Brasil, DART, S. Concepts in Configuration Management Systems. In: INTERNATIONAL WORKSHOP ON SOFTWARE CONFIGURATION MANAGEMENT (SCM), Proceedings... Trondheim, Norway, June, p. 1-18, FRANÇA, Breno B. N., et. al. Utilização do Ambiente WebAPSEE na implantação do nível G do MPS.BR no CTIC-UFPA. In:Simpósio Brasileiro de Qualidade de Software, Anais... Ouro Preto. SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE - SBQS 2009, INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERING. IEEE Std : IEEE Standard Glossary of Software Engineering Terminology. New York, INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504: Information Technology - Process Assessment Part 2 - Performing an Assessment, Geneve, INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 12207: Tecnologia de Informação - Processos de ciclo de vida de Software. Genebra, LIMA, Adailton et al. Gerência Flexível de Processos de Software com o Ambiente WebAPSEE. In: Sessão de Ferramentas do Simpósio Brasileiro de Engenharia de Software (SBES), Anais... Florianópolis: Informática-UFSC, 2006b. p LIMA, Adailton Magalhães; LIMA REIS, Carla A.; REIS, Rodrigo Quites. Análise do ambiente de WEBAPSEE no atendimento aos requisitos de ambientes de processos de software. In: XX Semana Paraense de Informática e Telecomunicações, Anais... Belém. XX Semana Paraense de Informática e Telecomunicações, LIMA REIS, Carla A.; REIS, Rodrigo Q.. Laboratório de Engenharia de Software e Inteligência Artificial: Construção do ambiente WebAPSEE. Revista ProQuality (UFLA), v. 3, p , ROYCE, W. W. Managing the development of large software systems: Concepts and techniques. In: Proceedings of IEEE WESTCON. Proceedings Los Angeles, CA, p. 1 9, SALES, Ernani de O. Gerência de Configuração de Software Integrada à Execução de Processos de Software. 2009, 125f. Dissertação de Mestrado Programa de Pós-Graduação em Ciência da Computação, Universidade Federal do Pará, Belém. SALES, Ernani de O.; LIMA REIS, Carla A.; LIMA, Adailton Magalhães. Gestão de Configuração integrada a Gerência de Processos de Software no Ambiente WebAPSEE. In: 33ª Conferência Latino Americana de Informática (CLEI 07). San José, Costa Rica, SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, SOFTEX ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral: 2009, 2009a. Disponível em: < Acesso em 15 de novembro de 2009.

9 SOFTEX ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS:2009, 2009c. Disponível em: < Acesso em 10 de junho de 2009b.