A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O … · RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27. ... a definição foi à norma ISSO/IEC 12207 [2], ... de processo apresentados

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

ÍNDICE DE TABELAS

Tabela 1 - Níveis de maturidade MPS 13

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.

http://http/www.sei.cmu.edu/cmmi/

http://www.sei.cmu.edu/library/assets/presentations/CMMI%20Benefits.pdf

[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.

http://www.techoje.com.br/

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.


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.


Tree Tools: Não havia controle formal e nem formas de avaliar o impacto

sobre as alterações solicitadas.


Tree Tools: Através de cálculo envolvendo prazo versus recursos

alocados.


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.



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.


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.


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.


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.


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.



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


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.


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


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.


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.


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.


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



◦ Não havia um processo definido para o gerenciamento de processos.


◦ Com base na opinião e experiência dos gerentes de projetos e pessoal

técnico.


◦ Alterados conforme demanda do cliente, sem procedimentos de análise de

impacto.


◦ 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.


◦ Nunca foi medida.



◦ 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.



◦ 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.


◦ 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.


◦ 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.


◦ 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.


entregues?

◦ Ainda não está sendo medida.



◦ 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



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.


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.


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.


Não havia controle de custos de projetos.


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.



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.



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.


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%.


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).


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.


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.



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.

Documents

A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O … · RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27. ... a definição foi à norma ISSO/IEC 12207 [2], ... de processo apresentados