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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À 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

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.