0
UNIJUÍ – UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO
RIO GRANDE DO SUL
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
DIOGO FRITZEN KALB
Ijuí – RS
Julho/2014
1
DIOGO FRITZEN KALB
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
Projeto de Pesquisa Final do Curso de
Ciência da Computação do DCEEng –
Departamento de Ciências Exatas e
Engenharia da UNIJUÍ – Universidade
Regional do Noroeste do Estado do Rio
Grande do Sul, apresentado como
requisito
para
a
aprovação
no
componente curricular Trabalho de
Conclusão de Curso.
Orientador: Msc. Romário Lopes Alcântara
Ijuí – RS
Julho/2014
2
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
DIOGO FRITZEN KALB
Projeto de Pesquisa Final do Curso de
Ciência da Computação do DCEEng –
Departamento de Ciências Exatas e
Engenharia da UNIJUÍ – Universidade
Regional do Noroeste do Estado do Rio
Grande do Sul, apresentado como requisito
para a aprovação no componente curricular
Trabalho de Conclusão de Curso.
______________________________________
Orientador: Prof. Msc.Romário Lopes Alcântara
BANCA EXAMINADORA:
______________________________________
Prof. Msc. Marcos Ronaldo Melo Cavalheiro
Ijuí
Julho/2014
3
Dedico esse trabalho a
minha amada família.
4
AGRADECIMENTOS
Meus sinceros agradecimentos a todos aqueles que
de alguma forma doaram um pouco de si para que a
conclusão deste trabalho se torna-se possível:
A Deus, o centro e o fundamento de tudo em minha
vida, por renovar a cada momento a minha força e
disposição e pelo discernimento concedido ao longo
dessa jornada.
Aos meus pais, Armindo Kalb e Loiva Salete Fritzen
Kalb que com muito carinho e apoio, não mediram
esforços para que eu chegasse até esta etapa da
minha vida.
Ao meu professor Orientador Msc. Romário Lopes
Alcântara, pelo auxílio, disponibilidade de tempo e
material, sempre com uma simpatia contagiante e
pelo fornecimento de material para pesquisa do
tema.
A todos os professores do curso, que foram
importantes na minha vida acadêmica e no
desenvolvimento deste trabalho.
Aos amigos e colegas, pelo incentivo e pelo apoio
constante.
E a todos que direta ou indiretamente fizeram parte
da minha formação!
MEU MUITO OBRIGADO!
5
“Os nossos pais amam-nos porque somos seus
filhos, é um fato inalterável. Nos momentos de
sucesso, isso pode parecer irrelevante, mas nas
ocasiões de fracasso, oferecem um consolo e
uma segurança que não se encontram em
qualquer outro lugar” (Bertrand Russell).
6
RESUMO
A fundamental finalidade do trabalho foi descrever e debater a implantação de um
modelo de melhoramento no processo de software em uma empresa de pequeno
porte, e o modelo a ser usado será MPS.BR – Melhoria de Processo de Software
Brasileiro. A empresa escolhida buscou inserir o MPS.BR para poder mobilizar todos
os colaboradores para ter um melhor entendimento e também uma melhoria em
todos os softwares desenvolvidos e consequentemente satisfação dos seus clientes.
O modelo foi escolhido por ter um valor baixo e por aperfeiçoar o método de
software de uma forma gradual. O entendimento de alguns conceitos como os de
engenharia, qualidade de software e a melhoria de processos de software tornou-se
eficaz para elaborar o mesmo. O modelo se mostrou viável para a implantação de
avanços de forma gradual e voltado a realidade da empresa.
Palavras-Chave: MPS.BR. Processo de Software. Qualidade de Software.
Engenharia de Software.
7
ABSTRACT
The fundamental purpose of the study was to describe and discuss the
implementation of a model of the software process improvement in a small-sized
company, and the model to be used will be MPS.BR - Improvement of Brazilian
Software Process. The company sought to enter the chosen MPS.BR to be able to
mobilize all employees to have a better understanding and also an improvement in all
developed software and hence customer satisfaction. The model was chosen to have
a low value and improve the software method in a gradual manner. The
understanding of some concepts such as engineering, software quality and process
improvement software became effective for preparing the same. The model was
feasible to deploy advances gradually and facing the reality of the company.
Keywords: MPS.BR. Software Process. Software Quality. Software Engineering.
8
LISTA DE ABREVIATURAS E SIGLAS
AI: Artificial Intelligency
CMMI: Capability Maturity Model Integration
ETM: Equipe Técnica do Modelo
FCC: Fórum de Credenciamento e Controle
IEC: International Electrotechnical Commission
IEE: Institute of Electrical and Engineers
ISO: International Organization for Standardization
ITIL: Information Technology Infrastructure Library
MA.MPS: Método de Avaliação da Melhoria do Processo de Software
MPS.BR: Melhoria do Processo de Software
MR.MPS: Modelo de Referência da Melhoria do Processo de Software
PRM: Process Reference Model
RUP: Rational Unified Process
SOFTEX: Associação para Promoção da Excelência do Software Brasileiro
TI: Tecnologia da Informação
TQM: Total Quality Management
9
LISTA DE FIGURAS
Figura 1: Engenharia de software .............................................................................. 19
Figura 2: Modelo em cascata ..................................................................................... 21
Figura 3: Diagrama do modelo espiral ....................................................................... 22
Figura 4: Fases do processo unificado (RUP) ............................................................ 25
Figura 5: Elementos chave do TQM ........................................................................... 26
Figura 6: Componentes da estrutura do CMMI-DEV .................................................. 31
Figura 7: Componentes do programa MPS.BR .......................................................... 34
Figura 8: Processos do ciclo de vida de software ...................................................... 36
10
LISTA DE TABELAS
Tabela 1: Características do processo ....................................................................... 29
Tabela 2: Níveis da ISO/IEC 15504 ........................................................................... 38
Tabela 3: Níveis de maturidade do MR-MPS ............................................................. 44
Tabela 4: Custos níveis MPS-BR ............................................................................... 50
Tabela 5: Resultados alcançados .............................................................................. 55
11
SUMÁRIO
1 INTRODUÇÃO ........................................................................................................ 13
1.1 JUSTIFICATIVA ................................................................................................... 14
1.2 OBJETIVOS DO ESTUDO ................................................................................... 15
1.2.1 Objetivo Geral .................................................................................................. 15
1.2.2 Objetivos Específicos ..................................................................................... 15
2 ASPECTOS GERAIS DO MPS.BR ......................................................................... 16
2.1 SOFTWARE ......................................................................................................... 16
2.2 PRINCIPAIS APLICAÇÕES ................................................................................. 17
2.2.1 Software Básico .............................................................................................. 17
2.2.2 Software de Tempo Real ................................................................................. 17
2.2.3 Software Comercial ......................................................................................... 17
2.2.4 Software Científico e de Engenharia ............................................................. 18
2.2.5 Software Embutido ou Embargado ................................................................ 18
2.2.6 Software de Computador Pessoal ................................................................. 18
2.2.7 Software de Inteligência Artificial .................................................................. 18
2.2.8 Software Online ............................................................................................... 18
2.3 ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS ......................... 19
2.3.1 Paradigmas de Engenharia de Software ....................................................... 20
2.3.2 Modelos de Processo de Desenvolvimento de Software............................. 20
2.3.2.1 O Modelo em Cascata .................................................................................... 20
2.3.2.2 Modelo Espiral ................................................................................................ 21
2.3.2.3 Modelo de Prototipação.................................................................................. 23
2.3.2.4 O Modelo RUP ............................................................................................... 23
2.4 QUALIDADE DE SOFTWARE ............................................................................. 25
2.4.1 Garantia da Qualidade do Software ............................................................... 27
2.4.2 Melhoria do Processo de Software ................................................................ 27
2.5 MODELO DE QUALIDADE DE SOFTWARE ....................................................... 29
2.5.1 Modelo CMMI ................................................................................................... 30
2.5.2 Modelo ISO/IEC 9126 ....................................................................................... 31
2.5.3 Modelo MPS ..................................................................................................... 33
3 PROJETO MPS.BR ................................................................................................ 34
3.1 BASE TÉCNICA PARA A DEFINIÇÃO DOS COMPONENTES DO MPS.BR ...... 35
3.1.1 ISO/IEC 12207:2008 ......................................................................................... 35
3.1.2 ISO/IEC 15504 .................................................................................................. 37
12
3.1.3 ISO/IEC 20000 .................................................................................................. 39
3.1.4 MPS.BR e suas Estruturas de Apoio ............................................................. 40
3.2 DESCRIÇÃO DOS MODELOS MPS .................................................................... 40
3.2.1 Descrição do Modelo de Referência MR-MPS .............................................. 40
3.2.2 Descrição do Modelo de Avaliação MA-MPS ................................................ 41
3.2.3 Descrição do Modelo de Negócio MN-MPS ................................................... 41
4 PROCESSO MPS.BR ............................................................................................. 42
4.1 CAPACIDADE DO PROCESSO .......................................................................... 42
4.1.1 Atributos de Processo .................................................................................... 43
4.1.2 Exclusão de Processos .................................................................................. 44
4.2 NÍVEIS DE MATURIDADE ................................................................................... 44
4.2.1 Nível G – Parcialmente Gerenciado ............................................................... 45
4.2.2 Nível F – Gerenciado ....................................................................................... 46
4.2.3 Nível E – Parcialmente Definido ..................................................................... 47
4.2.4 Nível D – Largamente Definido ....................................................................... 48
4.2.5 Nível C – Definido ............................................................................................ 48
4.2.6 Nível B – Gerenciado Quantitativamente ...................................................... 49
4.2.7 Nível A – Em Otimização................................................................................. 49
4.3 CUSTOS .............................................................................................................. 50
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO COM
NÍVEL G DO MPS.BR EM UMA EMPRESA DE PEQUENO PORTE ....................... 51
5.1 TIPO DE PESQUISA ............................................................................................ 51
5.2 PROCESSOS METODOLÓGICOS ...................................................................... 51
5.3 DEFINIÇÃO DA EMPRESA ................................................................................. 52
5.4 PROCESSO ATUAL............................................................................................. 52
5.5 IMPLEMENTAÇÕES ............................................................................................ 53
5.6 RESULTADOS ESPERADOS COM A IMPLEMENTAÇÃO ................................. 53
5.7 RESULTADOS ALCANÇADOS ........................................................................... 55
5.8 ANÁLISE DA IMPLEMENTAÇÃO ........................................................................ 57
5.9 DIFICULDADES ENCONTRADAS NA IMPLEMENTAÇÃO ................................. 58
6 CONCLUSÃO ......................................................................................................... 59
7 TRABALHOS FUTUROS........................................................................................ 61
8 REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 62
ANEXO ...................................................................................................................... 65
13
1 INTRODUÇÃO
A melhoria de processos de software em empresas brasileiras tem ocorrido
cada vez mais em consonância com o modelo de Melhoria do Processo de Software
Brasileiro (MPS.BR) (SOFTEX, 2009).
Estudos indicam que dentro do âmbito das empresas de software brasileiras,
empresas que se certificam em programas de qualidade têm maior possibilidade de
exportar e também de ocupar o mercado interno (IPEA, 2006).
O MPS.BR (Melhoria do Processo de Software Brasileiro) apresenta seus
principais atributos baseados no SOFTEX o qual é responsável por agenciar a
qualidade de software no Brasil, responsável por alterar o perfil do software nacional,
que está se desenvolvendo em outros países.
Hoje em dia são muitos os modelos de avanço de processo de software
disponíveis, entre eles se destacam: CMMI, ISO 15504, ISO 12207, ISO 20000 e o
modelo brasileiro MPS.BR o qual se adapta ao fato de diferentes empresas com
abordagem nas micro, pequenas e médias. O que todos têm em comum é a procura
da qualidade nos processos, o que normalmente implica no avanço da qualidade de
seus produtos.
Segundo Travassos e Kalinowski (2009, p. 27), os resultados de
desempenho de organizações que seguiram o MPS.BR indicam que estas empresas
obtiveram maior satisfação dos seus clientes, maior produtividade, capacidade de
desenvolver projetos maiores e satisfação com o MR-MPS.
As organizações tentam implementar o MPS.BR com a finalidade principal
de garantir e também planejar que o começo dos projetos sejam cumpridos, com
isso os sistemas de qualidade alcançam o avanço contínuo de seus produtos e
serviços, pensando nisso vamos trabalhar com o modelo MPS.BR focando a prática
do Nível G.
Este trabalho tem como foco principal o modelo de melhoria e avaliação do
processo de software, aplicando-se em uma empresa de pequeno porte da área de
desenvolvimento de software, levando em consideração os níveis de implantação
para poder ter uma melhor compreensão dos conceitos e com isso um melhor
entendimento dos envolvidos na implementação do MPS.Br nível G.
14
A parte inicial deste trabalho, se dá pela apresentação da justificativa que
visa explicar a importância e para que é interessante esta pesquisa. Seguida dos
objetivos que busca-se atingir com a referente indagação.
No segundo capítulo, Aspectos Gerais do MPS.Br busca conceitos e teorias
necessárias para melhor entendimento deste tema, tais como: software e suas
principais aplicações, engenharia do software, qualidade do software, modelo de
qualidade de software, projeto MPS.BR, descrição do MR-MPS-SW, níveis de
maturidade.
Após o referencial teórico, apresenta-se o tipo de pesquisa, e por fim, a
caracterização da empresa, processo atual, implementações, resultados e
dificuldades.
1.1 JUSTIFICATIVA
Segundo Softex (2005), tendo em vista a contribuição com soluções para o
cenário brasileiro da qualidade de software, o projeto MPS.BR (Melhoria do
Processo de Software Brasileiro), continua se desenvolvendo desde 2003, por sete
grandes instituições, com capacidade complementares no avanço de processo de
software, que procura constituir um padrão de software fundamentado em guias que
ajudam para a avaliação da qualidade do produto.
Com o custo muito alto dessas certificações muitas vezes tornasse inviáveis
a empresas de micro, médio e pequeno porte, por meio de um acordo entre a Softex,
o Governo e Universidades teve início o projeto MPS-BR (Melhoria do Processo de
Software Brasileiro) o qual é uma solução brasileira ajustada com o modelo
internacional CMMI, mas elaborada com base na realidade brasileira.
Dando
a
oportunidade
para
as
empresas
que
trabalham
com
desenvolvimento de software a seguir o modelo MPS-BR e apresentar um diferencial
no competitivo mercado, conseguindo essa certificação com um reduzido custo se
for comparada com as normas estrangeiras, o modelo MPS-BR está tendo amplo
desenvolvimento nos últimos anos chegando nos países próximos como Peru, Chile,
Argentina, Costa Rica, e Uruguai. O Brasil é um dos países que o desenvolvimento
de software no mundo é um dos maiores, o que faz com que mais e mais clientes
querem produtos de melhor qualidade e cada vez mais complexos.
15
1.2 OBJETIVOS DO ESTUDO
1.2.1 Objetivo Geral
O objetivo do trabalho é a implantação do melhor processo de
desenvolvimento em uma empresa de porte pequeno usando o modelo descrito no
MPS.BR. Com essa implantação a empresa tem a expectativa de conseguir um
avanço expressivo na qualidade de seus softwares, uma significativa melhora no
gerenciamento de projetos e, conseguindo assim um aumento no número de
clientes.
Foi escolhido o modelo MPS.BR nível G, por se adaptar aos padrões
brasileiros, tendo como proposta aperfeiçoar o processo de software.
1.2.2 Objetivos Específicos
Por meio da fundamentação teórica, esperamos conseguir base para poder
desenvolver o tema escolhido neste estudo, revisando a parte teórica estudada para
o desenvolvimento do Trabalho de Conclusão e o emprego da própria para
avaliação dos problemas, ficando assim desenvolvido por meio de uma análise
profunda, abrangendo o desenvolvimento de software, condições de avaliação para
adaptar a característica do processo de software, melhoramentos, custos, geração
de negócios novos e também suas vantagens e desvantagens.
16
2 ASPECTOS GERAIS DO MPS.BR
2.1 SOFTWARE
Conforme Cândido (2004, p. 75), no começo deste século, fatores como a
globalização da economia e a maior concorrência do mercado têm gerado inúmeros
desafios para as empresas. No fato dessas empresas serem baseadas em
desenvolvimento de software, criar sistemas em tempo hábil, com valores plausíveis
e qualidade adequada tornou-se essencial.
A qualidade no método influencia inteiramente na obra final. Um método de
software desordenado demostra a ausência de qualidade e organização da empresa
responsável pelo desenvolvimento do software.
Na atualidade são muitos os métodos de melhoria de processos de software
no mercado, os que mais se sobressaem são: ISO15504, ISO12207, CMMI e o
modelo MPS-BR o qual é brasileiro. Eles têm em comum a procura da qualidade nos
métodos, o que provoca a melhora dos produtos.
Ao passar do tempo, ninguém imaginava que o software tornaria um
elemento muito importante para o mundo e teria a capacidade de manipular
a informação. Com muitos elementos computacionais tiveram mudanças até
hoje e continuam tendo. Com este crescimento computacional, levam a
criação de sistemas perfeitos e problemas para quem desenvolve softwares
complexos. As preocupações dos engenheiros de software para
desenvolverem os softwares sem defeitos e entregarem estes produtos no
tempo marcado, assim leva a aplicação da disciplina de engenharia de
software. Com o crescimento desse segmento muitas empresas possuem
mais especialistas em TI em que cada um tem sua responsabilidade no
desenvolvimento de software e é diferente de antigamente que era um único
profissional de software que trabalhava sozinho numa sala (PRESSMAN,
2007, p. 39).
Conforme dados de Significados (2011, p. 16), os software podem ser
classificados em três tipos:
- software de sistema: é o conjunto de dados processadas pelo sistema
interno de um computador que permite a interação entre o usuário e os
periféricos por meio de uma interface gráfica;
- software de programação: é o conjunto de ferramentas que permitem ao
programador desenvolver sistemas utilizando linguagens de programação
e um ambiente para o desenvolvimento;
17
- software de aplicação: são programas que permitem ao usuário
executar uma série de serviços característicos de diversas áreas.
2.2 PRINCIPAIS APLICAÇÕES
2.2.1 Software Básico
Segundo Pressman (2007, p. 34), define-se como um conjunto de
programas que dão base a outros programas. As qualidades marcantes desta
categoria de software são: a intensa interação com o hardware e compartilhamento
de recursos, uso constante de processamento concorrente, que demanda o
escalonamento, e estruturas de dados muito complexas. Temos como exemplo
compiladores, editores de texto, sistemas operacionais.
2.2.2 Software de Tempo Real
Para Pressman (2007, p. 35), essa categoria caracteriza por monitorar,
avaliar e controlar fatos do mundo real. Existem elementos típicos como: Coleta de
dados do ambiente externo, Análise que transforma a informação de acordo com a
necessidade do sistema, controle e saída para o ambiente externo e um
componente de monitoração que coordena todos os outros. Lembrando que tempo
real caracteriza-se por responder dentro de restrições de tempo exatas. Temos
como exemplo nas aeronaves os controles de navegação, nos automóveis os
sistemas de injeção eletrônica.
2.2.3 Software Comercial
Conforme Pressman (2007, p. 35), essa categoria é a maior área privada de
software. Nela os dados são reunidos de uma forma que facilite as operações
comerciais e as decisões administrativas, usando ainda métodos de computação
interativa. Temos como exemplo controle de estoque, folha de pagamento, contas a
pagar e receber.
18
2.2.4 Software Científico e de Engenharia
Segundo Modesto e Oliveira (2010, p. 34), “são software que auxiliam as
aplicações científicas. Têm sido caracterizados por algoritmos de processamento de
números”.
2.2.5 Software Embutido ou Embargado
Para Modesto e Oliveira (2010, p. 35), são software próprios de um
determinado hardware. É usado para controlar produtos e sistemas para os
mercados industriais e de consumo. Tem como característica utilizar uma memória
de somente leitura e usam rotinas limitadas e particulares.
2.2.6 Software de Computador Pessoal
Segundo Modesto e Oliveira (2010, p. 18), conceitua-se pelo software
utilizados em computadores de uso pessoal, entre muitas outras aplicações, são
responsáveis por processamento de textos, planilhas eletrônicas, computação
gráfica.
2.2.7 Software de Inteligência Artificial
Conforme Modesto e Oliveira (2010, p. 18), caracteriza-se pelo uso de
algoritmos não numéricos para resolver problemas complexos. Atualmente a área de
AI (Artificial Intelligency) mais ativa é a dos sistemas especialistas, também
chamados sistemas baseados em conhecimento.
2.2.8 Software Online
Para Modesto e Oliveira (2010, p. 18), são software que trabalham em
conexão com a internet. Os arquivos não são carregados localmente e sim através
de um servidor, com tempo de resposta curto, mas maior que o de tempo real.
19
2.3 ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS
Na engenharia de software há recursos aperfeiçoados e alguns não
aperfeiçoados.
Abaixo uma figura conveniente que apresenta a engenharia de software em
vários aspectos.
Figura 1: Engenharia de software
Fonte: CeviuBlog (2013, p. 19).
Segundo Sommerville (2004, p. 132), a engenharia de software é uma
ciência da engenharia que se toma de todos os aspectos da produção de software,
desde as práticas iniciais de especificação do sistema até a manutenção do mesmo,
após ele entrar em operação. Com essa definição, podemos destacar dois termos
importantes que são:
- estudo da engenharia: aplica as teorias, processos e ferramentas nos
casos apropriados, de maneira seletiva;
- todos os aspectos da produção de software: engenharia não se
designa somente aos métodos técnicos de desenvolvimento, além disso a
atividade como o gerenciamento de projetos de software e o
desenvolvimento de ferramentas.
20
Esses termos levam à busca de um processo de desenvolvimento que
considere a componente “Qualidade”.
2.3.1 Paradigmas de Engenharia de Software
Conforme Seno um paradigma é escolhido tendo-se como base a natureza
do projeto e da aplicação, os métodos e ferramentas a serem usados, os controles e
os produtos que precisam ser entregues.
2.3.2 Modelos de Processo de Desenvolvimento de Software
Os modelos de métodos de desenvolvimento de software nasceram pela
obrigação de dar resposta aos casos a avaliar, pois só na altura em que encaramos
o problema é que podemos sugerir o modelo.
Nos modelos de métodos de software é oferecido um cuidado exclusivo à
representação abstrata dos dados do método e sua dinâmica, não formando
métodos de desenvolvimento, porque este trabalha num grau, além disso, do que os
padrões de período de vida.
2.3.2.1 O Modelo em Cascata
Segundo Leite (2007, p. 20), o modelo cascata (waterfall) tornou-se
conhecido na década de 70 e é referenciado na maior parte dos livros de engenharia
de software ou manuais de exemplos de software. Nele as atividades do método de
desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada
para a próxima.
Conforme Leite (2007, p. 20), este modelo, introduziu enormes atributos ao
desenvolvimento. A primeira chama a atenção de que o método de desenvolvimento
deve ser administrado de forma disciplinada, com atividades visivelmente marcantes,
apurada a partir de um plano e sujeitas a gerenciamento durante a concretização.
Outra qualidade determina de modo claro quais são estas atividades e quais
as condições para cumpri-las. Finalmente, o modelo introduz o afastamento das
atividades do sentido e design da atividade de programação que era o núcleo das
atenções no desenvolvimento de software.
21
Figura 2: Modelo em cascata
Fonte: Victorino e Bräscher (2009, p. 21).
Conforme Victorino e Bräscher (2009, p. 21), o modelo em cascata é
composto pelas seguintes etapas:
- levantamento de requisitos: tem por objetivo propiciar que usuários e
desenvolvedores tenham a mesma compreensão do problema a ser
resolvido;
- análise de requisitos: tem por objetivo construir modelos que
determinam qual é o problema para o qual se procura conceber uma
solução de software;
- projeto: tem por objetivo adaptar o modelo de análise de tal modo que
possa servir como base para implementar a solução no ambiente alvo;
- implementação: etapa em que a codificação do sistema é efetivamente
executada;
- teste: consiste na verificação do software;
- implantação: fase em que o sistema entra em produção.
2.3.2.2 Modelo Espiral
Segundo Pressman (2007, p. 65), modelo espiral é uma combinação do
modelo de processo de desenvolvimento iterativo e sequencial modelo de
desenvolvimento, ou seja, modelo em cascata linear com alta ênfase em análise de
risco.
O modelo espiral tem quatro fases. Um projeto de software passa
repetidamente por essas fases em iterações chamadas espirais.
22
A fase de Identificação começa com a coleta dos requisitos de negócios na
espiral da linha de base. Nos espirais posteriores como o produto amadurece, a
identificação de requisitos de sistema, requisitos de subsistemas e os requisitos de
unidade são todas feitas nesta fase.
A fase de Projeto começa com o projeto conceitual na espiral da linha de
base e envolve projeto arquitetônico, projeto lógico de módulos, design de produtos
físicos e design final nas espirais subsequentes.
A fase Construir ou envergadura refere-se a produção do produto de
software real em cada espiral. Na espiral da linha de base quando o produto é
apenas pensado a o projeto está sendo desenvolvido e é desenvolvido nesta fase
para obter feedback do cliente.
A fase de Avaliação e Análise de risco inclui identificar, estimar e monitorar
viabilidade e gestão de riscos técnicos, como o não cumprimento do cronograma e
superação custo. Depois de testar a acumulação, no final da primeira iteração, o
cliente avalia o software e fornece o feedback.
A seguir uma representação esquemática do modelo espiral listando as
atividades em cada fase:
Figura 3: Diagrama do modelo espiral
Fonte: Pressman (2007, p. 65).
Com base na avaliação do cliente, o processo de desenvolvimento de
software entra na iteração seguinte e, subsequentemente, segue a abordagem linear
para implementar o feedback sugerido pelo cliente. O processo de iteração ao longo
da espiral continua ao longo da vida do software.
23
2.3.2.3 Modelo de Prototipação
Segundo Kumar (2012, p. 23), a ideia fundamental é que, em vez de
congelar os requisitos antes de um projeto ou de codificação avançar, um protótipo
descartável é construído para entender as requisições. Este protótipo é desenvolvido
com base nos requisitos atualmente conhecidas. Ao utilizar este protótipo, o cliente
pode ter uma “sensação real” do sistema, já que as interações com protótipo pode
permitir que o cliente entenda melhor os requisitos do sistema desejado.
Prototipagem é uma ideia atraente para sistemas complexos e grandes para as
quais não há nenhum processo manual ou sistema existente para ajudar a
determinar os requisitos.
Idealmente, o protótipo serve como um mecanismo para identificação dos
requisitos do software. Se um protótipo executável é elaborado, o
desenvolvedor tenta usar partes de programas existentes ou aplicar
ferramentas (por exemplo, geradores de relatório, gestores de janelas etc.)
que possibilitem programas executáveis serem gerados rapidamente
(PRESSMAN, 2007, p. 67).
Conforme Kumar (2012, p. 23), devemos usar o modelo de Prototipação
quando o sistema desejado precisa ter um monte de interação com os usuários
finais. Normalmente os sistemas on-line, tem uma quantidade muito elevada de
interação com os usuários finais, são os mais adequados para o modelo de
protótipo. Pode demorar um pouco para um sistema ser construído, que permite
facilidade de uso e precisa de um mínimo de treinamento para o usuário final.
2.3.2.4 O Modelo RUP
Segundo a IBM (s.d., p. 23), é um framework de processo abrangente que
fornece práticas testadas pela indústria para software e sistemas de entrega e de
execução, para uma gestão eficaz do projeto. É um dos muitos processos contidos
na Biblioteca Processo Racional, que oferece as melhores práticas de orientação
adequada para o seu desenvolvimento em particular ou necessidade do projeto.
Segundo Sommerville (2007, p. 72) as melhores práticas abordadas são as
seguintes:
24
- desenvolver o software interativamente: planejar os incrementos de
software com base nas prioridades do cliente, desenvolver e entregar o
mais cedo possível às características de sistema de maior prioridade no
processo de desenvolvimento;
- gerenciar requisitos: documentar explicitamente os requisitos do cliente
e manter o acompanhamento das mudanças desses requisitos. Analisar o
impacto das mudanças no sistema antes de aceitá-las;
- usar arquiteturas baseadas em componentes: estruturar a arquitetura
do sistema com componentes, reduzindo a quantidade de software a ser
desenvolvido e, consequentemente, reduzir custos e riscos;
- modelar software visualmente: usar modelos gráficos de UML para
apresentar as visões estática e dinâmica do software;
- verificar a qualidade do software: garantir que o software atenda aos
padrões de qualidade da organização;
- controlar as mudanças do software: gerenciar as mudanças do
software,
usando
um
sistema
de
gerenciamento
de
mudanças,
procedimentos e ferramentas de gerenciamento de configuração.
Conforme Martinez (s.d., p. 24), o RUP está organizado em cinco (5) fases
que são:
- fase de concepção/iniciação: esta fase abrange as tarefas de
comunicação com o cliente e planejamento;
- fase de elaboração: abrange a modelagem do modelo genérico do
processo;
- fase de construção: desenvolve ou adquire os componentes de
software;
- fase de transição: abrange a entrega do software ao usuário e a fase de
testes;
- fase de produção: a implantação é continuada e completada e ainda é
feito um acompanhamento para influência das funcionalidades do
software.
Essas cinco fases estão ilustradas na Figura 4.
25
Figura 4: Fases do processo unificado (RUP)
Fonte: Pressman (2007, p. 73).
O modelo é melhorado por dois vetores, que são o dinâmico e o estático.
O vetor estático (eixo y), chamado de Method Content, descreve como o
software é desenvolvido. Esse vetor lista as nove (9) disciplinas do RUP e
abrange todo o modo como as coisas são desenvolvidas. O eixo x por sua
vez captura tudo isso e distribui no tempo através de fases, iterações,
atividades e subatividades, gerando processos (MORIYA, 2007).
2.4 QUALIDADE DE SOFTWARE
Conforme Campos (2013, p. 25), a ISO 9000:2005, qualidade é o grau em
que um conjunto de características essenciais a um produto. Ou seja, pode-se
garantir que se algum produto ou serviço atende as condições apontadas, este
mesmo produto ou serviço possui a qualidade esperada.
Segundo Martins (2012, p. 25), qualidade de software é um conceito
complexo, que não pode ser definido de maneira simples. Classicamente, o
conhecimento de qualidade tem significado que o produto desenvolvido deve
cumprir sua especificação.
Conforme Campos (2013, p. 25), a qualidade pode ter sua avaliação através
do grau de satisfação que as pessoas medem um certo produto ou serviço. Esse
produto ou serviço pode ter qualidade para algumas pessoas e para outras nem
tanto. O termo TQM (Total Quality Management), amplamente usado nas
organizações, também descreve uma abordagem para a melhoria da qualidade.
26
Para Kan (2002, p. 26), “O termo tem tomado vários significados,
dependendo de quem interpreta e como se aplica. ” Os elementos chaves do TQM
podem ser resumidos conforme a Figura 5:
Figura 5: Elementos chave do TQM
Fonte: Kan (2003, p. 26).
Segundo Campos (2013, p. 26), os elementos chave do TQM são os
seguintes:
a) Foco do cliente (customer focus): tem um foco no cliente, na maioria
das vezes é um forte colaborador para o total sucesso de um negócio e
envolve garantir que todos os aspectos da empresa colocam seus clientes
em primeiro lugar;
b) Melhoria de processo (process improvement): é a ocupação proativa
na identificação, análise e avanço em processos de negócios existentes
dentro de uma organização para otimizar e para avaliar novas quotas ou
padrões de qualidade;
c) Lado humano da qualidade (human side of quality): se quiser melhorar
um sistema complexo, devemos convencer o povo em torno da empresa
a fazer as coisas de forma diferente. Mas uma mudança que parece
sensata e benéfica para a empresa pode sentir ameaçador para os
outros;
d) Métricas,
modelos,
medições
e
análise
(metrics,
models,
measurement and analysis): o objetivo é direcionar o progresso
contínuo em todos os parâmetros da qualidade por um sistema de
avaliação orientado a metas.
27
2.4.1 Garantia da Qualidade do Software
Quando os modelos de negócios e os mercados mudam mais rápido do que
as aplicações que os suportam pode ser desenvolvida, o teste de software é muitas
vezes primeiro a ser cortado do orçamento ou cronograma, apesar do fato de que
defeitos de software têm um impacto direto e negativo sobre a rentabilidade. Mesmo
um pequeno número de defeitos podem ter um impacto catastrófico sobre uma
empresa, seus clientes e seus parceiros. Estima-se que um defeito de software
encontrado e os custos pós-produção fixa de 100 vezes mais do que se o defeito foi
encontrado na fase de concepção.
Há muitos benefícios e menos riscos de ter uma organização independente
de testes de software parceiro em vez de in-house testes. Testadores
independentes e consultores de teste trazer uma imparcialidade muito necessária
para os processos de teste para uma melhor qualidade, e em casa o pessoal está
liberado para se concentrar em suas atividades principais. Testes independentes
traz consigo as melhores of-breed de gestão da qualidade de processos, porque
essa é a sua principal atividade.
2.4.2 Melhoria do Processo de Software
Conforme o IEE (Institute of Electrical and Eletronic Engineers), de forma
mais comum, método é uma série de passos atingidos para uma determinada
finalidade.
Segundo Sommerville (2004, p. 141), durante os últimos anos, aumentou o
interesse por parte das organizações que tem desenvolvimento de software pelo
avanço de suas técnicas. O avanço da metodologia significa compreender os
métodos existentes e poder alterá-los. Com esse objetivo obtido, o abatimento dos
valores e do período pode se tornar a fundamental meta do avanço.
Os princípios para o alcance da Melhoria de Processos de Software é fazer
um levantamento das condições necessárias aos clientes, criar um ciclo de vida para
os métodos e, por fim, concretizar a instalação e manutenção do próprio.
Para Silveira (2012, p. 27), para se ter uma qualidade de software depende
da capacitação dos métodos. Existe investimento insuficiente das empresas em
certificações que confirmem a qualidade e a maturidade dos processos na
28
fabricação de software. Para as pequenas empresas, esse investimento é um
problema por ter um valor elevado das certificações. Com a ação de entidades
privadas, centros de estudos e governo têm a probabilidade de aperfeiçoarmos os
processos de software no Brasil, tendo como foco principal pequenas e médias
empresas.
Segundo Sommerville (2004, p. 142), aperfeiçoar o processo de software de
uma organização não é somente seguir métodos ou ferramentas exclusivas ou
algum modelo de processo que tenha sido usado em diferente lugar.
... Desde que o software, como todo capital, é conhecimento incorporado, e
como esse conhecimento está inicialmente disperso, tácito, latente e
incompleto na sua totalidade, o desenvolvimento de software é um processo
de aprendizado social. O processo é um diálogo no qual o conhecimento,
que deve se transformar em software é reunido e incorporado ao software.
O processo fornece interação entre usuários e projetistas, entre usuários e
ferramentas em desenvolvimento e entre projetistas e ferramentas em
desenvolvimento (tecnologia). É um processo iterativo no qual a própria
ferramenta serve como meio de comunicação, com cada nova rodada de
dialogo explicitando mais conhecimento útil do pessoal envolvido...
(BAETJER, 1998, p. 85).
A elaboração de software de computador é um processo de prática, e o
resultado, é a inclusão de informações coletadas, reunidos à medida que o processo
é administrado. Processo é a base da engenharia de software.
Segundo Pressman (2007, p. 76), é ele que permite o desenvolvimento
lógica e aceitável de softwares de computador. Processos de software compõem a
base para a influência gerencial de projetos de software e constitui o conteúdo no
qual os métodos técnicos são aplicados, os produtos de trabalho (modelos,
documentos, dados, relatórios, formulários, etc.) são produzidos, os limites são
constituídos, a qualidade é garantida e as alterações são adequadamente
administradas.
Assim como os produtos, os processos também têm atributos ou
características (Tabela 1).
29
Tabela 1: Características do processo
Característica
do Processo
Facilidade de
compreensão
Visibilidade
Facilidade de
suporte
Aceitabilidade
Confiabilidade
Robustez
Facilidade de
manutenção
Rapidez
Descrição
Até que ponto o processo está explicitamente definido e com que facilidade se pode
compreender a definição do processo?
As atividades de processo culminam em resultados nítidos, de modo que o progresso do
processo seja externamente visível?
Até que ponto as atividades do processo podem ser apoiadas por ferramentas CASE?
O processo definido é aceitável e utilizável pelos engenheiros responsáveis pela produção
do produto de software?
O processo está projetado de tal maneira que seus erros sejam evitados ou identificados
antes que resultem em erros no produto?
O processo pode continuar, mesmo que surjam problemas inesperados?
O processo pode evoluir para refletir os requisitos mutáveis da organização ou melhorias
de processo identificadas?
Com que rapidez pode ser concluído o processo de entrega de um sistema, a partir de
uma determinada especificação?
Fonte: Sommerville (2004, p. 145).
É por meio do avanço nos processos de software que se visa chegar a um
acréscimo de qualidade e a uma obra final que atenda o mercado em geral porque
ela envolve distintos aspectos, dentre eles temos os técnicos, os gerenciais e até
mesmo, os culturais:
- disposição das obras de avanço ao assunto;
- dispor uma tática e colocar quais os objetivos de interesse da
organização;
- opção de um exemplo de processo para ter como referência, por
exemplo, CMM, ISO/IEC 15504 (SPICE e CMMI);
- opção de um processo para o avanço de produtos (por exemplo, IDEAL e
Guia 15504);
- informação da situação atual das práticas da organização;
- idealização;
- implantação de atos de avanço;
- acompanhamento, avaliação e institucionalização do avanço.
2.5 MODELO DE QUALIDADE DE SOFTWARE
Desenvolver software de qualidade assegurada, com elevada produtividade,
dentro do prazo estabelecido e sem necessitar de mais recursos que os alocados,
tem sido o grande desafio da Engenharia de Software.
30
2.5.1 Modelo CMMI
Segundo Pressman (2007, p. 691), o CMMI (Capability Maturity Model
Integration) é uma abordagem para a melhoria de processos compatível com a
Norma ISSO 15504 (SPICE). Embora as duas abordagens sejam semelhantes, o
CMMI não foi baseado em SPICE, como se poderia pensar. O modelo foi constituído
de forma independente, com participação da indústria, do governo norte-americano
e do Instituto de Engenharia de Software (SEI) da Carnegie Mellon University (CMU).
CMMI é o sucessor do modelo CMM (Capability Maturity Model), que foi
desenvolvido entre 1987 e 1997. Em 2002 foi lançada a versão 1.1 do CMMI, e, em
novembro de 2010, a versão 1.3.
A versão atual do CMMI possui três vertentes:
a) CMMI para aquisição (CMMI-ACQ): provê diretrizes para suporte às
decisões relacionadas à aquisição de produtos e serviços;
b) CMMI para desenvolvimento (CMMI-DEV): provê diretrizes para
monitorar, mensurar e gerenciar processos de desenvolvimento;
c) CMMI para serviços (CMMI-SVC): provê diretrizes para entrega de
serviços dentro das organizações e para clientes externos.
Os modelos CMMI podem ser usados como guias para desenvolver e
melhorar processos da organização, e também como um framework para avaliar a
maturidade dos processos da organização.
CMMI se originou na indústria de software, mas também tem sido adaptado
a outras áreas, como a indústria de hardware, serviços e comércio em geral. O
termo “software” sequer aparece nas definições de CMMI, o que torna o modelo bem
mais abrangente do que seu predecessor, o CMM.
Existem duas representações do CMMI, a representação contínua e a
representação em estágios. A representação contínua é projetada para permitir à
empresa focar em processos específicos que deseja melhorar em função de suas
prioridades. Já a representação em estágios é aplicada à organização como um todo
e permite que se compare a maturidade de diferentes organizações.
Os principais componentes da estrutura do CMMI estão representados na
Figura 6 e definidos a seguir:
31
Figura 6: Componentes da estrutura do CMMI-DEV
Fonte: SEI (2010b, p. 36).
2.5.2 Modelo ISO/IEC 9126
Conforme Pressman (2007, p. 362) o ISO/IEC 9126 trata da avaliação do
produto de software, do ponto de vista das suas características de qualidade. A
norma é aplicável para quem faz aquisição e/ou de desenvolvimento de software,
usuários, assim como para quem fornece suporte, manutenção ou realiza auditoria
de software.
Esta norma não é aplicada com o objetivo de obter uma certificação através
de um esquema de reconhecimento mútuo. A norma sugere sua aplicação nas
seguintes situações:
- definir os requisitos de qualidade do software;
- avaliar especificações de software para verificar se satisfazem os
requisitos de qualidade durante o desenvolvimento;
- descrever características e atributos do software implementado;
- avaliar o software desenvolvido antes de ser entregue;
- avaliar o software antes da aceitação.
Segundo Pressman (2007, p. 363) a norma sugere a avaliação dos atributos
da
qualidade
do
software
relacionados
a
Funcionalidade,
Confiabilidade,
Usabilidade, Eficiência, Manutenibilidade e Portabilidade.
Funcionalidade: um conjunto de atributos que satisfazem necessidades
implícitas e explícitas.
32
Os subconjuntos de requisitos de qualidade funcionais são:
- adequabilidade;
- exatidão;
- interoperabilidade;
- conformidade;
- segurança.
Confiabilidade: um conjunto de atributos relacionados à capacidade do
software de manter seu nível de desempenho, conforme as condições estabelecidas
por um período de tempo estabelecido.
Subconjuntos de requisitos de qualidade de confiabilidade são:
- maturidade;
- tolerância a falhas;
- capacidade de recuperação.
Usabilidade: um conjunto de atributos relacionados ao esforço para usar o
software ou na avaliação individual de tal uso, por um ou mais usuários.
Subconjuntos de requisitos de qualidade de usabilidade são:
- facilidade de entendimento;
- facilidade de aprendizagem;
- facilidade de operação.
Eficiência: um conjunto de atributos que dizem respeito à relação entre o
nível de desempenho do software e à quantidade de recursos usada, sob condições
estabelecidas.
Subconjuntos de requisitos de qualidade de eficiência são:
- comportamento do tempo;
- comportamento de recursos.
Facilidade de manutenção: um conjunto de atributos relacionados ao
esforço necessário para realizar modificações específicas.
Subconjuntos de requisitos de qualidade de facilidade de manutenção são:
- facilidade de análise;
- facilidade de mudança;
- estabilidade;
- facilidade de teste.
Portabilidade: um conjunto de atributos de software relacionados à
habilidade do software ser transferido de um ambiente para outro.
33
Subconjuntos de requisitos de qualidade de portabilidade são:
- capacidade de adaptação;
- facilidade de instalação;
- nível de conformidade;
- facilidade de substituição.
2.5.3 Modelo MPS
Conforme o Guia de Avaliação (2009, p. 6), busca-se que o modelo MPS
seja apropriado ao perfil de empresas com tamanhos desiguais e qualidades,
privadas e públicas, apesar de que com específico cuidado às micro, pequenas e
médias empresas. Também se acredita que o modelo MPS seja compatível com os
padrões de qualidade aceitos internacionalmente e que traga como pressuposto a
aplicação de toda a capacidade existente nos modelos de avanço de processo já
disponíveis. Ele apresenta como base os requisitos de processos definidos nos
exemplos de avanço de processo e recebe a obrigação de inserir os princípios de
engenharia de software de forma acertada ao assunto das empresas, ficando em
acordo com as principais abordagens internacionais para definição, avaliação e
melhoria de processos de software.
34
3 PROJETO MPS.BR
O programa MPS.BR é uma iniciativa brasileira para melhoria contínua de
processos de software criado em dezembro de 2003. O MPS.BR tem como uma de
suas metas definir e aperfeiçoar um modelo de avanço e avaliação de processo de
software, focando preferencialmente as micro, pequenas e médias empresas, de
forma a atender suas necessidades de negócios e ser reconhecido nacional e
internacionalmente como um modelo aplicável à indústria de software.
A Softex – Associação para Promoção da Excelência do software Brasileiro,
é responsável pela coordenação do Programa MPS.BR e conta com o apoio do
Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos
(FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e
Banco Internacional de Desenvolvimento (BID).
Segundo Guia Geral de Software (2012, p. 13) o MPS.BR é constituído dos
seguintes componentes: Modelo de Referência (MR-MPS); Método de Avaliação
(MA-MPS); e Modelo de Negócio (MN-MPS). O MR-MPS tem como base técnica as
normas ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 20000 e o modelo CMMI-DEV. O
MA-MPS tem como base técnica a norma ISO/IEC 15504. Cada um é constituído de
guias e documentos que permitem a implementação/avaliação dos projetos de
melhoria de processos.
A Figura 7 apresenta o Programa MPS.BR e seus componentes:
Figura 7: Componentes do programa MPS.BR
Fonte: Guia Geral de Software (2012, p. 14).
35
Conforme o Guia Geral de Software (2012, p. 14), a finalidade do projeto
MPS.BR é o melhoramento de processos do software brasileiro, para alcançar suas
metas a médio e longo prazo temos:
a) uma
meta
técnica,
que
tende
essencialmente
a
concepção
e
aperfeiçoamento do modelo MPS;
b) qualquer meta de negócio, apontando à dispersão e adoção do modelo
MPS, em todas as regiões, em um período de tempo justo.
3.1 BASE TÉCNICA PARA A DEFINIÇÃO DOS COMPONENTES DO MPS.BR
Diversos modelos de processos de desenvolvimento de software surgiram
nos últimos anos como, por exemplo, os apresentados pelos padrões ISO/IEC
12207, ISO/IEC 15504 e ISO/IEC 20000.
3.1.1 ISO/IEC 12207:2008
A Norma ISO/IEC 12207 foi criada pela ISO – The International Organization
for Standardization e o IEC - International Electrotechnical Commission dentro de um
esforço conjunto dessas organizações.
Conforme Rocha, Maldonado e Weber (2001, p. 12), ISO/IEC 12207 – Esse
padrão internacional ou modelo de referência chamado de Processo do Ciclo de
Vida do Software e tem como objetivo fundamental fornecer uma estrutura
excepcional para que o adquirente, fornecedor, desenvolvedor, mantenedor,
operador, gerentes e técnicos envolvidos com o desenvolvimento de software usem
uma linguagem comum que é constituída na forma de processos bem marcantes.
Em 1988, deu início ao desenvolvimento da norma e em agosto de 1995 ela
foi divulgada como norma internacional. Em 1998, foi divulgada a sua versão
brasileira que tem o nome igual a internacional, apenas acrescentada as iniciais
NBR.
Conforme Lima (2013, p. 42), a ISO/IEC 12207 estabelece 5 processos
fundamentais, 8 processos de apoio, 4 processos organizacionais e um processo de
adaptação, totalizando 18 processos, conforme apresentado na Figura 8.
36
Figura 8: Processos do ciclo de vida de software
Fonte: Rocha, Maldonado e Weber (2001, p. 13).
Segundo Bischoff (2008, p. 63) os 18 processos da ISO/IEC 12207 estão
arranjados em 4 classes de processos com o objetivo específico, conforme a lista a
seguir:
I. Classe dos processos fundamentais: são os processos constituídos pelas
atividades essenciais de início e execução para o desenvolvimento, operação e a
manutenção no ciclo de vida do software. Os processos fundamentais definidos na
norma são:
- processo de aquisição: atividade do adquirente;
- processo de fornecimento: atividade do fornecedor;
- processo de operação: atividade do operador;
- processo de manutenção: atividade do mantenedor.
II. Classe dos processos de apoio: são os processos constituídos por
atividades que auxiliam processos fundamentais ou organizacionais. Essa classe é
composta pelos processos de documentação, gerência de configuração, garantia de
qualidade, verificação, validação, revisão conjunta e resolução de problemas.
III. Classe dos processos organizacionais: esses processos são formados
pelas atividades para estabelecer e implementar uma estrutura constituída dos
processos do ciclo de vida e pessoal envolvido no desenvolvimento do software.
Nessa classe são definidos os processos de gerência, infraestrutura, melhoria e
treinamentos.
IV. Classe do processo de adaptação: atividades elementares para adaptar a
norma de forma a viabilizar a sua aplicação na organização ou em projetos, como
37
por exemplo: estratégia de aquisição, ciclo de vida de projetos, cultura
organizacional, técnicas de desenvolvimento, características de produtos e serviços
de software.
É possível também que nem todas as etapas do ciclo de vida ocorram para
um determinado software. Exemplo disso é quando se pretende adquirir um
programa já pronto, o que exclui a fase de desenvolvimento.
3.1.2 ISO/IEC 15504
Segundo Anacleto et al. (2003, p. 2), o modelo de referência ISO/IEC 15504
também conhecido como SPICE, foi desenvolvido como um framework para ter uma
avaliação de processos de engenharia de software e do arranjo do projeto e do
negócio. É organizado e classificado como as melhores técnicas em duas extensões
que são: nível de capacidade e categoria de processos. Ultimamente a norma é
comum podendo ser usada por diferentes tipos de processos, não estando mais
excepcionalmente dedicada a software. Apesar disso, sua principal finalidade é o
avanço e a avaliação dos processos, nos dois casos três elementos fundamentais
devem ser exatamente definidos para que a avaliação de processos seja alcançada
conforme a ISO/IEC 15504, sendo:
1. os processos: devem ser verificados por um avaliador competente,
segundo os requisitos previstos na norma;
2. uma escala de medida: deve ter como referência um modelo de avaliação
de processos compatível;
3. um método de medição: deve ser realizado seguindo um processo
compatível.
Com novas opiniões a ISO/IEC 15504 foi disponibilizado um padrão de
referência de processo PRM (Process Reference Model). Este padrão criou uma
arquitetura como padrão de referência de método com duas dimensões: Dimensões
de Processo e Dimensão da Capacidade do Processo.
 Dimensão de processo
