CLAUDIO TESTONI CARDOZO

SISTEMA DE ENSINO PRESENCIAL CONECTADOPROCESSOS GERENCIAIS

SISTEMÁTICA DE PRODUÇÃO DE SOFTWARESLinha de Produção de Softwares baseado na ISO9001:2008

Caxias do Sul2009

SISTEMÁTICA DE PRODUÇÃO DE SOFTWARESLinha de Produção de Softwares baseado na ISO9001:2008

Trabalho de Conclusão de Curso apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção do título de Tecnólogo em Processos Gerenciais.

Orientador: Prof. Fábio Goulart de Andrade

CLAUDIO TESTONI CARDOZO

Caxias do Sul2009

Caxias do Sul, 20 de novembro de 2009

Dedico este trabalho ao meu filho que, por

várias vezes me questionou, por cima do meu

ombro, quando o mesmo ficaria pronto...

AGRADECIMENTOS

Ao Prof. Alexandre Menoncim, que pôde me apoiar e me guiar em

meus erros e acertos em todos os trabalhos e atividades desenvolvidas.

Ao Prof. Fábio Goulart de Andrade, que corretamente me orientou

na elaboração deste trabalho.

A todos os meus tutores eletrônicos dos semestres anteriores, e

também a todos os tutores de sala que tive, em cada um dos semestres que cursei,

que me apoiaram, me ouviram e me criticaram de forma sempre construtiva.

A todos os meus colegas do curso, aos que permaneceram comigo

desde o início, aos que, por seus motivos próprios não continuaram o curso e aos

novos colegas que conheci ao passar dos semestres.

"Estratégia é a arte ou ciência de saber identificar e empregar meios disponíveis para atingir determinados fins, apesar de a eles se oporem obstáculos e/ou antagonismos conhecidos." Sun Tzu

CARDOZO, Claudio Testoni. SISTEMÁTICA DE PRODUÇÃO DE SOFTWARES: Linha de Produção de Softwares baseado em ISO9001:2008. 2009. 23 páginas. Trabalho de Conclusão de Curso (Graduação em Processos Gerenciais) – Centro de Ciências Empresariais e Sociais Aplicadas, Universidade Norte do Paraná, Caxias do Sul, 2009.

RESUMO

Em processo de grande expansão econômica, o mercado brasileiro vêm buscando um forte posicionamento no mercado de softwares de computador. É possível observar o grande crescimento deste mercado, atendendo clientes de diversos segmentos. Uma das principais características deste modelo é a adoção de técnicas utilizadas na engenharia industrial de produção em série, para a criação de um ambiente produtivo de desenvolvimento de software com qualidade e baixo custo. Os avanços da engenharia de software nos últimos anos permitiram a criação de diversas metodologias de produção, que se assemelham em diversos aspectos à norma NBR ISO 9001:2008, a qual será a base de todo o desenvolvimento deste trabalho, observando seus requisitos e apontando, nos diversos aspectos do processo de produção de software, onde o mesmo é aplicado. A prática de utilizar uma metodologia nacional representa uma redução de custo considerável em comparação às normas de produção de software conceituadas internacionalmente, a exemplo da metodologia CMMi, uma vez que a mesma possui facilidades de capacitação e organismos certificadores residentes no Brasil, e também promove uma garantia de qualidade à produção elaborada, pois estabelece um rígido controle de análise de indicadores e organização de processos.

Palavras-chave: ISO 9001. CMMi. SEI. Produção. Fábrica. Software. Desenvolvimento.

CARDOZO, Claudio Testoni. SISTEMÁTICA DE PRODUÇÃO DE SOFTWARES: Linha de Produção de Softwares baseado em ISO9001:2008. 2009. 23 páginas. Trabalho de Conclusão de Curso (Graduação em Processos Gerenciais) – Centro de Ciências Empresariais e Sociais Aplicadas, Universidade Norte do Paraná, Caxias do Sul, 2009.

ABSTRACT

In the economic boom process, Brazil seeks a strong position in the computer software market. It is possible to see the great growth of this market, serving customers in various segments. A key feature of this model is the adoption of techniques used in the industrial production engineering series, to create a productive environment for developing quality software at low cost. Advances in software engineering in recent years have enabled the creation of various production methodologies, which are similar in many aspects to the standard NBR ISO 9001:2008, which will be the basis for any development of this work, observing their requirements and pointing at the various aspects of the software production process, where it is applied. The practice of using a national methodology represents a considerable cost reduction in comparison to the production standards of reputable software internationally, such as the CMMi methodology, since the same has facilities for training and certifying centers residents in Brazil, and also promotes a quality assured production development, establishing a strict control analysis of indicators and organization processes.

Key-words: Software. Production. CMMi. NBR. ISO 9001. Development.

LISTA DE GRÁFICOS

Gráfico 1: Macro-fluxo de produção de software.......................................................25Gráfico 2: Macro-fluxo de produção com respectivos realizáveis..............................26Gráfico 3: Fluxo de entrada de uma requisição de software......................................28Gráfico 4: Planejamento estratégico..........................................................................29Gráfico 5: Fluxo de entrada do projeto de desenvolvimento......................................31Gráfico 6: Fluxo de avaliação de projetos de software..............................................33Gráfico 7: Fluxo de aceite e revisões de projeto (Verificação)...................................34Gráfico 8: Fluxo de validação de produtos de software.............................................36Gráfico 9: Avaliação de falhas encontradas em testes de softwares.........................37Gráfico 10: Análise de abrangência de falhas...........................................................38Gráfico 11: Controle de alterações em produtos.......................................................40Gráfico 12: Testes de regressão................................................................................41Gráfico 13: Desempenho quantitativo de produção...................................................44Gráfico 14: Índices chave de desempenho de processos.........................................46

LISTA DE TABELAS

Tabela 1: Normas Técnicas.......................................................................................18Tabela 2: Histórico da qualidade de software............................................................21Tabela 3: Pré-requisitos para conclusão de projetos de software.............................32Tabela 4: Exemplo de controle de revisões de projetos............................................35Tabela 5: Análise de melhoria de qualidade de software..........................................37

LISTA DE QUADROS

Quadro 1: Fatores explítitos.......................................................................................19Quadro 2: Fatores implícitos......................................................................................20Quadro 3: Indicadores de qualidade..........................................................................43

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associação Brasileira de Normas Técnicas

UNOPAR Universidade Norte do Paraná

NBR Norma Brasileira

