A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O … · RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27....
Transcript of A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O … · RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27....
UNIVERSIDADE POSITIVO
PRÓ-REITORIA DE PÓS-GRADUAÇÃO, PESQUISA E EXTENSÃO
CURSO DE ESPECIALIZAÇÃO EM
GESTÃO DA TECNOLOGIA DA INFORMAÇÃO
PROJETO DE TRABALHO DE CONCLUSÃO DE CURSO
A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O
DESENVOLVIMENTO DE SISTEMAS
CLÉVERSON TRAJANO PRÉCOMA PORTES
DYONATA LAITENER RAMOS
CURITIBA
2011
CLÉVERSON TRAJANO PRÉCOMA PORTES
DYONATA LAITENER RAMOS
A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O
DESENVOLVIMENTO DE SISTEMAS
Projeto de especialização apresentado ao Programa de Especialização em Gestão da Tecnologia da Informação
Orientador: Anderson Ravanello.
CURITIBA
2011
SUMÁRIO
ÍNDICE DE FIGURAS 5
ÍNDICE DE TABELAS 6
1. INTRODUÇÃO 7
2. O QUE É QUALIDADE? 7
3. PROPÓSITO DA GARANTIA DA QUALIDADE DE SOFTWARE 8
3.1. Histórico 8
3.2. O Propósito 9
4. MPS.BR 10
4.1. Modelo de Referência 10
4.2. Modelo de Avaliação 11
4.3. Modelo de Negócio 12
5. CMMI 13
6. INTRODUÇÃO A PESQUISA 14
7. PÓS IMPLANTAÇÃO DO PROCESSO DE QUALIDADE 15
7.1. CMMI 15
7.2. MPS.BR 17
8. APLICAÇÃO DOS QUESTIONÁRIOS 20
8.1. Pré Implantação de Processo de Qualidade 20
8.2. Pós Implantação de Processo de Qualidade 21
9. CONCLUSÃO 23
10. REFERÊNCIAS 25
11. ANEXOS 27
11.1. RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27
11.2. RESPOSTAS QUESTIONÁRIO EMPRESA E-GOVERNE 29
11.3. RESPOSTAS QUESTIONÁRIO EMPRESA GUENKA 31
11.4. RESPOSTAS QUESTIONÁRIO EMPRESA NVI 33
ÍNDICE DE FIGURAS
Figura 1 - Componentes do modelo MPS 10
Figura 2 - Variação Desempenho das 65 Empresas que Adotaram o MPS e
Participaram da Pesquisa Periódica iMPS em 2009 e 2010 17
Figura 3 - Variação de Desempenho das 11 Empresas com MPS que
Revalidaram/Mudaram de Nível entre 2009 e 2010 18
Figura 4 - Variação de Desempenho de 42 Empresas com a Evolução no Modelo
MPS entre 2008 e 2010 19
1. INTRODUÇÃO
Atualmente vivenciamos um período na sociedade em que em todas as áreas
estão focando cada vez mais em processos de qualidade, principalmente para o
constante desenvolvimento de produtos/serviços para fins empresarias.
As empresas estão buscando por processos e gestão da qualidade não mais
como estratégias de diferenciação de mercado, mas sim como uma condição de
preexistência neste mercado voraz e competitivo.
Esta busca também é orientada com objetivos específicos para a implantação
dos processos de qualidade nas organizações, estes objetivos são especificamente:
gerenciar a lucratividade e os recursos; gerenciar riscos; gerenciar e manter
orçamentos, programações e qualidade; obter dados para melhoria do processo.
Porem esta tendência do mercado da implantação de processos de qualidade
esta trazendo a chamada “melhoria continua” para as organizações, a gestão dos
processos esta acontecendo, as medições realizadas, em geral o processo de
qualidade esta realmente modificando os processos das organizações? Os seus
objetivos vêm alcançando os resultados esperados?
Além de responder as perguntas acima este artigo pretende demonstrar a
importância dos processos para a geração de um produto com qualidade e também
nas questões relacionadas a custo, gestão de recursos, aquisição de novos clientes e
também um retrato da situação atual de diversas empresas antes de um processo de
qualidade de software definido e após a implantação e aplicação de um modelo de
qualidade de processo de software. Apresentaremos inicialmente dois modelos de
qualidade o CMMI e o MPS.BR, que embora não façam parte do escopo deste artigo
mais são de uma grande importância possuir um pequeno conhecimento do que cada
modelo propõe para uma boa gestão de qualidade.
2. O QUE É QUALIDADE?
Esta é a primeira pergunta que deve ser feita quando esse assunto é
mencionado!
Qualidade é, segundo a Sociedade Americana de Qualidade, "O grau até o qual
um conjunto de características inerentes satisfaz as necessidades esperadas".
Um conceito moderno de qualidade diz que é importante:
- A Satisfação do cliente: entendimento, avaliação, definição e gerenciamento de
expectativas de forma a atender às necessidades do cliente. Isso exige uma
combinação de conformidade com os requisitos (o projeto deve produzir o que afirmou
que produziria) e adaptação ao uso.
- Prevenção sobre Inspeção (Auditoria): o custo de prevenção de erros em geral
é muito menor que o custo de corrigi-los, conforme revelado pela inspeção.
- Responsabilidade da gerência: o sucesso exige a participação de todos os
membros da equipe, mas é sempre responsabilidade da gerência fornecer os recursos
necessários para que exista sucesso.
- Melhoria contínua: o ciclo PDCA é a base da melhoria da qualidade: Plan
(Planejar), Do (Fazer), Check (Verificar), Act (Atuar).
Para os Modelos de Maturidade de Processos de Software CMMI© e MPS.BR,
qualidade é: "O grau no qual um sistema, componente ou processo satisfaz os
requisitos especificados e as necessidades e expectativas do cliente ou usuário”.
Com base nestas definições de qualidade pode-se dizer, então que a Garantia
da Qualidade "envolve um conjunto de atividades voltadas para avaliar o processo
pelo qual os produtos são desenvolvidos ou manufaturados, visando fornecer
confiança necessária de que estes estejam em conformidade com os requisitos
técnicos especificados".
3. PROPÓSITO DA GARANTIA DA QUALIDADE DE
SOFTWARE
3.1. Histórico
A garantia da qualidade é uma atividade fundamental para qualquer negócio que
gera produtos usados por outros.
A primeira função formal de controle e garantia da qualidade foi introduzida nos
Laboratórios Bell em 1916 e espalhou-se pelo mundo da manufatura.
A história da garantia da qualidade no desenvolvimento de software ocorre
paralelamente à história da qualidade na fabricação do hardware, entretanto, padrões
de garantia da qualidade de software somente foram introduzidos na década de 70.
As necessidades e requisitos a serem tratados pelo software são cada vez mais
críticos. Os sistemas são desenvolvidos para atender atividades das quais dependem
milhares de pessoas ou até milhares de vidas.
Hospitais, Tráfego Aéreo, Usinas de Energia, Mercado Financeiro, Comércio
Interno e Internacional, Governos, Indústrias etc. são aplicações entre milhares que
não podem ser tiradas de operação, pois não há como substituídas.
Diante deste quadro é fácil entender porque a preocupação das organizações e
dos próprios desenvolvedores de software em desenvolver aplicações com qualidade.
3.2. O Propósito
O propósito da Garantia da Qualidade de Software é fornecer aos vários níveis
de gerência, adequada visibilidade dos projetos, dos processos de desenvolvimento e
dos produtos gerados.
A Garantia da Qualidade de Software atua como "guardião", fornecendo um
retrato do uso do Processo e não é responsável por executar testes de software.
Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no
sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de
software:
Desenvolver software de alta qualidade;
Ter alta produtividade da equipe de desenvolvimento;
Cumprir o cronograma estabelecido junto ao cliente;
Não necessitar de recursos adicionais não previstos.
4. MPS.BR
Com o objetivo de favorecer e estimular principalmente a micro, pequena e
média empresa brasileira de produção de software a um custo acessível, foi criado,
em 2003, o projeto MPS-BR. É um projeto de Melhoria do Processo de Software
Brasileiro, coordenado pela SOFTEX(Sociedade para Promoção da Excelência do
Software Brasileiro), e composto por mais sete instituições brasileiras com
competências na melhoria de processos de software. São elas: COPPE/UFRJ,
CESAR, CenPRA, CELEPAR, ABNT, Sociedade Núcleo de Apoio à Produção e
Exportação de Sotware do Rio de Janeiro – RIOSOFT e Sociedade Núcleo SOFTEX
2000 de Campinas.
A estrutura do modelo MPS-BR foi fundamentada com base em outros modelos
e padrões já existentes, adaptando para a realidade brasileira. O ponto de partida para
a definição foi à norma ISSO/IEC 12207 [2], a série de normas ISSO/IEC 15504
(SPICE) [3] e o modelo CMMI (Capability Maturity Model Integration) [4].
O modelo MPS está dividido em três (3) componentes (Figura 1): Modelo de
Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-
MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo
MPS [1].
Figura 1 - Componentes do modelo MPS
4.1. Modelo de Referência
Contém os requisitos que os processos das empresas devem atender para estar
em conformidade com o modelo. Está definido em níveis de maturidade que são uma
combinação entre processos e sua capacidade.
A definição dos processos segue os requisitos para um modelo de referência
de processo apresentados na ISO/IEC 15504-2, declarando o propósito e os
resultados esperados de sua execução [1]. Cada nível de maturidade é uma
junção entre processos e capacidade dos processos, ou seja, é composto por um
conjunto de processos em um determinado nível de capacidade [5].
São definidos sete (7) níveis de maturidade para o modelo: A(Em
Otimização), B(Gerenciado Quantitativamente), C(Definido), D(Largamente
Definido), E(Parcialmente Definido), F(Gerenciado) e G(Parcialmente Gerenciado).
4.2. Modelo de Avaliação
O objetivo do modelo de Avaliação é verificar a maturidade da empresa na
execução de seus processos de software. Descreve um conjunto de atividades e
tarefas a serem cumpridas para atingir este propósito.
Segundo [6], o Processo e o Método de Avaliação MA-MPS foram definidos de
forma a:
Permitir a avaliação objetiva dos processos de software de uma
organização/unidade organizacional;
Permitir a atribuição de um nível de maturidade do MR-MPS com base no
resultado da avaliação; ser aplicável a qualquer domínio na indústria de software;
Ser aplicável a organizações/unidades organizacionais de qualquer tamanho.
O processo de avaliação é dividido em quatro (4) sub processos:
1. Contratar a avaliação;
2. Preparar a realização da avaliação;
3. Realizar a avaliação final;
4. Documentar os resultados da avaliação;
Como resultado da execução deste processo:
São obtidos dados e informações que caracterizam os processos de software
da organização/unidade organizacional;
É determinado o grau em que os resultados esperados são alcançados e os
processos atingem o seu propósito;
É atribuído um nível de maturidade do MR-MPS à organização/unidade
organizacional.
A avaliação é válida por um período de três (3) anos a contar da data em que a
avaliação final foi concluída com a empresa avaliada.
4.3. Modelo de Negócio
Este modelo descreve as regras de negócio para implementação do MR-MPS.
Para cada nível de maturidade há um guia que detalha os processos existentes que
são descritos em termos de atributos de processo (AP). O atendimento destes
atributos é avaliado utilizando os respectivos resultados esperados de atributo de
processo (RAP).
A seguir um resumo dos níveis de maturidades, seus processos associados
e atributos de processo a ser atingido (Tabela 1):
Tabela 1 - Níveis de maturidade MPS
5. CMMI
Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de
processo que ajuda as organizações a melhorarem seu desempenho.
CMMI pode ser utilizado para orientar a melhoria do processo através de um
projeto, uma divisão, ou uma organização inteira.
CMMI em engenharia de software e desenvolvimento organizacional é uma
abordagem de melhoria de processo que fornece às organizações os elementos
essenciais para a melhoria de processos eficazes.
CMMI é registrada no Patent and Trademark Office EUA pela Carnegie Mellon
University.
Segundo o Software Engineering Institute [7], CMMI ajuda “integrar funções
organizacionais tradicionalmente separadas, gols processo de melhoria e definir
prioridades, fornecer orientações para processos de qualidade, e fornecer um ponto
de referência para a avaliação de processos em curso".
6. INTRODUÇÃO A PESQUISA
Há cerca de alguns anos, o mercado que podemos intitular como “indústria de
software”, era ainda um nicho pequeno com poucas empresas, poucos produtos e com
algumas grandes empresas se destacando. Com o passar dos anos, o aumento da
tecnologia, da dependência do ser humano e de processos computacionais o cenário
mudou significativamente obrigando as empresas a mudarem seus paradigmas e
investirem na otimização de fatores como custo, tempo e qualidade.
Porem com esse aumento significativo da demanda do mercado muitas
empresas não estavam preparadas para receber tantos projetos ao mesmo tempo e
trabalhar cada vez mais com um número menor de pessoas em cada projeto, com isso
formou-se um cenário onde existia uma grande falha no processo de desenvolvimento
de software com empresas que não estavam capacitadas em prestar este serviço
juntamente com um processo de qualidade de produto.
Com relação à afirmação acima foi realizada uma pesquisa [11], onde foi
possível ter uma visão da imaturidade das indústrias de software através dos
seguintes indicadores:
Mais de 30% dos projetos são cancelados antes de serem finalizados.
Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas.
Os custos extrapolam em mais de 180% os valores originalmente previstos.
Os prazos excedem mais de 200% os cronogramas iniciais.
Para que esse cenário seja alterado é necessário que as organizações estejam
apoiadas em modelos de processo organizacionais focados em qualidade de processo
e também em qualidade de desenvolvimento. Citando estes modelos podemos
novamente voltar a falar em CMMI e MPS.BR que foram explanados anteriormente e
alguns frameworks de desenvolvimento de software como SCRUM e XP.
Citamos anteriormente ambos os modelos de qualidade e otimização de
desenvolvimento de software, pois a qualidade do produto está diretamente
relacionada à qualidade do processo de desenvolvimento. Desta forma, é comum que
a busca por um software de maior qualidade passe pela estruturação e implantação de
um processo de qualidade de desenvolvimento de software.
É importante que se procure melhorar a qualidade do produto, mas devemos nos
preocupar de forma mais ampla em melhorar a qualidade de trabalho, de serviço, de
informação, de processo e de pessoal.
Enfim é necessário adequar um processo de qualidade de processo juntamente
com o desenvolvimento pessoal da equipe de forma a se buscar uma melhoria
continua do processo de produção de software com o objetivo focado em qualidade de
produto, diminuição de custos, e economia de tempo.
7. PÓS IMPLANTAÇÃO DO PROCESSO DE QUALIDADE
Com base nas premissas que foram apresentadas anteriormente as empresas
deste setor buscaram implantar processos certificados que pudessem garantir uma
melhoria continua em seus processos e em consequência aumentar a qualidade do
processo e produto final para os seus clientes. Para isso foram utilizados os modelos
que já foram explanados neste documento, sendo eles: CMMI e MPS.BR.
O que iremos apresentar agora é um relato sobre os resultados de melhoria de
processos baseadas nestes modelos. Os resultados foram obtidos através de
apresentações em conferencias públicas, artigos publicados e colaborações
individuais.
Juntos, estes resultados fornecem a prova de conceito sobre o potencial de
melhoria dos modelos apresentados.
7.1. CMMI
Iremos apresentar agora como estão algumas empresas que implantaram o
CMMI em seus processos e conseguiram coletar métricas de como as suas
organizações se encontravam na época anterior a implantação do processo de
qualidade e após a obtenção no nível mais elevado do modelo de qualidade de
software.
Lembrando que apenas a decisão de implantar o CMMI em sua organização
não é o suficiente, é preciso fazer uma boa definição de processos, utilizar o novo
processo, contabilizar e medir os resultados, e fazer a melhoria continua com base
nas lições aprendidas e das métricas que foram coletadas dentro de cada projeto.
Os resultados [8] obtidos foram baseados nos resultados de 2010 de seis
organizações de defesas, sendo elas: Raytheon, Harris, Northrop Grumman, AIS,
Armament SEC, Lockeed Martin. Os resultados foram divulgados em uma pesquisa
realizada pelo Software Engineering Institute Carnegie Mellon University, e
apresentado em Maio de 2010.
Os resultados apresentados são o comparativo do pré e pós implantação do
processo de qualidade em empresas que possuíam um nível 3 do CMMi e adquiriram
o nível 5 no ano de 2010.
Entregas no prazo aumentaram em 5%.
Diminuição de erros e retrabalho em mais de seis vezes. Esta contagem foi
realizada no inicio da fase de testes dos sistemas, este ganho de seis vezes
menos erros nos sistemas representa de 5-6 meses de ganho no cronograma
dos projetos, considerando um projeto grande.
Diminuição em cerca de 58% em horas trabalhadas para corrigir erros nos
sistemas.
Os custos dos projetos reduziram cerca de 28%.
Aumento de 85% na remoção prévia de erros, antes do inicio da fase de testes.
Aumento de 42% da produtividade das organizações.
Aumento de 50% na satisfação do cliente com o processo e produto entregue
Redução das horas extras e pressão interna nos projetos
Diminuição do replanejamento do escopo do projeto.
Diminuição com horas de treinamento, a documentação do processo habilita o
processo de transferência do conhecimento para novos membros das
organizações.
Retenção da mão de obra e satisfação da equipe de trabalho.
7.2. MPS.BR
Para avaliação de empresas que implantaram o modelo MPS foi utilizado como
base o documento iMPS 2010 [9] que relata o desempenho de empresas certificadas
no MPS.BR.
Nesta análise foram utilizados os seguintes indicadores:
A) Variação do faturamento
B) Número de clientes no país
C) Número de funcionários
D) Custo médio dos projetos
E) Prazo médio dos projetos
F) Tamanho médio dos projetos
G) Produtividade
H) Qualidade
I) Retorno do investimento para implementação e avaliação do modelo
Neste trabalho iremos analisar somente os indicadores A, D, G, H e I por
refletirem melhor nosso objetivo.
Figura 2 - Variação Desempenho das 65 Empresas que Adotaram o MPS e
Participaram da Pesquisa Periódica iMPS em 2009 e 2010
Pela Figura 2 pode-se observar uma tendência de aumento no Faturamento
nas empresas entre 2009 e 2010. Isto pode ser explicado por outro indicador, o Custo
Médio dos Projetos, onde houve uma redução significativa do mesmo para a maioria
das empresas entre as avaliações.
No indicador de Produtividade percebe-se uma redução ou manutenção nos
resultados medidos. Isto pode ser explicado pelo controle mais rigoroso no processo
de desenvolvimento que o próprio MPS exige na definição dos mesmos.
Quanto ao retorno do investimento, apenas 14% relataram que não obtiveram
retorno algum. O restante das empresas afirmou já ter obtido algum ou todo o retorno
investido na implantação do processo de qualidade. Além disso, deve ser feito uma
investigação mais precisa para entender se estas empresas foram avaliadas
recentemente, o que impediria obter este retorno.
O indicador Qualidade, que nesta avaliação é medido em termos de
capacidade de encontrar defeitos (número de defeitos / unidade de tamanho do
software), mostra uma pequena tendência de aumento. Porém, entre os indicadores,
este é o que se obteve menor número de respostas entre as empresas e
consequentemente possui o menor nível de confiança do resultado.
Figura 3 - Variação de Desempenho das 11 Empresas com MPS que
Revalidaram/Mudaram de Nível entre 2009 e 2010
Outra análise foi realizada entre as empresas avaliadas entre 2009 e 2010 que
mudaram ou revalidaram seus níveis de maturidade como mostra a figura 3. Nesta
análise pode ser visto um aumento ou manutenção do faturamento entre as empresas,
nenhuma obteve redução neste indicador. É possível observar também redução em
custos e prazos o que pode ser explicado pela redução no tamanho dos projetos e
reflexo da adoção de práticas e controles que a adoção de um processo de
maturidade exige. Neste gráfico não podemos tirar uma conclusão sobre o indicador
qualidade devido poucas empresas terem respondido e ao baixo nível de confiança.
Figura 4 - Variação de Desempenho de 42 Empresas com a Evolução no Modelo
MPS entre 2008 e 2010
Consolidando a tendência de melhoria dos resultados com a implantação de um
modelo de qualidade, foram verificados os dados entres as empresas que evoluíram
no modelo entre 2008 e 2010 e tiveram todos os questionários respondidos no
período. Como pode ser visto no gráfico da figura 4 a tendência de melhora nos
indicadores é verificada pelo aumento de faturamento, número de clientes,
funcionários e redução do custo médio dos projetos.
8. APLICAÇÃO DOS QUESTIONÁRIOS
Para fundamentar ainda mais os resultados obtidos e explanados no tópico
anterior este projeto ainda irá apresentar questionários que foram realizados com
empresas que implantaram recentemente um modelo de qualidade.
Como forma de demonstrar as principais alterações que sofrem os processos
internos das organizações pré e pós implantação de um modelo de qualidade foram
realizadas doze perguntas a quatro organizações diferentes.
Estas perguntas foram formalizadas para representar as principais alterações
que uma organização identifica com a melhoria continua e definição de processos com
base em um modelo de qualidade.
A seguir é possível verificar uma visão geral que as quatro organizações
partilharam em seus questionários.
8.1. Pré Implantação de Processo de Qualidade
1. Como era o processo de gerenciamento de projetos?
No geral não havia um processo definido.
2. Como era feita a estimativa de prazos dos projetos?
Na maioria dos casos a estimativa era feita com base na experiência dos
gerentes do projeto e da equipe técnica, somente uma das empresas estimava
prazos com a técnica de UCP (Use Case Point).
3. Como era feito o controle das alterações de escopo dos projetos?
No geral não havia um controle sobre as alterações e nem como medir o
impacto destas alterações no escopo.
4. Como era feita a estimativa de custos dos projetos?
Nas empresas que a realizavam a estimativa era feita com base na
experiência dos profissionais envolvidos ou no calculo entre o número de horas
planejado pelos recursos utilizados no projeto, uma vez que o planejamento de
horas também era realizado com base na experiência teríamos aqui uma
estimativa de custos que muitas vezes ficava longe do real custo do projeto.
5. Como era a satisfação do cliente com o processo e os produtos entregues?
Não havia um processo definido para a medição da satisfação do cliente,
porém as empresas alegaram que recebiam muitas reclamações referentes
aos erros que continham no produto final. Com isso podemos entender que
mesmo entregando o produto no prazo a qualidade do mesmo era questionada
pelo cliente.
6. Como era feita a documentação na qual um Analista de Sistemas enviava para
um programador desenvolver um requisito no projeto?
Não existia um padrão de documentação entre os projetos das
organizações, as informações poderiam ser passadas desde um documento
Word até de forma informal, uma conversa entre Analista e Desenvolvedor. A
não definição de um padrão ocasionava muitos erros nos projetos e um
retrabalho muito grande, o que impactava diretamente no prazo e custo do
projeto.
8.2. Pós Implantação de Processo de Qualidade
1. Como é o atual processo de gerenciamento de projetos?
Em todos os casos foram definidos planos de projetos, aonde são
mapeadas todas as fases do projeto, quem serão os responsáveis, uma
definição clara do escopo, plano de riscos, matriz de rastreabilidade de
requisitos, plano de testes, plano de comunicação, cronograma. No geral o
plano de projeto contempla todas as definições do projeto, contemplando todas
as fases e definindo todos os processos que serão realizados e inclusive já
prevenindo os riscos que possam ocorrer no decorrer do projeto.
O Plano de projeto foi criado para que os projetos sejam muito bem
definidos já na sua fase de negociação e planejamento e que é utilizado para a
definição dos novos projetos e manutenção dos já existentes.
2. Como é feita a estimativa de prazos dos projetos?
Cada empresa seguiu para uma linha de estimativa, seja pelo calculo de
UCP ou seja por uma planilha definida internamente com variáveis que sejam
de suma importância para o calculo de horas do projeto.
O importante é que foi definido um processo de qualidade e quantificado
por fatores que agregam valor para uma estimativa de prazo coerente.
O mais importante é que a estimativa de prazos afeta diretamente no
cronograma, pois com uma estimativa de qualidade o cronograma do projeto
passa a ser bem mais realista e fundamentado para uma estimativa muito
próxima do real.
3. Como são gerenciadas as alterações de escopos dos projetos?
No geral agora toda mudança é previamente analisada pelos
responsáveis do projeto, verifica-se qual é o tipo da alteração, verifica-se o
impacto desta alteração no escopo, isto caso a organização possua uma matriz
de rastreabilidade dos artefatos e por fim obtêm-se a aprovação do cliente para
tal alteração já considerando as mudanças no custo e prazo do projeto.
Após todo este processo de análise são realizadas as devidas alterações
no escopo e no cronograma, somente após estes procedimentos é iniciada a
fase de desenvolvimento das alterações necessárias.
4. Como é realizada a estimativa de custos dos projetos?
Agora as organizações têm processos definidos para estimativa do custo
com base nos recursos envolvidos e nas horas que cada recurso irá trabalhar
no projeto. Algumas organizações também levam em consideração os recursos
tecnológicos que serão utilizados assim como todos os treinamentos, viagens e
até mesmo custos de implantação e despesas indiretas (administrativas).
5. Como é medida a satisfação do cliente com o processo e os produtos
entregues?
Na maioria dos casos ainda não possui um processo definido de
medição. Algumas empresas fazem esta medição através da diminuição das
reclamações de erros nos sistemas, que podemos salientar que diminuíram
consideravelmente possibilitando ainda a aquisição de novos contratos de
projetos com os mesmos clientes.
6. Qual é a padronização de documento na qual um Analista de Sistemas envia
para um programador desenvolver um requisito no projeto?
No geral as empresas agora estão utilizando UML (Unified Modeling
Language), como diagrama de classes, especificação de casos de uso, modelo
de testes, protótipos e modelo de dados. Estes documentos diminuíram
consideravelmente os erros de sistema, o re-trabalho e ainda foi possível
aumentar a produtividade da equipe técnica após passar a curva aprendizado
do novo processo.
Algumas organizações ainda possuem revisores destes documentos, o
que diminui ainda mais a ocorrência de erros nos sistemas.
9. CONCLUSÃO
Com este trabalho verificou-se que a percepção e constatação de que a
implantação de um processo de qualidade de software proporciona melhoria no
produto final é cada vez mais evidente.
Isto se reflete na quantidade de empresas que vem adotando um padrão de
qualidade. A concorrência e as exigências do mercado estão obrigando as empresas a
se enquadrar em um novo modelo de desenvolvimento de software, que é o
desenvolvimento através de um processo bem definido, alcançando assim o que
chamamos de processo de qualidade de software.
O que identificamos, na maioria dos casos, foi que esta busca esta sendo
movida não mais em busca de um diferencial de processo/produto, mas sim como
uma forma de sobrevivência para o mercado. Com base nesta afirmação foram
realizados questionários com diversas empresas para identificar qual é o verdadeiro
impacto desta busca pela qualidade nos processos diferenciados das empresas, e
verificou-se que ela realmente é benéfica.
Pela percepção dos pesquisadores, o sucesso de implantação de um processo
de qualidade depende diretamente do apoio da alta gerência da empresa, uma análise
da organização como um todo incluindo aí aspectos culturais, um bom planejamento e
principalmente o comprometimento dos funcionários na manutenção do mesmo após a
implantação. Percebeu-se também que em um primeiro momento o processo
implantado pode gerar uma diminuição na produtividade geral, o que pode ser
explicado pelos controles impostos pelo próprio processo de desenvolvimento. Porém,
em variáveis como prazo, retrabalho, número de defeitos, cronograma é perceptível
algum tipo de mudança para melhor. Com a institucionalização dos processos a
tendência é de aumento na produtividade.
Outro ponto de vista dos pesquisadores após toda a pesquisa efetuada e após
todas as respostas de diferentes empresas foi identificar melhorias nos processos,
definições de padrões de desenvolvimento, elaboração de métricas de
acompanhamento de qualidade e melhoria, entre outros. Tudo isso independente de
qual foi o objetivo que iniciou a busca da qualidade de software pelas empresas.
Enfim, em todas as organizações foi possível identificar uma maior maturidade
nos processos e a busca continua pela melhoria do produto final, tanto nos fatores
qualidade, tempo e custo. Embora o custo e tempo de implantação de um processo de
qualidade sejam altos, ele acaba retornando o investimento no médio e longo prazo
para as organizações.
Nas pesquisas realizadas junto às empresas foi constatada a inexistência de
indicadores consistentes que retratassem o período anterior à implantação dos
modelos de qualidade. Devido a isso, a pesquisa levou em conta a percepção dos
profissionais. Porém pesquisas realizadas mais de uma vez após a implantação de um
processo de qualidade, isto é, em instituições que já internalizaram o processo com
indicadores de medição já definidos, pode verificar-se a melhora nos mesmos. Além
disso, permitiu verificar um crescimento das mesmas, apontado pelos indicadores de
número de funcionários, faturamento e número de clientes. Este crescimento pode
estar ligado à redução nos custos dos projetos e na capacidade de oferecer produtos
com maior qualidade.
Concluindo assim que os processos de qualidade não são apenas tendências de
mercado, mas sim diferencias de desenvolvimento de processo que impactam
beneficamente no custo, tempo e qualidade do seu produto final, trazendo assim
benefícios para as organizações. Dessa forma a instituição de um processo de
qualidade está se tornando um requisito indispensável em empresas de
desenvolvimento de software que desejam ter produtos de qualidade e manter-se num
mercado competitivo.
10. REFERÊNCIAS
[1] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO – SOFTEX. MPS.BR – Guia Geral: 2009, maio 2009. Disponível em
www.softex.br
[2] ISO/IEC 12207:1995/Amd 1:2002/Amd 2:2004. Technology Information –
Software Life Cycle Processes.
[3] ISO/IEC 15504. Technology Information – Process Assessment Part 1 –
Concepts and vocabulary; part 2 – Per-forming an assessment; part 3 – Guidance on
performing an assessment; part 4 –Guidance on use for process improvement and
process capability determination; and part 5 – An exemplar process assessment
model.
[4] Chrissis, M. B., Konrad, M, Shrum, S. CMMI: Guidelines for Process
Integration and Product Improvement, Addison Wesley, 2003.
[5] Weber, K., Araújo, E., Rocha, A. R., Oliveira, K., Rouiller, A. C., Wangenheim,
C. G., Araújo, R., Salviano, C., Macha-do, C. F., Scalet, D., Galarraga, O., Amaral, M.
P., Yoshida, D. “Melhoria de Processo de Software Brasileiro (MPS.BR): Um Programa
Mobilizador”
[6] Rocha, A. C. “Lições Aprendidas em Avaliações MPS”, In: MPS.BR Lições
Aprendidas
[7] Software Engineering Institute. Disponível em http/www.sei.cmu.edu/cmmi/
Acessado no dia 13 de março de 2011.
[8] Benefits of CMMI Within the Defense Industry: Disponível em:
http://www.sei.cmu.edu/library/assets/presentations/CMMI%20Benefits.pdf, acessado
no dia 07 de junho de 2011.
[9] iMPS 2010, Desempenho das Empresas que Adotaram o Modelo MPS de
2008 a 2010:
http://www.softex.br/mpsbr/_livros/arquivos/Softex%20iMPS%202010%20Portugues%
20Baixa.pdf acessado no dia 07 de junho de 2011.
[10] Sally Godfrey (2008) What is CMMI?. Apresentação da NASA. Acessado no
dia 13 Março de 2011.
[11] Pádua, C. F., Mendes, M. S. A busca da qualidade no desenvolvimento de software: http://www.techoje.com.br acessado no dia 22 de abril de 2011.
11. ANEXOS
11.1. RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS
Pré Implantação de Processo de Qualidade
1. Como era o processo de gerenciamento de processos?
Tree Tools: Bom, vou responder como “gerenciamento de projetos”. Não
havia nada formal, nem atividades definidas e nem papel definido.
2. Como era feita a estimativa de prazos dos projetos?
Tree Tools: Já utilizámos a estimativa por UCP – Use Case Points, mas
o seu preenchimento não tinha critérios objetivos, ou seja, dependia de quem
preenchia a planilha.
3. Como era feito o controle das alterações de escopo dos projetos?
Tree Tools: Não havia controle formal e nem formas de avaliar o impacto
sobre as alterações solicitadas.
4. Como era feita a estimativa de custos dos projetos?
Tree Tools: Através de cálculo envolvendo prazo versus recursos
alocados.
5. Como era a satisfação do cliente com o processo e os produtos entregues?
Tree Tools: Na realidade o cliente era pouco afetado, pela política da
empresa, de cumprir sempre os contratos. O maior afetado era a própria Tree
Tools que pagava pela falta de processos, tendo que realizar mais do que o
previsto.
6. Como era feita a documentação na qual um Analista de Sistemas enviava para
um programador desenvolver um requisito no projeto?
Tree Tools: Era informal, sem padrão, as vezes verbal.
Pós Implantação de Processo de Qualidade
1. Como é o atual processo de gerenciamento de processos?
Tree Tools: Para manter a coerência vou responder sobre
“gerenciamento de projetos”. Após a implantação do MPS-BR temos um
processo bem definido para gerenciamento de projetos. Na fase de Iniciação é
feito um Plano do Projeto, com definição clara do escopo, WBS, matriz de
riscos, plano de testes, plano de comunicação, plano de implantação,
cronograma, etc. Durante o projeto são realizadas reuniões de Monitoramento
e Controle onde são tratados em torno de 16 itens, tais como utilização do
processo, riscos, cronograma, etc.
2. Como é feita a estimativa de prazos dos projetos?
Tree Tools: A planilha de UCP foi totalmente reformulada, com critérios
objetivos para que os resultados sejam os mesmos independentemente de
quem a preenche. Além disso, a planilha já distribui todos os tempos de todas
as atividades do cronograma. O cronograma é então inserido na ferramenta
Project Builder, que é atualizado via browser por todos os envolvidos no
projeto.
3. Como são gerenciadas as alterações de escopos dos projetos?
Tree Tools: Uma vez definido o escopo no Plano do Projeto, qualquer
alteração deve ser formalmente solicitada, é feita uma análise de impacto
sobre o projeto em termos de prazo e custo, e se aprovada a solicitação de
mudança é registrada e acompanhada até a sua implantação. Para apoiar a
análise de impacto é utilizada a matriz de rastreabilidade de artefatos,
alimentada nas fases do ciclo de vida do projeto.
4. Como é realizada a estimativa de custos dos projetos?
Tree Tools: Todos os custos são controlados pela ferramenta Project
Builder. Como o principal insumo é pessoa, o custo deste é obtido pela
ferramenta multiplicando o valor da pessoa pela quantidade de horas alocadas
no projeto.
5. Como é medida a satisfação do cliente com o processo e os produtos
entregues?
Tree Tools: Ainda não temos um processo formal desta medição.
Estamos este ano implementando o nível F do MPS-BR que possui a área de
processo chamada Medição. Vamos analisar a possibilidade e formas de
medirmos este indicador.
6. Qual é a padronização de documento na qual um Analista de Sistemas envia
para um programador desenvolver um requisito no projeto?
Tree Tools: O programador recebe a especificação do caso de uso, o
protótipo (quando aplicável), o modelo de dados e o roteiro de testes do caso
de uso.
- A especificação do caso de uso é feita pelo Analista de Sistemas em
MS-Word;
- O protótipo (quando aplicável) é feito pelo Analista de Sistemas
normalmente em HTML ou ZK;
- O modelo de dados é feito pelo Analista de Sistemas em Toad Data
Modeler;
- O roteiro de testes é feito pelo Analista de Testes no Testlink.
11.2. RESPOSTAS QUESTIONÁRIO EMPRESA E-GOVERNE
Pré Implantação de Processo de Qualidade
1. Como era o processo de gerenciamento de Projetos?
Só existia o monitoramento quanto à execução das atividades de
desenvolvimento de software, não existia um planejamento. Não existia o
gerenciamento de riscos e reuniões de acompanhamento de projetos, que causava
muita falha de comunicação.
2. Como era feita a estimativa de prazos dos projetos?
As estimativas eram sempre baseadas na experiência do profissional,
portanto, o mesmo projeto tinha estimativas diferentes sob o ponto de vista de
dois gerentes de projetos.
3. Como era feito o controle das alterações de escopo do projeto?
Simplesmente não havia um controle de mudança de escopo, tudo o que
o cliente solicitava era feito. Isso causava um grande prejuízo para os projetos,
tanto na questão financeira, quanto na motivacional, pois as equipes sempre
faziam horas extras para entregar as demandas, porém o projeto nunca
acabava.
4. Como era a satisfação do cliente com o processo e os produtos
entregues?
Recebíamos muitas reclamações referentes a erros básicos. E em muitas
vezes escutávamos: “Esta funcionalidade estava funcionando na versão
anterior. Como é que pode? Conserta uma coisa e estraga outra.”. Isso
também causava grande desmotivação na equipe do projeto que quanto mais
se empenhava para corrigir problemas, mais erros apareciam.
5. Como era feita a documentação na qual um Analista de Sistemas enviava
para um programador desenvolver um requisito no projeto?
Em alguns projetos, as informações eram repassadas através de um
documento Word, porém, não existia um padrão, cada analista colocava as
informações que julgasse necessário, e na ordem que bem entendesse. Em
outros projetos, não havia documentação, em muitas vezes, a descrição das
atividades era feita por conversa.
Pós Implantação de Processo de Qualidade
1. Como é o atual processo de gerenciamento de projetos?
Existe um modelo de plano de projeto em que o Gerente de Projeto
documenta formalmente todo o planejamento do projeto: escopo, cronograma,
equipe, descrição de atividades, treinamentos necessários para a equipe do
projeto, qual será a forma de homologação, a comunicação entre os principais
envolvidos no projeto, inclusive o cliente, entre outras. Sem contar que
periodicamente, são realizadas reuniões de acompanhamento do projeto com a
equipe, nessas reuniões são analisadas algumas métricas para monitoramento
do projeto, como por exemplo, tendência de atraso, esforço gasto,
porcentagem de conclusão.
2. Como é feita a estimativa de prazos dos projetos?
Hoje utilizamos a estimativa de Pontos por Caso de Uso. Identificamos
todos casos de uso com seu grau de complexidade. Esta estimativa nos tá um
total de horas x, essas horas são distribuídas no cronograma do projeto.
3. Como é gerenciado as alterações de escopo do projeto?
Após a obtenção do comprometimento do cliente com o escopo, toda
mudança, seja inclusão, alteração ou exclusão de requisitos, deve
obrigatoriamente ter uma avaliação dos impactos de mudança. E esses
impactos (aumento de custo e/ou prazo, etc), devem ser acordados com o
cliente. Desta forma não há sustos na entrega do produto.
4. Como é medida a satisfação do cliente com o processo e os produtos
entregues?
Principalmente na diminuição de solicitações de correções de erros e
conseqüentemente na assinatura de novos contratos.
5. Qual é a padronização de documento na qual um Analista de Sistemas
enviava para um programador desenvolver um requisito no projeto?
Existe todo um processo, desde o levantamento do requisito com o
cliente, até seu desenvolvimento através de linhas de código. Depois de
mapeados todos os casos de uso, esses são especificados em um documento
padrão, que após sua elaboração, é revisado por outro profissional com
mesmo perfil do que especificou o caso de uso. Essa padronização facilitou a
localização de informações dentro do documento e garantiu que todas as
informações necessárias para a codificação do caso de uso estão presentes no
documento.
11.3. RESPOSTAS QUESTIONÁRIO EMPRESA GUENKA
Pré Implantação de Processo de Qualidade
1. Como era o processo de gerenciamento de processos?
◦ Não havia um processo definido para o gerenciamento de processos.
2. Como era feita a estimativa de prazos dos projetos?
◦ Com base na opinião e experiência dos gerentes de projetos e pessoal
técnico.
3. Como era feito o controle das alterações de escopo dos projetos?
◦ Alterados conforme demanda do cliente, sem procedimentos de análise de
impacto.
4. Como era feita a estimativa de custos dos projetos?
◦ Com base na opinião e experiência dos gerentes de projetos e pessoal
técnico identificava-se o esforço necessário, com isso calculava-se o custo
que demandaria para recursos humanos e infra-estrutura.
5. Como era a satisfação do cliente com o processo e os produtos entregues?
◦ Nunca foi medida.
6. Como era feita a documentação na qual um Analista de Sistemas enviava para
um programador desenvolver um requisito no projeto?
◦ Uma documentação muito superficial, o Programador sempre necessitava
da presença do Analista de Sistemas para sanar dúvidas em relação ao
documentado.
Pós Implantação de Processo de Qualidade
1. Como é o atual processo de gerenciamento de processos?
◦ Há um responsável por coordenar o processo de melhoria, o qual conta
com grupos de analista, programadores e tester para apoiar no
desenvolvimento de novos processos e ajustes dos já existentes.
2. Como é feita a estimativa de prazos dos projetos?
◦ Uma metodologia baseada na complexidade dos requisitos foi criada, mas
ainda permanece a opinião especializada, visto que ainda não há uma base
sólida de informações referentes as medições realizadas.
3. Como são gerenciadas as alterações de escopos dos projetos?
◦ Hoje qualquer mudança de escopo deve ser analisada por um comitê, que
aprova ou não a alteração, sempre levando em conta o impacto e o custo.
4. Como é realizada a estimativa de custos dos projetos?
◦ Com base no esforço obtido pela metodologia de complexidade dos
requisitos, o custo é estimado, mais ainda é considerada a opinião
especializada, visto que não há uma base sólida de informações
provenientes das medições.
5. Como é medida a satisfação do cliente com o processo e os produtos
entregues?
◦ Ainda não está sendo medida.
6. Qual é a padronização de documento na qual um Analista de Sistemas envia
para um programador desenvolver um requisito no projeto?
◦ Diagrama de casos de uso, descrição dos casos de uso, diagramas de
classes e protótipos de telas.
11.4. RESPOSTAS QUESTIONÁRIO EMPRESA NVI
Pré Implantação de Processo de Qualidade
1. Como era o processo de gerenciamento de processos?
Antes da implementação do Modelo MPS.BR, a NVi já tinha implantado
processos na área de desenvolvimento de software, devido à certificação
ISO9001:2000.
Nos processos estava prevista a realização de Análise Crítica em determinadas
etapas dos projetos, para garantir o gerenciamento das mesmas e tomadas de ações
corretivas, porém com menor detalhamento.
2. Como era feita a estimativa de prazos dos projetos?
Não havia uma ferramenta formal para esta finalidade. Os prazos eram
estimados considerando a experiência da equipe em projetos anteriores, porém não
eram agregados tempos de testes, planejamento, monitoramento, passagem de
código entre ambientes, etc.
Isso ocasionava a entrega do produto no prazo, porém com erros devido à
pressa em desenvolver dentro do prazo estipulado e com custo adicional pelo trabalho
realizado em horário extraordinário.
3. Como era feito o controle das alterações de escopo dos projetos?
As mudanças eram requisitadas por e-mail ou discutidas em reuniões cuja
formalização constava em atas. Não havia um documento específico de escopo. O
detalhamento do escopo estava parte no documento de análise do projeto e parte na
proposta comercial, mas não era completo.
4. Como era feita a estimativa de custos dos projetos?
Não havia controle de custos de projetos.
5. Como era a satisfação do cliente com o processo e os produtos entregues?
A satisfação com as funcionalidades e prazos de entrega era boa. Havia
reclamações quanto a quantidade de erros (já que o cumprimento do prazo era
mascarado pela falta de testes mais consistentes).
Como a empresa tinha implantado a ISO, as reclamações eram tratadas por
Ações Corretivas e a satisfação era freqüentemente avaliada por pesquisa formal
implementada pela ISO.
6. Como era feita a documentação na qual um Analista de Sistemas enviava para
um programador desenvolver um requisito no projeto?
Por um formulário interno de Especificação Técnica contendo as regras de
negócio, tratamento de campos, criação de novas tabelas ou campos nas estruturas
do banco de dados e imagem de telas.
Pós Implantação de Processo de Qualidade
1. Como é o atual processo de gerenciamento de processos?
A definição dos processos continua seguindo as normas ISO9001:2000,
complementadas com as exigências do Modelo MPS.BR.
O processo de desenvolvimento de software foi segmentado para contemplar a
Gerência de Requisitos e Gerência de Projeto.
A cada fase do ciclo de vida do projeto o gerenciamento é registrado nas
Revisões de Marco. Durante a fase de desenvolvimento o gerenciamento é registrado
nas atas de reuniões de monitoramento, em geral semanais.
Nas reuniões de monitoramento são acompanhadas as realizações das
atividades do cronograma, os riscos que podem causar atrasos no projeto e
respectivas ações, quando necessárias e a necessidade de alocação de novos
recursos.
As mudanças no escopo do projeto são também analisadas nas reuniões de
monitoramento quanto ao seu impacto no projeto e quanto às alterações nos
documentos (rastreabilidade, cronograma, estimativa de esforço e prazo, custos, etc).
Um re-planejamento do projeto é estabelecido e acompanhado até conclusão final das
ações.
2. Como é feita a estimativa de prazos dos projetos?
Com base na experiência da equipe, foi desenvolvida uma ferramenta interna,
em planilha, para estimativa de esforço e prazo para os projetos.
Na ferramenta foram incluídos os itens que antes não eram computados no
esforço: planejamento, monitoramento, testes, preparação de ambiente, passagem de
código e geração de scripts.
A opção por desenvolver ferramenta interna para essa finalidade se baseou na
falta de experiência da empresa com ferramentas de mercado, o que poderia levar a
escolhas erradas além dos custos envolvidos. A opção foi acertada, tanto que, em
mais de um ano de uso, as estimativas tiveram apenas duas revisões e o desvio
padrão entre o esforço estimado e o realizado, não passou de 20%.
3. Como são gerenciadas as alterações de escopos dos projetos?
São registradas no documento de análise, onde são detalhados o escopo,
limites, requisitos e análise das regras. O versionamento do documento é alterado e
enviado para análise e aprovação do cliente. Após retorno é passado para a equipe
técnica que trata as alterações como mudança de projeto, devidamente registrada no
documento de gerenciamento/monitoramento do projeto (vide pergunta 1).
4. Como é realizada a estimativa de custos dos projetos?
Foi desenvolvida ferramenta interna, em planilha, para controle dos custos. Além
dos recursos humanos envolvidos no projeto, são também inseridos recursos
tecnológicos, viagens para treinamento e implantação e despesas indiretas
(administrativas).
Ao final do projeto, são apurados os recursos e esforços efetivamente gastos,
através do gerenciamento, para cálculo do custo final realizado.
5. Como é medida a satisfação do cliente com o processo e os produtos
entregues?
Pela análise de indicadores de erros reportados pelo cliente, após entrega do
projeto. Os indicadores de erros já eram acompanhados por exigência da ISO e novos
indicadores foram criados após implementação do MPS.BR.
Com o esforço da atividade de testes incorporada aos projetos, os erros foram
reduzidos substancialmente.
6. Qual é a padronização de documento na qual um Analista de Sistemas envia
para um programador desenvolver um requisito no projeto?
Continuamos com o mesmo documento utilizado antes da implementação do
Modelo MPS.BR. Acrescentamos apenas o registro de revisão da especificação
técnica por outro colaborador da equipe técnica, para garantir a consistência entre o
mesmo e o documento de análise do projeto, onde constam os requisitos aprovados
pelo cliente.