U S G MPS - UFPAspider.ufpa.br/projetos/siga_mpsbr/tcc.pdf · companies improve on the development...
80
UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Anderson Jones Silva de Jesus UMA SOLUÇÃO SISTÊMICA PARA A GERÊNCIA DE ATIVOS NO CONTEXTO DA IMPLEMENTAÇÃO DOS NÍVEIS DO MPS.BR Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira Belém 2009
Transcript of U S G MPS - UFPAspider.ufpa.br/projetos/siga_mpsbr/tcc.pdf · companies improve on the development...
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Anderson Jones Silva de Jesus
UMA SOLUÇÃO SISTÊMICA PARA A GERÊNCIA DE ATIVOS NO CONTEXTO DA IMPLEMENTAÇÃO DOS
NÍVEIS DO MPS.BR
Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação
Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira
Belém 2009
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Anderson Jones Silva de Jesus
UMA SOLUÇÃO SISTÊMICA PARA A GERÊNCIA DE
ATIVOS NO CONTEXTO DA IMPLEMENTAÇÃO DOS NÍVEIS DO MPS.BR
Data da defesa: ____/____/____
Conceito: ____________
Banca Examinadora
Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA – Orientador
Prof. Alfredo Braga Furtado Faculdade de Computação/UFPA – Membro
Prof. Dionne Cavalcante Monteiro Faculdade de Computação/UFPA – Membro
Belém 2009
À Deus e a Seu filho Jesus Cristo pelo cuidado que sempre têm por nós.
AGRADECIMENTOS
Acima de tudo a Deus, que nos tem dado fôlego de vida e disposição, a Ele a
honra e glória pelos séculos dos séculos.
A meus pais pela incansável luta de cada dia, abrindo mão de si mesmos
para que tivéssemos uma boa educação.
A minha querida esposa, Areli, pelo apoio durante a confecção deste trabalho
A cada um dos professores e colegas que contribuíram para nossa formação
Aos professores Francisco Edson e Alfredo Furtado que muito nos
incentivaram e apoiaram durante todo o curso, até hoje.
Às gerentes Socorro Bandeira e Conceição Guimarães pelo apoio e incentivo.
Agradeço especialmente ao professor Sandro Bezerra, nosso orientador, o
qual tem sempre agido como um verdadeiro profissional da educação na tarefa de
nos orientar, apesar de nossas falhas para com ele. Se não fosse seu apoio e ajuda,
em orientar-nos e desafiar-nos, não chegaríamos até aqui.
Que Deus abençoe a cada um de vocês!
“Bem-aventurado o homem que acha sabedoria, e o homem que adquire
conhecimento, porque é melhor a sua
mercadoria do que artigos de prata, e maior o seu lucro que o ouro mais fino. Mais preciosa é do que os rubis, e tudo o que mais possas desejar não se pode comparar a ela.”
Rei Salomão
RESUMO
Na busca por melhoria dos padrões de qualidade na produção de software,
empresas aperfeiçoam-se nos processos de produção, a fim de garantir que os
softwares sejam criados de forma sistemática. Um estudo voltado para atender esta
área de qualidade, deficiente em algumas empresas, foi feito de modo a atender as
dificuldades das empresas que queiram implementar os níveis de
qualidade/maturidade do modelo MPS.BR (Melhoria do Processo de Software
Brasileiro), onde são identificadas as dificuldades encontradas pelas empresas.
Desta forma, este trabalho visa implementar uma solução sistêmica que gerencia os
ativos organizacionais (ferramentas de software, procedimentos e templates de
artefatos gerados) para cada processo usado como base para a implementação de
um programa de qualidade aderente ao modelo MPS.BR, simplificando o processo
de implementação dos níveis deste modelo por parte dos consultores envolvidos.
PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Modelos de
Melhoria, MPS.BR, Ferramentas de Software.
ABSTRACT
In the search for improvement of quality standards in the software development,
companies improve on the development processes to ensure that software is created
in a systematic way. A study aimed to address this area of quality, deficient in some
companies, was made in order to meet the difficulties of companies that wish to
implement the maturity/quality levels of MPS.BR model (Improvement for Brazilian
Software Process), where the problems are identified encountered by companies.
Thus, this work aims to implement a systemic solution that manages the
organizational assets (software tools, procedures and artifacts templates generated)
for each process used as a basis for implementing a quality program adhering to the
MPS.BR model, simplifying the implementation process of levels this model by the
consultants involved.
KEYWORDS: Process Improvement, Software Quality, Models for Improvement, MPS.BR, Software Tools.
SUMÁRIO
1 Introdução ........................................................................................................... 13
1.1 Fundamentação Teórica .............................................................................. 13
1.2 Problemática ................................................................................................ 13
1.3 Justificativa ................................................................................................... 13
1.4 Objetivo ........................................................................................................ 14
1.5 Metodologia .................................................................................................. 14
1.6 Estrutura ....................................................................................................... 14
2 Processo de Desenvolvimento de Software ....................................................... 16
2.1 Conceito de Processo de Software .............................................................. 16
2.2 Exemplos de Modelos de Processos de Software ....................................... 19
2.3 Meta-Processo de Software ......................................................................... 29
3 Melhoria de Processos de Software ................................................................... 32
3.1 Processo Padrão .......................................................................................... 32
3.2 Normas e Modelos de Qualidade para Processos de Software ................... 33
3.2.1 A Norma ISO/IEC 12207 – Tecnologia de Informação – Processos de Ciclo de Vida de Software ................................................................................... 33
3.2.2 A Norma ISO/IEC 15504 (SPICE) ......................................................... 35
3.2.3 Capability Maturity Model (CMM) ........................................................... 39
3.2.4 Capability Maturity Model Integration (CMMI) ........................................ 41
3.2.5 Norma ISO 9000-3 (Qualidade dos Processos)..................................... 44
3.3 O Modelo de Referência MPS.BR (Melhoria de Processo de Software Brasileiro) ............................................................................................................... 47
3.3.1 Modelo de Referência para Melhoria de Processo de Software ............ 49
3.3.2 Método de Avaliação ............................................................................. 53
4 SiGA-MPS.Br – uma Solução Sistêmica de Ativos de Processo para Implementações no MPS.BR .................................................................................... 55
4.1 Motivação ..................................................................................................... 55
4.2 Projeto da Solução Sistêmica ...................................................................... 55
4.2.1 Definição da Ferramenta ....................................................................... 56
4.2.2 Fluxo de atividades ................................................................................ 56
4.2.3 Arquitetura ............................................................................................. 63
4.2.4 Modelo de Entidade-Relacionamento .................................................... 65
4.3 Protótipo da Ferramenta .............................................................................. 66
4.4 Estudo de Caso ............................................................................................ 72
5 Conclusão ........................................................................................................... 75
5.1 Visão Geral .................................................................................................. 75
5.2 Trabalhos propostos..................................................................................... 75
Referências Bibliográficas ......................................................................................... 77
LISTA DE FIGURAS
Figura 2.1 Rede de Atividades de um processo de software [Reis.98] ..................... 18
Figura 2.2 Ciclo de Vida do RUP (adaptado de [Krutchen.03]) ................................. 21
Figura 2.3 Componentes do framework do processo OPEN (adaptado de [Graham.97]) ............................................................................................................. 22
Figura 2.4 Exemplo de rotas de aplicação do Catalysis (adaptado de [D’Souza.99]) .................................................................................................................................. 24
Figura 2.5 Práticas do XP (adaptado de [Jefrries.01]) ............................................... 26
Figura 2.6 Processo do Crystal (adaptado de [Cockburn.02]) ................................... 27
Figura 2.7 Fases do SCRUM [Bach.95] .................................................................... 28
Figura 2.8 Escopo do Agile Modeling (adaptado de [Ambler.02]) ............................. 29
Figura 2.9 Visão Geral do Meta-Processo de Software [Reis.99b] ........................... 31
Figura 3.1 Estrutura da Norma ISO/IEC 12207 [ISO.97] [ISO.01] [ISO.04a]. ............ 35
Figura 3.2 Modelo de Avaliação de Processos proposto pela ISO/IEC TR 15504 [ISO.98] ..................................................................................................................... 39
Figura 3.3 Estrutura do CMM [Paulk.93] ................................................................... 40
Figura 3.4 Categorização das Áreas de Processo do CMMI de acordo com a área de atuação e o nível de maturidade [Fernandes.04] ...................................................... 43
Figura 3.5 Modelo de Negócio para melhoria de processo de software (MN mps) [Weber.04] ................................................................................................................. 49
Figura 3.6 Definição do Modelo de Referência do MPS.BR [Softex.07a] .................. 50
Figura 3.7 Modelo de Referência para melhoria do Processo de Software (MR mps) [Softex.07a] ............................................................................................................... 52
Figura 4.1 Diagrama de Atividades Geral do SiGA-MPS.Br ...................................... 57
Figura 4.2 Diagrama de Atividades da “Cadastra Processos” ................................... 58
Figura 4.3 Diagrama de Atividades da “Cadastra Resultados Esperados” ............... 59
Figura 4.4 Diagrama de atividades da “Cadastra os Tipos de Recursos” ................. 60
Figura 4.5 Diagrama de Atividades da “Cadastra Recurso Disponível” .................... 61
Figura 4.6 Diagrama de Atividade da “Vincula Tipo de Recurso a Resultados Esperados” ................................................................................................................ 62
Figura 4.7 Diagrama de atividades da “Consulta Recursos” ..................................... 63
Figura 4.8 Diagrama de Pacotes do Sistema seguindo o modelo MVC .................... 64
Figura 4.9 Modelo de Entidade-Relacionamento ...................................................... 65
Figura 4.10 Tela de Cadastro dos Processos ........................................................... 68
Figura 4.11 Tela de Registro dos Resultados Esperados ......................................... 69
Figura 4.12 Tela de Registro dos Tipos de Recursos ............................................... 69
Figura 4.13 Tela de Registro dos Recursos .............................................................. 70
Figura 4.14 Tela de Cadastro dos Resultados Esperados x Tipos de Recurso ........ 71
Figura 4.15 Tela de Consulta da ferramenta SiGA-MPS.BR ..................................... 72
Lista de Tabelas
Tabela 2.1 Alguns Princípios e Práticas em XP (adaptado de [Jefrries.01]) ............. 25
Tabela 3.1 Processos Definidos na ISO 9000-3 [ISO.91] ......................................... 44
Tabela 3.2 Regras para Caracterizar o grau de implementação das práticas [Softex.07b] ............................................................................................................... 54
13
1 INTRODUÇÃO
Neste capítulo serão apresentados os aspectos que motivaram o desenvolvimento desta
monografia, seus objetivos e a estrutura desta.
1.1 Fundamentação Teórica
Em uma fábrica de software há uma relação direta entre o nível de maturidade na
execução de processos e a qualidade de um produto de software. Desta maneira, as fábricas de
software buscam a maturidade através da implementação de normas e modelos de qualidade
em seus setores de desenvolvimento, a partir do uso de normas como: a ISO/IEC 12207
[ISO.97] [ISO.01] [ISO.04a] e a ISO/IEC 15504 [ISO.04b], os modelos de maturidade CMMI
[CMMI.02] e o modelo de referência MPS.BR (Melhoria de Processo do Software Brasileiro)
[Softex.07a][Softex.07b].
Estas normas e modelos auxiliam as empresas como guias que representam a maneira
de execução dos seus processos de desenvolvimento de software, indo do seu planejamento
até sua entrega e manutenção junto ao cliente. O MPS.BR é um modelo criado para a
realidade das empresas brasileiras, e criado a partir de estudo de um modelo e normas
internacionais. Este modelo é dividido em sete níveis de maturidade. Sua avaliação é feita
pelos processos e a empresa escolhe em que nível e em que setor da sua fábrica deve ser
avaliado.
1.2 Problemática
No processo de implementação e avaliação da maturidade do MPS.BR em organizações
que buscam o programa de melhoria da qualidade, o implementador-consultor e o avaliador
realizam a tarefa quase que manualmente, apenas auxiliado por editores de texto e planilha, o
que gera uma perda de tempo que poderia ser melhor aplicado no restante da tarefa de
implementação e avaliação, o que pode tornar este trabalho um processo moroso. Desta feita,
há a necessidade de um trabalho de pesquisa, de modo que a mesma tarefa possa ser realizada
em um menor tempo.
1.3 Justificativa
Este trabalho diz respeito a uma solução sistêmica aplicada a tal problemática, tendo em
vista a não existência de uma ferramenta homologada pela SOFTEX (Associação para
14
Promoção da Excelência do Software Brasileiro) para auxílio na implementação do modelo de
qualidade MPS.BR. Foi escolhido o MPS.BR como modelo de qualidade dado o seu menor
custo de implementação e avaliação, mais acessível às empresas, pois há incentivo do
Governo Federal, e por ser um modelo aderente às recomendações de vários outros modelos
em uso atualmente.
1.4 Objetivo
Em [Silva.08] é produzida uma súmula das boas práticas definidas nos guias de
implementação dos níveis G e F do MPS.BR, para caracterizar de uma forma sintetizada os
ativos recomendados pela Equipe Técnica do Modelo MPS.BR. Nele cita-se como
recomendação de trabalhos futuros a criação de um sistema para exibição e cadastramento
dessas boas práticas. Este trabalho objetiva o atendimento desse sistema no contexto da gestão
de conhecimento dos ativos organizacionais dos implementadores-consultores e avaliadores
obtidos ao longo da realização das suas atividades.
Este trabalho especificamente objetiva a catalogação de ativos e boas práticas para todos
os níveis no MPS.BR, e sua utilização em implementações de empresas, observando-se a
simplificação do trabalho que este proporciona, com conseqüente redução do tempo de
consultoria para um implementação do modelo MPS.BR.
1.5 Metodologia
Para o desenvolvimento deste trabalho foi usado como base: o entendimento do escopo;
levantamento de requisitos; implementação e correção de possíveis problemas. O
entendimento do escopo e o levantamento de requisitos ocorreram através de entrevistas com
um avaliador certificado pela SOFTEX e leitura dos guias do MPS.BR disponibilizados pela
SOFTEX em (www.softex.org.br). A implementação foi feita em Delphi 7.0 com arquitetura
desktop.
1.6 Estrutura
Além deste capítulo introdutório, a organização da monografia foi feita da seguinte
forma:
O capítulo 2 tem por objetivo explicar o que é processo de software, conceito e
definição de processo e meta-processo.
15
O capítulo 3, é dedicado a explicar os principais modelos e normas de qualidade de
processo de software (ISO 12207, ISO 15504, CMM e CMMI, ISO 9000-3) e o modelo de
qualidade escolhido MPS.BR.
No capítulo 4 é apresentado o sistema Siga-MPS.BR, a motivação para o seu
desenvolvimento, a definição do seu escopo e o projeto de concepção e especificação.
No capítulo 5 será realizada a conclusão do trabalho proposto, comentando os
resultados obtidos e propostas para trabalhos futuros.
Por último as referências bibliográficas com toda a base referencial de conhecimento
utilizada para realização deste trabalho.
16
2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
2.1 Conceito de Processo de Software
Humphrey define em [Humphrey.89], processo de software como o conjunto de tarefas
de engenharia de software necessárias para transformar os requisitos dos usuários em
software. Na definição de um processo de software devem ser consideradas as seguintes
informações: atividades a serem realizadas, recursos utilizados, artefatos consumidos e
gerados, procedimentos adotados, paradigma e tecnologia adotados, e o modelo de ciclo de
vida utilizado [Falbo.98].A Figura 2.1 mostra um diagrama do funcionamento da atividade do
processo de software.
2.1 Atividade do Processo de Software
Os processos de software podem apresentar grande complexidade e possibilitar diversas
alternativas de execução de suas atividades. Desta forma, um processo de software definido
permite que profissionais de engenharia de software possam trabalhar de forma ordenada,
possibilitando um melhor entendimento do seu trabalho, bem como de outras atividades
executadas por outros membros da mesma equipe [Humphrey.89].
No entanto, não existe um processo de software que possa ser genericamente aplicado a
diversos projetos, visto que nenhum projeto é idêntico ao outro. Variações nas políticas e
17
procedimentos organizacionais, métodos e estratégias de aquisição, tamanho e complexidade
do projeto, requisitos e métodos de desenvolvimento do sistema, entre outros fatores,
influenciam na forma como um produto de software é adquirido, desenvolvido, operado e
mantido [ISO.97] [ISO.01] [ISO.04a]. Assim, na definição de um processo deve-se considerar
a sua adequação às tecnologias envolvidas, ao tipo de software em questão, ao domínio de
aplicação, ao grau de maturidade (ou capacitação) da equipe em engenharia de software, às
características próprias da organização, às características do projeto e da equipe
[Humphrey.89], [Rocha.01].
Esse conjunto de tarefas de engenharia, aqui chamados de atividades, incorpora e
implementa procedimentos, regras e políticas, e com o objetivo de gerar ou modificar um
conjunto de artefatos. As atividades podem ser organizadas em redes com duas dimensões
(horizontal e vertical, como visto na Figura 2.2) e estão associadas com papéis, ferramentas e
artefatos.
Uma atividade de processo aloca recursos (por exemplo, máquinas e orçamento), é
escalonada, monitorada e atribuída a desenvolvedores (agentes), os quais podem fazer uso de
ferramentas para executá-la [Reis.98 apud Oliveira.06]. Pode dizer-se que uma atividade é
automática quando é executada sem intervenção humana, somente por ferramentas
automatizadas. Toda atividade possui uma descrição, que pode especificar os artefatos
necessários, as relações de dependência com outras atividades, as datas planejadas de início e
fim, os recursos a serem alocados e os agentes responsáveis pela mesma.
18
Um agente está relacionado com as atividades de um processo e pode ser uma pessoa
ou uma ferramenta automatizada (quando a atividade é automática). Os agentes podem estar
organizados em cargos, diferentes agentes terão percepções acerca do que acontece durante o
processo de software. Um agente gerente, por exemplo, perceberá os aspetos de controle e
alocação de recursos e cronogramas para atividades, enquanto um desenvolvedor perceberá as
suas atividades como atribuições que devem ser feitas para produzir um resultado.
Um artefato é um produto criado ou modificado durante um processo. Tal produto é
resultado de uma atividade e pode ser utilizado posteriormente como matéria-prima para a
mesma ou para outra atividade a fim de gerar novos produtos. Desta forma, uma atividade
pode consumir produtos (de entrada) e gerar novos produtos (de saída). Os produtos são
freqüentemente persistentes e possuem versões [Reis.98].
a
b
c
d
e
f
g
a.1
a.2
a.3
e.1 e.3 e.4
e.2
a.3.1
a.3.2
Figura 2.2 Rede de Atividades de um processo de software [Reis.98]
19
A realização do processo é afetada pelas restrições, que podem atingir atividades,
agentes, recursos, artefatos, papéis e seus relacionamentos. Uma restrição é uma condição
definida que um passo de processo deve satisfazer antes ou depois de ser executado.
Um modelo de processo de software é uma descrição abstrata do processo de software.
Vários tipos de informação devem ser integrados em um modelo de processo de software para
indicar quem, quando, onde, como e por que os passos são realizados. Para representar um
modelo de processo de software é utilizada uma linguagem de modelagem do processo de
software, a qual deve oferecer recursos para descrever e manipular os passos do processo
[Reis.98].
Um modelo do processo instanciado ou processo executável é um modelo de
processo pronto para execução. Este modelo pode ser interpretado por uma máquina de
processo, a qual é um componente provido por um ambiente de desenvolvimento de software
(ADS) com capacidade de suportar a modelagem e a execução de processo de software (ADS
Orientado a Processo).
Por sua vez, um projeto, segundo [Pressman.00], é a instância de um processo, com
objetivos e restrições específicos. Pode-se dizer que um projeto é um esforço para
desenvolver um produto de software, ou seja, envolve uma estrutura organizacional, prazos,
orçamentos, recursos e um processo de desenvolvimento. Neste sentido, a gerência de
projetos tem como responsabilidades o planejamento, controle e monitoração de um processo
em execução, enquanto que a gerência de processos preocupa-se em construir, analisar e
verificar modelos de processo, para isso obtendo informações durante a execução desse
processo a fim de evoluir tais modelos para que possam ser usados posteriormente.
2.2 Exemplos de Modelos de Processos de Software
Na literatura especializada podem-se encontrar duas frentes de processo de software.
Uma definida como processos tradicionais, ou também chamada de processos pesados, os
quais se caracterizam por possuir como foco principal a previsibilidade dos requisitos do
sistema, e o comando e o controle desses mesmos requisitos a partir de um prévio
planejamento antes do início do desenvolvimento, transformando estas ações em um processo
rigoroso [Pressman.00]. Rigoroso, pois a especificação de requisitos torna-se a etapa
fundamental, onde todas as necessidades do cliente são definidas e documentadas, sendo que
para cada um destes requisitos, são gerados outros documentos, tornando o processo de
20
análise e projeto bastante demorado e de difícil manutenção caso alguma especificação seja
alterada. Pode-se, ainda, caracterizar que estes tipos de processo possuem uma abordagem
voltada para o planejamento detalhado e artefatos de uma fase para a seguinte.
Já a outra frente chamada de processos ágeis ou processos leves que possuem seu foco
na eficiência, abordando como premissa o compromisso entre “nenhum processo” e processos
rigorosos [Beck.00]. Esta frente propõe que a análise de requisitos seja muito mutável,
“abraçando” mudanças como principal área de atuação da metodologia. Sendo assim os
planejamentos são constantes, não havendo uma etapa exclusiva para isso. Ficando o foco
principal com a codificação. Para isso os meios para estes fins são: adaptabilidade; cada item
de processo deve agregar valor; orientação a pessoas; comunicação; e aprendizado.
No entanto, podem-se notar como principais problemas destes tipos de processo os
listados a seguir:
• Processo Tradicional: a burocracia, uma vez que agrega mais tarefas para as suas
ações; e a não adaptabilidade, onde a realidade (prazo, escopo, processo, pessoas)
difere do planejado / documentado;
• Processo Ágil: a escalabilidade a equipes grandes / dispersas; e a mudança de
cultura de paradigma.
Como modelos de processos existentes na comunidade, destacamos alguns nos itens
seguintes.
2.2.1 RUP – Rational Unified Process
O RUP [Krutchen.03] é um processo de Engenharia de Software bem definido e bem
estruturado que fornece um framework de processo configurável. Como objetivos pode-se
mencionar: o aumento da produtividade da equipe, fornecendo acesso fácil a uma base de
dados com guidelines, templates e ferramentas; assegurar a produção de um software de alta
qualidade para atender as necessidades do usuário final.
O RUP é caracterizado por possuir seis best practices para controle dos requisitos de
um projeto: desenvolvimento iterativo e incremental, que possibilita o aumento do
entendimento do problema através de sucessivos refinamentos; gerenciamento dos
requisitos, descrevendo como elicitar, organizar e documentar a funcionalidade necessária e
as limitações; uso de arquitetura baseada em componentes, a qual permite a descrição de
21
como projetar uma arquitetura que seja flexível e suporte mudanças, sendo intuitivamente
entendível e promovendo o reuso; controle de mudanças, descrevendo como controlar,
rastrear e monitorar mudanças para permitir o desenvolvimento iterativo; modelagem visual,
a qual ajuda a comunicar diferentes aspectos do software, mostrar como os elementos se
ajustam, manter a consistência entre o projeto e sua implementação; verificação da
qualidade, ajuda a planejar, projetar, implementar, executar e medir (confiabilidade,
funcionalidade e performance) o aplicativo e o sistema.
O ciclo de vida do RUP é formado por: uma estrutura dinâmica, formada por ciclos,
fases, iterações e marcos; e uma estrutura estática, composta de atividades, disciplinas,
artefatos e papéis; conforme mostra a Figura 2.3.
Figura 2.3 Ciclo de Vida do RUP [Krutchen.03]
2.2.2 OPEN – Object-oriented Process, Environment and Notation
Trata-se de uma abordagem metodológica focada num processo, de domínio público
projetado para desenvolvimento de aplicações de software, particularmente, o
desenvolvimento orientado a objetos e baseado em componentes. Foi criada inicialmente pela
junção dos métodos: MOSES, SOMA, Firesmith, Synteshis [Graham.97] e mais recentemente
dotada das idéias de BON, Ooram, UML [Graham.97], entre eoutros.
22
O OPEN [Sellers.97] é definido como um framework de processo, conhecido como
OPF (OPEN Process Framework). Este é um meta-modelo a partir do qual pode ser gerado
um processo organizacional específico (instância). Cada uma dessas instâncias do processo é
criada a partir da escolha de atividades, tarefas e técnicas específicas e configurações. Esta
instanciação é necessária para que os detalhes das tarefas e técnicas atendam o domínio do
problema.
Ele suporta uma abordagem dirigida a casos de uso, responsabilidades e documentos.
Provê, ainda, a base ao ciclo de vida, possuindo uma estrutura voltada para gerência de
projeto e reuso, suportando modelagem do processo de negócios, prezando pela qualidade do
software e o uso de métricas. A Figura 2.4 permite uma visualização dos componentes do
framework do processo do OPEN,
Procedimentos
Unidades
de Trabalho
Estágios
Linguagens
Componentes Essenciais
do Processo
produz
são documentados
usando
cria avalia iterage
mantém
executa
provê organização macro
a
Guias
ajuda a
Para cada elemento (representado por um caixa), o OPEN permite que o usuário selecione quantas e quais instâncias serão usadas. A documentação OPF provê uma lista detalhada de sugestões para seleção dos melhores guias junto a organização. Produtos
de Trabalho
Figura 2.4 Componentes do framework do processo OPEN (adaptado de [Graham.97])
2.2.3 Catalysis
O Catalysis [D’Souza.99] incorpora conceitos importantes para o desenvolvimento de
software baseado em componentes. O método utiliza-se de UML, com algumas alterações,
para especificação dos diferentes artefatos (diagramas) que são elaborados durante o
processo de desenvolvimento.
23
Os princípios fundamentais do Catalysis são: construção de um modelo de domínio do
sistema, baseado em tipos, objetos e ações, que enfatizam a independência entre o domínio,
a possível solução de software e sua implementação; forte ênfase nos conceitos de abstração
e refinamento para representar os relacionamentos essenciais entre os artefatos do sistema
obtidos durante o processo de desenvolvimento (a ênfase no refinamento dos artefatos cria
uma série de fatorações, extensões e transformações que visam o rastreamento dos
requisitos até o código); ênfase na especificação de pré-condições, pós-condições e
invariantes; procedimentos e diagramas que apóiam o particionamento do sistema, e o
projeto e a conexão de componentes; forte articulação do processo de desenvolvimento com
os conceitos de arquitetura de software, padrões e frameworks; uso de ciclo de vida rápido,
iterativo e incremental.
Com relação à seqüência de estágios que constituem o processo de desenvolvimento
baseado em Catalysis, é importante ressaltar que Catalysis não define um processo único de
desenvolvimento, mas contém um conjunto de idéias, conceitos e procedimentos que
possibilitam aos projetistas escolher o melhor processo para o seu projeto. Catalysis permite
o desenvolvimento de um sistema por meio de várias possíveis rotas. Cada rota envolve a
seqüencia de atividades e artefatos que melhor se adapta às características do projeto. A
Figura 2.5 exibe um exemplo de rotas.
24
Figura 2.5 Exemplo de rotas de aplicação do Catalysis [D’Souza.99]
2.2.4 XP – eXtreme Programming
O XP é uma metodologia de peso leve voltada a pequenas e médias equipes de
desenvolvedores de software, nomeando a codificação como a atividade de papel
fundamental no desenvolvimento. Ela promete reduzir o risco de projeto, aumentando
a produtividade através de todo ciclo de desenvolvimento dos sistemas, importando-se
com a satisfação dos membros do time que está produzindo o software.
Tendo o risco como problema básico, XP [Jefrries.01] tenta encontrar uma nova
maneira de desenvolver software, pois acredita que a maneira antiga fracassa em
entregar software no prazo e com valor agregado. Essas falhas causam grandes
impactos econômicos e humanos.
XP é uma disciplina de desenvolvimento de software baseada nos valores de
simplicidade, comunicação, realimentação e coragem. Sendo uma metodologia ágil,
25
eficiente, de baixo risco e flexível, XP funciona trazendo ao time todo o uso de
práticas simples, com realimentação suficiente para que o time saiba onde está. Esses
conceitos e práticas de senso comum são levados a níveis extremos, como vemos em
alguns dos exemplos contidos na Tabela 2.1.
Nenhum dos conceitos de XP são novos, alguns são tão antigos quanto a programação
em si. No entanto, XP inova pois unifica esses conceitos em uma mesma metodologia,
como visualizadas na Figura 2.6, assegurando que são factíveis e capazes de
aproveitar o máximo potencial de cada componente.
Tabela 2.1 Alguns Princípios e Práticas em XP (adaptado de [Jefrries.01])
Conceitos Abordagem XP Práticas XP
Revisores de Código Revisa-se o código todo o tempo
Pair Programming
Testes Toda a Equipe irá testar o software, inclusive o
cliente
Unit Testing
Functional Testing
Projeto Todos vão tornar essa atividade diária
Refactoring
Arquitetura Todos irão definir e refinar a arquitetura todo o tempo
Metaphor
Interações Curtas Minutos, horas ao invés de semanas, meses ou anos
The Planning Game
26
Figura 2.6 Práticas do XP [Jefrries.01]
2.2.5 Crystal
Crystal [Cockburn.02] faz parte de um conjunto de metodologias criadas por Alistair
Cockburn, cujas premissas são: todo projeto tem necessidades, convenções e uma
metodologia diferente; o funcionamento do projeto é influenciado por fatores humanos, e há
melhora neste quando os indivíduos produzem melhor; melhor comunicação e lançamentos
freqüentes reduzem a necessidade de construir produtos intermediários do processo.
Ela se caracteriza por possuir: desenvolvimento cíclico e incremental; forte
comunicação e interação entre as pessoas; especificação e projeto informal; análise de
requisitos mínimos; versões com incrementos regulares de um mês (no máximo 4 meses);
projetos pequenos; equipes de 3 a 8 desenvolvedores; especialidades pessoais distintas e
complementares. O processo do Crystal pode ser visualizado na Figura 2.7.
As políticas do Crystal resumem-se a liberação de versões regulares; acompanhamento
do projeto através de gráficos; envolvimento direto do usuário; automatização de testes de
27
funcionalidade (regressão); duas verificações do usuário por release (no meio e no fim de
cada interação); reuniões para ajustes do produto e da metodologia no início e meio de cada
iteração.
2.2.6 SCRUM
O SCRUM [Bach.95] tem sua origem a partir da ADM – Advanced Development Methods e
da VMARK Software, caracterizada como sendo um processo ágil, empírico e incremental
com base em técnicas e ferramentas Orientadas a Objetos. O foco da metodologia está no
gerenciamento, manutenção e desenvolvimento de softwares.
O objetivo do SCRUM é garantir maior flexibilidade e habilidade para tratamento de sistemas
tanto complexos como simples, e produzir um sistema aderente a requisitos iniciais e
adicionais durante o projeto (requisitos dos clientes, necessidades do negócio, pressão relativa
ao tempo, competitividade do mercado, qualidade, recursos). Caracteriza-se por possuir uma
entrega e um cronograma flexíveis, equipes de desenvolvimento pequenas (por volta de 6
pessoas), revisões freqüentes, colaboração e orientação a objetos.
A Figura 2.8 permite um entendimento das fases que compõem o SCRUM: Planejamento,
processo definido, relativamente curto, projeto da arquitetura do sistema, estimativas de datas
e custos, criação de lista de tarefas (pendências), definição de equipes e seus líderes, e
definição de pacotes a serem desenvolvidos; Sprint (Ciclos), processo empírico, cada equipe
Fluxos de Trabalho
Papéis Materiais
Locais
Planejamento de Próxima Release
Figura 2.7 Processo do Crystal (adaptado de [Cockburn.02])
28
recebe uma parte da lista de pendência para desenvolvimento (não sofrendo modificações
durante o sprint), realizada durante 1 a 4 semanas, sempre apresentam um executável final,
reuniões diárias e revisão do produto; Encerramento, iniciada quando todos os aspectos são
satisfatórios (tempo, competitividade, requisitos, qualidade e custo) e é composta pelas
atividades de Testes de Integração, Testes de Sistema, Documentação do Usuário, Preparação
do Material de Treinamento e Preparação de Material de Marketing.
2.2.7 Agile Modeling
Define um conjunto de valores, princípios e práticas a serem acopladas a uma
metodologia de desenvolvimento, não define um processo completo [Ambler.02], conforme
visto na Figura 2.9.
A metodologia AM é uma coleção de práticas, guiadas por princípios e valores que
podem ser aplicados por profissionais de software no dia a dia. Não é um processo
prescritivo, ela não define procedimentos detalhados de como criar um dado tipo de modelo,
ao invés, ela provê conselhos de como ser efetivo na atividade de modelagem.
24 horas
30 dias
Reuniões Diárias
do SCRUM
Tarefas da Lista de Pendência expandidas por Equipe
Lista de Pendências do Sprint (Ciclo)
Lista de Pendência dos Produtos priorizada
pelo Proprietário do Produto
Demonstração de Nova Funcionalidade
Figura 2.8 Fases do SCRUM [Bach.95]
29
Sua filosofia trata em agilizar a criação e manutenção de modelos através de práticas
ágeis e eficazes. Estes modelos incluem requisitos, análise, projeto e projeto de banco de
dados. Foca no uso de ferramentas simples, como: Quadro Branco, Post-it, e Cartões CRC –
Classe, Responsabilidade e Colaboração (técnica usada para permitir que as pessoas rompam
com o modo procedural de pensar e apreciem de modo mais completo a tecnologia de objetos,
representando os objetos que compõem o projeto de um sistema).
Possui com valores: comunicação, simplicidade, feedback, coragem e humildade,
agregando alguns princípios básicos como o fato de considerar que o software é o principal
objetivo; a documentação deve ser boa o bastante para alcançar os objetivos; mudanças fazem
parte do desenvolvimento; a melhor solução é a mais simples; facilidade de manutenção,
documentação e motivação dos desenvolvedores são importantes para o próximo release;
qualidade para atender clientes e desenvolvedores; artefatos devem ser validados o mais breve
possível por outros desenvolvedores envolvidos; conteúdo é mais importante que a
representação.
Figura 2.9 Escopo do Agile Modeling (adaptado de [Ambler.02])
2.3 Meta-Processo de Software
Um processo de software e seu modelo têm uma natureza evolucionária, devido à
necessidade de melhoria e correção contínua e devido à instabilidade do ambiente
operacional. Ou seja, o modelo é primeiro estabelecido para representar o mundo real inicial,
e, durante seu tempo de vida, é exposto a mudanças causadas por eventos planejados e não-
planejados de fora e de dentro da organização [Reis.98]. Existe um ciclo de vida para
processo de software análogo ao ciclo de vida de produtos de software. As atividades do ciclo
de vida de processo de software são chamadas de meta-atividades, e o processo de
desenvolvimento e evolução de processo de software é denominado de meta-processo.
30
As fases do meta-processo são representadas em alto nível de abstração, de forma que
cada fase pode ser decomposta em sub-fases de pouca granularidade. A seguir são descritas as
meta-atividades básicas [Humphrey.89]. A interação destas pode ser vista na Figura 2.10:
• Provisão de Tecnologia: a tecnologia de suporte a produção de software e de
modelos de processo deve ser provida, incluindo as linguagens de modelagem de
processo, modelos de processo prontos para reutilização e ferramentas para
aquisição, modelagem, análise, projeto, simulação, evolução, execução e
monitoração de modelos de processo;
• Análise de Requisitos do Processo: nesta fase são identificados requisitos a
atividades de projeto de um novo processo, ou novos requisitos para um processo
existente. Os requisitos resultantes especificam os recursos e propriedades que o
processo deve oferecer. Os métodos utilizados nesta fase podem ser os métodos
convencionais de análise de sistemas de informação (por exemplo, SADT ou
modelos orientados a objetos), ou até mesmo técnicas de aquisição de
conhecimentos e métodos formais;
• Projeto do Processo: provê a arquitetura geral e detalhada do processo. Nesta etapa
as linguagens de modelagem do processo são utilizadas, havendo necessidade que
satisfaçam os requisitos;
• Implementação ou Instanciação do Processo: implementa a especificação do
processo produzida pela atividade anterior. Nesta fase é gerado um modelo de
processo instanciado, contendo informações detalhadas sobre prazos, agentes e
recursos utilizados por cada atividade definida no processo;
• Simulação do Processo: a simulação ocupa um papel chave na verificação e
validação dos processos definidos. A simulação é uma tarefa que geralmente é
acompanhada tanto pelo projetista de processo quanto pelo gerente do
desenvolvimento com o objetivo de antever o comportamento do projeto (execução
do processo);
• Execução do Modelo de Processo: nesta etapa o modelo de processo instanciado é
executado através da invocação de ferramentas para guiar e assistir a realização do
31
processo no mundo real. Informações sobre o andamento do processo (feedback) são
coletadas e analisadas durante a execução;
• Avaliação do Processo: provê informação quantitativa e qualitativa descrevendo o
desempenho de todo o processo em execução. Esta fase ocorre simultaneamente à
execução do modelo de processo e as informações adquiridas são utilizadas na
atividade de análise de requisitos. Nesta fase são usados métodos de avaliação de
processos como o SCAMPI do SEI [Paulk.93], assim como métricas de monitoração
do processo e do produto.
No meta-processo é necessária a participação dos agentes humanos que operam na fase
de execução do processo [Reis.99a]. Entretanto, para que o processo seja modelado entra em
cena um projetista de processo, que é o responsável por descrever o processo a ser executado
e um gerente do processo que deverá acompanhar a execução e a avaliação do processo,
analisando seu desempenho.
Figura 2.10 Visão Geral do Meta-Processo de Software [Reis.99b]
32
3 MELHORIA DE PROCESSOS DE SOFTWARE
Os processos de software podem apresentar grande complexidade e possibilitar diversas
alternativas de execução de suas atividades. Desta forma, um processo de software definido
permite que profissionais de engenharia de software possam trabalhar de forma ordenada,
possibilitando um melhor entendimento do seu trabalho, bem como de outras atividades
executadas por outros membros da mesma equipe [Humphrey.89].
No entanto, não existe um processo de software que possa ser genericamente aplicado a
diversos projetos, visto que nenhum projeto é idêntico ao outro. Variações nas políticas e
procedimentos organizacionais, métodos e estratégias de aquisição, tamanho e complexidade
do projeto, requisitos e métodos de desenvolvimento do sistema, entre outros fatores,
influenciam na forma como um produto de software é adquirido, desenvolvido, operado e
mantido [ISO.97] [ISO.01] [ISO.04a]. Assim, na definição de um processo deve-se considerar
a sua adequação às tecnologias envolvidas, ao tipo de software em questão, ao domínio de
aplicação, ao grau de maturidade (ou capacitação) da equipe em engenharia de software, às
características próprias da organização, às características do projeto e da equipe
([Humphrey.89], [Rocha.01]).
3.1 Processo Padrão
Em uma organização ou grupo de desenvolvimento multi-organizacional, diversos
projetos podem coexistir possuindo características específicas. Porém, existe um conjunto de
elementos fundamentais os quais se deseja que sejam incorporados em qualquer processo
definido. A [ISO.98] define o conjunto destes elementos fundamentais como o processo
padrão, ou seja, o processo básico que conduz o estabelecimento de um processo comum
dentro da organização. Desta forma, um processo padrão define uma estrutura única a ser
seguida por todas as equipes envolvidas em um projeto de software [Maidantchik.99],
independente das características do software a ser desenvolvido. [Humphrey.89] define um
conjunto de razões para a definição de um processo padrão:
• Redução dos problemas relacionados a treinamento, revisões e suporte a
ferramentas;
• As experiências adquiridas nos projetos são incorporadas ao processo padrão e
contribuem para melhorias em todos os processos definidos;
33
• A utilização de padrões de processo, fornecendo as bases para medições de
processos e qualidade;
• Economia de tempo e esforço em definir novos processos adequados a projetos.
Na literatura atual, observa-se uma tendência à utilização de processos padrões na
definição de processos. A norma ISO/IEC 12207 [ISO.97] [ISO.01] [ISO.04a]., o SPICE
[ISO.98], o CMM [Paulk.93] e o CMMI [Chrissis.03], definem um processo padrão como um
ponto base a partir do qual um processo especializado poderá ser obtido de acordo com as
características de um projeto de software específico. Referida norma, em seus anexos A e B,
descreve procedimentos a serem utilizados na especialização do seu modelo de processo.
[Jacobson.98] define um template para processo que pode ser especializado em instâncias de
processos para atender às necessidades das organizações e de projetos específicos. Desta
forma, ser adaptável e configurável torna-se um importante requisito a ser atingido na
definição de um processo padrão.
3.2 Normas e Modelos de Qualidade para Processos de Software
A fim de definir, avaliar e melhorar a qualidade dos processos de software, diversos
padrões e modelos têm sido desenvolvidos. Em virtude da criação de padrões internacionais e
a maior preocupação com a qualidade de software, organizações passaram a adotar referidos
padrões e modelos na definição de processos de software, procurando melhorar a qualidade de
seus produtos, aumentarem a produtividade de suas equipes e reduzir os custos e riscos
associados ao desenvolvimento de software.
A utilização de padrões internacionais torna-se interessante tendo em vista o atual
contexto de globalização da economia mundial, aliada aos elevados custos ligados a criação
de padrões particulares a cada organização [ISO.98]. A adoção de padrões internacionais em
uma economia globalizada simplifica a relação entre clientes e fornecedores. Nesta seção
serão abordados as Normas ISO/IEC 12207 e ISO/IEC 15504, os modelos de maturidade
CMM e CMMI, já o modelo de referência MPS.BR será abordado em um capitulo em
separado por tratar-se do alvo neste texto.
3.2.1 A Norma ISO/IEC 12207 – Tecnologia de Informação – Processos de Ciclo de Vida de Software
A Norma ISO/IEC 12207 [ISO.97] [ISO.01] [ISO.04a]., objetiva estabelecer uma
estrutura comum para os processos de ciclo de vida de software, com terminologia bem
34
definida, para ser utilizada por desenvolvedores para construir, gerenciar e melhorar software.
A estrutura contém processos, atividades e tarefas a serem aplicados durante a aquisição,
fornecimento, desenvolvimento, manutenção e operação de produtos de software, e que
devem ser adaptados ao contexto e características de cada projeto de software. Tal adaptação
consiste na exclusão de processos, atividades e tarefas não aplicáveis. Com o objetivo de
evitar conflitos com procedimentos já adotados pela organização, o processo de adaptação
deverá estabelecer uma compatibilidade com políticas e normas já existentes na organização
[ISO.97]; [ISO.01], [ISO.04a],. [Zahran.98]; [Rocha.01].
A Norma ISO/IEC 12207 apresenta as seguintes limitações ([ISO.97] [ISO.01]
[ISO.04a]):
• Embora descreva a arquitetura dos processos de ciclo de vida de software, a Norma
não especifica detalhes de como implementar ou executar as atividades e tarefas
incluídas nos processos;
• O usuário da Norma é responsável por definir o formato e o conteúdo da
documentação a ser produzida;
• A Norma não define um modelo de ciclo de vida a ser utilizado, nem um método de
desenvolvimento de software a ser aplicado. Tal escolha será baseada nas
características do projeto e da equipe envolvida. Após a seleção de um modelo de
ciclo de vida, a Norma recomenda que seja realizado um mapeamento dos processos,
atividades e tarefas para o modelo.
A Norma ISO/IEC 12207 agrupa os processos de ciclo de vida em 03 (três) grandes
classes (Figura 3.1), sendo cada processo de ciclo de vida dividido em um conjunto de
atividades, e cada atividade em um conjunto de tarefas.
Os Processos Fundamentais executam as principais funções durante o ciclo de vida do
software. Compõem-se de 05 (cinco) processos: aquisição, fornecimento, desenvolvimento,
operação e manutenção.
Os Processos de Apoio auxiliam outros processos na execução de funções
especializadas, contribuindo para o sucesso e qualidade do projeto de software. Compõem-se
35
de 08 (oito) processos: documentação, gerência de configuração, garantia de qualidade,
verificação, validação, revisão conjunta, auditoria e resolução de problemas.
Os Processos Organizacionais constituem um conjunto de 04 (quatro) processos
responsáveis pelo gerenciamento e suporte de todo o ambiente de desenvolvimento, sendo
empregados, normalmente, fora de domínios ou contratos específicos. Compõem-se de quatro
processos: gerência, infra-estrutura, melhoria e treinamento.
Figura 3.1 Estrutura da Norma ISO/IEC 12207 [ISO.97] [ISO.01] [ISO.04a].
3.2.2 A Norma ISO/IEC 15504 (SPICE)
O projeto SPICE (Software Process Improvement and Capability Determination) tem as
suas origens bem próximas do SPA (Software Process Assessment). Ambos surgiram do fato
das organizações, a nível mundial, estarem fortemente dependentes do uso da tecnologia da
informação para automatizar suas operações e seus processos de negócio, e no crescimento da
frustração, por parte dos usuários, quando o produto de software é entregue. As falhas em
36
produtos de software vêm sendo uma das principais fontes de gastos nas organizações
[ISO.98].
Outro aspecto motivador foi o surgimento, nos anos 80, de iniciativas por parte dos
governos dos Estados Unidos e da Inglaterra, com o objetivo de melhorar o processo de
seleção dos seus fornecedores de software. Tal movimento tinha o objetivo de conter o
crescimento dos custos associados ao software, bem como, reduzir os riscos associados aos
projetos de software e melhorar a qualidade dos produtos finais. Desde o início dos anos 90,
um grande número de métodos para melhoria de processos e determinação da capacitação
começou a ser desenvolvido em vários países. Dentre eles destacam-se iniciativas como:
CMM, TRILLIUM e BOOTSTRAP [Zahran.98]. Todos estes métodos procuravam identificar
e avaliar áreas-chave de processo de software, de modo a analisar fraquezas e riscos. Assim, a
necessidade de um consenso internacional para avaliação de processos de software se fazia
sentir, não só pela facilidade de se trabalhar com um método amplamente aceito, como
também, pela possibilidade de se comparar resultados.
A ISO/IEC TR 15504 [ISO.98] fornece uma arquitetura para avaliação de processos de
software, devendo ser utilizada por organizações envolvidas em planejar, gerenciar,
monitorar, controlar e melhorar a aquisição, o fornecimento, o desenvolvimento, a operação, a
evolução e o suporte de software.
A Norma provê uma abordagem para avaliação de processos de software com os
seguintes propósitos:
• Permitir o entendimento, por uma organização, do estado dos seus processos,
visando estabelecer melhorias;
• Determinar a adequação dos processos de uma organização para atender a um
requisito particular ou classe de requisitos;
• Determinar a adequação de processos da organização a um contrato ou classe de
contratos.
37
3.2.2.1 O Modelo de Referência
O modelo de referência, descrito na parte 2 da ISO/IEC TR 15504, define, em alto
nível, os objetivos fundamentais a serem alcançados e que são essenciais para uma boa
engenharia de software. A arquitetura do modelo apresenta 02 (duas) dimensões:
• Dimensão de processo: caracterizada pelos propósitos do processo, que são os
objetivos essenciais de um processo. Os processos de software previstos na ISO/IEC
TR 15504 são classificados em 05 (cinco) categorias de acordo com o tipo de
atividade executada: Categoria Cliente-Fornecedor (CUS), consiste de processos
que impactam diretamente o cliente, no apoio ao desenvolvimento e transição do
software para o cliente, e proporcionam a correta operação e uso do produto de
software ou serviço; Categoria de Engenharia (ENG), consiste de processos que
diretamente especificam, implementam ou mantêm o produto de software, sua
integração com o restante do sistema e documentação associada; Categoria de Apoio
(SUP), consiste de processos que podem ser utilizados por quaisquer outros
processos (incluindo os próprios processos de apoio) em vários pontos do ciclo de
vida do software; Categoria de Gerência (MAN), consiste de processos que contêm
práticas de natureza genérica que podem ser utilizadas por quem gerencia qualquer
tipo de projeto ou processo que contenha um ciclo de vida de software; e Categoria
Organização (ORG), consiste de processos que estabelecem os objetivos da
organização e desenvolvem processos, produtos e recursos que auxiliam no alcance
destes objetivos. As categorias e os processos são fortemente relacionados àqueles
definidos pela Norma ISO/IEC 12207, sendo incluídos alguns novos processos não
previstos na referida Norma.
• Dimensão de capacitação do processo: caracterizada por uma série de atributos de
processo, aplicáveis a qualquer processo, que representam características
mensuráveis necessárias para gerenciar um processo e melhorar sua capacitação. A
dimensão de capacitação define uma escala de 06 (seis) níveis para medição da
capacitação de qualquer processo definido no modelo de referência. Cada nível
representa um avanço na execução do processo, estabelecendo um caminho natural
para a melhoria da capacitação. A determinação da capacitação é realizada por um
conjunto de atributos de processos (uma característica mensurável da capacitação de
um processo aplicável a todos os processos. Para cada atributo são associados uma
38
descrição e um conjunto de características específicas) que medem se foi atingido
um determinado aspecto da capacitação. Os níveis de capacitação previstos na
ISO/IEC TR 15504 são: Nível 0: Incompleto, o processo não está implementado, ou
falha em atingir seus resultados; Nível 1: Executado, o processo é implementado e
alcança seus resultados; Nível 2: Gerenciado, o processo descrito como “executado
no nível 1”, passa a ser gerenciado, planejado, acompanhado, verificado e ajustado;
Nível 3: Estabelecido, o processo descrito como “gerenciado no nível 2” é
executado usando um processo definido, o qual é baseado em princípios de
engenharia de software e é capaz de alcançar os resultados esperados; Nível 4 –
Previsível, o processo descrito como “estabelecido no nível 3” é executado
consistentemente dentro de limites definidos para alcançar os resultados esperados;
Nível 5 – Otimizado, o processo descrito como “previsível no nível 4” é modificado
e adaptado para atender efetivamente aos objetivos do negócio.
3.2.2.2 O Modelo de Avaliação
O modelo de referência descrito anteriormente não fornece um detalhamento suficiente
para conduzir avaliações da capacitação do processo. Desta forma, a Norma ISO/IEC TR
15504 sugere um modelo de avaliação compatível com os requisitos definidos no modelo de
referência. Referido modelo apóia uma avaliação através de indicadores da execução e
capacitação dos processos, proporcionando, desta forma, a interpretação dos propósitos e
atributos dos processos definidos no modelo de referência. Na prática, qualquer outro modelo
de avaliação, que atenda aos requisitos do modelo de referência, pode ser utilizado.
A estrutura do modelo de avaliação expande a estrutura do modelo de referência para
incluir indicadores de avaliação da execução e capacitação do processo. Ocorre uma
correspondência entre as categorias de processo, os processos, os objetivos, os níveis de
capacitação e os atributos de processo do modelo de referência e os do modelo de avaliação.
A Figura 3.2 ilustra o relacionamento entre o modelo de referência e o modelo de avaliação.
O modelo de avaliação é baseado no princípio de que a capacitação de um processo
pode ser avaliada atingindo-se os objetivos dos atributos de processo. Um indicador de
avaliação apóia a determinação do grau de extensão em que um atributo de processo é
satisfeito. Cada processo possui um conjunto de práticas base associadas, cuja execução provê
uma indicação da extensão em que os objetivos do processo são atingidos. De forma similar,
cada atributo de processo na dimensão de capacitação possui um conjunto de práticas de
39
gerência, cuja execução provê uma indicação da extensão em que os atributos de processo são
atingidos.
Figura 3.2 Modelo de Avaliação de Processos proposto pela ISO/IEC TR 15504 [ISO.98]
3.2.3 Capability Maturity Model (CMM)
O CMM propõe a avaliação e melhoria da capacitação de uma organização. Para isso,
descreve uma arquitetura de maturidade de processos em 05 (cinco) níveis, onde as
organizações passariam de uma cultura de processos adhoc para uma cultura de processos
disciplinados, onde se praticam melhorias contínuas [Paulk.93]. Foi desenvolvido pelo
Software Engineering Institute (SEI), em resposta a uma necessidade do governo dos Estados
Unidos em avaliar a capacitação de seus fornecedores de software [Zahran.98].
Um nível de maturidade é um platô bem definido em direção a um processo de software
maduro, indicando uma capacitação de processo. Na estrutura do CMM, cada nível de
maturidade, com exceção do nível 1, é composto de várias áreas-chave de processo (KPA,
identifica um conjunto de atividades relacionadas que, quando coletivamente executadas,
alcançam o conjunto de objetivos considerados importantes para melhorar a capacitação dos
processos); cada KPA é organizada em 05 (cinco) seções denominadas “características
comuns” (são atributos que indicam se a implementação e institucionalização de uma KPA é
efetiva, repetível e duradoura). As características comuns contêm práticas-chave
(correspondem à infra-estrutura e atividades que contribuem para a efetiva implementação e
institucionalização de uma KPA) que, quando executadas em conjunto, alcançam os objetivos
das KPAs. A Figura 3.3 ilustra a estrutura do CMM.
40
Figura 3.3 Estrutura do CMM [Paulk.93]
Cada KPA indica o que deve ser realizado para alcançar um nível de maturidade. Uma
organização que se encontre em determinado nível de maturidade deve realizar todas as KPAs
deste nível, como também aquelas dos níveis inferiores. Para uma KPA ser satisfeita, todos os
seus objetivos devem ser alcançados. A seguir, são apresentados os níveis de maturidade do
CMM e as suas correspondentes áreas-chave de processo.
• Nível 1 Inicial: O processo de software é caracterizado como ad hoc e,
eventualmente, caótico. Poucos processos são definidos, e o sucesso depende de
esforços individuais e heroísmo. Não existem KPAs associadas.
• Nível 2 Repetitivo: Os processos básicos de gerenciamento são estabelecidos para
acompanhar custo, cronograma e funcionalidade. Os sucessos em projetos anteriores
com aplicações similares são repetidos. As KPAs do nível 2 objetivam questões
relacionadas ao estabelecimento de controles básicos de gerência do projeto. São
elas: Gerência de Requisitos, Planejamento do Projeto, Acompanhamento do
Projeto, Gerência de Subcontratos, Garantia da Qualidade e Gerência de
Configuração.
• Nível 3 Definido: O processo de software em relação às atividades de
gerenciamento e desenvolvimento é documentado, padronizado e integrado em um
processo de software padrão para a organização. Todos os projetos utilizam uma
versão aprovada e adaptada do processo padrão para desenvolvimento e manutenção
41
de software. As KPAs do nível 3 objetivam tanto questões organizacionais como de
projeto. São elas: Foco no Processo da Organização, Definição do Processo da
Organização, Programa de Treinamento, Gerenciamento Integrado do Software,
Engenharia de Produto de Software, Coordenação entre Grupos e Revisões.
• Nível 4 Gerenciado: São coletadas medições detalhadas do processo de software e
da qualidade do produto. Tanto o processo de software como os produtos são
quantitativamente entendidos e controlados. As seguintes KPAs são previstas:
Gerenciamento Quantitativo do Processo e Gerenciamento da Qualidade do
Software.
• Nível 5 Otimizado: Melhorias contínuas nos processos são estabelecidas pelo
retorno quantitativo dos processos e conduzidas pela introdução de idéias e
tecnologias inovadoras. As seguintes KPAs são previstas: Prevenção de Defeitos,
Gerenciamento de Mudanças Tecnológicas e Gerenciamento de Mudanças no
Processo.
Cada KPA é descrita em termos de práticas-chave, que descrevem as atividades e a
infra-estrutura que contribuem para a efetiva implementação e institucionalização da KPA. As
práticas-chave são organizadas em 05 (cinco) características comuns, listadas a seguir:
Compromisso para Execução, Habilidade para Execução, Atividades Executadas, Medição e
Análise, e Verificação da Implementação.
As práticas da característica comum “Atividades Executadas” descrevem o que deve ser
implementado para atingir os objetivos da KPA. As outras práticas constituem a base através
da qual a organização pode institucionalizar as práticas descritas na referida característica
comum.
3.2.4 Capability Maturity Model Integration (CMMI)
O conceito de processo possui várias definições, a ABNT define processo como um
conjunto de atividades inter-relacionadas que transforma entradas em saídas [ABNT.94], o
IEEE define processo como uma seqüência de passos realizados para um determinado
propósito [IEEE.06], Paulk [Paulk.95] define processo de software como um conjunto de
atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter
o software e os produtos relacionados.
42
O propósito do CMMI (Capability Maturity Model Integration) é fornecer guias para o
melhoramento de processos e para o gerenciamento do desenvolvimento, aquisição, e
manutenção de produtos e serviços [CMMI.02].
A principal proposta concreta atual para avaliar e aperfeiçoar a qualidade na produção
de software é o CMMI, do SEI [Fernandes.04]. O CMMI é um modelo de avaliação baseado
em maturidade, e atualmente aplicável a diversas organizações tecnológicas: quer produzam
software ou sistemas, quer executem projetos inovadores ou operações contínuas. CMMI
aplica-se também a organizações que necessitam de forte integração entre arquitetura de
produto e arquitetura de processo produtivo, como é o caso em TI.
O CMMI possui duas representações: contínua e em estágios. A representação contínua,
similar a ISO/IEC 15504 [ISO.98], oferece uma abordagem mais flexível para melhoria do
processo, são focadas áreas de processo específicas diretamente relacionadas ao objetivo de
negócio da organização. A representação em estágios, similar a SW-CMM [Paulk.93], oferece
um passo a passo detalhado para melhoria do processo, descreve a seqüência de execução das
áreas de processo e estas são agrupadas em níveis de maturidade que quando alcançados
indicam uma melhoria substancial do processo. O foco deste artigo é na representação em
estágios do CMMI.
Os componentes da representação em estágio do modelo CMMI são: Níveis de
Maturidade, Áreas de Processo, Objetivos Específicos e Genéricos, Práticas Específicas e
Genéricas, e Características Comuns.
Um nível de maturidade é um estágio evolutivo de melhoramento de processo. Na
representação por estágio, existem cinco níveis de maturidade: nível 1 (inicial) – os processos
são usualmente caóticos e adhoc; nível 2 (gerenciado) – os requisitos são gerenciados e os
processos são planejados, realizados, medidos e controlados; nível 3 (definido) – os processos
são bem caracterizados e entendidos, e são descritos em termos de padrões, procedimentos,
ferramentas e métodos; nível 4 (gerenciado quantitativamente) – objetivos quantitativos para
qualidade e performance do projeto são estabelecidos e usados como critério nos processos de
gerenciamento; nível 5 (otimizando) – os processos são continuamente melhorados.
Cada nível de maturidade é definido por um conjunto de áreas de processo. Uma área de
processo é um conjunto de práticas relatadas que, quando cumpridas coletivamente,
43
satisfazem um conjunto de objetivos considerados importantes para se ter uma melhoria
significativa naquela área.
A Figura 3.4 apresenta as 25 áreas de processo do modelo CMMI-SE-SW-IPPD-SS v
1.1, categorizadas quanto à área de atuação e quanto ao nível indicado de maturidade na qual
devem ser implementadas. Este modelo aplica-se a organizações que desenvolvem software e
sistemas computacionais, que necessitam de integração entre produto e processo, e que ainda
possuem necessidade de sub-contratação de projetos.
Figura 3.4 Categorização das Áreas de Processo do CMMI de acordo com a área de atuação e o nível de maturidade [Fernandes.04]
Os objetivos específicos aplicam-se a uma área de processo e descrevem o que deve ser
implementado para satisfazer a área de processo. Os objetivos específicos são componentes
obrigatórios e são usados em auditorias para determinar se uma área de processo está
cumprida. As práticas específicas são componentes desejáveis e descrevem as atividades para
cumprimento dos objetivos específicos de uma área de processo.
Os objetivos genéricos são assim denominados, pois podem aparecer em múltiplas áreas
de processo. O cumprimento de um objetivo genérico para uma área de processo significa
maior controle no planejamento e implantação de processos associados a esta área. Os
objetivos genéricos são componentes obrigatórios e são usados em auditorias para determinar
se uma área de processo está cumprida.
44
As quatro características comuns organizam as práticas genéricas de cada área de
processo, são elas: CO (compromisso a executar) – inclui práticas que garantem que o
processo está estabelecido e perdurará, envolve estabelecimento de políticas e liderança
organizacional; AB (habilidades a executar) – inclui práticas que estabelecem as condições
necessárias para que o processo possa ser implementado completamente, envolve planos,
recursos, estruturas organizacionais e treinamento; DI (direcionando a execução) – inclui
práticas que monitoram e controlam a execução do processo, envolve colocar produtos de
trabalho sob gerência de configuração, monitorar e controlar o desempenho do processo em
relação ao plano e realizar ações corretivas; VE (verificando a execução) – inclui práticas que
garantam conformidade com os requisitos da área de processo, envolve revisões e auditorias.
As práticas genéricas fornecem institucionalização para assegurar que os processos
associados a uma área de processo sejam eficazes, repetíveis e duradouros. As práticas
genéricas são categorizadas pelos objetivos genéricos e pelas características comuns.
3.2.5 Norma ISO 9000-3 (Qualidade dos Processos)
A norma NBR ISO 9000 trata as normas de gestão e garantia da qualidade. A parte 3
desta norma traz as diretrizes para a aplicação da NBR 9001 ao desenvolvimento,
favorecimento e manutenção de software. Esta norma técnica é estabelecida pela ABNT –
Associação Brasileira de Normas Técnicas. Na Tabela 3.1 podem ser visualizados os
processos definidos na ISO 9000-3.
Tabela 3.1 Processos Definidos na ISO 9000-3 [ISO.91]
Grupo Atividade Estrutura do Sistema de Qualidade Responsabilidade do fornecedor
Responsabilidade do comprador Análise crítica conjunta
Atividades do Ciclo de Vida
Análise crítica do contrato Especificação dos requisitos do comprador Planejamento do desenvolvimento Projeto e implementação Testes e validação Aceitação Cópia, entrega e instalação Manutenção
Atividades de Apoio
Gerenciamento de configuração Controle de documentos Registros da qualidade Medição Regras, convenções Aquisição Produto de software incluído Treinamento
45
A ISO 9000-3 é uma das normas mais conhecidas para a gestão e a garantia de
qualidade de software. Seu objetivo é “fornecer orientação para a garantia da qualidade de
software” [ISO.91]. A estrutura do sistema de qualidade é abordada, bem como
documentação, auditoria, atividades de ciclo de vida e itens de contrato.
A revisão da norma ISO 9000 feita em 2000 trouxe a abordagem de modelo por
processos, e centrou-se na gestão de melhoria destes processos onde é reconhecido o ciclo de
melhoria contínua que monitora e potencializa as evoluções. Esta revisão se estende para a
norma ISO 9000-3.
Nesta norma, software é definido como sendo uma “criação intelectual compreendendo
os programas, procedimentos, regras e qualquer documentação correlata à operação de um
sistema de processamento de dados” [ISO.91]. “Criação Intelectual”, nesta normal, é um
termo vago e sem definição, mas que pressupõe a dependência do elemento humano.
[Pressman.00] reafirma o conceito de que o processo de software é dependente
justamente desta criação intelectual, pois “o software, como todo capital, é incorporado ao
conhecimento, e porque este conhecimento é inicialmente disperso, implícito, oculto, e
incompleto em larga escala, o desenvolvimento de software é um processo de aprendizado
social” [Pressman.00]. Mesmo o trabalho técnico pode ser criativo, baseado no conhecimento,
na análise de situações e alternativas e, conseqüentemente, na composição de soluções.
A norma ISO 9000-3 toma, como base, diretrizes contratuais da produção de software.
Fornecedor e cliente, contrato, administração e auditoria são algumas palavras importantes e
que mostram sua particular preocupação na abrangência do processo.
Como prerrogativa de qualidade, além da documentação que é comum a todos os
modelos aqui analisados, tem-se o desenvolvimento contínuo da qualidade ao longo de todo o
desenvolvimento do processo, ao invés de tentar medi-la no produto final.
O processo de certificação de uma empresa de software segundo as normas ISO 9001 /
9000-3 segue um conjunto de passos bem definidos [Paulino.99]:
• A empresa estabelece o seu sistema de qualidade;
46
• A empresa faz uma solicitação formal a um órgão certificador, incluindo detalhes do
negócio da empresa, escopo da certificação solicitada e cópia do manual de
qualidade;
• Órgão certificador faz uma visita à empresa, colhe mais dados e explica o processo
de certificação;
• Órgão certificador verifica se a documentação do sistema de qualidade está de
acordo com a norma ISO;
• Órgão certificador envia uma equipe à empresa com fins de auditoria. Nesta visita,
será verificado se todos na empresa cumprem o que está documentado no manual de
qualidade;
• Órgão certificador emite o certificado de qualidade;
• Órgão certificador realiza visitas periódicas à empresa para assegurar que o sistema
continua sendo efetivo.
A norma não referencia o seu humano para conquista da qualidade. A única situação em
que se atrela qualidade de software a pessoas é no que diz respeito ao treinamento, pois o
treinamento deve ser dado “todo pessoal que executa atividades que influenciam a qualidade”
[ISO.91]. A norma explicita que determinadas tarefas devem ser realizadas por um pessoal
qualificado com base na educação adequada, treinamento e experiência, sem que para isso
existam maiores definições ou especificações.
Outro aspecto relacionado a seres humanos da ISO 9000-3 é o foco no usuário do
produto de software. Um sistema gerado para um tipo específico de usuário torna-se melhor
se suas necessidades e características típicas para seu tipo de perfil forem analisadas e levadas
em consideração.
A menos destes aspectos, não há menção da possível influência do ser humano na
qualidade, e muito menos do grau desta influência.
47
3.3 O Modelo de Referência MPS.BR (Melhoria de Processo de Software
Brasileiro)
Em 2003, a Qualidade tornou-se uma das prioridades da Sociedade SOFTEX
(Sociedade para Promoção da Excelência do Software Brasileiro), elencada como um dos seus
Projetos Estruturantes. Desde dezembro de 2003, sete renomadas instituições brasileiras, com
competências complementares na melhoria de processos de software em empresas, participam
do projeto Melhoria do Processo de Software Brasileiro (MPS BR): a Sociedade SOFTEX,
coordenadora do projeto; três instituições de ensino, pesquisa e centros tecnológicos
(COPPE/UFRJ, CESAR, CenPRA); uma sociedade de economia mista, a Companhia de
Informática do Paraná (CELEPAR), hospedeira do Subcomitê de Software da Associação
Brasileira de Normas Técnicas (ABNT); e duas organizações não-governamentais integrantes
do Programa SOFTEX (Sociedade Núcleo de Apoio à Produção e Exportação de Software do
Rio de Janeiro – RIOSOFT e Sociedade Núcleo SOFTEX 2000 de Campinas). Desde o início
do projeto, a COPPE/UFRJ convidou a Universidade Católica de Brasília (UCB) para ser sua
parceira no projeto, que assim se uniu ao grupo.
O Projeto MPS BR visa a melhoria de processos de software em empresas brasileiras, a
um custo acessível, especialmente na grande massa de micro, pequenas e médias empresas
[Weber.04]. Tem como objetivo principal definir e implementar o Modelo de Referência para
melhoria de processo de software (MR mps) em empresas. O projeto tem como objetivos
secundários disseminar, em diversos locais no país: a capacitação no uso do modelo (cursos
de Introdução ao MR mps e cursos e provas para Consultores de Implementação e
Avaliadores do modelo); o credenciamento de instituições implementadoras e/ou avaliadoras
do modelo, especialmente instituições de ensino e centros tecnológicos; a implementação e
avaliação do modelo com foco em grupos de empresas.
O projeto compreende seis etapas. A 1ª etapa teve como objetivo organizar o projeto,
estabelecer seus objetivos e definir a primeira versão do Modelo de Referência (MR mps). A
2ª etapa teve como objetivos o aprimoramento do Modelo de Referência, o início das
atividades de treinamento no modelo e a realização de experiências iniciais de uso do MR
mps em empresas. Em quatro etapas semestrais, estão sendo realizadas implementações em
outras empresas, em diversos locais (especialmente onde houver Agente SOFTEX interessado
e instituições credenciadas para implementação e/ou avaliação do modelo).
48
Normalmente, a implementação e avaliação de modelos como o CMMI, mesmo nos
seus níveis mais baixos (2 e 3), está fora do alcance da micro, pequena e média empresa,
especialmente no Brasil, devido ao seu custo elevado [Weber.04]. Para resolver este
problema, o Projeto MPS BR criou dois modelos: (i) o Modelo de Referência para melhoria
de processo de software (MR mps), que será descrito na seção 3.3.1, e, (ii) o Modelo de
Negócio para melhoria de processo de software (MN mps), descrito nesta seção.
No Brasil, algumas instituições e um bom número de Agentes SOFTEX têm experiência
na formação e gestão de grupos de empresas para melhoria de processo de software, seja de
grupos de empresas voltados à implementação e certificação ISO 9000 [ISO.91] seja de
grupos de empresas voltados à implementação e avaliação CMM e CMMI. A partir destas
experiências concebeu-se para o projeto MPS BR um modelo de negócios que prevê duas
situações:
• A implementação do MR mps de forma personalizada para uma empresa (MNE –
Modelo de Negócio Específico);
• A implementação do MR mps de forma cooperada em grupos de empresas (MNC –
Modelo de Negócio Cooperado), com custo mais acessível às micro, pequenas e
médias empresas por dividir proporcionalmente parte dos custos entre as empresas e
por se buscar outras fontes de financiamento.
Para a implementação do MR mps e a realização de avaliações segundo o modelo,
existem instituições credenciadas. O credenciamento é feito pelo Fórum de Credenciamento e
Controle (FCC) do projeto. No momento do credenciamento, a Sociedade SOFTEX sempre
assina um convênio com as instituições credenciadas.
A Figura 3.5 ilustra o Modelo de Negócio definido para o Projeto MPS BR. No Modelo
de Negócio Específico para uma empresa (MNE), cada empresa interessada negocia e assina
um contrato específico com uma das Instituições Credenciadas para Implementação (ICI) do
MR mps. Para avaliação, negocia e assina outro contrato específico com uma das Instituições
Credenciadas para Avaliação (ICA). A entidade coordenadora do Projeto MPS BR (Sociedade
SOFTEX) toma conhecimento, através da ICI ou ICA, do contrato e dos resultados da
implementação e/ou avaliação na empresa.
49
Figura 3.5 Modelo de Negócio para melhoria de processo de software (MN mps) [Weber.04]
No Modelo de Negócio Cooperado (MNC), o primeiro passo, é a constituição de um
grupo de empresas interessadas na implementação do MR mps (o que pode acontecer, por
exemplo, por iniciativa de um Agente SOFTEX). A partir de sua constituição, a coordenação
do grupo de empresas irá negociar e assinar um contrato com uma das Instituições
Credenciadas para Implementação (ICI) do MR mps. Posteriormente, irá negociar e assinar
outro contrato para avaliação das empresas com uma das Instituições Credenciadas para
Avaliação (ICA). Neste caso, a Sociedade SOFTEX toma conhecimento da implementação
e/ou avaliação no grupo de empresas, através da ICI ou ICA, e assina um convênio com a
entidade organizadora do grupo de empresas (por exemplo, um Agente SOFTEX), sempre
que pertinente. Assim, a Sociedade SOFTEX e seus Agentes Regionais estarão acelerando a
velocidade de implementação da melhoria de processos de software no Brasil, especialmente
na micro, pequena e média empresa.
3.3.1 Modelo de Referência para Melhoria de Processo de Software
Fundamentalmente, o Projeto mps Br visa a criação e disseminação do Modelo de
Referência para melhoria de processo de software (MR mps). Não é objetivo do projeto
definir algo novo no que se refere a Normas e Modelos de Maturidade. A novidade do projeto
está na estratégia adotada para sua implementação, criada para a realidade brasileira
[Softex.07a]. Além disto, o Modelo de Negócio definido para o projeto tem grande potencial
de replicabilidade no Brasil e em outros países de características semelhantes, como por
50
exemplo, os países latinoamericanos. Desta forma modelos, normas e métodos já disponíveis
foram ponto de partida para a definição do Modelo de Referência, como visto na Figura 3.6.
Figura 3.6 Definição do Modelo de Referência do MPS.BR [Softex.07a]
O ponto de partida para definição do MR mps foi, então, a análise da realidade das
empresas brasileiras, a norma ISO/IEC 12207, a série de normas ISO/IEC 15504 (SPICE) e o
modelo CMMI (Capability Maturity Model Integration).
Em 1988, foi proposto o desenvolvimento da Norma ISO/IEC 12207 dentro de um
esforço conjunto da ISO – International Organization for Standardization e do IEC –
International Electrotechnical Commission em estabelecer uma estrutura comum para os
processos de ciclo de vida de software como forma de ajudar as organizações a
compreenderem todos os componentes presentes na aquisição e fornecimento de software e,
assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz. A Norma foi
publicada internacionalmente em 1995 e no Brasil em 1998.
A ISO/IEC 15504 (SPICE) presta-se à realização de avaliações de processos de
software com dois objetivos: a melhoria de processos e a determinação da capacidade de
processos de uma organização. Se o objetivo for a melhoria de processos, a organização pode
realizar a avaliação gerando um perfil dos processos que será usado para a elaboração de um
plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os
riscos inerentes aos processos. No segundo caso, a empresa tem o objetivo de avaliar um
fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite
ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para
auxiliar na tomada de decisão de contratá-lo ou não.
51
O CMMI surgiu para resolver o problema de se usar vários modelos e é o resultado da
evolução do SW-CMM, SECM (System Engineering Capability Model) e IPD-CMM
(Integrated Product Development Capability Maturity Model). É, portanto, o sucessor destes
modelos. Além disso, o CMMI foi desenvolvido para ser consistente e compatível com a
ISO/IEC 15504. Como já visto, existem dois tipos de representação no CMMI: em estágios e
contínua. Tem-se, assim, um único modelo que pode ser visto de duas perspectivas distintas.
A representação em estágios é a representação usada no SW-CMM. Esta representação define
um conjunto de áreas de processo para definir um caminho de melhoria para a organização,
descrito em termos de níveis de maturidade. A representação contínua é o enfoque utilizado
no SECM, no IPD-CMM e também no SPICE. Este enfoque permite que uma organização
selecione uma área de processo específica e melhore com relação a esta área. A representação
contínua usa níveis de capacidade para caracterizar melhoria relacionada a uma área de
processo.
O Modelo de Referência para melhoria de processo de software (MR mps) compreende
níveis de maturidade e um método de avaliação, como visto na Figura 3.7. A norma de
referência para os processos de ciclo de vida de software no MR mps é a ISO/IEC 12207
conforme sua atualização publicada em 2002 [Softex.07a]. Esta norma pode ajudar as
organizações na definição de seus processos, pois ela contém uma clara definição da
arquitetura, terminologia e responsabilidades inerente a processos. Essa atualização inseriu
processos e acrescentou na sua descrição propósito e resultados de implementação o que
possibilita a avaliação da capacidade do processo. A norma, incluindo o seu anexo, é
composta por: Processos fundamentais, que são os de Aquisição, Fornecimento,
Desenvolvimento, Operação e Manutenção; Processos de apoio, que são os de
Documentação, Gerência de Configuração, Garantia da Qualidade, Verificação, Validação,
Revisão Conjunta, Auditoria, Resolução de Problemas e Usabilidade; e os Processos
organizacionais, que são os de Gerência, Infra-estrutura, Melhoria, Recursos Humanos,
Gestão de Ativos, Gestão de Programa de Reuso e Engenharia de Domínio.
Cada organização interessada em implementar o MR mps deve, a partir deste conjunto,
selecionar os processos que lhe são pertinentes conforme o processo de adaptação.
52
Figura 3.7 Modelo de Referência para melhoria do Processo de Software (MR mps) [Softex.07a]
Os níveis de maturidade estabelecem uma forma de prever o desempenho futuro de uma
organização com relação a uma ou mais disciplinas. Um nível de maturidade é um patamar
definido de evolução de processo. Cada nível de maturidade estabelece uma parte importante
do processo da organização.
No MR mps a maturidade de processo está organizada em duas dimensões: a dimensão
capacidade (capability dimension) e a dimensão processo (process dimension). A dimensão
da capacidade é um conjunto de atributos de um processo que estabelece o grau de
refinamento e institucionalização com que o processo é executado na organização. À medida
que evolui nos níveis, um maior ganho de capacidade de desempenhar o processo é atingido
pela organização. Os níveis estabelecem uma maneira racional para aprimorar a capacidade
dos processos definidos no MR mps. Já a dimensão de Processos é baseada na ISO/IEC 12207
e estabelece o que a organização deveria executar para ter qualidade na produção,
fornecimento, aquisição e operação de software.
A interseção dessas duas dimensões define a maturidade do processo que no MR mps
são sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C
(Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G
(Parcialmente Gerenciado). Para cada um destes níveis de maturidade foram atribuídas áreas
53
de processo, com base nos níveis 2, 3, 4 e 5 do CMMI em estágios. Esta divisão tem uma
gradação diferente do CMMI em estágios com o objetivo de possibilitar uma implementação
mais gradual e adequada às micro, pequenas e médias empresas brasileiras. A possibilidade de
se realizar avaliações considerando mais níveis permite uma visibilidade dos resultados de
melhoria de processo, na empresa e no país, com prazos mais curtos. Para cada área de
processo são considerados objetivos e práticas específicos, de acordo com o Nível de
Maturidade em questão [Softex.07a].
3.3.2 Método de Avaliação
A avaliação das organizações segundo o MR mps deverá ser realizada considerando-se
a aderência às áreas de processo estabelecidas para cada nível de maturidade e a adequação
das práticas que implementam as áreas de processo. O método de avaliação foi definido com
base na ISO/IEC 15504.
O nível de implementação das práticas relacionadas a uma área de processo é avaliada a
partir de Indicadores. Estes indicadores, que devem ser definidos pela empresa para cada
prática relacionada a uma área de processo, podem ser de um dos três tipos a seguir: Direto,
Indireto ou Afirmação. Indicadores Diretos são produtos intermediários, resultado de uma
atividade. Indicadores Indiretos são, em geral, documentos que indicam que uma atividade foi
realizada. Afirmações são resultantes de entrevistas com a equipe dos projetos avaliados, onde
os entrevistados relatam como uma prática foi implementada. O nível de implementação de
uma prática é avaliado de acordo com quatro níveis: TI – Totalmente Implementada; LI –
Largamente Implementada; PI – Parcialmente Implementada, e, NI- Não Implementada. A
Tabela 3.1 contém as regras para caracterizar o grau de implementação das práticas,
completamente aderentes à norma ISO/IEC 15504 (SPICE). Os pontos nesta escala devem ser
entendidos como uma porcentagem que representa o grau de alcance. A decisão final sobre o
grau de implantação de um processo é da equipe de avaliação, considerando os resultados da
avaliação nos projetos avaliados.
54
Tabela 3.2 Regras para Caracterizar o grau de implementação das práticas [Softex.07b]
Grau de Implementação da Prática
Caracterização Grau de Alcance
Totalmente Implementado O indicador direto está presente e julgado
adequado;
Existe pelo menos um indicador indireto e/ou
afirmação para confirmar a implementação;
Não foi notada nenhuma fraqueza substancial.
>85% a 100%
Largamente Implementado O indicador direto está presente e julgado
adequado;
Existe pelo menos um indicador indireto e/ou
afirmação para confirmar a implementação;
Foi notada uma ou mais fraquezas.
>50% a 85%
Parcialmente Implementado O indicador direto não está presente ou é julgado
inadequado;
Artefatos ou afirmações sugerem que alguns
aspectos da prática estão implementados;
Fraquezas foram documentadas.
> 15% a 50%
Não Implementado Qualquer situação diferente das acima. 0 a 15%
Uma empresa é considerada de nível A, B, C, D, E, F ou G se todas as suas áreas,
unidades, divisões ou setores tiverem sido avaliados como naquele nível. Uma empresa,
entretanto, pode desejar ter avaliado apenas um ou alguns de seus setores, áreas, unidades ou
divisões (organização a ser avaliada). É possível que, como resultado de uma ou mais
avaliações, partes de uma empresa tenham alcançado um determinado nível e partes da
mesma, outro nível. Em qualquer caso, o documento comprobatório da avaliação deverá
explicitar o que foi objeto de avaliação (escopo da avaliação) e o nível resultante de
maturidade.
Para realização de uma avaliação devem ser submetidos todos os projetos concluídos e
todos os projetos em andamento a partir da implementação MR mps na empresa ou na
organização que será avaliada. Durante o planejamento da avaliação, a instituição avaliadora
deve selecionar um subconjunto suficiente de projetos que garanta a representatividade da
organização a ser avaliada. Este número, entretanto, não deve ser inferior a dois projetos
concluídos e dois projetos em andamento. Algumas empresas podem desenvolver um único
produto. Isto, entretanto, não é impedimento para a avaliação, pois projetos são entendidos em
sentido amplo, incluindo projetos de manutenção no produto. O resultado de uma avaliação
tem validade de dois anos.
55
4 SIGA-MPS.BR – UMA SOLUÇÃO SISTÊMICA DE ATIVOS DE PROCESSO
PARA IMPLEMENTAÇÕES NO MPS.BR
4.1 Motivação
A definição e institucionalização de processos de desenvolvimento de software são
práticas constantes em inúmeras empresas com este fim, porém, pouca atenção é dada à área
da garantia da qualidade de produtos/serviços prestados ou fornecidos por estas. Apesar desta
necessidade, o investimento para promover a realização do programa de qualidade
organizacional não é acessível, pois os modelos de qualidade requerem investimento alto e o
retorno desse investimento se dá em longo prazo [Silva.08].
Assim, o MPS.BR foi criado como um modelo nacional, pensando nas características
do mercado brasileiro de desenvolvimento software. Este modelo já é bem aceito
internacionalmente, sendo aderente ao modelo CMMI, ISO/IEC 12207 e ISO/IEC 15504
assim, ao se implementar os níveis G e F, por exemplo, contempla-se o nível 2 do CMMI,
todavia a partir de um procedimento de implementação mais célere, visto que o MPS.BR está
divido em um maior número de níveis de maturidade, em relação aos outros modelos,
facilitando assim a adequação da empresa e reduzindo os custos daquela implementação e
avaliação [Silva.08].
Em [Silva.08], consta como proposta de um trabalho futuro de pesquisa a criação de
uma solução sistematizada que catalogasse e auxiliasse/apoiasse na seleção dos ferramentais
(ferramentas de software, procedimentos e templates de artefatos) usados para a
implementação dos processos constantes no modelo MPS.BR, com fins na obtenção desses
resultados. O consultor-implementador do MSP.BR, certificado pela SOFTEX, realiza suas
tarefas usando como base experiências próprias sem possuir qualquer ferramenta
sistematizada que o auxilie no armazenamento dos ativos usados no programa de melhoria da
qualidade organizacional, o que pode aperfeiçoar o compartilhamento das práticas usadas nas
organizações que adotam o MPS.BR a partir da disseminação das lições aprendidas por este
público, com o uso de uma ferramenta pra esse fim. Com intuito de atender a essa proposta,
foi desenvolvida a ferramenta SiGA-MPS.Br, foco deste trabalho.
4.2 Projeto da Solução Sistêmica
As seções a seguir permitem um detalhamento do projeto de concepção e
especificação da solução proposta neste trabalho.
56
4.2.1 Definição da Ferramenta
O SiGA-MPS.Br é uma ferramenta de auxílio aos consultores de implementação para
empresas que desejam a avaliação do modelo MPS-BR. O SiGA-MPS.Br cataloga cada um
dos tipos de recursos, por item (ferramentas de software, templates artefatos ou
procedimentos) , classificando-os por resultado esperado em cada um dos processos contidos
neste modelo. Estes processos são classificados por nível, de acordo com as premissas
definidas no modelo de referência para melhoria do processo de software do MPS.BR. Aos
tipos de recursos vinculam-se recursos (ativos).
O SiGA-MPS.Br, além de exibir o nome do recurso que pode ser utilizado na obtenção
de determinado resultado esperado, pode exibir executar o recurso, se desejado pelo usuário.
Esta ferramenta vem a facilitar grandemente o trabalho dos consultores de
implementação, até mesmo de empresas interessadas na avaliação do modelo, pois, com esta
ferramenta, é possível exibir de forma simples exemplos de ferramentas de documentação,
artefatos e/ou procedimentos que podem ser utilizados pela entidade que deseja alcançar um
determinado nível de avaliação do MPS.BR, o que seria dificultoso sem esta ferramenta.
O SiGA-MPS.Br, permite a qualquer momento o acréscimo ou atualização de
informações referentes a processos, resultados esperados, tipos de recursos e recursos. Assim,
o avaliador, por exemplo, ao se deparar com uma nova ferramenta utilizada na obtenção de
determinado resultado esperado no MR-mps.br (Modelo de referência MPS.BR), esse pode
catalogar no Siga-MPS.Br para mostrar essa ferramenta como exemplo a um outro cliente que
porventura não possua ferramenta para alcançar esse resultado esperado.
4.2.2 Fluxo de atividades
Esta seção permitirá um entendimento das atividades (operações/funções) projetadas
para compor a ferramenta SiGA-MPS.Br através da representação diagramática do diagrama
de atividades constante na UML – Unified Modeling Language [Yonezawa.08] . Assim, na
Figura 4.1 tem-se o diagrama de atividades da ferramenta SiGA-MPS.Br, em uma visão mais
geral de todas as atividades que a compõem. A seguir cada uma das atividades é descrita, bem
como um detalhamento maior das atividades é definido a partir de outros diagramas
projetados. Vale ressaltar, ainda, que a seção 4.3 permite uma visualização dos protótipos de
interface gráfica concebidas para o desenvolvimento de cada uma destas atividades.
57
Figura 4.1 Diagrama de Atividades Geral do SiGA-MPS.Br
Como explicado anteriormente, com o Siga-MPS.BR é possível além da consulta a
ativos, o cadastramento destes, assim como a manutenção dos processos, resultados
esperados, vinculados a cada nível do MR-mps.br, tipos de recursos e recursos.
No registro/edição de processos, inicialmente seleciona-se o nível de maturidade ao
qual o processo se refere, em seguida identifica-se se este trata de uma edição de um processo
existente ou inserção de novo processo. Após essa etapa preenchem-se os campos para edição
(objetivo, finalidade) ou para inserção de dados (nome, objetivo, finalidade), em seguida
confirma-se ou cancela-se a edição/inserção, conforme pode ser visualizado na Figura 4.2.
58
Figura 4.2 Diagrama de Atividades da “Cadastra Processos”
No registro/manutenção de resultados esperados, inicialmente seleciona-se o nível
de maturidade e o processo aos quais esse processo se refere, em seguida é identificado se se
trata de uma edição de um processo existente ou inserção de novo processo. Após essa etapa
preenchem-se os campos para edição ou para inserção de dados (nome, definição). Em
seguida confirma-se ou cancela-se a edição/inserção, conforme visualizado na Figura.4.3.
59
Figura 4.3 Diagrama de Atividades da “Cadastra Resultados Esperados”
No registro/manutenção dos tipos de recursos, inicialmente seleciona-se o item
(ferramenta de software, template de artefato ou procedimento) ao qual se refere, em seguida
edita-se ou insere-se um novo tipo, preenchendo-se os campos. Em seguida confirma-se ou
cancela-se a edição/inserção, conforme visualizado na Figura 4.4.
60
Figura 4.4 Diagrama de atividades da “Cadastra os Tipos de Recursos”
Após o registro dos tipos de recursos, devem-se distribuir os recursos de acordo com o
tipo. Para tanto, seleciona-se o item e o tipo de recurso, em seguida insere-se um novo
registro, preenchendo os campos adequados ou edita-se alterando os dados de um recurso já
existente. Após isso basta confirmar as alterações. Na Figura 4.5 é visualizado o diagrama de
atividades referente a essa ação.
61
Figura 4.5 Diagrama de Atividades da “Cadastra Recurso Disponível”
Após o registro dos tipos de recursos e dos resultados esperados, estes devem ser
associados. Para tanto se seleciona o nível de maturidade, seguido do resultado esperado e do
item de recurso a que se refere o tipo de recurso. Após isso, pode-se incluir ou excluir os tipos
de recursos associados a cada um dos resultados esperados. Na Figura 4.6 há o diagrama que
representa esta atividade.
62
Figura 4.6 Diagrama de Atividade da “Vincula Tipo de Recurso a Resultados Esperados”
Tendo concluído os registros/manutenções, podem-se consultar os recursos para cada
um dos resultados esperados. Na Figura 4.7 há o diagrama de atividades mostrando como
efetuar a consulta, selecionando-se na seqüência: Processo, Resultado Esperado e Tipo de
Recurso; a seguir podem-se selecionar os recursos disponíveis, inclusive abrindo-os ou
executando-os.
63
Figura 4.7 Diagrama de atividades da “Consulta Recursos”
4.2.3 Arquitetura
Como padrão de projeto arquitetural da ferramenta, utilizou-se a modelagem MVC,
Model-View-Controler, (Modelo-Visão-Controle). Neste padrão, o objetivo é separar dados
ou lógica de negócios (Modelo) da interface do usuário (Visão) e do fluxo da aplicação
(Controle). O modelo é formado por entidades de negócio que representam os dados do
sistema. Componentes de visão têm o objetivo de apresentar as informações pertencentes ao
modelo e capturar eventos de usuário. Componentes de controle tratam os eventos capturados,
notificam e coordenam componentes de modelo. Os componentes de controle fazem a ponte
entre componentes de visão e do modelo. O sistema foi dividido como mostrado na Figura
4.8.
64
Figura 4.8 Diagrama de Pacotes do Sistema seguindo o modelo MVC
4.2.3.1 Tecnologias Usadas
Como metodologia de desenvolvimento da ferramenta, inicialmente foram realizadas
entrevistas com um avaliador líder e consultor-implementador do modelo MPS.BR,
certificado pela SOFTEX, a fim de que esse provesse informações sobre a atividade de
implementação, e quais as ferramentas utilizadas para essa atividade. Assim, foi descrito o
processo, de onde foram apurados os requisitos básicos ao sistema. Seguiram-se os estudos no
Guia Geral [Softex.07a], que explica o modelo de referência, além de fornecer uma visão
geral do modelo, no guia de avaliação [Softex.07b] que explica como se dá a avaliação dos
níveis, os critérios da avaliação e os requisitos para a avaliação e no trabalho [Silva.08] que
faz uma análise dos ferramentais usados como base para a implementação dos níveis G e F do
modelo em referência.
O desenvolvimento da ferramenta foi feito através de prototipação evolutiva, ou seja,
um protótipo inicial produzido após a validação inicial, no qual foram adicionadas novas
funcionalidades, retornando sempre para nova validação, minimizando, assim, a possibilidade
de erros no desenvolvimento do projeto, visto que os usuários estão em constante contato com
a ferramenta. Desta feita, são vistos os pontos em que a ferramenta não atende as necessidades
dos usuários, ou algum requisito que não foi contemplado nos protótipos ou no levantamento
dos requisitos iniciais, quando ainda não se tem um protótipo desenvolvido.
65
A prototipação evolutiva tinha um ciclo pré-definido pelos envolvidos, haviam marcos
a ser seguidos, com reuniões para avaliação do protótipo, levantando os pontos fracos e fortes
da ferramenta, melhorias que deveriam ocorrer ou novos requisitos que surgiram durante o
processo de desenvolvimento da ferramenta. Todas as reuniões eram acompanhadas por um
avaliador do modelo de referência MPS.BR credenciado pela SOFTEX, o qual validava a
ferramenta e acrescentava novos requisitos. Até que a ferramenta foi validada sem erros, de
forma a satisfazer todas as requisições levantadas.
A ferramenta foi desenvolvida utilizando-se como ambiente de desenvolvimento o
Borland Delphi 7.0, acessando um banco de dados modelado em Microsoft Access.
4.2.4 Modelo de Entidade-Relacionamento
Na figura 4.9 é visualizado o modelo Entidade-Relacionamento concebido para o
desenvolvimento da ferramenta SiGA-MPS.BR. Após esta visualização, cada uma das
entidades é discutida sucintamente.
Figura 4.9 Modelo de Entidade-Relacionamento
• Nível: armazena os níveis de maturidade do modelo MPS.BR. Possui os
campos: nível, string de um caracter, o qual armazena a letra correspondente ao
nível de maturidade; e descrição, string[255], a descrição correspondente ao
nível;
66
• Processo: armazena os dados do processo, está vinculado ao nível de
maturidade. Possui como campos: o identificador do processo, string[3], o nível
ao qual este processo está associado; o nome do processo, string [255]; sua
descrição, string[255]; e sua finalidade, string[255];
• ResultadoEsperado: cada um dos resultados esperados do modelo de referência
MR-mps.br. possui como campos: a “Sigla” do resultado esperado, string[3]; o
processo vinculado, string[3]; e a descrição do resultado esperado, string[255];
• RecursoItem: armazena os tipos de Recursos (Ferramentas de Software,
Templates de Artefatos ou Procedimentos) no campo: Item (string[30]); possui
também um campo objeto para descrever de forma resumida de que trata cada
Item (string[255]);
• RecursoTipo: armazena: os tipos de recursos no campo Tipo, string[30]; está
associada a tabela RecursoItem, para tanto possui o campo Item (string[255]);
• Recurso: representa os Ativos, armazena: o nome do recurso no campo Nome
(string[255]); o campo Tipo (string[255]) identifica o tipo do recurso; o campo
Caminho (string[255]) armazena o caminho do recursos no computador, para
poder executá-los; e o campo Desenvolvedora (string[255]) identifica o
responsável/fornecedor pelo software;
• ResultadoEsperado_Recurso: essa entidade associa os resultados esperados:
campo ResultadoEsperado (string[5]) aos Tipos de Recursos; campo
RecursoTipo (string[255]); diferenciado-os de acordo com o item a que se
refere, através do campo RecursoItem (string[255]);
4.3 Protótipo da Ferramenta
A ferramenta foi definida como tendo duas etapas: a etapa de Registros/Manutenção,
onde seriam cadastrados e mantidos os processos, resultados esperados, tipos de recursos,
recursos categorizados por tipo e associação de Resultados esperados a Tipos de Recursos; e a
etapa de Consulta, onde se pode filtrar para cada nível, seus processos; para cada processo
seus resultados esperados; para cada resultado esperados e item desejado, os tipos de recursos
disponíveis; e para cada tipo de recurso os recursos (ativos de processo) disponíveis, os quais
67
podem ser inicializados a partir da ferramenta, para exibição ao avaliado como alternativa de
ferramenta para obtenção do referido resultado esperado.
O funcionamento da ferramenta dá-se da seguinte maneira: após executar a
ferramenta, seja por linha de comando ou clicando-se em seu ícone na área de trabalho, tem-
se a tela inicial do sistema. O protótipo foi desenvolvido para agilizar o acesso as suas
informações, assim optou-se por apenas uma tela onde se apresentam vários guias, as quais
permitem o acesso a todas as funcionalidades, descritas nos diagramas de atividades.
Para as operações de registro, seleciona-se o guia Manutenção. A seguir, para
cadastrar-se o Processo clica-se no guia correspondente (Processo), então são mostrados os
controles para as operações de registro/manutenção dos processos, conforme visualizado na
Figura 4.10. Posteriormente, seleciona-se o nível do processo desejado na caixa suspensa
“Nível”. Ao selecionar-se, são mostrados, em forma de tabela, os vários processos
cadastrados, os quais podem ser editados, bastando-se clicar sobre cada um deles para que
estes preencham as caixas de texto (processo, nome, objetivo e finalidade). Caso deseje-se
cadastrar um novo processo, deve-se clicar sobre o ícone adicionar, abaixo da tabela de
processos, em seguida são preenchidas as caixas de texto processo, nome, objetivo e
finalidade.
Após as operações de edição ou inserção de dados nas caixas de textos, deve-se clicar
no botão “Confirmar”, na barra de navegação abaixo da tabela, que verificará as exceções,
como: caso se tente inserir um processo já existente, resulta em uma mensagem de erro, não
confirmando a inserção, conforme visualizado no diagrama de atividades constante na Figura
4.2, caso não haja problemas com os dados inseridos/alterados, confirmam-se e gravam-se os
dados no banco de dados, atualizando em seguida a tabela onde são exibidos os processos.
68
Figura 4.10 Tela de Cadastro dos Processos
Na Figura 4.11 é visualizada a tela de registro/manutenção dos Resultados Esperados,
as ações são executadas conforme descrito no fluxo de atividades da Figura 4.3. As seleções
de nível e processo são feitas através de caixas suspensas, ao selecionar o nível a caixa
Processo exibe apenas os processos vinculados ao referido nível, os campos Sigla e Definição
são caixas de texto através dos quais é possível tanto a inclusão de novos resultados como a
edição dos já existentes, para tanto há uma tabela onde são mostrados os resultados esperados
já cadastrados, filtrados através da seleção e nível e processo. Clicando-se sobre o registro
desejado este preenche as caixas de texto já citadas. Para se alterar os valores ou inserir
novos, pode-se fazer uso da barra de navegação abaixo da tabela. Nesta pode-se selecionar o
botão Editar para iniciar alteração de algum valor desejado (Sigla ou Definição), ou pode-se
clicar no botão Inserir, para inclusão de um novo resultado esperado. Posteriormente, clica-se
em Confirmar ou Cancelar para finalizar a operação de inclusão ou edição.
69
Figura 4.11 Tela de Registro dos Resultados Esperados
Para a manutenção dos dados referentes aos Tipos de Recursos, a tela segue o mesmo
padrão da anterior, conforme visualizado na Figura 4.12. Nesta tela seleciona-se o item de
recurso na caixa suspensa Item, posteriormente na tabela abaixo dos controles são exibidos os
Tipos de Recursos cadastrados como o item referido. A edição e inserção de novos valores
são realizadas nos mesmos moldes da inclusão/edição dos resultados esperados, seguindo o
que foi descrito no item Fluxo de Controle e visualizado no fluxo de atividades da Figura 4.4.
Figura 4.12 Tela de Registro dos Tipos de Recursos
70
A tela de inclusão e manutenção dos Recursos, visualizada na Figura 4.13, segue o
mesmo padrão. Seguindo o diagrama de atividades, Figura 4.5, inicialmente seleciona-se o
item ao qual o recurso diz respeito, em seguida seleciona-se o Tipo de Recurso, assim são
exibidos na tabela todos os recursos cadastrados com o item e o tipo de recurso selecionados.
Assim, pode-se da mesma forma que nas telas anteriores inserir ou editar os itens, utilizando a
barra de navegação abaixo da tabela. Nesta tela, há para a caixa de texto, um botão associado
o qual pode ser utilizado para localizar o aplicativo, ou documento que se deseje executar
quando da consulta do recurso.
Figura 4.13 Tela de Registro dos Recursos
Na Figura 4.14 é visualizada a tela de registro/manutenção das associações de
Resultados Esperados a Tipos de Recurso. Para se efetuar as referidas associações,
primeiramente deve-se selecionar na primeira caixa suspensa, o nível de maturidade o qual se
deseja restringir, em seguida selecionar o Resultado Esperado, na caixa suspensa seguinte.
Então, seleciona-se o item ao qual será referido (Ferramentas de Software, Templates de
Artefatos ou Procedimentos). Após esta seleção, são exibidos nas listas inferiores: à esquerda
os Tipos de Recursos não vinculados ao Resultado Esperado selecionado; e à direita os
vinculados. A inclusão e exclusão são feitas clicando-se nas setas entre as duas listas, as quais
migram os Tipos de Recursos selecionados entre as listas, vinculando ou desvinculando um
determinado Tipo de Recurso. O fluxo desta atividade está representado no diagrama de
atividade da Figura 4.6.
71
Figura 4.14 Tela de Cadastro dos Resultados Esperados x Tipos de Recurso
Feitas as inclusões, pode-se efetuar as consultas. Na Figura 4.15 é visualizada a tela de
Consulta do sistema Siga-MPS.BR. A seqüência segue o definido no diagrama de atividades
da Figura 4.7. Iniciando na caixa suspensa Nível, onde se seleciona o nível de maturidade a
ser consultado, passa-se a selecionar o processo, que já está mostrando apenas os processos
referentes ao nível selecionado, em seguida identifica-se o Resultado Esperado, entre os
disponíveis para aqueles cadastrados para o processo selecionado. Na seqüência, escolhe-se
um dos itens de recurso. Após esta seleção, são exibidos os Tipos de Recursos disponíveis
para esta seleção. Clicando-se sobre cada um dos Tipos de Recurso visualiza-se na lista à
direita os ativos (Recursos) disponíveis, os quais podemos abrir ou executar com um duplo-
clique sobe o nome, proporcionando assim a possibilidade de exibir para cada um dos
Resultados Esperados em cada nível do MPS.BR os ativos disponíveis para utilização na
obtenção do referido resultado.
72
Figura 4.15 Tela de Consulta da ferramenta SiGA-MPS.BR
4.4 Estudo de Caso
Como forma de avaliar a sistematização da ferramenta proposta neste trabalho, a
solução inicialmente foi disponibilizada a dois avaliadores líderes e consultores-
implementadores de nível experiente no modelo MPS.BR, credenciados pela SOFTEX e
pertencentes à Instituição Avaliadora e Implementadora SWQuality. Estes dois validadores da
ferramenta receberam treinamento para manipular o uso da mesma a partir das atividades
apresentadas.
Com base nisso, ao longo das avaliações realizadas em 4 (quatro) empresas em
Salvador no ano de 2008, o papel dos avaliadores seriam de coletar os ativos usados como
base para a implementação dos processos organizacionais e dispor dos mesmos para registro
na ferramenta Siga-MPS.BR. A partir disso, estes ativos mantidos serviriam como lições
aprendidas no contexto de consultorias provenientes das implementações dos programas de
melhoria da qualidade organizacional. Esta prática foi realizada no contexto de duas
organizações que se propunham aderir às premissas propostas pelo modelo MPS.BR, uma
situada em Belo Horizonte-MG e outra em Belém-PA. Ambas organizações encontram-se em
implementação dos seus processos de desenvolvimento de software com base no modelo
MPS.BR e possuem a finalidade de serem avaliadas seguindo o modelo MA-MPS.Br em
2009.
73
A avaliação da ferramenta decorria na análise das evidências do nível G do MPS.BR,
durante as avaliações realizadas, para inclusão na sua base de dados, para posteriormente esta
mesma ferramenta provesse os ativos para serem usados e assim adaptados ao contexto de
uma possível organização, o que perfaz o caráter da gestão do conhecimento nas
implementações usando o modelo MPS.BR.
Após a realização de toda metodologia de avaliação descrita, usando a ferramenta
Siga-MPS.BR como base, os validadores listaram os seguintes pontos fortes:
• Atende aos objetivos que se propõe, já que funciona como um repositório de
ativos/melhores práticas propostas em implementações usando o modelo MPS.BR
e assim a sua disseminação;
• Organiza em diferentes visões as atividades promovidas por esta gestão do
conhecimento, o que facilita o entendimento das tarefas de forma sistematizada;
• Redução do tempo na identificação dos melhores ativos usados como base para a
implementação do programa da qualidade pelo modelo MPS.BR;
Porém algumas melhorias também foram detectadas para aperfeiçoar a operação dos
serviços providos:
• Prover um serviço de impressão de todas as informações geradas e mantidas com
foco em comprovações;
• Implementar todas as atividades de gestão de conhecimento que a comunidade e a
literatura especializadas propõem para uso;
• Dispor a publicação dos ativos coletados em uma página Web que sirva como
pesquisa para todos os membros pertencentes a uma Instituição Avaliadora e
Implementadora credenciada pela SOFTEX, com fins de disseminação de todo o
conhecimento aprendido;
• Dotar a ferramenta de todas as práticas constantes no guia de referência do modelo
MPS.BR, a fim de possibilitar com que os usuários possam associar os ativos
disponíveis de acordo com a sua real finalidade.
74
No mais, os membros validadores acreditam que a Siga-MPS.BR está preparada para
possibilitar a gestão de conhecimento dos ativos usados nas implementações do modelo
MPS.BR.
75
5 CONCLUSÃO
Neste capítulo serão abordadas as considerações finais deste trabalho, serão revistos
conceitos que embasam este trabalho. Assim como, serão apresentados projetos não contemplados
neste documento, os quais podem ser adotados como trabalhos futuros.
5.1 Visão Geral
Para melhor compreensão deste trabalho estudou-se o processo de software e as
normas e modelos de qualidade. Processo de software é a seqüência de passos a ser seguida
para transformar os requisitos de um cliente em um software que atenda a tais requisitos. Para
se garantir a qualidade deste software, foram criados diversos padrões e normas de qualidade
para processos de software, entre os quais citamos ISO/IEC 12207, ISO/IEC 15504, CMM,
CMMI e ISO/IEC 9000-3. Porém como foco do trabalho optou-se pelo modelo de referência
MPS.BR, por ser um modelo desenvolvido para a realidade brasileira, possuir uma maior
graduação de níveis, facilitando a adequação e minimizando custos, além de ser aderente as
normas ISO 12207, ISO 15504, CMMI.
Este trabalho objetivou a criação do Siga-MPS.BR, uma solução para catalogação de
ativos e melhores práticas de processo para implementação do modelo MPS.BR,
proporcionando a simplificação do trabalho, com conseqüente redução do tempo de
consultoria para implementação do modelo MPS.BR. Outro objetivo era a utilização desta
ferramenta em uma avaliação de certificação oficial com foco em analisar a implementação
tida como base para o modelo MPS.BR, o que proporciona uma melhor gestão do
conhecimento dos ativos organizacionais usados como parâmetros para a execução de tal
atividade.
5.2 Trabalhos propostos
Com base no desenvolvimento deste trabalho, destacamos pontos que podem ser estudados e desenvolvidos em trabalhos futuros.
• Criação de relatórios para visualização/impressão de todas as informações mantidas no sistema, identificando o responsável pelo cadastramento/alteração, através de um controle de login (acesso);
• Criar um módulo funcional que permita a troca de informações sobre as funcionalidades e aspectos dos ativos ou das boas práticas mantidas no sistema;
76
• Prover na Web um repositório onde o sistema possa alimentar e atualizar suas informações sobre Ativos/Boas Práticas, permitindo, inclusive, consulta na própria página Web;
• Alterar o ambiente de implementação para Web, incluindo as propostas citadas anteriormente;
77
Referências Bibliográficas
[ABNT.94] ABNT (Associação Brasileira de Normas Técnicas), NBR ISSO 8402/1994 –
Gestão da Qualidade e Garantia da Qualidade, Terminologia, Brasil, 1994.
[Ambler.02] AMBLER, Scott W., Agile Modeling, 2002.
[Bach.95] BACH, James, SCRUM Software Development Process - Building The Best
Possible Software, ADVANCED DEVELOPMENT METHODS Inc. 1995.
[Beck.00] BECK, Kent, Extreme Programming Explained. Addison-Wesley, 2000.
[Chrissis.03] CHRISSIS, M. B., KONRAD, M. and SHRUM, S., CMMI Guidelines for
Process Integration and Product Improvement, Addison-Wesley, 2003.
[CMMI.02] CMMI Product Team, Capability Maturity Model Integration (CMMI) for
Software Engineering Version 1.1, Staged Representation, Carnegie Mellon,
USA, 2002.
[Cockburn.02] COCKBURN, Alistair, Crystal Clear – A human-powered methodology for small
teams including the seven properties of effective software projects, Humans and
Technology, 2002.
[D’Souza.99] D’SOUZA, D. & WILLS, A., Objects, Components and Frameworks with UML
– The Catalysis Approach, Addison-Wesley Publishing Company, 1999.
[Falbo.98] FALBO, Ricardo de Almeida, Integração de Conhecimento em um Ambiente de
Desenvolvimento de Software, Orientadora: Ana Regina Cavalcanti da Rocha.
Tese de Doutorado, COPPE/UFRJ, 1998.
[Fernandes.04] FERNANDES, Jorge Henrique Cabral, Alinhando Produção de Software e TI,
White paper, Departamento de Ciência da Computação – Universidade de
Brasília, 2004.
[Graham.97] GRAHAM, I., HENDERSON-SELLERS, B. & YOUNESSI, H., Life Cycle
Patterns. The OPEN Process Specification, Addison-Wesley, UK, 1997.
[Humphrey.89]] HUMPHREY, Watts S., Managing the Software Process, The SEI Series in
Software Engineering. Addison-Wesley, 1989.
[Ids.03] IDS Scheer, ARIS Process Platform, disponível em:
www.idsscheer.de/germany/products/29770, 2003
[IEEE.06] IEEE (Institute of Electrical and Electronic Engineers) Computer Society,
http://www.computer.org, 2006.
[ISO.91] ISO 9000-3, Quality management and quality assurance standards – parte 3:
guidelines for the application of ISSO 9001:1994 to the development, supply and
maintenance of computer software. International Organization for
Standardization, 1991.
78
[ISO.97] NBR ISO/IEC 12207:1995, Tecnologia de informação – processos de ciclo de
vida de software. Associação Brasileira de Normas Técnicas, 1997.
[ISO.01] The International Organization for Standardization and the International
Electrotechnical Comission (2001) “ISO/IEC 12207 Amendment: Information
Technology – Amendment 1 to ISO/IEC 12207”, Geneve.
[ISO.04a] The International Organization for Standardization and the International
Electrotechnical Comission (2004) “ISO/IEC 15504-1 Information Technology –
Process Assessment – Part 1 – Concepts and Vocabulary”, Geneve.
[ISO.04b] The International Organization for Standardization and the International
Electrotechnical Comission (2003) “ISO/IEC 12207 Amendment: Information
Technology – Amendment 2 to ISO/IEC 12207”, Geneve.
[Jacobson.98] JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software
Development Process, Addison Wesley Longman, Inc, 1998.
[Jefrries.01] JEFRRIES, Ron, What is Extreme Programming?, Disponível via web em
www.xprogramming.com/xpmag/whatisxp.htm, 2001.
[Kruchten.03] KRUCHTEN, Philippe, Introdução ao RUP – Rational Unified Process, Rio de
Janeiro: Editora Ciência Moderna Ltda., 2003.
[Maidantchik.99] MAIDANTCHIK, C. L. L. M., Gerência de Processos de Software para Equipes
Geograficamente Dispersas, Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ,
1999.
[Oliveira.06] OLIVEIRA, Sandro Ronaldo Bezerra, Processo de Software: Princípios,
Ambientes e Mecanismos de Execução, Orientador Alexandre Marcos Lins de
Vasconcelos.Dissertação de Doutorado. CI – UFPE, 2006
[Paulino.99] PAULINO, Rita de Cássia Romeiro, Metodologia de Avaliação Centrado no
Usuário para a Melhoria Contínua do Processo de Desenvolvimento de Sistemas,
Orientador: José Leomar Todesco. Departamento de Engenharia de Produção –
UFSC, 1999.
[Paulk.93] PAULK, Mark C. & CURTIS, Bill & CHRISSIS, Mary Beth & WEBER, Charles
V., Capability Maturity Model for Software, Version 1.1. Technical Report
CMU/SEI-93-TR-024. Software Engineering Institute - Carnegie Mellon
University, 1993.
[Paulk.95] PAULK, M. C., WEBER, C.V., CURTIS, B., CHRISSIS, M.B., The Capability
Maturity Model: Guidelines for Improving Software Process, Addison – Wesley,
USA, 1995.
[Pressman.00] PRESSMAN, R. S., Software Engineering: A Practioner’s Approach, 5th edition.
MacGraw-Hill International Edition, 2000.
79
[Reis.98] REIS, Carla Alessandra Lima, Um Gerenciador de Processos de Software para o
Ambiente PROSOFT, Orientador Daltro José Nunes. Dissertação de Mestrado.
PPGC – UDFRGS, 1998.
[Reis.99a] REIS, Rodrigo Quites & REIS, Carla Alessandra Lima, Engenharia de Software,
Notas de Aula da Especialização em Análise de Sistemas. DI-UFPA, 1999.
[Reis.99b] REIS, Rodrigo Quites & REIS, Carla Alessandra Lima, Métricas para Estimativa
de Custo de Software, Notas de Aula da Especialização em Análise de Sistemas.
DI-UFPA, 1999.
[Rocha.01] ROCHA, Ana Regina Cavalcanti da & MALDONADO, José Carlos & WEBER,
Kival Chaves, Qualidade de Software: Teoria e Prática, São Paulo: Prentice Hall,
2001.
[Sellers.97] SELLERS, B. Henderson- & GRAHAM, I. & YOUNESSI, H., The OPEN
Process (Tasks, Techniques and Management), Chapter of Handbook of Object
Technology. Centre for Object Technology Applications and Research – School
of Information Technology – Swinburne University of Technology, CRC Press,
1997.
[Silva.08] SILVA, Diego Batista & ANDRADE FILHO, Roberto Alves de & PIMENTEL,
Rodrigo Alves, Uma Análise das Recomendações dos Níveis G e F do MPS.BR
para Implementação do Programa de Qualidade, Orientador Sandro Ronaldo
Bezerra de Oliveira. Trabalho de Conclusão de Curso. CBCC – UNAMA, 2008.
[Softex.07a] Softex - Sociedade para Promoção da Excelência do Software Brasileiro,
MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral, versão 1.2,
2007.
[Softex.07b] Softex - Sociedade para Promoção da Excelência do Software Brasileiro,
MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Avaliação,
versão 1.1, 2007.
[Weber.04] WEBER, Kival C. et al, Modelo de Referência para Melhoria de Processo de
Software: uma abordagem brasileira, Conferência Latinoamericana de
Informática – CLEI, Arequipa-Peru, 2004.
[Yonezawa.08] YONEZAWA, Wilson M.. UML - Diagramas. Disponível
em:http://www.unesp.br/gs/treinamento/graduacao/CursoUML-Diagramas.pdf.
Acesso em: 24 jun.2008
[Zahran.98] ZAHRAN, S., Software Process Improvement, Addison Wesley Longman Inc,
1998.
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Anderson Jones Silva de Jesus
UMA SOLUÇÃO SISTÊMICA PARA A GERÊNCIA DE ATIVOS NO CONTEXTO DA IMPLEMENTAÇÃO DOS
NÍVEIS DO MPS.BR
Belém 2009