ISO International Organization for Standardization

CMMi Capability Maturity Model Integration

SEI Software Engineering Institute

IDG International Data Group

ABES Associação Brasileira das Empresas de Software

PDP Planejamento e Desenvolvimento de Produtos

SQG Sistema de Gestão da Qualidade

SUMÁRIO

1 INTRODUÇÃO.........................................................................................14

2 DESENVOLVIMENTO.............................................................................16

2.1 Qualidade de software.............................................................................172.1.1 Fatores explícitos.....................................................................................192.1.2 Fatores implícitos.....................................................................................202.2 Histórico da Qualidade de Software.........................................................212.3 Importância da Qualidade de Software....................................................222.4 Métricas da Qualidade de Software.........................................................232.4.1 Métricas Internas.....................................................................................232.4.2 Métricas Externas....................................................................................242.5 Processo de Produção de Softwares.......................................................252.6 Produção de softwares alinhado à ISO 9001:2008..................................262.6.1 Item 7.3.1: Planejamento do projeto e desenvolvimento.........................282.6.2 Item 7.3.2: Entradas de projeto e desenvolvimento.................................302.6.3 Item 7.3.3: Saídas de projeto e desenvolvimento....................................312.6.4 Item 7.3.4: Análise crítica de projeto e desenvolvimento.........................322.6.5 Item 7.3.5: Verificação de projeto e desenvolvimento.............................332.6.6 Item 7.3.6: Validação de projeto e desenvolvimento...............................352.6.7 Item 7.3.7: Controle de alterações...........................................................392.6.8 Item 8: Medição, análise e monitoramento..............................................412.6.8.1 Indicadores de satisfação do mercado....................................................422.6.8.2 Indicadores de produtividade e produção................................................432.6.8.3 Índices chave de desempenho de processos..........................................453 CONCLUSÃO..........................................................................................47

APÊNDICES..............................................................................................................49

APÊNDICE A – Formulário de requisição de novas solicitações de sistemas...........50

1 INTRODUÇÃO

Estabelecer os processos e a sistemática de uma linha de produção

de softwares, baseada na norma ABNT NBR 9001:2008, estabelecendo o software

desenvolvido como sendo um produto sendo projetato, desenvolvido, testado e

entregue ao mercado.

O mercado de softwares vêm crescendo muito nos últimos anos, e

as projeções deste mercado apontam um crescimento bastante promissor para o

Brasil, neste nicho de negócio.

Segundo IDG, 2009: “Um levantamento encomendado pela ABES

(Associação Brasileira das Empresas de Software) e realizado pela consultoria IDC

indica que o mercado nacional de softwares e serviços é o 12º maior do mundo,

movimentando 7,41 bilhões de dólares em 2005.

A expectativa da IDC e da ABES é que o segmento mantenha um

crescimento médio de 11% até 2009, indica a pesquisa”

Com o crescimento da demanda por softwares no mercado

brasileiro, também ocorreu o crescimento de empresas (oferta) para este nicho de

mercado, principalmente, empresas de pequeno porte, com poucos funcionários,

elaborando e desenvolvendo sistemas para os seus clientes.

Para que possamos alinhar às expectativas dos clientes, que

buscam softwares com qualidade, confiabilidade e segurança, é necessário que a

produção destes esteja alinhada à modelos que permitam aos fabricantes atingir

este tipo de excelência.

Existem vários modelos atualmente, que permitem ao fabricante

adotar práticas afim de garantir prazos e qualidade no processo de produção de

softwares. Neste trabalho, iremos abordar o processo de desenvolvimento de

softwares utilizando por base a norma ABNT NBR ISO9001:2008.

A norma ABNT NBR ISO9001:2008 é um documento técnico da

ABNT (Associação Brasileira de Normas Técnicas), que promove a adoção de uma

abordade de processo para o desenvolvimento, implementação e melhoria da

eficácia de um sistema de gestão da qualidade para aumentar a satisfação do

14

cliente pelo atendimento aos seus requisitos.

Segundo ISO9001: “Para uma organização funcionar de maneira

eficaz, ela tem que determinar e gerenciar diversas atividades interligadas. Uma

atividade ou conjunto de atividades que usa recursos e que é gerenciada de forma a

posibilitar a transformação de entradas em saídas pode ser considerada um

processo. Frequentemente a saída de um processo é a entrada para o processo

seguinte.”

Assim, abordando todos os conceitos de produção de software,

estruturas de projeto de softwares, levantamento de requisitos, processo de

produção de softwares em série, sistemática de documentação, alinhamento dos

produtos desenvolvidos com as expectativas dos clientes, testes e garantia de

qualidade, bem como distribuição dos mesmos ao mercado, estaremos analisando e

cobrindo todos os requisitos impostos pela norma ABNT NBR ISO9001:2008 em

uma fábrica de softwares.

15

2 DESENVOLVIMENTO

Poucas vezes se encontram na literatura definições claras para

software. Convivemos com um suposto consenso sobre o seu significado: é como

se todos soubessem o que é software e não fosse necessário definí-lo. Observam-

se, no entanto, grandes dificuldades para a identificação de suas características

próprias (tanto quanto do processo para seu desenvolvimento), o que pode ser

atribuído, em boa medida, a esta indefinição.

Os conceitos de qualidade discutidos requerem um esforço de

interpretação e adaptação para sua aplicação ao desenvolvimento e à manutenção

de software, devido às características peculiares desse tipo de produto e de seu

processo de desenvolvimento.

A engenharia de produção de software é considerada uma das áreas

mais importantes desta década, devido à crescente disseminação do uso do

software, como parte integrante das mais variadas áreas da sociedade. Entretanto o

desenvolvimento, manutenção e demais tarefas relacionadas ao software, são

relativamente novos se comparadas às áreas tradicionais da engenharia. Como

resultado, não há na produção de software o mesmo rigor existente nos projetos

tradicionais de engenharia. Assim, existe um nível elevado de insatisfação com o

software, tanto por parte dos usuários, que não vêem as suas necessidades

atendidas, quanto com relação à organização que o desenvolve, por não conseguir

torná-lo econômica e comercialmente viável. (BARRETO, 2007)

16

2.1 QUALIDADE DE SOFTWARE

A qualidade de software é cada vez mais importante e determinante

na escolha de um produto. Qualidade de software pode ser definida como: “O

conjunto de características a serem satisfeitas em determinado grau de modo que o