Conforme Maciel, Valls e Savoine (s.d., p. 5), é constituído por cinco
categorias avaliadas como essenciais para uma adequada prática da engenharia de
software. As categorias da dimensão de processos são:
38
- CON – consumidor e fornecedor: tem um impacto direto sobre os
consumidores;
- ENG – engenharia: esta categoria agrupa os processos que levam à
implementação do produto;
- SUP – suporte: seus processos dão suporte e apoio aos demais
processos da organização;
- MAN – administração: na categoria de gerência estão incluídos os
processos que de forma genérica podem ser usados na administração de
todo outro processo ou do projeto em si;
- ORG – organização: inclui todos os processos organizacionais da
empresa como infraestrutura.
A dimensão de capacidade permite uma avaliação mais detalhada dos
processos executados por uma organização. Enquanto a dimensão de
processo se limita à verificação de execução ou não dos processos, a
dimensão de capacidade leva a uma avaliação de níveis semelhantes aos
do CMMI (KOSCIANSKI; SOARES, 2007, p. 177).
A ISO/IEC 15504 também define seis níveis de capacidade que são
mostradas na Tabela 2.
Tabela 2: Níveis da ISO/IEC 15504
NÍVEL
NOME
0
Incompleto
1
Executado
2
Gerenciado
3
Estabelecido
4
Previsível
5
Otimizado
DESCRIÇÃO
O processo não é implementado ou falha em atingir seus
objetivos.
O processo essencialmente atinge os objetivos, mesmo se de
forma planejada ou rigorosa.
O processo é implementado de forma controlada (planejado,
monitorado e ajustado); os produtos por ele criados são
controlados e mantidos de forma apropriada.
O processo é implementado de forma sistemática e consistente.
O processo é executado e existe um controle que permite
verificar se ele se encontra dentro dos limites estabelecidos para
atingir os resultados.
O processo é adaptado continuamente para, de uma forma mais
eficiente, atingir os objetivos de negócio definidos e projetados.
Fonte: Koscianski e Soares (2007, p. 178).
39
Cada um doa níveis apresentados possui incluídos os atributos de processo
que são aplicáveis a todos os processos.
O modelo de referência ISO/IEC 15504 é compatível com CMMI (Capability
Maturity Model Integration).
3.1.3 ISO/IEC 20000
Segundo Guia Geral de Software (2012, p.16), a norma ISO/IEC 20000
[ISO/IEC, 2011] publicada em dezembro de 2005 tem como finalidade fornecer um
padrão de referência comum para uma empresa proporcionar serviços de TI para
clientes internos ou externos. Esta norma fornece a adoção de um enfoque de
processos associada para a gestão de serviços de TI e alinha-se com os melhores
métodos do ITIL para entrega e suporte de serviços. A ISO/IEC 20000 incide em
cinco elementos, sob o título geral Tecnologia da Informação – Gerenciamento de
Serviços.
Segundo o Guia Geral de Software (2012, p.16), a ISO/IEC 20000-1 aponta
ao provedor de serviços as condições para projetar, estabelecer, implementar, atuar,
monitorar, revisar, sustentar e aperfeiçoar o GSTI (Gerenciamento de Serviços de
TI). As condições contêm o projeto, mudança, entrega e avanço dos serviços para
acatar as condições antecipadamente acordados. A ISO/IEC 20000-2 concebe um
acordo do setor sobre padrões de qualidade em processos de GSTI e apresenta as
melhores práticas para esses processos [ISO/IEC, 2011]. A ISO/IEC TR 20000-3
abastece orientações, explicações e indicações para a definição do escopo,
aplicabilidade e demonstração da conformidade com a ISO/IEC 20000-1 pelo uso de
exemplos
práticos.
A
ISO/IEC
20000-4
tem
como
finalidade
facilitar
o
desenvolvimento de um modelo para avaliação de processo de acordo com a norma
ISO/IEC 15504. O modelo de referência de processo, previsto nesta norma, é um
perfil lógico dos dados dos processos para o gerenciamento de serviços que podem
ser aplicados em um nível básico. Todo processo é descrito em termos de uma
finalidade e resultados associados. A ISO/IEC 20000-5 expõe um exemplo de plano
de prática no qual são fornecidos guias para os provedores de serviços acatarem
aos requisitos da ISO/IEC 20000-1.
40
3.1.4 MPS.BR e suas Estruturas de Apoio
O programa MPS.BR conta com duas estruturas de apoio para o
desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC)
e a Equipe Técnica do Modelo (ETM). Por meio destas estruturas, o MPS.BR obtém
a participação de representantes de universidades, instituições governamentais,
centros de pesquisa e de organizações privadas, os quais contribuem com suas
visões complementares que agregam qualidade ao empreendimento.
Cabe ao FCC:
- emitir parecer que subsidie decisão da SOFTEX sobre o credenciamento
de Instituições Implementadoras (II) e Instituições Avaliadoras (IA);
- monitorar
os
resultados
das
Instituições
Implementadoras
(II)
e
Instituições Avaliadoras (IA), emitindo parecer propondo à SOFTEX o seu
descredenciamento no caso de comprometimento da credibilidade do
modelo MPS.
Cabe à ETM apoiar a SOFTEX sobre os aspectos técnicos relacionados ao
Modelo de Referência (MR-MPS) e Método de Avaliação (MA-MPS), para:
- criação e aprimoramento contínuo do MR-MPS, MA-MPS e seus guias
específicos;
- capacitação de pessoas por meio de cursos, provas e workshops.
3.2 DESCRIÇÃO DOS MODELOS MPS
O MPS.Br conta com um modelo de referência, o MR-MPS e também com
um método de avaliação, que é o MA-MPS, além de ter um modelo de negócio que é
o MN-MPS, o segundo foi criado porque existem empresas que terão de fazer a
análise e avaliação de como as empresas que estão fazendo parte do MPS.Br estão
agindo.
3.2.1 Descrição do Modelo de Referência MR-MPS
Segundo o Guia Geral de Software (2012, p. 17), o Modelo de Referência
MPS (MR-MPS) determina níveis de maturidade que é um ajuste entre processos e
sua capacidade.
41
Conforme o Guia Geral de Software (2012, p. 17), o significado dos
processos segue a forma exposta no modelo de referência ISO/IEC 15504-2,
afirmando a intenção e os resultados esperados de sua execução. Isso admite
avaliar e atribuir graus de efetividade no cumprimento dos processos. As atividades
e serviços necessários para atender ao propósito e aos resultados aguardados não
são determinadas mas sim carecem ficar a cargo dos usuários do MR-MPS.
Capacidade do processo é a diferenciação da habilidade do processo para
conseguir os objetivos de negócios, atuais e futuros; permanecendo relacionada
com o acolhimento das características de processos associados aos processos de
cada nível de maturidade.
3.2.2 Descrição do Modelo de Avaliação MA-MPS
Segundo o Guia Geral de Software (2012, p. 18), é composto basicamente
pelos requisitos do método, atividade do método, indicadores para avaliação e
características da qualificação dos avaliadores. Este método permite a realização de
avaliação em unidades organizacionais segundo o modelo MPS.
O processo de avaliação é composto por quatro fases: Preparação e
planejamento, condução da avaliação, Resultados e certificação.
3.2.3 Descrição do Modelo de Negócio MN-MPS
Segundo o Guia Geral de Software (2009, p. 45), o modelo MPS estabelece
um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras
desenvolvedoras de software.
O modelo de negócio contém descrição de regras de negócios para
implementação do MR-MPS pelas instituições implementadoras, avaliação seguindo
o MA-MPS pelas instituições avaliadoras.
42
4 PROCESSO MPS.BR
Segundo o Guia Geral de Software (2012, p. 18), os processos no MPS-BR
são descritos em termos de propósito e resultados. O propósito descreve o objetivo
geral a ser atingido durante a execução do processo.
Os resultados esperados do processo constituem os resultados a serem
alcançados com a efetiva prática do processo. Estes resultados podem ser
confirmados por um produto de trabalho determinado ou uma alteração expressiva
de estado ao se executar o processo.
4.1 CAPACIDADE DO PROCESSO
Segundo o Guia Geral de Software (2012, p. 18), a capacidade do processo
é representada por um conjunto de atributos de processo descrito em termos de
resultados esperados. A capacidade do processo expressa o grau de refinamento e
institucionalização com que o processo é executado na organização/unidade
organizacional.
No
MR-MPS-SW,
à
medida
que
a
organização/unidade
organizacional evolui nos níveis de maturidade, um maior nível de capacidade para
desempenhar o processo deve ser atingido.
Os diferentes níveis de capacidade dos processos são descritos por nove
atributos de processos (AP) descritos a seguir:
- AP 1.1 – o processo é executado: este atributo confirma o quanto o
processo chega ao seu propósito;
- AP 2.1 – o processo é gerenciado: este atributo confirma o quanto a
execução do processo é gerenciada;
- AP 2.2 – os produtos de trabalho do processo são gerenciados: este
atributo confirma o quanto os produtos de trabalho produzidos pelo
processo são gerenciados apropriadamente;
- AP 3.1 – o processo é definido: este atributo confirma o quanto um
processo padrão é sustentado para apoiar a prática do processo definido;
- AP 3.2 – o processo está implementado: este atributo confirma o quanto o
processo padrão é efetivamente praticado como um processo definido
para chegar aos seus resultados;
43
- AP 4.1 – o processo é medido: este atributo confirma o quanto os
resultados de avaliação são usados para certificar que a execução do
processo alcance os seus objetivos de performance e apoia o alcance dos
objetivos de negócio definidos;
- AP 4.2 – o processo é controlado: este atributo confirma o quanto o
processo é controlado estatisticamente para produzir um processo
durável, capaz e previsível dentro dos limites constituídos;
- AP 5.1 – o processo é objeto de melhorias incrementais e inovações: este
atributo confirma o quanto as alterações no processo são identificadas a
partir do exame de defeitos, problemas, causas comuns de alteração do
desempenho e da busca de aspectos inovadores para a definição e
prática do processo;
- AP 5.2 – o processo é otimizado continuamente: este atributo confirma
como as alterações na definição, gerência e desempenho do processo
têm impacto essencial para a obtenção dos objetivos acentuados do
avanço do processo.
4.1.1 Atributos de Processo
Segundo o Guia Geral de Software (2012, p. 24), os atributos do processo
são nove (9) e são eles que descrevem o nível de capacidade do processo. O
atendimento aos atributos do processo (AP), pelo atendimento aos resultados
esperados dos atributos do processo (RAP), é requerido para todos os processos no
nível correspondente ao nível de maturidade, embora eles não sejam detalhados
dentro de cada processo. Esses níveis são acumulativos, ou seja, se a organização
está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos
de processo dos níveis G e F para todos os processos relacionados no nível de
maturidade F (que também inclui os processos de nível G). Em outras palavras, na
passagem para um nível de maturidade superior, os processos anteriormente
implementados devem passar a ser executados no nível de capacidade exigido
neste nível superior.
Na Tabela 3 são descritos os níveis de maturidade, os processos de cada
um deles e também os atributos apropriados.
44
Tabela 3: Níveis de maturidade do MR-MPS
Fonte: Guia Geral de Software (2012, p. 24).
4.1.2 Exclusão de Processos
Conforme Guia Geral de Software (2012, p. 24), determinados processos
podem ser excluídos, absoluta ou parcialmente, do escopo de uma avaliação MPS
por não serem pertinentes ao negócio da unidade organizacional que está sendo
avaliada. Toda exclusão necessita ser justificada no Plano de Avaliação. O
consentimento das exclusões e suas justificativas é de responsabilidade do
Avaliador Líder.
4.2 NÍVEIS DE MATURIDADE
Os níveis de maturidade colocam patamares de desenvolvimento de
processos, distinguindo estágios de avanço da implementação de processos na
45
organização. O nível de maturidade em que se encontra uma organização aceita
prever a sua performance no futuro ao executar um ou mais processos.
Segundo Guia Geral de Software (2012, p. 26), o MR-MPS-SW determina
sete níveis de maturidade: G (Gerenciado Parcialmente), F (Gerenciado), E (Definido
Parcialmente),
D
(Definido
Largamente),
C
(Definido),
B
(Gerenciado
Quantitativamente) e A (Otimização). A escala de maturidade tem início no nível G e
progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído
um perfil de processos que recomendam onde a organização necessita colocar o
empenho do progresso. A melhoria e a obtenção de um determinado nível de
maturidade do MR-MPS-SW se obtêm porque são atendidas as finalidades e todos
os resultados esperados dos respectivos processos e os resultados esperados das
características de processo constituídos para aquele nível.
A separação em 7 estágios tem a finalidade de permitir uma prática e
avaliação apropriada às micros, pequenas e médias empresas. A possibilidade de se
realizar avaliações considerando mais níveis ainda permite uma visibilidade dos
resultados de avanço de processos em tempos mais curtos.
4.2.1 Nível G – Parcialmente Gerenciado
O nível de maturidade G é composto pelos processos Gerência de Projetos
e Gerência de Requisitos. Neste nível a implementação dos processos deve
satisfazer os atributos de processo AP 1.1 e AP 2.1.
 GERÊNCIA DE PROJETOS - GPR
