1) O documento descreve a experiência na definição de um processo de desenvolvimento de software baseado no MPS.BR nível G em uma fábrica de software. 2) O processo foi definido usando as normas ISO/IEC 12207, ISO/IEC 15504 e o guia geral do MPS.BR nível G para melhorar o processo de desenvolvimento de software. 3) A implantação do novo processo resultou em uma evolução gradual, melhor definição das atividades e prazos de entrega, e melhor acompanhamento do desenvolvimento de software.

1. A EXPERIÊNCIA NA DEFINIÇÃO DE UM PROCESSO BASEADO NO
MPS.BR NÍVEL G
Norton Coelho Guimarães
Graduado em Análise de Sistemas pela Universidade Salgado de Oliveira - UNIVERSO e Pós-Graduando em
Orientação a Objetos e Internet pelo Centro Universitário de Goiás - Uni-ANHANGÜERA
Resumo: Este artigo apresenta a experiência na definição, descrição e implantação de um
processo de desenvolvimento de software baseado no modelo de referência do MPS.BR no
nível G, juntamente com: a norma internacional ISO/IEC 12207, na definição do ciclo de vida
do processo de desenvolvimento de software e garantia da qualidade; a norma internacional
ISO/IEC 15504 na definição da elicitação dos requisitos e a gerência de requisitos; o
PMI/PmBok na definição das fases da gerência de projetos e; a Unified Model Language
(UML) como padrão de documentação dos artefatos de desenvolvimento de software. O
processo foi implantado em uma fábrica de software visando à melhoria no processo de
desenvolvimento de software baseado nas propostas do modelo de referência do MPS.BR no
nível G e com a substituição da técnica de desenvolvimento estruturado pelo paradigma
orientado a objetos. Observou-se uma evolução gradual durante a implantação do novo
processo de software e a melhoria na definição do que será feito e o como será feito, com
prazo de entrega do projeto definido e um melhor acompanhamento de todo o
desenvolvimento de software. Por fim, conclui-se pela necessidade de adquirir uma
maturidade mais elevada do processo de software, não sendo suficiente o nível G do MPS.BR
como ideal de qualidade dos produtos de uma fabrica de software.
Palavras-chave: melhoria do processo de software brasileiro (MPS.BR); processo de
software; engenharia de software; qualidade de software.
1 INTRODUÇÃO
Desde o surgimento do termo ―crise do software‖, no final da década de 1960, que
instituições de pesquisa vêm buscando uma forma de solucionar o problema na produção de
software. Um dos resultados dessas pesquisas foi o surgimento do termo Engenharia de
Software (MAFFEO, 1992).
Segundo Pressman (1995, p.31) a engenharia de software é um
[...] rebento da engenharia de sistemas e de hardware. Ela abrange um
conjunto de três elementos fundamentais — métodos, ferramentas e
procedimentos — que possibilita ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para
a construção de software de alta qualidade produtivamente.

2. 2
Segundo Bezerra (2007, p. 22) um processo de desenvolvimento de software
compreende
[...] todas as atividades necessárias para definir, desenvolver, testar e
manter um produto de software. Alguns objetivos de um processo de
desenvolvimento são: definir quais as atividades a serem executadas
ao longo do projeto; quando, como e por quem tais atividades serão
executadas; prover pontos de controle para verificar o andamento do
desenvolvimento; padronizar a forma de desenvolver software em
uma organização.
Segundo dados da Secretaria de Política de Informática do Ministério da Ciência e
Tecnologia mostram que apenas 49 empresas dispõem de um processo de desenvolvimento de
software avaliado pela SEI (Software Engineering Institute) da Carnegie Mellon University
no modelo do CMM (Capability Maturity Model) e 21 empresas no CMMI (Capability
Maturity Model Integration). Observa-se que somente empresas de grande porte conseguiram
tal feito (MCT, 2006).
O programa de Melhoria de Software Brasileiro (MPS.BR) foi criado com o
intuito de proporcionar uma oportunidade as micro, pequenas e médias empresas produtoras
de software de elaborar um processo de produção de software, respeitando os padrões de
qualidade internacionais (MPS.BR, 2006).
Este trabalho discute a experiência na definição de um processo para o
desenvolvimento de software orientado a objetos em uma Fábrica de Software. As seções 2, 3
e 4 apresentam uma revisão bibliográfica das normas ISO/IEC 12207, ISO/IEC 15504 e o
guia geral do MPS.BR. A seção 5 relata a experiência da implantação de um processo baseado
no guia geral do MPS.BR no nível G. Finalmente, na seção 6, são apresentadas as conclusões
deste trabalho.