software satisfaça as necessidades de seus usuários”. (ROCHA, 2000).

“Qualidade é uma condição essencial de qualquer software, sendo uma

preocupação básica da Engenharia de Software identificar os requisitos de

qualidade e estabelecer os mecanismos para controlar o processo de

desenvolvimento de software, de forma a garantir a qualidade do produto.”

(STAHL, 1988).

Segundo BARRETO (2007), atualmente existe uma série de normas

de qualidade de software. As principais normas nacionais e internacionais são: ISO

9126, NBR 13596 (versão brasileira da ISO 9126), ISO 14598, ISO 12119, IEEE

P1061, ISO 12207, NBR ISO 9001, NBR ISO 9000-3, NBR ISO 10011, CMM, SPICE

ISO 15504.

17

Tabela 1: Normas TécnicasNORMA DESCRIÇÃO

ISO 9126 Características da qualidade de produtos de software.

NBR 13596 Versão brasileira da ISO 9126

ISO 14598 Guias para a avaliação de produtos de software, baseados na utilização prática da norma ISO 9126.

ISO 12119 Características de qualidade de pacotes de software (software de prateleira, vendido com um produto embalado).

IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software).

ISO 12207 Software Life Cycle Process. Norma para a qualidade do processo de desenvolvimento de software.

NBR ISO 9001 Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica (processo).

NBR ISO 9000-3 Gestão de qualidade e garantia de qualidade. Aplicação da norma ISSO 9000 para o processo de desenvolvimento de software.

NBR ISO 10011 Auditoria de Sistemas de Qualidade (processo).

CMM Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software do Departamento de Defesa dos EEUU) para avaliação da qualidade do processo de desenvolvimento de software. Não é uma norma ISO, mas é muito bem aceita no mercado.

SPICE ISO 15504 Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software. Ainda não é uma norma oficial ISO, mas o processo está em andamento.

18

2.1.1 Fatores explícitos

Os fatores explícitos são externados pelo cliente. É o cliente quem

define a qualidade, bem como a qualidade dos projetos / processos, qualidade do

produto final, manutenções corretivas, adaptativas e introdução de melhorias no

produto, como mostra o Quadro 1.

Quadro 1: Fatores explítitos

19

2.1.2 Fatores implícitos

Os fatores implícitos dizem respeito aos fatores da qualidade de

software, que é percebido pelo fabricante, e que atendem aos fatores explícitos e

principalmente à produção econômica do software, como mostra o Quadro 2.

Quadro 2: Fatores implícitos

20

2.2 HISTÓRICO DA QUALIDADE DE SOFTWARE

O assunto que refere-se a qualidade de software, com o decorrer

dos anos, vem aumentando, como pode ser observado na Tabela 2.

Tabela 2: Histórico da qualidade de software

1950 A qualidade era vista simplesmente como uma verificação se o produto estava pronto.

1960 Incluída a atividade de testes.

1970 Inicia-se a verificação do cumprimento de normas definidas para as diversas atividades.

1980 O controle da qualidade de software é visualizado como uma atividade de todo o ciclo de vida do desenvolvimento do produto.

1990 A qualidade de software é considerada uma necessidade. Iniciou-se os primeiros trabalhos de publicação de normas da qualidade.

2000Começa-se a verificar que a maioria dos softwares desenvolvidos não entra no mercado sem que passe por rigorosos testes para assegurar a qualidade dos mesmos.

Fonte: Silva (1999)

21

2.3 IMPORTÂNCIA DA QUALIDADE DE SOFTWARE

A qualidade, hoje em dia, é essencial para a sobrevivência e o

sucesso de empresas de software. Uma organização não sobressairá tanto no

mercado nacional quanto no mercado global a menos que produza software de boa

qualidade e seus clientes percebam seus produtos e serviços como sendo de boa

qualidade (Sanders, 1994).

O controle na qualidade do software é um conjunto planejado e

sistemático de testes de todas as situações necessárias para fornecer confiança

adequada, da qual o produto está de acordo com os requisitos técnicos

estabelecidos.

Por Antonioni (1995), a utilização de sistemas de qualidade tem sido

baseada, geralmente, nas normas desenvolvidas pela International Organization for

Standardization – Organização Internacional de Padrões (ISO), denominadas de

normas série ISO 9000.

22

2.4 MÉTRICAS DA QUALIDADE DE SOFTWARE

Existe uma área de estudos à parte dentro da qualidade de software

denominada de métricas de software. A função é definir, de forma precisa, como

quantificar numericamente uma determinada característica. Essas métricas estão

definidas em externas e internas.

2.4.1 Métricas Internas

É uma escala quantitativa e o método que pode ser utilizado para

medir diretamente um atributo ou uma característica do software. Essa parte é

especialmente útil para desenvolvedores e alguns avaliadores que podem obter

materiais internos tais como especificações – os quais determinam os requisitos de

um software – e código fonte.

Essa parte proporciona uma coleção de métricas internas e alguns

guias para seu uso. Cada métrica pode ser aplicável para medir um atributo interno

do produto de software. Também proporciona características internas e modelo da

qualidade que mostram a relação entre eles como um guia. Essa métrica é útil como

definição dos objetos do projeto e revisão de produtos intermediários, pode ser

usada como referência para o desenvolvimento de métricas novas, e para pesquisas

gerais e estudos.

A documentação que padroniza as definições de características da

qualidade e métricas que são recomendadas para serem usadas na avaliação e

especificação dos requisitos da qualidade são encontradas nas normas ISO/IEC,

disponíveis através do site da Associação Brasileira de Normas Técnicas no

endereço eletrônico: www.abnt.com.br para maiores detalhes.

23

2.4.2 Métricas Externas

É uma escala quantitativa e o método que pode ser usado para

medir uma característica ou sub-característica do software independente do

comportamento do sistema que contém o software. Essa parte pode ser usada pelos

desenvolvedores, avaliadores, compradores e pelos usuários. Cada métrica pode

ser aplicada para medição de uma característica de qualidade, uma sub-

característica ou um atributo externo de um produto de software. Essas métricas

externas, resumem-se na especificação de requerimentos da qualidade, na

avaliação de qualidade de produtos no teste final, e no teste de aceitação. Essa

métrica pode ser utilizada como referencia para o desenvolvimento de novas

métricas, e para pesquisas e estudos em geral.

24

2.5 PROCESSO DE PRODUÇÃO DE SOFTWARES

No processo de produção de softwares, podemos observar um