O propósito do processo Gerência de Projetos é estabelecer e manter
planos que definem as atividades, recursos e responsabilidades do projeto, bem
como prover informações sobre o andamento do projeto que permitam a realização
de correções quando houver desvios significativos no desempenho do projeto. O
propósito deste processo evolui à medida que a organização cresce em maturidade.
Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de
forma que a gerência de projetos passe a ser realizada com base no processo
definido para o projeto e nos planos integrados. No nível B, a gerência de projetos
passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da
organização. Novamente, alguns resultados evoluem e outros são incorporados.
46
 GERÊNCIA DE REQUISITOS – GRE
O propósito do processo Gerência de Requisitos é gerenciar os requisitos do
produto e dos componentes do produto do projeto e identificar inconsistências entre
os requisitos, os planos do projeto e os produtos de trabalho do projeto.
4.2.2 Nível F – Gerenciado
O nível de maturidade F é constituído pelos processos do nível de
maturidade anterior (G) acrescentados dos processos Aquisição, Garantia da
Qualidade, Gerência de Configuração, Gerência de Portfólio de Projetos e Medição.
Neste nível a prática dos processos precisam satisfazer as características de
processo AP 1.1, AP 2.1 e AP 2.2.
 AQUISIÇÃO – AQU
A
finalidade
do
processo
Aquisição
é
gerenciar
o
alcance
de
produtos/serviços que atendam às obrigações expressas pelo adquirente.
 GERÊNCIA DE CONFIGURAÇÃO – GCO