3. 3
2 NBR ISO/IEC 12207
Em 1987 o International Organization for Standardization (ISO) e o International
Electrotechnical Commission (IEC) estabeleceu um Comitê de Técnicas Comuns (JTC1)
sobre Tecnologia da Informação (SINGH, 1998).
Em junho 1989, o JTC1 iniciou o desenvolvimento de um padrão internacional,
ISO/IEC 12207, sobre processos do ciclo de vida do software para preencher as necessidades
do desenvolvimento de software (SINGH, 1998).
Em 1995 a ISO/IEC 12207 foi publicada e atualizada em 2002 (COALLIER,
2003).
A ISO/IEC 12207 está dividida em três agrupamentos de processos que podem ser
executadas durante o ciclo de vida de software (NBR ISO/IEC 12207, 1998).
A NBR ISO/IEC 12207 (1998, p.5)
[...] agrupa as atividades que podem ser executadas durante o ciclo de
vida de software em cinco processos fundamentais, oito processos de
apoio e quatro processos organizacionais. Cada processo de ciclo de
vida é dividido em um conjunto de atividades; cada atividade é então
dividida em um conjunto de tarefas.
A Figura 1 demonstra o agrupamento dos processos e atividades.

4. 4
Figura 1 – Processos de Ciclo de Vida do Software. (Fonte: NBR ISO/IEC 12207, 1998, p.6).
2.1 Processos fundamentais de ciclo de vida
A parte fundamental é toda parte que inicia ou executa o desenvolvimento,
operação ou manutenção dos produtos de software (NBR ISO/IEC 12207, 1998).
De acordo com a NBR ISO/IEC 12207 (1998, p.5) os processos fundamentais são:
1) Processo de aquisição: Define as atividades do adquirente. Este processo
inclui pedido de proposta, seleção de fornecedor e gerência do processo de
aquisição;
2) Processo de fornecimento: Define as atividades do fornecedor,
organização que provê o produto de software ao adquirente. Determina os

5. 5
procedimentos e recursos necessários para gerenciar e garantir o projeto, o
desenvolvimento e a execução dos planos de projeto até a entrega do
sistema, ou software para o adquirente;
3) Processo de desenvolvimento: Define as atividades do desenvolvedor,
organização que define e desenvolve o produto. Contém as atividades para
análise de requisitos, projeto, codificação integração, testes, instalação e
aceitação relativos ao software;
4) Processo de operação: Define as atividades do operador, organização que
provê serviço de operação de um sistema;
5) Processo de manutenção: Define as atividades do mantenedor, organização
que provê o serviço de manutenção do produto de software. Este processo
inclui a migração e a descontinuação do produto de software.
2.2 Processos de apoio de ciclo de vida
Um processo de apoio auxilia outro processo quando necessário, contribuindo
para a qualidade do projeto de software (NBR ISO/IEC 12207, 1998).
De acordo com a NBR ISO/IEC 12207 (1998, p.5) os processos de apoio são:
1) Processo de documentação: Define as atividades da documentação dos
produtos gerados em um processo de ciclo de vida;
2) Processo de gerência de configuração: Define as atividades de gerência de
configuração, bem como identificar e definir os itens de software em um
sistema, e estabelecer suas linhas básicas (baseline); controlar as
modificações e liberações dos itens;

6. 6
3) Processo de garantia da qualidade: Define as atividades da garantida da
qualidade. Este processo inclui as revisões conjuntas, auditorias,
verificação e validação dos produtos gerados em um ciclo de vida;
4) Processo de verificação: Define as atividades para verificação dos
produtos de software;
5) Processo de validação: Define as atividades para validação dos produtos
de software do projeto de software;
6) Processo de revisão conjunta: Define as atividades para avaliação da
situação e produtos de uma atividade, onde uma delas revisa a outra parte;
7) Processo de auditoria: Define as atividades para determinar a
conformidade com requisitos, planos e contrato;
8) Processo de resolução de problema: Define um processo para análise e
remoção dos problemas que forem surgindo durante o ciclo de vida do
projeto.
2.3 Processos organizacionais de ciclo de vida
Eles são empregados para estabelecer e implementar uma estrutura subjacente.
São tipicamente empregados fora do domínio de projetos e seus resultados contribuem para a
melhoria da organização (NBR ISO/IEC 12207, 1998).
De acordo com a NBR ISO/IEC 12207 (1998, p.6) os processos organizacionais
são:
1) Processo de gerência: Define as atividades de gerência durante um
processo de ciclo de vida;