macro-fluxo estabelecido entre a requisição (solicitação do cliente) até a entrega do

produto de softwares pronto ao mesmo.

A requisição do cliente pode ser considerada a ENTRADA deste

processo, que por sua vez têm como resultado a entrega e posterior ACEITE do

cliente em relação ao produto desenvolvido.

Gráfico 1: Macro-fluxo de produção de software

Conforme observamos no Gráfico 1, o início do processo de

produção é chamado de Levantamento de Requisitos. Após o Levantamento de

Requisitos, as atividades de elaboração, produção, homologação e entrega são

realizados. Para cada etapa do processo, existem processos que são desenvolvidos

pela engenharia de softwares que correspondem à concretização de cada um dos

25

itens, como pode ser visto no Gráfico 2.

Gráfico 2: Macro-fluxo de produção com respectivos realizáveis

2.6 PRODUÇÃO DE SOFTWARES ALINHADO À ISO 9001:2008

JURAN (1992, P. 4) define o desenvolvimento de produtos como

“uma etapa da espiral da qualidade que traduz as necessidades do usuário,

descobertas por intermédio de informações de campo, num conjunto de requisitos

do projeto do produto para a fabricação”.

Para KRUGLIANSKAS (1992), “muitas empresas brasileiras

desenvolvem seus produtos empiricamente, utilizando um sistema de informações

deficiente, que muitas vezes repete os mesmos erros de projeto”. Reforça Fiod

(1993), que o projeto de produtos, para quem quer se manter competitivo, não deve

ser desenvolvido como atividade intuitiva, empírica e de tentativa e erro, mas deve

ser desenvolvido apoiado em método sistêmico com forte embasamento científico. A

norma NBR ISO 9001:2008, orienta quais são os elementos básicos deste método

sistêmico.

A utilização de método sistêmico no processo de desenvolvimento

de produtos permite direcionar os recursos para satisfazer os clientes; oferecer um

produto de qualidade dentro do prazo a custo competitivo; e reduzir o desperdício

normalmente gerado por alterações tardias, erros, diversidade desnecessária de

26

produtos, excessiva complexidade do produto e burocracia.

A repetibilidade do processo de desenvolvimento de produtos tem

maior probabilidade de ser concretizada se existir o padrão de sistema. Entende-se

por padrão de sistema a descrição das etapas do processo de desenvolvimento de

produtos, as técnicas a serem utilizadas e os setores envolvidos, ou seja, o

estabelecimento do método, das técnicas e do nível de autoridade e

responsabilidade.

Para DESCHAMPS e NAYAK (1997), o planejamento estratégico é

importante, pois nele se determinam como e com que freqüência a organização

pretende competir com novos produtos. O processo do planejamento estratégico é

integrador, pois combina planos para o produto e para o desenvolvimento

tecnológico. Tal processo leva ao ciclo de planejamento específico de produtos para

determinar quais novos produtos serão introduzidos e em que época. O plano de

desenvolvimento busca definir como a capacidade de desenvolvimento da empresa

poderá satisfazer a nova demanda de produtos.

A norma ISO9001:2008 considera uma série de requisitos de

aderência para aceitação do processo adotado pela empresa como compatível com

a mesma.

Não todos, porém, uma parte dos seus requisitos, numerados como

“itens”, referem-se especificamente à linha de produção. Conforme observado no

estágio in-loco na empresa Constat, e na sequência deste trabalho, será possível

criar uma análise metodológica de processo estabelecido entre cada um dos

requisitos, ou itens, impostos pela norma, e sua aderência ao processo de software

adotado pela mesma.

27

2.6.1 Item 7.3.1: Planejamento do projeto e desenvolvimento

De acordo com ISO9000 (2008), “A organização deve planejar e

controlar o projeto e desenvolvimento do produto. Durante o planejamento do projeto

e desenvolvimento, a organização deve determinar:

a) As etapas do projeto e desenvolvimento;

b) As revisões, verificações e validações que sejam apropriadas a

cada etapa do projeto e desenvolvimento;

c) As responsabilidades e autoridades para o projeto e

desenvolvimento.

A organização deve gerir a comunicação entre os diferentes grupos

envolvidos no projeto e planejamento para assegurar comunicação eficaz e clara

atribuição de responsabilidades.

A saída do planejamento deve ser atualizada, conforme for

apropriado, à medida que o projeto e desenvolvimento evoluírem.”

O planejamento do projeto e desenvolvimento do mesmo permite

avaliar a forma como é estabelecida a estratégia de evolução dos produtos, e o

alinhamento desta estratégica com as necessidades do mercado.

No Gráfico 3 abaixo, podemos observar que existe 2 possíveis

entradas para o desenvolvimento de alguma novo produto pela empresa:

Gráfico 3: Fluxo de entrada de uma requisição de software

28

Planejamento Estratégico: É o planejamento empresarial definido

anualmente pela empresa Constat que estabelece as diretrizes e estratégias para

alcançar suas metas. Este planejamento também define funcionalidades e novos

recursos que os produtos devem passar a ter, para adaptação ao mercado atual,

alcance de novos mercados e evolução tecnológica. No Gráfico 4, pode ser

observado o planejamento estratégico utilizado pela empresa – as metas financeiras

foram retiradas deste gráfico por questões de confidencialidade estratégica da

organização estudada – no padrão da ferramenta BSC (Balanced Scored Card)

onde é possível observar na cor verde, os blocos que correspondem à novas

funcionalidades e novos recursos a serem desenvolvimento para manutenção da

competitividade dos seus produtos no mercado ao qual atua. Cada um dos recursos

listados são oficializados através de formulários criados especificamente para a

documentação de “User Stories”, que é a entrada dos projetos de produção de

software da empresa.

Gráfico 4: Planejamento estratégico

Solicitação de clientes: É uma requisição de mudança, novo recurso,

ou melhoria no produto, solicitado por um cliente externo, diretamente à empresa

fabricante, para adequação do sistema à alguma mudança ou evolução do uso do

29

software / produto no processo deste cliente. A solicitação é estabelecida através de

uma requisição formal, pelo preenchimento de um formulário de requisição

específico para determinar o que o cliente está pedindo, e permitir a análise quando

a sua viabilidade técnica, comercial e estratégica do produto (APÊNDICE A).

2.6.2 Item 7.3.2: Entradas de projeto e desenvolvimento

De acordo com ISO9000 (2008), “Devem ser determinadas as