A finalidade do processo Gerência de Configuração é colocar e sustentar a
integridade de todos os produtos de trabalho de um processo ou projeto e
disponibilizá-lo a todos os envolvidos.
 GARANTIA DA QUALIDADE – GQA
A finalidade do processo Garantia da Qualidade é garantir que os produtos
de trabalho e a execução dos processos permaneçam em acordo com os planos,
procedimento e padrões constituídos.
 GERÊNCIA DE PORTFÓLIO DE PROJETOS – GPP
A finalidade do processo Gerência de Portfólio de Projetos é dar início e
sustentar projetos que sejam necessários, suficientes e sustentáveis, de forma a
atender as finalidades estratégicas da organização.
Este processo compromete o investimento e os recursos organizacionais
apropriados e coloca a autoridade necessária para executar os projetos escolhidos.
É nele que e executado a qualificação contínua de projetos para confirmar que eles
justificam o prosseguimento dos investimentos, ou podem ser redirecionados para
justificar.
47
 MEDIÇÃO – MED
A finalidade do processo Medição é coletar, armazenar, analisar e relatar os
dados relativos aos produtos desenvolvidos e aos processos implementados na
organização e em seus projetos, de forma a apoiar os objetivos organizacionais.
4.2.3 Nível E – Parcialmente Definido
O nível de maturidade E é composto pelos processos dos níveis de
maturidade anteriores (G e F), acrescidos dos processos Avaliação e Melhoria do
Processo Organizacional, Definição do Processo Organizacional, Gerência de
Recursos Humanos e Gerência de Reutilização. O processo Gerência de Projetos
sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com
base no processo definido para o projeto e nos planos integrados. Neste nível a
implementação dos processos deve satisfazer os atributos de processo AP 1.1, AP
2.1, AP 2.2, AP 3.1 e AP 3.2.
 AVALIAÇÃO E MELHORIA DO PROCESSO ORGANIZACIONAL – AMP