7. 7
2) Processo de infra-estrutura: Define as atividades de infra-estrutura. A
infra-estrutura pode incluir hardware, software, ferramentas, técnicas,
padrões e recursos para o desenvolvimento, operação ou manutenção;
3) Processo de melhoria: Define as atividades que uma organização executa
para estabelecer, medir, controlar e melhorar seu processo de ciclo de vida;
4) Processo de treinamento: Define as atividades para treinamento. Este
processo inclui preparação de pessoal e os materiais de treinamento.
Singh (1998, p. 17) conclui a ISO/IEC 12207 como
[...] o primeiro padrão internacional que provê um completo conjunto
de processos para aquisição e fornecimento de produtos de softwares e
serviços. Esses processos podem ser utilizados também para controlar,
projetar, e melhorar o software durante todo o ciclo de vida.
3 ISO/IEC 15504-5
Em 1991 o JTC1 iniciou um estudo sobre a necessidade de uma norma para
avaliação de processos de software, produzindo assim a norma ISO/IEC 15504
(KOSCIANSKI; SOARES, 2006).
De acordo com a ISO/IEC 15504-5 (1999) o modelo de referência define um
modelo bidirecional:
1) A dimensão de processo;
2) A dimensão de capacidade.
3.1 A dimensão de processo
De acordo com a ISO/IEC 15504-5 (1999) a dimensão do processo é definida e
classificada em cinco categorias de acordo com o tipo de atividade:
1) Processo Cliente-Fornecedor (CUS): Define o processo que impacta
diretamente no cliente. Este processo inclui o suporte de aplicação e
atualizações de softwares no cliente;

8. 8
2) Processo de Engenharia (ENG): Define o processo de implementação ou
manutenção de software e documentação do sistema;
3) Processo de Suporte (SUP): Define o processo que podem ser utilizados
por qualquer outro processo em vários pontos no ciclo de vida de um
software;
4) Processo de Gerenciamento (MAN): Define os processos de gerência de
projeto ou de processo dentro de um ciclo de vida do software;
5) Processo Organizacional (ORG): Define os processos que estabelecem os
objetivos de negócio da organização.
Há um número de processos associados com cada categoria de processo e são
divididos em três grupos de processo (ISO/IEC 15504-5, 1999).

9. 9
Figura 2 – Grupo de processos (CÔRTES, 1998, p.13).
3.2 Dimensão de capacidade
A dimensão de capacidade define uma série de atributos agrupados em níveis de
capacidade. Um nível de capacidade é um conjunto de atributos de processos que trabalha
juntos para fornecer um destaque da capacidade no desempenho do processo (ISO/IEC
15504-5, 1999).
De acordo com a ISO/IEC 15504-5 (1999) existem seis níveis de capacidade no
modelo de referência, incorporando nove atributos de processo:
1) Nível 0: Processo Incompleto. O processo não é implementado;

10. 10
2) Nível 1: Processo Executado. O processo essencialmente atinge os
objetivos;
3) Nível 2: Processo Gerenciado. O processo é implementado de forma
controlada;
4) Nível 3: Processo Estabelecido. O processo é implementado de forma
consistente;
5) Nível 4: Processo Previsível. O processo é executado e existe um controle
que permite verificar se ele se encontra dentro dos limites estabelecidos
para atingir os resultados;
6) Nível 5: Processo Otimizado. O processo é adaptado continuamente.
Os atributos do processo são usados para medir se um processo alcançou uma
dada capacidade. Cada atributo mede um aspecto particular (ISO/IEC 15504-5, 1999). A
Tabela 1 demonstra os níveis e seus atributos.
Tabela 1 - Atributos de Processo (Fonte: CÔRTES, 1998, p.46).