entradas relativas aos requisitos do produto e mantidos os correspondentes registros

(ver 4.2.4). Estas entradas devem incluir:

a) Requisitos funcionais e de desempenho;

b) Requisitos estatutários e regulamentadores aplicáveis;

c) Onde aplicável, informação resultante de projetos anteriores

semelhantes;

d) Outros requisitos essenciais para o projeto e desenvolvimento.

As entradas devem ser revistas quanto à sua adequação. Os

requisitos devem ser completos, sem ambiguidades e não estar em conflito entre si.”

Segundo VERITAS (2009), o documento referenciado no APÊNDICE

A preenche este requisito da norma, como sendo o formato de entrada do projeto de

planejamento de um novo produto, ou alteração no mesmo.

Para automatizar o fluxo do processo de desenvolvimento, a

empresa Constat adotou a ferramenta Qualitor (o qual é desenvolvida pela própria

empresa) como sendo a ferramenta de apoio ao processo de solicitação e

gerenciamento do workflow de projetos e demandas.

A empresa Constat também desenvolveu um ambiente de auto-

atendimento aos seus atuais clientes, que permite aos mesmos preencher o

formulário de requisição de sistemas, e este por sua vez é entregue ao sistema

Qualitor que faz o tratamento do mesmo dentro do processo de desenvolvimento.

30

Gráfico 5: Fluxo de entrada do projeto de desenvolvimento

2.6.3 Item 7.3.3: Saídas de projeto e desenvolvimento

De acordo com ISO9000 (2008), “As saídas do projeto e

desenvolvimento devem ser apresentadas de uma forma adequada à verificação por

comparação com as entradas para o planejamento e o desenvovlimento e devem

ser aprovadas antes de emitidas.

As saídas do projeto e desenvolvimento devem:

a) Ir ao encontro dos requisitos das entradas para o projeto e

desenvolvimento;

b) Proporcionar informação apropriada para comprar, produzir e

fornecimento do serviço;

c) Conter ou referir critérios de aceitação do produto;

d) Especificar as características do produto que são essenciais na

sua utilização segura e apropriada.

Nota: A informação para a produção e o fornecimento do serviço pode

incluir detalhes para a preservação do produto.”

As saídas do projeto de desenvolvimento consistem na elaboração e

posterior entrega do projeto ao cliente. Este processo é representado pela

elaboração da especificação conceitual e técnica do software a ser desenvolvido, ou

alteração em software já existente. Esta especificação conceitual possui alguns pré-

requisitos a serem cumpridos para que seja válida, tanto para a norma ISO

31

9001:2008 quanto para o processo de engenharia de softwares:

Tabela 3: Pré-requisitos para conclusão de projetos de softwarePré-requisitos ResponsávelElaboração da análise do projeto e orçamento FabricanteElaboração do cronograma de entrega FabricanteElaboração dos requisitos técnicos FabricanteElaboração sobre plano de garantia e condições de entrega FabricanteAjustes e aceite sobre o projeto Cliente e FabricanteAjustes e aceite sobre condições de entrega Cliente e FabricanteAceite formal do cliente sobre orçamento Cliente

2.6.4 Item 7.3.4: Análise crítica de projeto e desenvolvimento

De acordo com ISO9000 (2008), “Em etapas apropriadas, revisões

sistemáticas do projeto e desenvolvimento devem ser realizadas de acordo com as

disposições planejadas (item 7.3.1):

a) Para avaliar a aptidão dos resultados do projeto e do

desenvolvimento de acordo com os requisitos do mesmo.

b) Para identificar quaisquer problemas e propor ações

necessárias.

Entre os participantes nessas revisões devem ser incluídos os

representantes de funções envolvida(s) na(s) etapa(s) de planejamento e

desenvovlimento que estã(rão) a ser revista(s). Os registros dos resultados de

revisões e de quaisquer ações devem ser mantidos (ver 4.2.4)”

Ao receber a solicitação de novo sistema, ou alteração do mesmo, o

processo de análise é efetuado realizando uma avaliação da entrada quanto à:

1. Viabilidade técnica: Por se tratar de um processo de

desenvolvimento tecnológico, é necessário identificar se a solicitação realizada é

técnicamente viável, se as tecnologias e utilizadas pela empresa são capazes de

suprir esta requisição;

2. Viabilidade estratégica: Ao realizar alterações em um produto de

software, é necessário analisar se o novo sistema ou alteração em sistema já

existente está compatível com a proposta do mesmo. É válido também notar que

32

todo sistema computacional possui um objetivo a ser cumprido pelo mesmo. Quando

este objetivo começa a ser desvirtuado em função de alterações no produto, o

mesmo pode criar em si vulnerabilidades mercadológicas impeditivas ao seu

crescimento;

3. Viabilidade comercial: Também é necessário avaliar o perfil do

cliente que está solicitando a alteração, quando oriundo de solicitações externas ao

planejamento estratégico. Uma solicitação de alteração na maioria das vezes é

resultado de uma necessidade ou fraqueza que o cliente identifica no sistema, e que

a mesma pressupõe uma dificuldade para o cliente melhorar ou ampliar os seus

processos.

O processo de aprovação de alterações é realizado pela área de

Análise e Engenharia do produto, que pode ser observada pelo Gráfico 6.

Gráfico 6: Fluxo de avaliação de projetos de software

2.6.5 Item 7.3.5: Verificação de projeto e desenvolvimento

De acordo com ISO9000 (2008), “A verificação deve ser realizada de

acordo com o planejamento realizado (ver 7.3.1), para assegurar que as saídas do

projeto e do desenvolvimento estão de acordo com os requisitos da entrada do

projeto e do desenvolvimento. Os registros dos resultados de verificação e de

quaisquer ações necessárias devem ser mantidos (ver 4.2.4)”.

O requisito em questão determina que os projetos de software

33

devem possuir um aceite por parte do cliente que o requisitou. Este aceite deve

determinar que a entrega da alteração de um software já existente, ou novo software

proposto, representa o cumprimento à requisição realizada pelo cliente.

O processo realizado para atender à este requisito pode ser

representado no Gráfico 7, que descreve a entrega do projeto ao cliente, para

solicitação do posterior aceite do mesmo.

Gráfico 7: Fluxo de aceite e revisões de projeto (Verificação)

A responsabilidade do sobre o aceite do projeto também faz parte do

planejamento de responsabilidades do projeto em questão, representado pelo pré-