A finalidade do processo Avaliação e Melhoria do Processo Organizacional é
definir como os processos padrão da organização colaboram para obter os objetivos
de negócio da organização e para apoiar a organização a planejar, conseguir e
implantar avanços contínuos nos processos com base no entendimento de seus
pontos fortes e fracos.
 DEFINIÇÃO DO PROCESSO ORGANIZACIONAL – DFP
A finalidade do processo Definição do Processo Organizacional é colocar e
sustentar um conjunto de ativos de processo organizacional e padrões do ambiente
de trabalho utilizáveis e aplicáveis às obrigações de negócio da organização.
 GERÊNCIA DE RECURSOS HUMANOS – GRH
A finalidade do processo Gerência de Recursos Humanos é ministrar a
organização e os projetos com os recursos humanos necessários e sustentar suas
capacidades apropriadas às necessidades do negócio.
 GERÊNCIA DE REUTILIZAÇÃO – GRU
A finalidade do processo Gerência de Reutilização é gerenciar o período de
vida dos ativos reutilizáveis.
48
4.2.4 Nível D – Largamente Definido
O nível de maturidade D é composto pelos processos dos níveis de
maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de
Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação, e
Verificação. É neste nível que acontece a implementação dos processos que precisa
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.
 DESENVOLVIMENTO DE REQUISITOS – DRE
