Implantação do MPS.BR nível G
Thais BergmannInstituto de Informática e Estatística – Universidade Federal de Santa Catarina (UFSC) Caixa Postal 15.064 – 91.501-970 – Florianópolis – SC – Brasil
thais.bergmann@gmail.com
1. Introdução
Dentre os principais fatores limitadores do crescimento das empresas de desenvolvimento de software está o caos em que essas operam, na maioria das vezes.
Freqüentemente essas empresas até tem processos informais de desenvolvimento que são abandonados sempre que ocorre algum problema como, por exemplo, atraso no cronograma ou mudança de prioridade do projeto na empresa. Para esse contexto foi criado o MPS.BR, que é o programa de melhoria de processos de software.
Uma vez que o MPS.BR é dividido em sete níveis, equivalentes ao CMMI, porém mais adequado a realidade das empresas de micro e pequeno porte, que podem implantar o modelo em etapas menores e desfrutarem dos benefícios mais rapidamente. Além disso, o MPS.BR custa em torno de quatro vezes menos que a certificação CMMI.
1.1 Organização deste Documento
O primeiro capítulo trouxe a introdução ao conteúdo a ser apresentado assim como a organização deste documento. O segundo capítulo traz informações sobre a engenharia de software, assunto introdutório para melhor entendimento dos demais temas abordados neste documento. O terceiro capítulo discorre sobre os principais padrões de qualidade para processo de desenvolvimento de software, com um foco maior para o MPS.BR devido a sua importância nesse trabalho. No quarto capítulo é apresentada a Ilog Tecnologia e relatado como ocorreu a implantação do MPS.BR nível G. O quinto capítulo traz as conclusões obtidas a partir deste trabalho assim como os trabalhos futuros e referências bibliográficas utilizadas.
2. Engenharia de Software
2.1 O que é software
“Software é: (1) Instruções (programas de computador) que quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que permitem
que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e ouso dos programas”. Pressman, 1995.
As principais características que diferem o software dos demais produtos são as seguintes: o software é desenvolvido por engenharia, assim como os demais produtos manufaturados, o software precisa ser projetado. A diferença está na forma de construção deste uma vez que não é físico não é trivial saber exatamente o que se tem pronto ou quanto ainda falta para finalizá-lo.
2.2 Crise do Software e Surgimento da Engenharia de Software
No início dos anos 80 a crise do software, devido a forma caótica como era desenvolvido e mantido, atraiu a atenção das empresas e governo americano. Nessa época o congresso americano verificou o impacto que a tecnologia tinha sobre a economia americana e na competitividade global dos Estados Unidos. O congresso verificou que o impacto da desordem vivida na época seria desastroso uma vez que a tecnologia dava forma ao futuro. A conclusão foi de que a melhor forma de se ter um futuro em ordem seria organizar o presente.
“A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos, isso se
tornou um problema pequeno e agora que temos computadores gigantescos, programar tornou-se um problema gigantesco.”
Edsger Dijkstra na sua apresentação “The Humble Programmer”,
Em 1984, o congresso americano fundou uma organização chamada Software Engineering Instituite (SEI), com uma equipe formada pelos mais importantes centros de pesquisa sobre o assunto nos EUA. Essa equipe ficou hospedada na Universidade Carnegie-Mellon em Pittsburgh. O objetivo do SEI é trabalhar para estabelecer normas e metodologias no campo de desenvolvimento de software para ajudar a América a manter a competitividade frente aos esforços tecnológicos no mundo. O SEI cumpriria esse objetivo através de programas de pesquisa, treinamentos e desenvolvimento profissional [11]. A primeira definição de engenharia de software foi proposta por Fritz Bauer em 1969, que é a seguinte:
“O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente
em máquinas reais”.
2.3 ISO/IEC 12207 – Processos do Ciclo de Vida do Software
“Ciclo de vida é a estrutura que contém processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo
a vida do sistema desde a definição de seus requisitos até o término de seu uso.”
NBR ISO/IEC 12207
O objetivo da ISO/IEC 12207 é que cliente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e desenvolvedores utilizem a mesma estrutura de
processos, com terminologias bem definidas, que podem ser referenciadas pela indústria de software.
O modelo de ciclo de vida do software consiste de todas as atividades desde a criação até a “aposentadoria” deste. A escolha do modelo de ciclo de vida é uma das mais influentes decisões para o sucesso do projeto em questão, pois se adequada contribui para que o processo de desenvolvimento do software seja eficiente, seja obtido um produto com mais qualidade além de minimizar os riscos inerentes ao processo. Assim como a escolha de um modelo de ciclo de vida inadequado ou a falta de um pode fazer que haja muito atividades desnecessárias e frustração ao longo do ciclo de vida do software. [31]
Os principais modelos existentes, suas vantagens e desvantagens podem ser vistos na tabela a seguir:
Modelo de
Ciclo de Vida Vantagens Desvantagens
Cascata
Passos bem definidos fazem a gerência do projeto e gestão de recursos mais fáceis.
Erros nos requisitos e projeto não são encontrados até a fase de teste, se torna caro para reparar.
Não permite mudanças nos requisitos.
Incremental
Permite que grandes problemas sejam quebrados em problemas menores para serem entregues a uma equipe.
Não resolve problemas do modelo cascata, a menos que combinado com os modelos de ciclo de vida iterativo, espiral ou evolucionário.
Iterativo/Espiral
Permite mudanças e o cliente é envolvido ao longo do ciclo de vida;
Alguns usuários acham fácil de gerenciar o tempo;
Permite o refinamento dos planos e idéias;
Teste acontece cedo – falhas podem ser encontradas mais cedo. Áreas importantes podem ser testadas primeiro;
Tempo para testar e fazer testes de regressão são elevados;
Bastante tempo entre o início e produção;
Alguns usuários acham que não é tão fácil para gerenciar por estágios; Pode ser difícil controlar custos e tempo;
Menos clareza nos marcos do projeto;
Evolucionário
Assim como o modelo de ciclo de vida iterativo e espiral, mais adequado aos marcos, menor tempo entre início e produção, entregas para áreas importantes primeiro.
Assim como os modelos de ciclo de vida iterativo/ espiral, riscos por falhas podem continuar se propagando se os testes forem insuficientes.
Modelo V
Fácil de gerenciar, de acordo com os critérios da ISO 9000.
Teste é contínuo e custo benefício em termos de defeitos encontrados e facilidade para consertar.
Necessita de muitos recursos para testar todos os derivados do projeto; No começo o ciclo de vida pode parecer caro e burocrático;
3. Padrões de Qualidade de Processo de Software
Os padrões de qualidade de processo de software mais conhecidos são a ISO/IEC 15504, CMMI e MPS.BR.
A ISO/IEC 15504 define um modelo referência de processos considerados essenciais para a engenharia de software no mundo [6]. A ISO/IEC 15504, cuja estrutura pode ser vista na (Figura 9), descreve duas dimensões a serem consideradas para avaliar a evolução e capacidade dos processos, a primeira dimensão define os processos que devem ser avaliados e a segunda dimensão define as escalas utilizadas para medição da capacidade dos processos avaliados [6].
O CMMI, criado pelo SEI no ano 2000 e teve a versão 1.1 lançada em 2002. Os principais objetivos alcançados ao criar o CMMI foram: eliminar inconsistências entre os modelos existentes, implementar melhorias no modelo CMM, estar compatível com a norma ISO/IEC 15504 e contemplar a forma de representação contínua. O CMMI permite duas representações, por estágios e contínua.
“O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos
(FINEP) e do Banco Interamericano de Desenvolvimento (BID).” Guia Geral
O MPS.BR além do processo de melhoria, estabelece o método de avaliação das empresas e processo de aquisição. Foi desenvolvido baseado nas normas ISO/IEC 12207 Processos de Ciclo de Vida de Software, suas emendas 1 e 2, na ISO/IEC 15504 – Avaliação de Processo e CMMI. Dessa forma está de acordo com o conteúdo do CMMI-DEV
3.1 Estrutura da Documentação MPS.BR
No Guia Geral está descrito o Modelo de Referência do MPS.BR. Ou seja, os processos e em função de seus resultados esperados, os níveis de maturidade e capacidades. Esses elementos descrevem a estrutura a ser implementada pela organização que deseja ter seus processos em conformidade com o MPS.BR [12].
O Guia de Aquisição contém as boas práticas para a aquisição de software e serviços correlatos [12].
O Guia de Avaliação contém o método e descrição dos papéis participantes de uma avaliação de maturidade no MPS.BR [12].
O Modelo de Negócios contém as regras para tornar-se uma instituição implementadora do MR-MPS, assim como para tornar-se uma instituição avaliadora. Além disso, contém orientações para organização de grupos de empresas para implementação e avaliação no MPS.BR, chamado de projeto cooperado e informações para obter a certificação de consultores de aquisição e treinamentos. [12]
Guias de Implementação: faz parte do conjunto de documentos de apoio ao MPS.BR. Estes guias fornecem orientações para implementar nas organizações os níveis de maturidade descritos no modelo de referência, detalhando os processos contemplados nos respectivos níveis de maturidade e os resultados esperados com a implementação dos processos.
3.2 Conceitos Importantes no MPS.BR
Atributo de processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC 15504-1, 2004]. Perfil do processo é um conjunto de pontuação de atributos de
processo para um processo avaliado [ISO/IEC 15504-1, 2004].
Resultado esperado do processo é resultado observável do sucesso do alcance do propósito do processo [ISO/IEC 12207:1995/Amd 1:2002]. A capacidade do processo é representada por um conjunto de atributos de processo descritos em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização. No MPS, à medida que a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização [12].
A estrutura de processos e níveis do MPS.BR pode ser vista na tabela abaixo:
Nível Processo Atributo de Processo
A Análise de Causas de Problemas e Resolução-ACP 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 B 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
Desenvolvimento para Reutilização – DRU
Análise de Decisão e Resolução – ADR
C
Gerência de Reutilização – GRU (evolução)
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Verificação – VER
Validação - VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP D Desenvolvimento de Requisitos – DRE AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP E
Avaliação e Melhoria do
Processo Organizacional – AMP
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Medição – MED
Garantia da Qualidade - GQA
Gerência de Configuração – GCO
F
Aquisição – AQU
AP 1.1, AP 2.1 e AP 2.2
Gerência de Requisitos – GRE G
Gerência de Projetos - GPR
AP 1.1 e AP 2.1
Tabela 1 - Estrutura de Processos e Níveis do MPS.BR – Fonte Guia Geral v1.2
No MPS.BR cada processo tem um propósito e seus resultados esperados. No nível G, estão os processos Gerência de Projetos e Gerência de Projetos. Os atributos de processo a serem atendidos nesse nível são o AP 1.1 e AP 2.1 [12], conforme citado anteriormente.
O propósito do processo Gerência de Projetos é:
“O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um
produto e/ou serviço, no contexto dos requisitos e restrições do projeto. [12]” Guia Geral
O propósito da Gerência de Requisitos é:
“O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os
requisitos, os planos do projeto e os produtos de trabalho do projeto”
Guia Geral
4. Ilog Tecnologia
A Ilog Tecnologia é uma micro empresa especializada no desenvolvimento de sistemas sob demanda. Foi fundada em 1997 e até o ano de 2007 dedicou-se ao desenvolvimento e evolução dos seus produtos para educação à distância. Em 2007 os direitos autorais dos produtos de educação à distância foram vendidos a empresa Datasul Educação Corporativa. Desde então a Ilog tem se dedicado ao desenvolvimento de sistemas sob demanda. Na mesma época em que a Ilog vendeu os direitos autorais dos seus produtos de Ensino a Distância iniciou o processo de implantação do MPS.BR nível G, através de um projeto cooperado coordenado pela ACATE. Em junho e julho de 2008 ocorrerão as avaliações para obter o nível G do MPS.BR.
4.1 Atividades para Implantação do MPS.BR na Ilog Tecnologia 4.1.1 Conscientização
A primeira atividade realizada pelos implementadores foram apresentações sobre o tema aos funcionários da Ilog para que esses se conscientizassem da importância de se ter um processo de desenvolvimento de software.
4.1.2 Diagnosticação da Situação Atual
A segunda atividade para a implantação do MPS.BR nível G foi a diagnosticação do processo de software existente na empresa, mesmo que informal.
4.1.3 Treinamento
A terceira atividade realizada para implantação do MPS.BR foram os treinamentos ministrados pelos implementadores sobre os processos do nível G do MPS.BR.
4.1.4 Mapeamento dos Processos
Para mapear os processos foi utilizada a técnica de brainstorm orientada pelos implementadores, para que todos os resultados esperados do MPS.BR mapeado fossem atendidos pelo processo. O processo foi mapeado baseado na experiência dos profissionais da Ilog e dos implementadores.
4.1.5 Detalhamento dos Processos Mapeados
Com o processo mapeado era possível iniciar a etapa de detalhamento deste processo. O detalhamento do processo implicava em decidir como deveria ser realizada cada atividade mapeada no processo. Isso era decidido em reuniões, geralmente com Gerente de Projetos, Analista de Sistemas e Gerente da Qualidade
4.1.6 Treinamento do Processo Organizacional
Após ter o processo totalmente documentado foi realizado o treinamento sobre o processo para todos os funcionários da Ilog. A partir de então o processo foi considerado institucionalizado, ou seja, foi considerado oficial para os próximos projetos a serem desenvolvidos na organização.
4.1.7 Avaliação Interna nos Projetos da Empresa
Após a institucionalização dos processos, os novos projetos passaram a ser avaliados quanto à consistência em relação aos processos. A avaliação do Projeto era realizada pelo Gerente da Qualidade. Nessas avaliações foram detectadas muitos pontos fracos e erros cometidos no desenvolvimento dos processos, além dos problemas do projeto avaliado.
4.1.8 Simulados
Os implementadores realizaram três simulados de avaliação ao longo da implantação. Além disso, contrataram um avaliador do oficial MPS.BR para realizar um simulado de avaliação.
4.2 Descrição dos Processos
Para obter o MPS.BR nível G a empresa precisa ter implantado os processos de Gerência de Projetos e Gerência de Requisitos. Para Implantação desses processos, foi necessária a criação de mais processos para darem apoio aos processos do nível G. Por isso foram criados os processos de Fornecimento, que descreve como devem ser as etapas que antecedem o planejamento de um projeto. Alem deste, foi criado o Processo de Encerramento, que descreve as ações a serem realizadas ao final de cada projeto. O processo de Gerência de Projetos foi dividido em dois: Processo de Planejamento de Projeto e o Processo de Monitoração, para que fossem executados com mais cuidado.
4.2.1 Processo de Fornecimento
O processo de Fornecimento descreve as atividades a serem realizadas antes de se ter o valor a ser cobrado pelo projeto solicitado. O objetivo deste processo é analisar a solicitação recebida para obter o valor a ser cobrado pelo projeto mais próximo possível do desejado. Um grande desafio na criação deste processo foi mantê-lo ágil de forma que a empresa não perdesse uma oportunidade por ter de ficar analisando para obter o exato valor do projeto e também que a Ilog conseguisse obter um valor que não a prejudicasse
4.2.2 Planejamento do Projeto
O objetivo deste processo é o planejamento do projeto em todas as suas etapas. Em um futuro próximo espera-se utilizar o histórico de projetos já encerrados para um planejamento mais preciso do projeto. Nesta etapa é onde acontece o planejamento do sistema a ser desenvolvido, o esforço, prazos, como ocorrerá o monitoramento do projeto.
4.2.3 Gerência de Mudanças de Requisitos
O objetivo do processo de Gerência de Requisitos é assegurar que qualquer mudança nos requisitos do sistema seja analisada de forma que o impacto das mudanças seja conhecido e tratado.
4.2.4 Encerrar o Projeto
Esse processo descreve as atividades a serem realizadas sempre que se considera um projeto encerrado. O objetivo principal deste processo é fazer com que as informações do projeto encerrado possam ser usadas no planejamento de projetos futuros.
4.2.5 Monitoração do Projeto
O processo de monitoração do projeto visa garantir que o projeto esta seguindo o que foi planejado e que os problemas encontrados sejam tratados
4.3 Preparação para Avaliação Oficial
Conforme o processo de avaliação do MPS.BR foram escolhidos dois projetos para serem avaliados. O objetivo do projeto avaliado era fazer um sistema para realizar uma avaliação do clima organizacional em empresas brasileiras, que foi dividido em duas etapas a serem avaliadas como projetos independentes na avaliação oficial do MPS.BR.
4.4 Avaliação Oficial
A avaliação oficial do MPS.BR ocorrerá em duas etapas, conforme guia da avaliação do modelo, na primeira etapa o avaliador analisará a planilha que contém todos os artefatos gerados ao longo da execução do processo. Esses artefatos são relacionados a cada resultado esperado do modelo. É dessa forma que o avaliador verificará se os resultados esperados estão sendo atendidos pelo processo. No final da avaliação o avaliador relatará os resultados requeridos pelo modelo, mas que não podem ser considerados atendidos através artefatos verificados.
A Ilog terá um prazo para resolver os problemas apontados pelo avaliador. Após esse período, o avaliador verificará se os itens apontados na primeira etapa foram corrigidos. Além disso, ocorrerão entrevistas com funcionários que participaram do projeto avaliado, para que o avaliador verifique se o processo é entendido e realizado por todos da mesma forma.
4.5 Ferramentas Utilizadas
4.51 Eclipse Process Framework - EPF
A ferramenta utilizada para dar apoio à criação e manutenção dos processos na Ilog, foi o Eclipse Process Framework, o EPF.
4.5.2 JExpChannel
O JExpChannel foi a ferramenta utilizada para o Gerenciamento de Projetos. Esse sistema foi desenvolvido pela empresa JExperts e ao longo da implantação a JExperts adequou muitas das funcionalidades do JExpChannel para que atendessem aos resultados esperados do MPS.RB nível G, o que facilitou a implantação dos processos.
5. Conclusões
A implantação do MPS.BR é uma excelente oportunidade para a indústria de software brasileiro, que há muito tempo convive com o caos no processo de desenvolvimento de software devido a falta de um modelo que se adequasse a sua realidade. Seja devido aos preços elevados ou ao próprio modelo, incompatível com o contexto de pequenas e médias empresas. Em um futuro próximo o MPS.BR pode ser a base para o aumento da competitividade brasileira na indústria de software no mundo, devida a compatibilidade deste com o CMMI.
5.1 Trabalhos Futuros
¾ Implantação dos demais níveis do MPS.BR;
¾ Integração dos templates, que contém as informações necessárias para atender ao modelo, aos sistemas da empresa;
¾ Realizar a Garantia da Qualidade nos projetos desenvolvidos pela empresa; ¾ Manutenção evolutiva dos processos existentes;
¾ Automatização das tarefas operacionais geradas pelo processo; 5.2 Referências Bibliográficas
Crise do Software
[24] Thayer, Richard H. Christensen, Mark J. Software Engineering. John Wiley & Sons, 2005.
[25] A “Crise do Software”. Disponível em
http://letshyve.wordpress.com/2007/04/25/artigo-a-crise-do-software/ acessado em março de 2008.
[26] Sisson, Martin Chito. Avaliação e Melhorias no Processo de Construção de Software. UFSC 2007.
12207
[1] Schmidt, Michael E.C. Implementing the IEEE Software Engineering Standards, SAMS, 2000.
[2] UNESP – Apresentação “Visão Geral da Norma ISO/IEC 12207”, 2006.
[3] Evans, Isabel. Achieving Software Quality through Teamwork. Artech House, 2004.
[4] NBR ISO/IEC 12207 – Tecnologia de Informação – Processos de Ciclo de Vida de Software: 1998.
[19] Contart, Soluções em Engenharia e Gestão - Ciclo de Vida Incremental. Disponível em http://www.dromostg.com.br/sol_engsoft3_4.aspx , acessado em novembro de 2007.
[20] Rational Software Corporation. Conceitos Iteração .Disponível em
http://www.wthreex.com/rup/process/workflow/manageme/co_phase.htm, acessado em novembro de 2007.
[21] Prado, Moacir de Sousa. Engenharia de Software. Disponível em
http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html, acessado em novembro de 2007.
[22] Engenharia de Programação. Disponível em
http://w3.ualg.pt/~pventura/ep/aulas_tp/t1_g5.pdf, acessado em novembro de 2007.
[31] McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press. 1996.
[36] Figura Arquitetura Geral do RUP. Disponível em:
http://pts.datasus.gov.br/processos/fluxos/tst_conceitosbasicos.htm, acessada em julho de 2008.
15504
[6] Bustard, David. Kawalek, Peter. Norris, Mark. Systems Modeling for Business Process Improvement, Artech House Boston, 2000.
[7] Fernandes, Jorge. Apresentação “Spice e ISO 15504”, 2004. Disponível em http://www.cic.unb.br/~jhcf/MyBooks/iess/SPICE/SPICE-26slides.pdf, acessado em novembro de 2007.
[9] ISO/IEC TR 15504-2:1998(E) - Information technology — Software process assessment — Part 2: A reference model for processes and process capability. 1998.
[32] Bustard, David. Kawalek, Peter. Norris, Mark. Systems Modeling for Business Process Improvement. Artech House. 2000.
CMMI
[8] Fagundes, Eduardo Mayer. Capability Maturity Model for Software. Disponível em http://www.efagundes.com/artigos/CMM.htm, acessado em novembro de 2007.
[11] Paulk, Mark C. Weber, Charles V. Garcia, Suzanne M. Chrissis, Mary Beth. Bush, Marilyn. Key Practices of the Capability Maturity ModelSM, Version 1.1 - Technical Report - CMU/SEI-93-TR-025 - ESC-TR-93-178. 1993.
[27] Lahoz, Carlos. Sant’Anna, Nilson. Os Padrões ISO/IEC 12207 e 15504 e a Modelagem de Processos da Qualidade de Software. 2003.
[10] Software Engineering Institute. Improving processes for acquiring better products and service. CMMI® for Acquisition, Version 1.2, November 2007. Technical Report CMU/SEI-2007-TR-017 - ESC-TR-2007-017.
MPS.BR
[12] SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral, Junho 2007, Versão 1.2. Disponível em http://www.softex.br/mpsbr/_guias/. Acessado em novembro de 2007.
[13] SOFTEX, MPS-BR - Melhoria de Processo do Software Brasileiro, Guia de Implementação Parte 1 – Nível G, Dezembro de 2006b. Disponível em
http://www.softex.br/mpsbr/_guias/. Acessado em novembro de 2007.
[33] Thiry, Marcello. Gerência de Projeto – Projeto Cooperado MPS.BR – ACATE 2007/2008. 2007.
EPF
[19] IBM Rational. The Eclipse Process Framework Project. Disponível em
http://www.ibm.com/developerworks/rational/library/05/1011_kroll/ Acessado em 30/03/08.
JExpChannel