requisito “Ajustes e aceite sobre o projeto” constante no parágrafo 2.6.3 deste

trabalho.

O controle de revisões de projetos pode ser realizada dentro do

mesmo projeto, na forma de uma tabela de gerenciamento de revisões de projetos,

conforme o exemplo na Tabela 4.

34

Tabela 4: Exemplo de controle de revisões de projetosRevisão Data Descrição da alteração00 09/11/200

9Abertura do projeto

01 17/11/2009

Mudanças no projeto relativo à:- Separação do projeto em 2 entregas (Janeiro/10 e Junho/10)- Mudança no processo de respondimento de pesquisas

02 19/11/2009

Mudanças no projeto relativo à:- Retirada do item previsto para Junho/10 (segregação de equipes)- Alteração do termo de compromisso BETA referente à entrega realizada em Janeiro/10.- Alteração no valor do projeto, referente à retirada do item de segregação de equipes

03 19/11/2009

Adição do serviço de desenvolvimento do conteúdo dos gateways + custos referente deslocamento e hospedagem para execução do serviço.

2.6.6 Item 7.3.6: Validação de projeto e desenvolvimento

De acordo com ISO9000 (2008), “A validação do projeto e

desenvolvimento deve ser realizado de acordo com o planejamento (ver 7.3.1), para

assegurar que o produto resultante é capaz de ir ao encontro dos requisitos

estabelecidos, para a aplicação específica ou para a utilização pretendida, onde

conhecidas. Onde quer que seja praticável, a validação deve ser completada antes

da entrega ou implementação do produto. Os registros dos resultados de validação e

de quaisquer ações necessárias devem ser mantidos (ver 4.2.4).”.

Conforme a norma NBR ABNT ISO 9001:2000 determina, a

validação do projeto é realizada antes da entrega do mesmo ao cliente, sob a forma

de produto final. Segundo observado durante o estágio na empresa Constat, a

validação do produto ocorre através dos processos de testes de software realizados

após a construção do mesmo, de acordo com o fluxo conforme pode ser verificado

no Gráfico 8.

35

Gráfico 8: Fluxo de validação de produtos de software

A homologação interna representa os testes realizados no produto,

baseado na última revisão do projeto elaborado e aceito pelo cliente, conforme

verificado no parágrafo 2.6.5 deste trabalho, item 7.3.5 da norma ABNT NBR ISO

9001:2008.

A homologação interna gera diversos indicadores que determinam

requisitos de aceitabilidade, padronização, conformidade ao projeto e funcionamento

dos produtos de software desenvolvidos, e também é a principal função de garantia

de qualidade dos produtos desenvolvidos.

No Gráfico 9 é possível observar uma análise quantitativa que

demonstra a quantidade de falhas encontradas em desenvolvimento de produtos.

36

Gráfico 9: Avaliação de falhas encontradas em testes de softwares

Se realizarmos uma análise comparativa dos dados acima, em

relação aos últimos 4 meses de cada ano, podemos verificar o resultado

demonstrado na Tabela 5 abaixo:

Tabela 5: Análise de melhoria de qualidade de software

Mês Falhas 2008 Falhas 2009 % Aumento QualidadeJulho 38 13 192,31Agosto 22 6 266,67Setembro 37 29 27,59Outubro 29 17 70,59Média: 139,29

A partir destes dados, podemos observar que, nos últimos 4 meses,

é possível identificar um aumento de qualidade médio de 139,29% em relação à

análise quantidade de falhas encontradas em produtos, representando uma maior

produtividade e redução de retrabalhos da equipe de produção.

37

Gráfico 10: Análise de abrangência de falhas

No Gráfico 10, podemos observar uma visão diferente do processo

de avaliação de falhas, onde é avaliado a abrangência destas falhas em relação à

carteira de clientes.

O software em estudo, em questão, possui uma média de 150

clientes ativos, sendo que uma falha no produto pode ser detectada em apenas um

cliente, ou em vários clientes que utilizam o mesmo. Isso representa a disseminação

da falha de produção em relação ao seu público.

A meta representada pela linha verde, no gráfico, representa o valor

de 5% de clientes, o qual é o limite máximo estabelecido internamente pela Constat,

para a abrangência das falhas de produto. Podemos observar que há uma

expressiva alta de disseminação de falhas nos meses de Agosto/2008,

Setembro/2008 e Outubro/2008. Esta alta foi característica de novas versões dos

produtos, sendo liberadas para o mercado, com baixo índice de testes realizados.

Uma vez que o processo de qualidade do produto sofreu melhorias

com a evolução dos processos de produção para adequação à da norma NBR ABNT

ISO 9001:2008, é possível observar que a característica de alta, nos demais meses

que demandam liberações de novas versões do produto, se mostra mais controlável,

apesar de ainda ficar abaixo da meta durante 2 ou 3 meses após liberação destas

versões (Verificado nos meses Março/2009, Abril/2009, Maio/2009 e nos meses

Setembro/2009 e Outubro/2009).

38

2.6.7 Item 7.3.7: Controle de alterações

De acordo com ISO9000 (2008), “As alterações no projeto e

desenvolvimento devem ser identificadas e os registros mantidos. As alterações

devem ser revistas, verificadas e validadas, conforme apropriado, e aprovadas antes

da implementação. A revisão das alterações no projeto e desenvolvimento deve

incluir a avaliação do efeito das alterações nas partes constituintes e no produto que

já foi entregue. Os registros dos resultados de revisões de alterações e de quaisquer

ações necessárias devem ser mantidos (ver 4.2.4).”

No processo de desenvolvimento de softwares em estudo, podemos

observar 2 pontos onde há alterações que precisam ser controladas:

a) No controle de alterações de projetos, antes do processo de

produção começar a executar. Este item pode ser observado no

exemplo citado na Tabela 4.

b) Alterações no próprio produto, constantes de mudanças

elaboradas por decisão interna ou através de mudanças

externas, que exercem influência sobre a qualidade do mesmo.

Alterações de produto representam um forte impacto no processo de

produção de software, uma vez que o mesmo passa por uma forte homologação

interna antes da sua liberação para o mercado. Ao ser alterado, todo o processo de

homologação precisa ser realizado novamente.

No ambiente de desenvolvimento de software, produtos novos são

representados por “versões” do mesmo. Estas versões consideram que um novo

produto foi liberado.

A cada alteração que um produto sofre, o mesmo ganha

numerações secundárias à sua nomenclatura, denominadas “releases”. Estas