A finalidade do processo Desenvolvimento de Requisitos é determinar as
condições do cliente, do produto e dos componentes do produto.
 INTEGRAÇÃO DO PRODUTO – ITP
A finalidade do processo Integração do Produto é compor os componentes
do produto, produzindo um produto integrado consistente com seu projeto, e
demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o
ambiente alvo ou equivalente.
 PROJETO E CONSTRUÇÃO DO PRODUTO – PCP
A finalidade do processo Projeto e Construção do Produto é projetar,
desenvolver e implementar recursos para atender as condições.
 VALIDAÇÃO – VAL
A finalidade do processo Validação é confirmar que um produto ou elemento
do produto atenderá a seu uso desejado quando posto no ambiente para o qual foi
desenvolvido.
 VERIFICAÇÃO – VER
A finalidade do processo Verificação é confirmar que todo serviço e/ou
produto de trabalho do processo ou do projeto acata apropriadamente os requisitos
especificados.
4.2.5 Nível C – Definido
O nível de maturidade C é composto pelos processos dos níveis de
maturidade anteriores (G ao D), acrescidos dos processos Desenvolvimento para
Reutilização, Gerência de Decisões e Gerência de Riscos. Neste nível a
49
implementação dos processos deve satisfazer os atributos de processo AP 1.1, AP
2.1, AP 2.2, AP 3.1 e AP 3.2.
 DESENVOLVIMENTO PARA REUTILIZAÇÃO – DRU
A finalidade do processo Desenvolvimento para Reutilização é identificar
ocasiões de reutilização sistemática de ativos na organização e, se possível, formar
um programa de reutilização para desenvolver ativos a partir de engenharia de
domínios de aplicação.
 GERÊNCIA DE DECISÕES – GDE
A finalidade do processo Gerência de Decisões é analisar possíveis
decisões críticas usando um processo formal, com critérios estabelecidos, para
avaliação das alternativas identificadas.
 GERÊNCIA DE RISCOS – GRI