11. 11
4 GUIA GERAL DO MPS.BR
A Associação para Promoção da Excelência do Software Brasileiro (SOFTEX),
desde dezembro de 2003 vem desenvolvendo o programa para Melhoria de Processo do
Software Brasileiro (MPS.BR) (MPS.BR, 2006).
O Modelo de Referência (MR-MPS) define níveis de maturidade que são uma
combinação entre processos e sua capacidade (MPS.BR, 2006, p. 14).
4.1 Níveis de Maturidade
Os níveis de maturidade são estágios de melhoria da implementação de processos
na organização, onde permite prever o seu desempenho futuro ao executar um ou mais
processos. De acordo com o MPS.BR (2006) são definidos sete níveis de maturidade:
1) Nível A: Processo em Otimização;
2) Nível B: Processo Gerenciado Quantitativamente;
3) Nível C: Processo Definido;
4) Nível D: Processo Largamente Definido;
5) Nível E: Processo Parcialmente Definido;
6) Nível F: Processo Gerenciado;
7) Nível G: Processo Parcialmente Gerenciado.
A escala de maturidade se inicia no nível G e progride até o nível A (MPS.BR,
2006).
4.2 Processos
De acordo com o MPS.BR (2006) os processos são agrupados de acordo com o
seu objetivo principal no ciclo de vida de software. O agrupamento é dividido em:

12. 12
1) Processos fundamentais: atendem o início e a execução do
desenvolvimento, operação ou manutenção dos produtos de software;
2) Processos de apoio: auxiliam outro processo quando necessário e
contribuindo para a qualidade do projeto de software;
3) Processos organizacionais: uma organização pode empregar estes
processos em nível corporativo para estabelecer, implementar e melhorar
um processo do ciclo de vida.
Os processos que compõem o MR-MPS são os descritos na Figura 3.
Figura 3 – Processos do MR-MPS (Fonte: MPS.BR, 2006, p. 17).

13. 13
4.3 Capacidades do Processo
De acordo com o MPS.BR (2006) a capacidade do processo é representada por
um conjunto de atributos de processo descrito em termos de resultados esperados, que são
divididos em:
1) AP 1.1: O processo é executado;
2) AP 2.1: O processo é gerenciado;
3) AP 2.2: Os produtos de trabalho do processo são gerenciados;
4) AP 3.1: O processo é definido;
5) AP 3.2: O processo está implementado.
A Tabela 2 apresenta os níveis de maturidade do MR-MPS, os processos e os
atributos de processo correspondentes a cada nível.
Tabela 2 – Nível de Maturidade do MR-MPS (Fonte: MPS.BR, 2006, p. 20).

14. 14
Koscianski; Soares (2006, p. 154) concluíram o MPS.BR como
[...] mais um modelo de melhoria de processos definidos em níveis,
semelhantes aos modelos CMM e CMMI. O projeto está em
andamento e os primeiros resultados práticos começaram a surgir em
2005.
O argumento básico do MPS.BR é que a proposta, por
apresentar um número maior de estágios que o CMMI, permita
implementação mais gradual e adequada às pequenas e médias
empresas brasileiras. Além disso, argumenta-se que poucas empresas
de pequeno ou médio porte podem arcar com os custos de
implementação dos modelos do SEI. O objetivo do modelo MPS.BR é
preencher essa lacuna em empresas brasileiras que desenvolvem
software.
5 A IMPLANTAÇÃO DO MPS.BR NÍVEL G.
Primeiramente para definir um processo de software é necessário que seja criado
um Grupo de Processo de Software (GPS) para pesquisar, definir e elaborar as documentações
necessárias.
A definição de um processo para atender os requisitos do MPS.BR Nível G é
muito trabalhoso, devido este nível de maturidade exigir o gerenciamento de projetos e
requisitos. Em uma empresa que detêm um processo caótico esse trabalho é ainda maior
(PRESSMAN, 1995).
O processo proposto para atender as necessidades de gerência de projetos,
procurou incorporar as principais características do PmBok (PMI, 2004) contemplando as
fases de:
1) Iniciação: Definir o que será feito no projeto;
2) Planejamento: Planejar como será feito no projeto;
3) Execução: Executar o planejado do projeto;
4) Controle: Gerenciar todas as fases do projeto;
5) Encerramento: Finalizar o projeto.
De acordo com o MPS.BR (2006, p.6) dois pontos são desafiadores na
implantação do nível G:

15. 15
1) Mudança de cultura organizacional, orientando a definição e melhoria dos
processos de desenvolvimento de software;
2) Definição do conceito acerca do que é ―projeto‖ para a organização.
Pensando nesses pontos desafiadores o GPS decidiu melhorar o processo de
engenharia de software não prevista na implantação do nível G, utilizando:
1) Um Ciclo de Vida (cascata, interativo e incremental) de acordo com o
tamanho do projeto (BEZERRA, 2007);
2) Um padrão de notação seguindo a UML (Unified Model Language)
(FURLAN, 1998);
3) E princípios da Orientada a Objetos (BEZERRA, 2007).
A gerência de requisitos acabou sendo o ponto crucial na melhoria da qualidade
no desenvolvimento de software, prevenindo e monitorando mudanças nos requisitos. Esse
monitoramento foi de grande ajuda para a gerência de projetos evitando retrabalho por falta
de entendimento do que foi proposto a ser desenvolvido.
Para cada uma das atividades do ciclo de vida, foram definidos sub-atividades que
incluem: o fluxo de trabalho, os métodos, as técnicas, os roteiros aplicáveis, os recursos
necessários, os artefatos requeridos e produzidos, os marcos de projeto e os pontos de controle
para acompanhamento do projeto e avaliação da qualidade. O quadro 1 apresenta um resumo
das definições feitas para as atividades em cada fase do ciclo de vida.

16. 16
Fase Recursos Humanos Produtos Anexos
1 - Iniciação Gerente de Projetos,
Analista de
Requisitos
Termo de Abertura Análise de Viabilidade,
Definição de Escopo,
Estimativa de Esforço e
Tamanho, Custo Estimado
Inicial, Cronograma
Inicial
2 - Planejamento Gerente de Projetos Plano de Projeto Ciclo de Vida, WBS,
Cronograma do Projeto,
Mapa de Risco,
Orçamento do Projeto,
Análise de Viabilidade,
Recursos Humanos
3 - Execução
3.1 – Análise Analista de
Requisitos
Lista de Requisitos,
Modelo de Caso de Uso,
Diagrama de Classe de
Negócio
3.2 – Projeto Projetista Diagrama de Classe,
Modelo de Dados,
Diagrama de Seqüência,
Diagrama de
Componentes, Diagrama
de Implantação,
Prototipação, Diagrama
de Transição de Estado
3.3 – Implementação Projetista,
Desenvolvedor
Código fonte
3.4 – Montagem Projetista Aplicação
3.5 – Homologação Gestor de Qualidade Aplicação Aprovada
4 – Controle Gerente de Projetos,
Gestor de Qualidade,
Gerente de Requisitos
Relatório de Projeto,
Relatório de Requisitos,
Planilha de Previsto e
Realizado, Planilha de
Não conformidades.
5 – Encerramento Gerente de Projetos Termo de Encerramento
Quadro 1 - Principais características do Processo definido
O processo está na fase de implantação. Foi definido um projeto de médio porte
dividido em quatro subprojetos, onde foi possível avaliar o que foi definido pelo GPS.
O primeiro subprojeto foi denominado de projeto piloto. Neste projeto foi possível
detectar que as fases definidas não estavam coesas e acarretando um atraso significativo do
projeto. As falhas foram corrigidas para o próximo subprojeto.
No segundo subprojeto foi possível identificar vários pontos passíveis de
melhoria. A gerência de requisitos foi a que mais sofreu mudanças para garantir que os