releases são alterações em relação ao produto original, que por sua vez possuem

desde correções à falhas existentes no produto original, quanto melhorias ao

mesmo.

39

Gráfico 11: Controle de alterações em produtos

Conforme visto em estudo realizado no estágio in-loco, o Gráfico 11

representa que:

A versão 6.00: foi liberada com 162 alterações em relação ao

produto original. Esta versão conteve várias melhorias, novos recursos, atualizações

tecnológicas e alterações para suportar os recursos solicitados pelo Planejamento

Estratégico da empresa (Gráfico 4).

A release 6.00.01: representa uma alteração realizada na versão

original, considerando 30 alterações realizadas, desde correções de falhas

detectadas após sua liberação ao mercado, até novas melhorias no produto. O

mesmo processo segue nas releases 02, 03 e 04 representadas pelo Gráfico 11,

acima.

As alterações realizadas em releases do produto são necessárias

uma vez que o mercado, através da sua exigência, pede alterações ao produto para

adequação específica aos seus processos. Para controlar alterações em produtos

existentes, é utilizada a técnica de Testes de Regressão, que utiliza um processo

automático de re-testar tudo o que foi testado anteriormente, em busca de falhas

oriundas de alterações realizadas em versões já liberadas, como pode ser visto no

Gráfico 12.

40

Gráfico 12: Testes de regressão

Os testes de regressão possuem uma grande importância no

processo de desenvolvimento de softwares em mercados onde, como citado

anteriormente, é necessário realizar pequenas adaptações em softwares já

oficialmente homologados e liberados para o mercado para garantir competividade

no mesmo. Eles garantem que alterações em pontos do sistema não afetem outros

pontos aleatórios, por exemplo, garante que alterações realizadas no “Cadastro de

clientes” não afete a “Emissão de notas fiscais”.

2.6.8 Item 8: Medição, análise e monitoramento

De acordo com ISO9000 (2008), “A organização deve planejar e

implementar os processos de medição, análise, monitoramento e melhoria

necessários para:

a) Demonstrar a conformidade com os requisitos do produto;

b) Assegurar a conformidade do sistema de gestão da qualidade;

c) Melhorar continuamente a eficácia do sistema de gestão de

qualidade.

Isso deve incluir a determinação de métodos aplicáveis, incluindo

técnicas estatísticas, e a extensão da sua utilização.”

Também, de acordo com ISO9000 (2008), “A organização deve

monitorar e medir as características do produto para verificar se foi ao encontro dos

41

requisitos do produto. Isto deve ser efetuado em etapas apropriadas do processo de

realização do produto de acordo com o seu planejamento (ver 7.1). A evidência da

conformidade com os critérios de aceitação deve ser mantida.”

Para atender aos critérios de medição, análise e monitoramento, é

necessário observar alguns aspectos do ambiente no qual a produção de softwares

está inserida:

2.6.8.1 Indicadores de satisfação do mercado

A satisfação dos clientes é alcançada a partir de diversas ações que

as empresas precisam executar, assim, oferecer produtos e serviços de qualidade,

além de preços e prazos são alguns pontos que podem influenciar na satisfação.

A definição de Kotler (1998) para satisfação é: "[...] o sentimento de

prazer ou de desapontamento resultante da comparação do desempenho esperado

pelo produto (ou resultado) em relação às expectativas da pessoa."

O cliente insatisfeito espalha informações negativas, e dessa

maneira a imagem da organização é prejudicada, por isso, a satisfação dos clientes

é um importante instrumento de marketing, que pode ser usado pelos

administradores como forma de tornar mais competitiva a empresa no mercado.

No estudo realizado na empresa Constat, pôde ser observado o

monitoramento constante do índice de satisfação dos clientes, conforme é

observado no Quadro 3.

42

Quadro 3: Indicadores de qualidade

Aqui podemos notar que, conforme visto no Gráfico 9, e na Tabela 5,

o índice de falhas no produto teve uma melhoria significativa no último ano. Como

podemos ver no Quadro 3, esta melhoria refletiu na satisfação dos clientes, quando

observamos o Indicador 2: “Índice Global Satisfação Clientes Qualitor”, que

representa a satisfação dos clientes em relação ao produto Qualitor que é fabricado

pela empresa.

Pelos resultados observados, podemos notar que o mercado

responde de forma bastante positiva aos seus fornecedores que adotam práticas de

gestão de qualidade consistentes e bem definidas.

2.6.8.2 Indicadores de produtividade e produção

A produtividade, considerada uma das mais importantes armas de

competição é a melhor determinante da competitividade e lucratividade das

indústrias, é portanto o melhor indicador do progresso econômico de uma

empresa. Através da produtividade, ou mais especificamente, do crescimento

continuado da produtividade,teremos melhor competitividade, nossos produtos

43

serão melhores e mais baratos, nossos serviços serão bem prestados, os salários

aumentarão e o nível de vida se aproximará de aquele existente nos países

rotulados como desenvolvidos.

A quantidade de novos recursos produzidos pelo desenvolvimento

de produtos, o atendimento aos acordos de nível de serviço estabelecidos

contratualmente por clientes e a visão geral de um processo de produção baseado

em diversos sub-indicadores de qualidade proporcionam uma visão macro da

produtividade da fábrica de softwares.

Gráfico 13: Desempenho quantitativo de produção

O Gráfico 13 representa o desempenho da linha de produção de

softwares, e mostra que houve um acréscimo considerável do processo de produção

desde Maio/2009. Este acréscimo é justificado pela liberação oficial de uma nova

versão do produto, ocorrida no mês de Abril/2009, o que elevou o processo de

produção da fábrica de softwares com demandas de ajustes e alterações no produto

já desenvolvido.

Este tipo de medição nos permite avaliar quando a demanda se

torna crítica e quando a mesma está esgotando a capacidade produtiva da linha

fabril. Cada valor do gráfico representa uma demanda de alteração no produto

desenvolvida no mês em questão, pela unidade de produção do software.

44

2.6.8.3 Índices chave de desempenho de processos

Os Indicadores Chave de Desempenho (Também chamados de KPI

– Key Point Indicators), tiveram sua aplicação estendida às mais diversas questões

referentes aos negócios e empresas. Com os recursos disponíveis de tecnologia de

informação, Hardware e Software, pode-se gerar indicadores para qualquer etapa de

um processo e medir o seu resultado. Muitas empresas trabalham com Indicadores