A finalidade do processo Gerência de Riscos é identificar, analisar, tratar,
monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.
4.2.6 Nível B – Gerenciado Quantitativamente
Este nível de maturidade é composto pelos processos dos níveis de
maturidade anteriores (G ao C). É neste nível que o processo de Gerência de
Projetos sofre sua segunda evolução, sendo acrescentados novos resultados para
atender aos objetivos de gerenciamento quantitativo. Neste nível a implementação
dos processos deve atender os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1
e AP 3.2 e os RAP 22 a RAP 25 do AP 4.1. A prática dos processos escolhidos para
análise de desempenho deve atender totalmente os atributos de processo AP 4.1 e
AP 4.2.
Este nível não possui processos específicos.
4.2.7 Nível A – Em Otimização
Este nível de maturidade é composto pelos processos dos níveis de
maturidade anteriores (G ao B). Neste nível a implementação dos processos deve
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2 e os RAP
22 a RAP 25 do AP 4.1. A implementação dos processos selecionados para análise
50
de desempenho deve satisfazer integralmente os atributos de processo AP 4.1 e AP
4.2. Os atributos de processo AP 5.1 e AP 5.2 devem ser integralmente satisfeitos
pela implementação de pelo menos um dos processos selecionados para análise de
desempenho.
Este nível não possui processos específicos.
4.3 CUSTOS
Segundo site WIKIPÉDIA (2014), o custo de uma certificação para uma
empresa pode ser de até US$ 400 mil, o que se torna inviável; para empresas de
micro, pequeno e médio porte.
Na Tabela 4 é demostrado os custos de cada nível de maturidade.
Tabela 4: Custos níveis MPS-BR
Custo de
Nível MPS.BR
Implementação (R$)
Nível G
58.000,00
41.000,00 - com nível G antes
Nível F
100.000,00 - direto no F
Nível E
83.500,00 - com G antes
125.000,00 - com G antes
Nível D
83.500,00 - com F antes
83.500,00 - com G antes
Nível C
58.000,00 - com E antes
Nível B
58.000,00 - com C antes
Nível A
58.000,00 - com B antes
Fonte: Softex (2014).
Taxa de
Avaliação (R$)
2.500,00
Custo de
Avaliação (R$)
15.000,00
3.000,00
20.000,00
3.800,00
25.100,00
5.000,00
31.700,00
5.800,00
35.100,00
6.700,00
7.500,00
40.160,00
45.200,00
51
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO COM
NÍVEL G DO MPS.BR EM UMA EMPRESA DE PEQUENO PORTE
Nesta parte, será apresentado o estudo de caso e as fundamentais
atividades que foram executadas para conseguir o avanço do processo de
desenvolvimento de software da empresa, ainda será mostrado os resultados do
estudo, método definido e seu nível de ação.
5.1 TIPO DE PESQUISA
O método empregado é um estudo de caso, cujos dados se compõe de
informações colhidas por meio de um questionário que foi aplicado na empresa no
setor de desenvolvimento de software. Foi baseado esse estudo em teorias
tecnológicas como Pressman, Softex, Sommerville, Wazlawick, dentre outros que
deram sustento a concretização da pesquisa.
5.2 PROCESSOS METODOLÓGICOS
A pesquisa foi realizada entre agosto de 2013 a junho de 2014.
Foi realizada uma revisão bibliográfica sobre os aspectos da engenharia de
software, qualidade de software, melhoria do processo de software e normas. Para
isso foi consultado livros, teses, monografias disponibilizadas na internet e na
literatura. Logo em seguida, procurou-se conhecer a empresa de um modo geral
com reuniões ou documentos obtidos.
Para conseguir os dados do modelo atual da empresa uma metodologia foi
empregada. Foi elaborado um questionário que as perguntas apresentavam a
finalidade de identificar os resultados aguardados no processo do MPS.BR que
estão conforme (Anexo A). O questionário foi formado de acordo com o Guia de
Implementação – Parte 1 [MR-MPS:2012] do nível G. Com isso, poderia se
comparar o estado atual com o estado almejado, que é o nível Parcialmente
Gerenciado.
Busca-se avaliar e descrever o processo de desenvolvimento de software da
empresa, focalizando nas implantações de avanços usando o modelo MPS.BR.
52
5.3 DEFINIÇÃO DA EMPRESA
Para a realização do estudo, foi selecionada uma empresa da área de
desenvolvimento de software que se chama HPR Informática, está instalada na
cidade de Chiapetta – Rio Grande do Sul.
Um de seus principais ramos de atuação é o desenvolvimento de software,
mas também trabalha com assistência técnica de computadores, a empresa se
destaca pelo uso distinto da informática com empenho com as metas e resultados
que acarretam grandes mudanças gerando retornos financeiros e operacionais para
os clientes. A maioria dos produtos desenvolvidos são voltados para setores de
automação comercial.
A empresa tem uma equipe de desenvolvimento formada por 6 pessoas,
podemos descrever a equipe sendo formada pelo seguinte organograma em três
níveis. Primeiro nível, diretoria, segundo os desenvolvedores e no terceiro a equipe
de suporte.
Apesar da empresa ter mais de 20 anos de atividades no mercado, é
possível apontar várias falhas. Podemos destacar as seguintes falhas:
- Gerência de projetos primitivo;
- Gerência de requisitos rudimentar;
- Os prazos das tarefas são estimados com dificuldades.
Pelo motivo da empresa ter poucos funcionários na área de desenvolvimento
não poderá ser alocado muitas pessoas para o projeto de mudança.
Na empresa existe dois tipos de atividades para o desenvolvimento de
software. A primeira é desenvolver um novo produto e a partir daí é identificada as
necessidades do mesmo. Segundo é depois que acontece o primeiro contato com o
cliente e é apresentado o produto e a partir disso é feito as mudanças conforme a
necessidade de cada um.
5.4 PROCESSO ATUAL
Embora a empresa possua um processo determinado, esse não era
unificado
para
o
desenvolvimento
de
software.
Não
existindo
qualquer
institucionalização do uso desse procedimento, tão pouco havia documentação
específica a ser aplicada ao produto durante todo o seu desenvolvimento.
53
A metodologia de desenvolvimento de software ficava concentrada na
capacidade e conhecimento de seus colaboradores, sendo assim, não havia uma
formalização e documentação apropriada para um bom emprego dos métodos neles
contidos. Todo conhecimento estava limitado individualmente.
Acredita-se que com a implantação do MPS.BR nível G, a gerência consiga
um controle maior sobre o projeto e as condições fiquem controladas de forma
apropriada. Esse alvo só será possível com a motivação da equipe toda.
5.5 IMPLEMENTAÇÕES
Para se adaptar a metodologia e atender as reivindicações do modelo MPSBR nível G a empresa foi submetida a alguns reajustes como os citados a seguir:
- Descrição dos processos: para conseguir o MPS.BR nível G a empresa
necessita ter implantado os processos de Gerência de Projetos e
Gerência de Requisitos;
- Processo de fornecimento: apresenta as atividades a serem alcançadas
antes de se ter o valor a ser cobrado pelo projeto requerido. A finalidade
deste processo é avaliar a solicitação recebida para conseguir o valor a
ser cobrado pelo projeto mais próximo possível do desejado;
- Planejamento do projeto: o objetivo é o planejamento do projeto em
todas as suas etapas, é nesta etapa onde acontece o planejamento do
sistema a ser desenvolvido, o esforço, prazos, como ocorrerá a
monitoração;
- Gerência de mudanças de requisitos: o objetivo é assegurar que
qualquer mudança nos requisitos do sistema seja analisada de forma que
o impacto das mudanças seja conhecido e tratado.
5.6 RESULTADOS ESPERADOS COM A IMPLEMENTAÇÃO
Segundo Guia Geral de Software (2012, p. 26), com a implementação do
MPS.BR Nível G tentamos chegar nos seguintes resultados com os processos de
Gerência de Projetos e Gerência de Requisitos:
Gerência de Projetos.
54
- GPR 1: definição da finalidade do projeto;
- GPR 2: as tarefas e os produtos de trabalho do projeto são
dimensionados utilizando métodos apropriados;
- GPR 3: o ciclo de vida e o modelo do projeto são definidos;
- GPR 4: a possibilidade de atingir as metas do projeto, levando em conta
as restrições e os recursos disponíveis, é avaliada. Se necessário ajuste
são realizados;
- GPR 5: o orçamento e o cronograma do projeto, incluindo a definição de
marcos e pontos de controle, são estabelecidos e mantidos;
- GPR 6: o cronograma e o orçamento do projeto são estabelecidos e
mantidos;
- GPR 7: os riscos do projeto são identificados, probabilidade de ocorrência
e prioridades de tratamento são determinados e documentados;
- GPR 8: os recursos e o ambiente de trabalho necessários para executar o
projeto são planejados;
- GPR 9: os recursos humanos para o projeto são planejados considerando
o perfil e o conhecimento necessário para executá-lo;
- GPR 10: um plano geral para a execução do projeto é estabelecido com a
integração de planos específicos;
- GPR 11: todos os setores da instituição devem ser analisados;
- GPR 12: o plano do projeto é revisado com todos os interessados e o
compromisso com ele é obtido;
- GPR 13: o escopo, as tarefas, as estimativas, o orçamento e o
cronograma do projeto são monitorados em relação ao planejamento;
- GPR 14: os recursos materiais e humanos bem como os dados relevantes
do projeto são monitorados em relação ao planejamento;
- GPR 15: os riscos são monitorados em relação ao planejamento;
- GPR 16: o envolvimento das partes interessadas no projeto é planejado,
monitorado e mantido;
- GPR 17: revisões são realizadas em marcos do projeto e conforme
estabelecido no planejamento;
- GPR 18: registros de problemas identificados e o resultado da análise de
questões pertinentes, incluindo dependências críticas, são estabelecidos
e tratados com as partes interessadas;
55
- GPR 19: ações para corrigir desvios em relação ao planejamento e para
prevenir a repetição dos problemas identificados são estabelecidas,
implementadas e acompanhadas até a sua conclusão.
Segundo Guia Geral de Software (2012, p. 29), a Gerência de Requisitos
tem os seguintes resultados esperados:
- GRE 1: o entendimento dos requisitos é obtido junto aos fornecedores de
requisitos;
- GRE 2: os requisitos são avaliados com base em critérios objetivos e um
comprometimento da equipe técnica com estes requisitos é obtido;
- GRE 3: a rastreabilidade bidirecional entre os requisitos, os produtos de
trabalho são estabelecidos e mantidos;
- GRE 4: revisões em planos e produtos de trabalho do projeto são
realizadas visando identificar e corrigir inconsistências em relação aos
requisitos;
- GRE 5: mudanças nos requisitos são gerenciadas ao longo do projeto.
5.7 RESULTADOS ALCANÇADOS
Já que a empresa nunca teve uma melhoria de processos de software antes,
os resultados dos questionários foram de que a empresa possui um nível bastante
baixo no quesito estudado que seria Gerência de Projetos e Gerência de Requisitos.
Somente alguns resultados foram implementados que serão demonstrados a seguir,
já os resultados não informados não foram alcançados.
Tabela 5: Resultados alcançados
GPR 3 - O ciclo de vida e o modelo do projeto são definidos.
GPR 4 - A possibilidade de atingir as metas do projeto, levando
em conta as restrições e os recursos disponíveis, é avaliada. Se
necessário ajustes são realizados.
GPR 6 - O cronograma e o orçamento do projeto são
estabelecidos e mantidos.
GPR 8 - Os recursos e o ambiente de trabalho necessários para
executar o projeto são planejados.
GPR 9 - Os recursos humanos para o projeto são planejados
considerando o perfil e o conhecimento necessário para executálo.
GPR 10 - Um plano geral para a execução do projeto é
estabelecido com a integração de planos específicos.
GPR 11 - Todos os setores da instituição devem ser analisados.
GPR 12 - O plano do projeto é revisado com todos os
interessados e o compromisso com ele é obtido.
Fonte: HPR Informática e Acessórios LTDA.
Parcialmente Implementado
Totalmente Implementado
Parcialmente Implementado
Parcialmente Implementado
Parcialmente Implementado
Totalmente Implementado
Parcialmente Implementado
Parcialmente Implementado
56
Conforme os questionários aplicados na empresa os únicos resultados que
foram totalmente implementados foram o GPR 4 e o GPR 10 que serão descritos a
seguir.
Os resultados do GPR 4 foram de que foi recebido uma atividade do cliente,
o projeto foi calculado verificando o mínimo de tempo e esforço da equipe. Foi
realizado uma reunião entre o gerente e os programadores para avaliar a viabilidade
do projeto e o tempo gasto. Não foram encontradas dificuldades porque foi apenas
realizada reuniões com os colaboradores da empresa.
Os resultados do GPR 10 foi de que o plano de execução foi estabelecido
com a integração dos planos específicos que são:
- Menu de projetos;
- Histórico;
- Menu de processos;
- Ajuste nos modelos existentes.
Conforme os questionários aplicados os resultados a seguir não foram
totalmente implementados sendo assim tendo seus resultados parcialmente
atendidos.
No caso do GPR 3 o modelo e as fases do ciclo de vida do projeto foram
definidas em partes, pois o ciclo de vida teve que ser definido muito no início do
desenvolvimento e esse conteve falhas pois ultrapassou a data final de entrega, mas
foi conseguido dividir o mesmo em fazes para o desenvolvimento.
No caso do GPR 6, que inclui cronogramas e orçamentos do projeto não
ficaram integralmente implementados, pois no andamento da elaboração do
cronograma o caminho decisivo não é observado, ficando assim parcialmente
implementado. Resultado Implementado é o de Comitê de Processos.
Nos resultados do GPR 8, foi registrado a ausência de uma prática de
segurança para os dados do projeto, apesar de serem distribuídos e gerenciados.
Os processos implementados foram de que teve um plano do projeto que envolve
menu de projetos e processos existentes na empresa.
No caso do GPR 9 foi constatado que a empresa tem planejamento de
recursos humanos e que a alocação dos recursos é feita seguindo o conhecimento
técnico do mesmo. Contudo, o que era esperado falhou no quesito treinamento, pois
o mesmo não está sendo executado ou não é verificado.
57
O resultado do GPR 11 que está totalmente relacionado com o planejamento
do entendimento, está parcialmente implementado, porque os interesses são
identificados bem como as obrigações de informação e também tendo sua área de
testes. Contudo a comunicação não é gerenciada para que todos os envolvidos
poção acessar às informações indispensáveis para o projeto ser desenvolvido.
Os resultados do GPR 12 foi de que realizaram ajustes no planejamento do
projeto em desenvolvimento como necessidade dos interessados, contudo não foi
obtido dos membros da empresa um compromisso para que seja totalmente
implementado na empresa.
Verificando os resultados esperados em Gerencia de Requisitos (GRE), não
foi descrito na tabela dos resultados alcançados, então podemos concluir que na
empresa não houve esses processos implementados nem parcialmente tão pouco
totalmente.
5.8 ANÁLISE DA IMPLEMENTAÇÃO
Segundo Zahran (1998, p. 226), a implementação de melhoria de processo
de software é uma atividade complexa e intensa em conhecimento.
A direção da empresa deve estar empenhada com a prática de avanço de
seus processos. Com isso os objetivos devem estar definidos com os objetivos da
empresa, por isso as revisões dos objetivos devem ser feitas periodicamente.
Deve-se envolver a equipe desde o início, buscando a participação de todos
em cada atividade para a melhoria dos processos. Os resultados devem ser
amplamente divulgados, abrindo espaços para debates para tirar dúvidas e
questionamentos para a possível melhoria do projeto final.
A busca pela qualidade de software pela empresa mostrou que teve uma
melhora na qualidade dos softwares desenvolvidos, e também mostrou-se
importante devido ao perfil da empresa, que tem profissionais que nunca tiveram um
envolvimento com a prática de melhoria de processo de software, enriquecendo
ainda mais seu quadro de professionais, podendo alcançar resultados satisfatórios
em projetos futuros.
58
5.9 DIFICULDADES ENCONTRADAS NA IMPLEMENTAÇÃO
Foi notado que a principal dificuldade encontrada na implementação do
MPS.BR nível G foi a resistência dos colaboradores em relação às variações
ocorridas em suas atividades.
Outra dificuldade percebida foi em relação ao Guia de Implementação do
modelo MPS.BR, que possui objetivos de auxiliar na implementação as quais são
muito subjetivas. Estas orientações apresentam informações do que deve ser feito
mas não oferecendo informações de como devem ser feitas.
Foi analisado que para ter um bom entendimento e uma boa implementação
deveríamos ter um tempo maior para mobilizar todos os envolvidos para poder
aplicar palestras explicando mais afundo o modelo a ser implantado, com seus
detalhes, podendo fazer um esboço de todo o plano de implementação, o qual não
teve como ser feito pelo pouco tempo que tivemos para a implementação.
Entretanto, um ponto de cautela tivemos que levar em conta, para o não
cumprimento de todos os objetivos propostos é de que o gerente da empresa
superestimava a capacidade dos colaboradores, colocando muitos projetos para
serem desenvolvidos e com prazos reduzidos, fazendo com que nem todos eram
terminados e entregues nos prazos estipulados.
Dificuldades foram muitas, mas as atividades que demandavam mais tempo
de documentação deixavam de ser implementadas devido à pressão do dia a dia.
A ausência de práticas administrativas no desenvolvimento de software é a
principal causa de sérios problemas enfrentados pela organização; são
exemplos: atrasos em cronogramas, custo maior do que o esperado e
presença de defeitos, ocasionando uma série de inconveniências para os
usuários e grande perda de tempo e de recursos. Até hoje esta afirmação
vem sido confirmada por vários autores (HUMPHREY, 1989).
59
6 CONCLUSÃO
Este trabalho de conclusão de curso teve o objetivo geral de implantar o
melhor processo de desenvolvimento em uma empresa de porte pequeno usando o
modelo descrito no MPS.BR. De uma forma geral, como a empresa nunca teve uma
melhoria de processos de software antes, os resultados obtidos mostram que a
empresa possui um nível bastante baixo no quesito estudado que seria Gerência de
Projetos e Gerência de Requisitos.
Na atualidade, seja qual for o veículo de informação, o software deverá estar
presente para que as máquinas tenham um funcionamento extraordinário. Os
métodos de melhoria de processos de software no mercado procuram a qualidade e
organização da empresa, o que provoca a melhora dos produtos.
Dentro da empresa somente alguns resultados foram implementados, outros
não foram alcançados: GPR 4 e o GPR 10 foram totalmente implementados. Foram
parcialmente implantados: GPR 3, GPR 6, GPR 8, GPR 9, GPR 11, GPR 12. Para
melhora nos resultados, a empresa deve comprometer-se em atentar o progresso
em seus processos, revisando seus objetivos constantemente, ainda entrosar a
equipe nas atividades de melhoria, pois uma dificuldade encontrada foi a aceitação
dos colaboradores em relação às mudanças ocorridas em seus afazeres.
As empresas desenvolvedoras de software buscam constantemente
aprimorar seus produtos em razão da alta competitividade existente no mercado a
fim de apresentar um produto diferenciado e ganhar o espaço diante de seu
concorrente, o retorno financeiro acontece de forma gradativa por isso é
imprescindível conscientizar os membros da equipe que um processo definido é
fundamental para a melhoria do produto final além de facilitar o trabalho de todos os
membros. Ressaltando sempre que o sucesso do trabalho depende do empenho de
todos.
O estudo de caso mostrou que o MPS.BR ajudou na evolução da qualidade
do processo e não apresenta barreiras para implantação como os demais padrões
internacionais. Se futuramente for aprovada pela gerencia da organização, será
implementado o restante das atividades da Gerencia de Processos, dando
continuidade à padronização de processos e garantindo a qualidade do produto
apresentado.
60
Enfim, fica claro que o mundo sofre constantes mudanças, e as empresas
devem modificar-se e atualizar suas informações para acompanhar essas
transformações. A atualidade utiliza muito à informática e esta deve atender as
necessidades daqueles que buscam, aprimorando sempre.
61
7 TRABALHOS FUTUROS
Com base no trabalho desenvolvido, diversas vertentes de trabalhos futuros
podem ser identificados. Já que a empresa não teve a implementação do Processo
Gerencia de Requisitos esse poderá ser um dos trabalhos a serem desenvolvidos e
também
oferecer
informações
aprofundadas
de
implementação correta do Modelo MPS.BR na empresa.
como
deve
ser
feita
a
62
8 REFERÊNCIAS BIBLIOGRÁFICAS
ABREU, V. F.; FERNANDES, A. A. Implantando a governança de TI: da estratégia
à gestão dos processos e serviços. 3. ed. Rio de Janeiro: Brasport Livros e
Multimídia Ltda, 2009.
ANACLETO, A. et al. 15504MPE: desenvolvendo um método para avaliação de
processos de software em MPEs utilizando a ISO/IEC 15504. São Paulo: UNIVALI,
2003.
BAETJER, H. Software as capitais. 1. ed. New Jersey: Wiley – IEE Computer
Society Pr, 1998. p. 85.
BISCHOFF, A. A. Modelo para a gestão do ciclo de vida de projetos de
aquisição de software: estudo de caso no sistema financeiro. Porto Alegre: PUC,
2008.
CAMPOS, M. F. Qualidade, qualidade de software e garantia da qualidade de
software são as mesmas coisas? 2013. Disponível em: <http://www.linhade
codigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidadede-software-sao-as-mesmas-coisas.aspx>. Acesso em: 21 nov. 2013.
CÂNDIDO, E. J. Uma simplificação da técnica análise de pontos de função para
estimar tamanho de aplicativos web. São Paulo: USP, 2004.
FURASTÉ, P. A. Normas técnicas para o trabalho científico: explicitação das
normas da ABNT. 16. ed. Porto Alegre: Dáctilo Plus, 2013.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia.
Rio de Janeiro: Elsevier-Campus, 2012. p. 185-186.
HUMPHREY, W. Managing the software process. S.L: Addison-Wesley, 1989.
IBM. IBM rational unified process (RUP). Disponível
01.ibm.com/software/rational/rup/>. Acesso em: 06 dez. 2013.
em:
<http://www-
KAN, S. H. Metrics and models in software quality engineering. 2. ed. Minnesota:
Addison-Wesley, 2002.
KOSCIANSKI, A.; SOARES, M. Qualidade de software. São Paulo: Novatec, 2007.
KUMAR, S. What is prototype model: advantages, disadvantages and when to use
it? 2012. Disponível em: <http://istqbexamcertification.com/what-is-prototype-modeladvantages-disadvantages-and-when-to-use-it/>. Acesso em: 05 dez. 2013.
63
LEITE, J. O modelo cascata. 2007. Disponível em: <http://engenhariade
software.blogspot.com.br/2007/03/o-modelo-cascata.html>. Acesso em: 05 dez.
2013.
LIMA, A. S. Norma NBR ISO/IEC 12207. 2013. Disponível em: <http://www.
micreiros.com/2013/norma-nbr-isoiec-12207/>. Acesso em: 06 jan. 2014.
MACIEL, A. C. F.; VALLS, C.; SAVOINE, M. M. Análise da qualidade de software
utilizando as normas 12207, 15504, ISO 900-3 e os modelos CMM/CMMI e
MPS.BR. Disponível em: <http://www.itpac.br/hotsite/revista/artigos/44/5.pdf>.
Acesso em: 10 jan. 2014.
MARTINEZ, M. RUP. Disponível em: <http://www.infoescola.com/engenharia-desoftware/rup/>. Acesso em: 05 jan. 2014.
MARTINS, E. Qualidade de software. 2012. Disponível em: <http://www.ic.
unicamp.br/~ranido/mc626/Qualidade.pdf>. Acesso em: 21 nov. 2013.
MODESTO, J.; OLIVEIRA, C. Tipos de software. 2010. Disponível em:
<http://nocoesengsw.blogspot.com.br/2010/03/tipos-de-software.html>. Acesso em:
20 nov. 2013.
_______, MPS.BR: melhoria de processo do software brasileiro – guia geral. Versão
1.0. 2005. Disponível em: <http://www.softex.br>. Acesso em: 11 jan. 2014.
_______, MPS.BR: melhoria de processo do software brasileiro – guia geral. Versão
1.2. 2009. Disponível em: <http://www.softex.br>. Acesso em: 20 jan. 2014.
_______, MPS.BR: melhoria de processo do software brasileiro – guia geral. 2012.
Disponível em: <http://www.softex.br>. Acesso em: 20 jan. 2014.
_______, MPS.BR: melhoria de processo do software brasileiro – guia de
implementação do nível G. 2012. Disponível em: <http://www.softex.br>. Acesso em:
21 jan. 2014.
MORIYA, R. K. RUP – environment discipline: RUP – metodologia. Disponível
em:
<http://robsonkoji.blogspot.com.br/2007/09/configuracao-dos-processos-rup.
html>. Acesso em: 10 jan. 2014.
PALESTINO, C. Bi2: business intelligence. Rio de Janeiro: Elsevier-Campus, 2011.
PRESSMAN, R. S. 7 categorias de software. Disponível em: <http://melhor
agora.org/2007/03/03/7-categorias-de-software-segundo-roger-pressman>. Acesso
em: 25 nov. 2013.
64
PRESSMAN, R. S. Engenharia de software. 7. ed. São Paulo: Makron Books,
2007.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade dos produtos de
software: teoria e prática. São Paulo: Prentice Hall, 2001.
RODRIGUES, C. Engenharia de software e o mercado de trabalho. Disponível
em: <http://www.ceviu.com.br/blog/info/artigos/engenharia-de-software-e-o-mercadode-trabalho/>. Acesso em: 05 dez. 2013.
SIGNIFICADOS. Significado de software. Disponível
significados.com.br/software>. Acesso em: 25 nov. 2013.
em:
<http://www.
SILVA, J. T. O MPS.Br como alternativa para micro e pequenas empresas: Um
estudo de caso. Recife: Universidade Federal de Pernambuco. 2008.
SILVEIRA, A. Melhoria de processo do software brasileiro – MPS.br. 2012.
Disponível em: <http://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-deprocessos-do-software-brasileiro--mpsbr>. Acesso em: 25 nov. 2013.
SOMMERVILLE, I. Engenharia de software. 6. ed. São Paulo: Pearson Addison
Wesley, 2004.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison
Wesley, 2007.
TRAVASSOS, G. H.; KALINOWSKI, M. Caracterização e variação de
desempenho de organizações que adotaram o modelo MPS. São Paulo: Softex,
2009.
VICTORINO, M.; BRÄSCHER, M. Organização da informação e do
conhecimento, engenharia de software e arquitetura orientada a serviços: uma
abordagem holística para o desenvolvimento de sistemas de informação
computadorizados. 2009. Disponível em: <http://www.dgz.org.br/jun09/Art_03.htm>.
Acesso em: 05 dez. 2013.
WAZLAWICK, R. Engenharia de software. Rio de Janeiro: Elsevier-Campus, 2013.
WIKIPÉDIA. Melhoria de processo do software brasileiro. Disponível em: <http://
pt.wikipedia.org/wiki/Melhoria_de_Processos_do_Software_Brasileiro>. Acesso em:
23 fev. 2014.
ZAHRAN, S. Software process improvement: practical guidelines for business
success. S.L: Addison Wesley, 1998.
65
ANEXO
66
ANEXO A – Questionário Utilizado para o Estudo
Questionário Utilizado para o Reconhecimento da Empresa
1. Nome da Instituição.
2. Área de Atuação:
( ) Aquisição de Software
( ) Fábrica de Software
( ) Fábrica de Testes
( ) Outras:________________________________________________________.
3. Número de Profissionais da Área de Desenvolvimento de Software.___________.
4. Qual o nível dos profissionais.
( ) Médio – Número de Profissionais:___________________________________.
( ) Superior – Número de Profissionais:_________________________________.
( ) Especialização – Número de Profissionais:____________________________.
( ) Mestrado – Número de Profissionais:_________________________________.
( ) Doutorado – Número de Profissionais:________________________________.
5. Clientes em Potencial:
( ) Pessoa Física
( ) Pessoa Jurídica
( ) Instituições Públicas
6. Qual o principal produto oferecido pela empresa?
7. Existem processos definidos pela empresa? Quais os principais?
8. Até que ponto a instituição está conseguindo prover as necessidades do mercado
em que se encontra inserida?
9. A empresa já adotou algum modelo ou padrão de qualidade?
10. Quais os pontos fortes da instituição?
11. Quais os pontos fracos da instituição?
12. Qual é a expectativa em termos de resultados com o final da implementação?
67
Questões Gerenciamento de Projetos (GPR)
SILVA (2008, p.56).
1. No início de um projeto, todo o escopo é conhecido e definido?
 Sim
 Não
 Não se aplica
 Não sei