17. 17
requisitos fossem mantidos coesos, coerentes e rastreáveis até o final do subprojeto. A
gerência de projetos também sofreu melhorias, principalmente no método de estimativa de
custo e prazo, adaptando o método empírico utilizado para a realidade da equipe.
No terceiro subprojeto as mudanças e melhorias apresentadas nos subprojetos
anteriores surtiram resultados positivos, podendo comprovar um melhor controle em todas as
fases do projeto e o cumprimento do que foi acordado no início do projeto. O terceiro
subprojeto está em fase de desenvolvimento. Com o ciclo de vida do projeto em cascata
(iniciação, planejamento, execução e encerramento), a fase de execução com três iterações e a
fase de controle em paralelo.
6 CONCLUSÃO.
Todas as empresas produtoras de software que almejam qualidade e produtividade
em seus produtos devem escolher um modelo de processo e adapta-lo a sua realidade. Neste
trabalho, apresentamos um processo de desenvolvimento de software baseado no modelo de
melhoria de processo de software brasileiro (MPS.BR) no nível G.
A escolha do MPS.BR foi motivada por razões:
1) Mercadológicas: devido aos editais públicos estarem pontuando empresas
que comprovem um processo de desenvolvimento avaliado pelo MPS.BR,
com o desenvolvimento orientada a objetos e artefatos de software no
padrão da UML;
2) Econômicas: visto que, comparados com outros processos de software, o
valor agregado para uma implantação é bastante reduzido;
3) Temporais: o prazo de implantação é reduzido, não ultrapassando seis
meses.

18. 18
À medida que o processo vai sendo institucionalizado inúmeras melhorias vão
surgindo e sendo agregadas ao processo já definido, buscando sempre melhorar a
documentação dos produtos.
Em curto prazo, foi possível observar que um processo definido para o
desenvolvimento de software baseado no MPS.BR muda drasticamente a cultura de uma
fábrica de software, fazendo com que seja produzido produtos com maior qualidade e
reduzindo com isso o custo da manutenção.
O nível G do MPS.BR é excelente para iniciar a melhoria de um processo de
software, mas não é suficiente para que uma empresa seja competitiva, consiga medir
resultados, avaliar a qualidade, e mesmo controlar suas versões de produtos. Sendo necessário
progredir para o nível F do MPS.BR.
REFERÊNCIAS BIBLIOGRAFIAS
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia Geral, versão 1.1, maio 2006. Disponível em:
<http://www.softex.br>. Acesso em: 4 de agosto de 2006.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia de Implementação Parte 1, dezembro 2006. Disponível em:
<http://www.softex.br>. Acesso em: 21 de março de 2007.
BEZERRA, Eduardo. Princípios da análise e projeto de sistemas com UML. Rio de
Janeiro: Elsevier, 2007.
COALLIER, François. A Web year is three months: International standardization in software
and systems engineering. ISO Bulletin, Genebra. Maio, 2003. Disponível em:
<http://www.iso.org/iso/en/commcentre/isobulletin/articles/2003/pdf/web03-05.pdf>. Acesso
em: 1 de maio de 2007.
CÔRTES, Mario L. Modelos de Qualidade de Software. Campinas, 1998. Disponível em
<http://www.ic.unicamp.br/~cortes/mc726/>. Acesso em: 10 de agosto de 2007.

19. 19
FURLAN, José Davi. Modelagem de Objetos através da UML – the Unified Modeling
Language. São Paulo: Makron Books, 1998.
ISO/IEC 15504. 1999. ISO/IEC TR 15504 Part 5: An Assessmente Model and Indicator
Guidance, ISO/IEC JTC1 SC7. International Standard Organization – ISO/IEC.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software: aprenda as
metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo:
Novatec Editora, 2006.
MAFFEO, Bruno. Engenharia de Software e especificação de sistemas. Rio de Janeiro:
Campus, 1992.
MINISTÉRIO DA CIÊNCIA E TECNOLOGIA - SECRETARIA DE POLÍTICA DE
INFORMÁTICA. Qualificação CMM e CMMI no Brasil. Brasília, 2006. Disponível em: <
http://www.mct.gov.br/upd_blob/0009/9238.pdf>. Acesso me: 21 agosto 2007.
NBR ISO/IEC 12207:1998, Tecnologia de Informação – Processos de Ciclo de Vida de
Software, Rio de Janeiro, ABNT – Associação Brasileira de Normas Técnicas.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Education do Brasil,
1995.
PROJECT MANAGEMENT INSTITUTE – PMI. A Guide to the Project Management Body
of Knowledge - PMBOK™, Syba: PMI Publishing Division, 2004. Disponível em:
<www.pmi.org>.
SINGH, Raghu. International Standard ISO/IEC 12207 Software Life Cycle Processes,
Federal Aviation Administration Washington, DC, USA, 23 Junho, 1998. Disponível em
<http://www.abelia.com/docs/12207cpt.pdf>. Acesso em: 1 de maio de 2007.