Chave de Desempenho como instrumentos de sua navegação. Eles vão além das

tradicionais métricas financeiras e passam a medir o sucesso dos processos nas

organizãções. A combinação de indicadores pode apontar o sucesso e a conclusão

de um objetivo estratégico em uma empresa.

Cabe aos altos executivos e suas equipes definirem quais serão os

Indicadores Chaves de Desempenho pois em uma empresa podem existir diversos

indicadores que de alguma forma apontam resultados e apoiam diagnósticos.

Devem ser eleitos como Indicadores Chave de Desempenho apenas aqueles que o

seu atingimento seja capaz de alinhar a empresa com a sua visão e objetivos

estratégicos. Um método constantemente aplicado em organizações para a escolha

dos indicadores chaves de desempenho é o Balanced Scorecard.

Conforme podemos observar no Gráfico 14, a empresa Constat

elaborou um Painel de Indicadores que demonstra os indicadores chave de

desempenho relativo à diversos escopos. No Gráfico 14 podemos observar os

indicadores chave de desempenho relativos aos processos da organização.

45

Gráfico 14: Índices chave de desempenho de processos

Apesar dos diversos indicadores de desempenho exibidos no

Gráfico 14, vamos detalhar apenas os indicadores de desempenho relativos ao

escopo do produto em questão:

%Atrasos SMSSLA: É um indicador que representa o percentual de

atrasos na liberação de correções à falhas de produtos encontrado em clientes. Este

prazo é estipulado no contrato estabelecido entre o cliente e a organização, quando

na aquisição do produto oferecido pela empresa. O índice máximo de atraso

permitido é 15%.

%Atrasos Sup Qua: É um indicador que representa o percentual de

atrasos na entrega de soluções à dúvidas e problemas enfrentados pelos clientes,

pela área de Suporte Técnico (Pós-Vendas) do produto. O índice máximo de atraso

permitido é 15%.

Índice DESENV: É um indicador composto que mede o desempenho

geral do processo de fabricação do produto. A sua meta é 8.

Índice Ser Qualitor: É um indicador composto que mede o

desempenho geral do processo de serviços, consultoria, implantação e treinamentos

do produto Qualitor, diz respeito à área de Serviços do produto. A sua meta é 8.

Índice Sup Qualitor: É um indicador composto que mede o

desempenho geral do processo de pós-vendas, suporte à dúvidas, recebimento de

requisições de alterações e registro de falhas em produtos. A sua meta é 8.

46

3 CONCLUSÃO

Na empresa estudada pode-se verificar que o processo de

desenvolvimento de produtos já era realizado sob o regimento de algumas

metodologias, mesmo antes da adoção da NBR ISO 9001:2008, pois a empresa já

possuía um histórico de crescimento cultural em programas de qualidade.

Uma das principais características da empresa estudada é sua

flexibilidade e existia certo receio dos colaboradores de que a implementação do

Sistema de Garantia da Qualidade fundamentado na NBR ISO 9001:2008 prejudica-

se a flexibilidade. Mas verificou-se com os envolvidos no PDP que os principais

benefícios da ISO 9001:2008 foram o planejamento, os registros, as verificações e

as medições, que permitiram criar um histórico do PDP, evitar a repetição de erros

de projeto o que contribuiu para o atendimento das expectativas dos clientes, dentre

elas, a flexibilidade.

A implementação do SGQ - NBR ISO 9001:2008 na empresa

analisada contempla o aperfeiçoamento dos fatores críticos de sucesso:

planejamento, aceite do cliente, monitoramento, comunicação e gerência

conciliadora.

Concluí-se que a implementação do requisito controle de projetos e

desenvolvimento em conformidade com a NBR ISO 9001:2008, pode propiciar o

aperfeiçoamento de alguns fatores críticos de sucesso, principalmente o

planejamento e a qualidade dos produtos, refletindo-se na satisfação dos clientes e

auxiliando no crescimento da organização.

47

REFERÊNCIAS

ABNT, ABNT NBR ISO 9001:2008, Sistemas de gestão da Qualidade, 2008.

ANTONIONI, José. Qualidade em software: manual de aplicação da ISO-9000. São Paulo: Makron Books, 1995.

BARRETO, José. Qualidade de Software. Disponível em: <http://www2.unemat.br/rhycardo/download/qualidade_em_software.pdf> Acesso em: 11/11/2009.

DESCHAMPS, Jean - Philippe; NAYAK, P. Ranganath. Produtos irresistíveis: como operacionalizar um fluxo perfeito de produtos do produtor ao consumidor. São Paulo: Makron Books, 1997.

JURAN, J. M.; GRYNA Frank M. Controle da qualidade - ciclo dos produtos: do projeto à fabricação. São Paulo: Makron Books, 1992. v. 3.

KOTLER, Philip. Administração e Marketing. 5. ed. São Paulo: Atlas, 1998.

KRUGLIANSKAS, Isak. Engenharia simultânea: organização e implantação em empresas brasileiras. In: Simpósio Nacional de Gestão da Inovação Tecnológica, São Paulo. Anais... São Paulo: Editora da USP, 1992. p. 47-52.

ROCHA, Ana Regina. Planejamento e Avaliação da Qualidade de Software. COPPE/UFRJ, 2000.

SANDERS, Joc; CURRAN, Eugene. Qualidade de software. Disponível em <http://www.geekbrasil.com.br>. Acesso em: 12/11/2009.

SILVA, Demétrius Domingos Wolff. Análise comparativa entre ambientes Oracle relacional versão 7 Oracle objeto relacional versão 8, utilizando padrões da norma ISO/IEC 9126. Blumenau, 1999. Relatório de estágio supervisionado. Bacharel em Ciências da Computação, Centro de Ciências Exatas e Naturais – FURB.

STAHL, Marimar. M. Avaliação da Qualidade de Software Educacional; Programa de Engenharia de Sistemas e Computação. COPPE/UFRJ. Rio de Janeiro: 1988.

STORCH, Mirian Mirdes. Proposta de avaliação de qualidade de produtos de software utilizando a norma ISO/IEC 9126. 2000. 82 f. Trabalho de conclusão de curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau.

VERITAS, Bureal, Brasil. Relatório de auditoria de recertificação da Constat na norma ISO NBR 9001:2008. Porto Alegre, RS, 2009.

48

APÊNDICES

49

APÊNDICE A – Formulário de requisição de novas solicitações de sistemas

50

51