2. O escopo é definido com técnicas adequadas?
 Sim
 Não
 Não se aplica
 Não sei
3. O escopo é definido em tarefas, cada uma com seus produtos de trabalho?
 Sim
 Não
 Não se aplica
 Não sei
4. O projeto é dividido em fases bem definidas?
 Sim
 Não
 Não se aplica
 Não sei
5. No início do projeto é feito um estudo de viabilidade levanto em consideração os
recursos e a infraestrutura disponível?
 Sim
 Não
 Não se aplica
 Não sei
6. No transcorrer do projeto é notada inviabilidade, seu escopo é alterado?
 Sim
 Não
 Não se aplica
 Não sei
68
7. O cronograma e orçamento do projeto são estabelecidos?
 Sim
 Não
 Não se aplica
 Não sei
8. São usadas metodologias apropriadas para avaliação de prazo e custo das
tarefas?
 Sim
 Não
 Não se aplica
 Não sei
9. No desenvolvimento do cronograma é observada a dependência entre tarefas?
 Sim
 Não
 Não se aplica
 Não sei
10. O caminho crítico é observado?
 Sim
 Não
 Não se aplica
 Não sei
11. O cronograma e orçamento são revistos e atualizados, quando necessário?
 Sim
 Não
 Não se aplica
 Não sei
12. Existe uma avaliação de riscos do projeto, com seus impactos e respectivas
probabilidades?
 Sim
 Não
 Não se aplica
 Não sei
69
13. Os riscos levantados são acompanhados?
 Sim
 Não
 Não se aplica
 Não sei
14. Os dados do projeto (como por exemplo: relatórios, dados informais, artefatos
gerados, etc.) são disponibilizados para os envolvidos do projeto quando aplicável?
 Sim
 Não
 Não se aplica
 Não sei
15. O armazenamento e distribuição de dados do projeto são gerenciados?
 Sim
 Não
 Não se aplica
 Não sei
16. Se aplicável, existe uma política de segurança para os dados do projeto?
 Sim
 Não
 Não se aplica
 Não sei
17. Existe planejamento de recursos humanos no projeto?
 Sim
 Não
 Não se aplica
 Não sei
18. No planejamento de recursos humanos é verificada a necessidade de
treinamento, e caso positivo, o mesmo é executado?
 Sim
 Não
 Não se aplica
 Não sei
70
19. O esforço e custo necessários para os produtos de trabalho são estimados com
base em experiências anteriores ou referências técnicas?
 Sim
 Não
 Não se aplica
 Não sei
20. Durante o planejamento, são identificados todos os interessados no projeto?
 Sim
 Não
 Não se aplica
 Não sei
21. É planejado o envolvimento dos interessados, com suas respectivas
necessidades de informação?
 Sim
 Não
 Não se aplica
 Não sei
22. A comunicação é gerenciada de forma a garantir que os envolvidos com o
projeto tenham acesso á informação necessária, ao longo do projeto?
 Sim
 Não
 Não se aplica
 Não sei
23. O planejamento do projeto é revisto com os interessados a fim de se obter um
compromisso?
 Sim
 Não
 Não se aplica
 Não sei
24. Ajustes necessários são realizados no planejamento do projeto de acordo com a
interação de todos os interessados?
 Sim
 Não
 Não se aplica
 Não sei
71
25. O monitoramento de cronograma é feito ao longo do projeto?
 Sim
 Não
 Não se aplica
 Não sei
26. O monitoramento de custos é feito ao longo do projeto?
 Sim
 Não
 Não se aplica
 Não sei
27. Há monitoramento ao longo do projeto em? Poderá ser marcado mais de uma
opção.
 Recursos
 Riscos
 Envolvimento dos Interessados
 De dados do Projeto
72
Questões Gerenciamento de Requisitos (GRE)
SILVA (2008, p.61).
1. Existe uma comunicação contínua com quem fornece os requisitos?
 Sim
 Não
 Não se aplica
 Não sei
2. As comunicações com quem fornece requisitos são formalizadas?
 Sim
 Não
 Não se aplica
 Não sei
3. A especificação dos requisitos é revista com quem fornece requisitos a fim de
garantir um entendimento entre ambas as partes?
 Sim
 Não
 Não se aplica
 Não sei
4. A aceitação de um grupo de requisitos é feita de forma objetiva (isto é, cada
requisito é avaliado e sua aceitação é feita objetivamente, como por exemplo, com o
uso de uma checklist)?
 Sim
 Não
 Não se aplica
 Não sei
5. Existe uma formalização do comprometimento dos requisitos?
 Sim
 Não
 Não se aplica
 Não sei
6. O comprometimento é mantido em caso de mudança nos requisitos?
 Sim
 Não
 Não se aplica
 Não sei
73
7. A rastreabilidade entre requisitos, plano de projeto e produto de trabalho é
estabelecida e modificada com a mudança de requisitos?
 Sim
 Não
 Não se aplica
 Não sei
8. Inconsistências entre requisitos, plano de projeto e produtos de trabalho são
identificadas, registradas e corrigidas?
 Sim
 Não
 Não se aplica
 Não sei
9. Mudanças de requisitos são registradas?
 Sim
 Não
 Não se aplica
 Não sei
10. Existe um histórico de decisões relacionado ao gerenciamento de requisitos
disponível?
 Sim
 Não
 Não se aplica
 Não sei
11. Os impactos das alterações de requisitos são analisados, e decisões sobre os
requisitos e plano de projeto são adotadas de acordo com esse impacto?
 Sim
 Não
 Não se aplica
 Não sei