Estruturação de uma fábrica de desenvolvimento de softwares baseado em ISO 9001:2008

1. SISTEMA DE ENSINO PRESENCIAL CONECTADO
PROCESSOS GERENCIAIS
CLAUDIO TESTONI CARDOZO
SISTEMÁTICA DE PRODUÇÃO DE SOFTWARES
Linha de Produção de Softwares baseado na ISO9001:2008

2. CLAUDIO TESTONI CARDOZO
SISTEMÁTICA DE PRODUÇÃO DE SOFTWARES
Linha 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
Caxias do Sul
2009

3. Caxias do Sul
2009

4. Dedico este trabalho ao meu filho que, por
várias vezes me questionou, por cima do meu
ombro, quando o mesmo ficaria pronto...
Caxias do Sul, 20 de novembro de 2009

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

6. "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

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

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

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

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

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

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

15. SUMÁRIO
1 INTRODUÇÃO.........................................................................................................14
2 DESENVOLVIMENTO.............................................................................................16
2.1 Qualidade de software..........................................................................................17
2.1.1 Fatores explícitos...............................................................................................19
2.1.2 Fatores implícitos...............................................................................................20
2.2 Histórico da Qualidade de Software......................................................................21
2.3 Importância da Qualidade de Software.................................................................22
2.4 Métricas da Qualidade de Software......................................................................23
2.4.1 Métricas Internas................................................................................................23
2.4.2 Métricas Externas...............................................................................................24
2.5 Processo de Produção de Softwares....................................................................25
2.6 Produção de softwares alinhado à ISO 9001:2008..............................................26
2.6.1 Item 7.3.1: Planejamento do projeto e desenvolvimento...................................28
2.6.2 Item 7.3.2: Entradas de projeto e desenvolvimento...........................................30
2.6.3 Item 7.3.3: Saídas de projeto e desenvolvimento..............................................31
2.6.4 Item 7.3.4: Análise crítica de projeto e desenvolvimento..................................32
2.6.5 Item 7.3.5: Verificação de projeto e desenvolvimento.......................................33
2.6.6 Item 7.3.6: Validação de projeto e desenvolvimento.........................................35
2.6.7 Item 7.3.7: Controle de alterações.....................................................................39
2.6.8 Item 8: Medição, análise e monitoramento........................................................41
2.6.8.1 Indicadores de satisfação do mercado...........................................................42
2.6.8.2 Indicadores de produtividade e produção.......................................................43
2.6.8.3 Índices chave de desempenho de processos.................................................45
3 CONCLUSÃO...........................................................................................................47
APÊNDICES...............................................................................................................49
APÊNDICE A – Formulário de requisição de novas solicitações de sistemas..........50

16. 14
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

17. 15
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.

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

19. 17
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.

20. 18
Tabela 1: Normas Técnicas
NORMA 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.

21. 19
2.1.1Fatores 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

22. 20
2.1.2Fatores 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

23. 21
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
A qualidade era vista simplesmente como uma verificação se o produto
1950
estava pronto.
1960 Incluída a atividade de testes.
Inicia-se a verificação do cumprimento de normas definidas para as
1970
diversas atividades.
O controle da qualidade de software é visualizado como uma atividade de
1980
todo o ciclo de vida do desenvolvimento do produto.
A qualidade de software é considerada uma necessidade.
1990
Iniciou-se os primeiros trabalhos de publicação de normas da qualidade.
Começa-se a verificar que a maioria dos softwares desenvolvidos não
2000 entra no mercado sem que passe por rigorosos testes para assegurar a
qualidade dos mesmos.
Fonte: Silva (1999)

24. 22
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.

25. 23
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.1Mé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.

26. 24
2.4.2Mé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.

27. 25
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
Levantamento de Homologação
requisitos interna
Elaboração do
Documentação
projeto
Aceite do cliente
Entrega
sobre o projeto
Produção do
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

28. 26
itens, como pode ser visto no Gráfico 2.
Gráfico 2: Macro-fluxo de produção com respectivos realizáveis
Levantamento de Elaboração do Aceite do cliente Produção do Homologação Testes e Métricas
requisitos projeto sobre o projeto software interna
Requisição (User Análise e
Aceite do projeto Código-Fonte
Story) Modelagem
Manuais de uso
Documentação
Consultoria,
Entrega Treinamento
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

29. 27
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.

30. 28
2.6.1Item 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
Planejamento Solicitação de
Estratégico clientes
Levantamento de
requisitos
Requisição (User
Story)

31. 29
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

32. 30
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.2Item 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.

33. 31
Gráfico 5: Fluxo de entrada do projeto de desenvolvimento
Solicitação de
clientes
Planejamento Levantamento de Requisição # 78548
Estratégico requisitos
Encaminha à área de Análise
e Engenharia
Requisição (User
Story)
2.6.3Item 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

34. 32
9001:2008 quanto para o processo de engenharia de softwares:
Tabela 3: Pré-requisitos para conclusão de projetos de software
Pré-requisitos Responsável
Elaboração da análise do projeto e orçamento Fabricante
Elaboração do cronograma de entrega Fabricante
Elaboração dos requisitos técnicos Fabricante
Elaboração sobre plano de garantia e condições de entrega Fabricante
Ajustes e aceite sobre o projeto Cliente e Fabricante
Ajustes e aceite sobre condições de entrega Cliente e Fabricante
Aceite formal do cliente sobre orçamento Cliente
2.6.4Item 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 todo sistema computacional

35. 33
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
Solicitação de
clientes
Planejamento Levantamento de Avaliação Elaboração do
Estratégico requisitos Engenharia projeto
Requisição (User Análise e
Story) Modelagem
2.6.5Item 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)”.

36. 34
O requisito em questão determina que os projetos de software
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)
Controle de
revisões N
Aceite do cliente Produção do
Elaboração do S
sobre o projeto software
projeto
Aceite do projeto Anexa o aceite
do cliente ao
Análise e projeto para
Modelagem
fins de
documentaçã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.

37. 35
Tabela 4: Exemplo de controle de revisões de projetos
Revisão Data Descrição da alteração
00 09/11/200 Abertura do projeto
9
01 17/11/200 Mudanças no projeto relativo à:
9 - Separação do projeto em 2 entregas (Janeiro/10 e Junho/10)
- Mudança no processo de respondimento de pesquisas
02 19/11/200 Mudanças no projeto relativo à:
9 - 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/200 Adição do serviço de desenvolvimento do conteúdo dos gateways +
9 custos referente deslocamento e hospedagem para execução do
serviço.
2.6.6Item 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.

38. 36
Gráfico 8: Fluxo de validação de produtos de software
N Testes OK ?
Controle de
N
revisões
S
Aceite do cliente Produção do Homologação Testes e Métricas
S
sobre o projeto software interna
Aceite do projeto Anexa o aceite
do cliente ao Código-Fonte
projeto para
fins de
documentação
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.

39. 37
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 Qualidade
Julho 38 13 192,31
Agosto 22 6 266,67
Setembro 37 29 27,59
Outubro 29 17 70,59
Mé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.

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

41. 39
2.6.7Item 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.

42. 40
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.

43. 41
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.8Item 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

44. 42
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.1Indicadores 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.

45. 43
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.2Indicadores 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

46. 44
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.

47. 45
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.

48. 46
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.

49. 47
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.

50. 48
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.

51. 49
APÊNDICES

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

53. 51
Desenvolvimento Constat :: Solicitação de alterações e customizações
Cliente: (Selecione o cliente )
Projeto: (Estabeleça um título para o projeto de customização )
Qualitor Start Qualitor Advanced Qualitor Advanced + ITIL Vistor
Sistema Interno
Versão atual do sistema : (Informe a versão + release atual do sistema instalado no cliente )
Marque se esta customização necessariamente precisa ser realizada na versão atual do cliente .
Cenário atual do cliente (User story):
(Descreva o que o processo que é realizado atualmente , sem esta customização , e onde a falta desta impacta no processo em questão .
Escopo da customização / alteração a ser realizada (Scope):
(Descreva detalhadamente qual alteração seria necessário realizar no sistema , para que os problemas relatados no cenário atual do cliente sejam
solucionados )
Objetivos a serem cumpridos (Goals):
(Descreva como a entrega desta customização será avaliada , quais itens devem ser contemplados , quais operações e atividades serão utilizadas para
validar o escopo desta customização . Nota: O cumrpimento dos objetivos representa o cumprimento do escopo da customização realizada ).
Equipe do projeto (Project Team):
Requisitor do projeto: (Informe o nome e e -mail do solicitante do projeto – Cliente)
Gestor comercial: (Informe o nome do gestor comercial - Constat - responsável pelo cliente / projeto em questão )
Consultor : (Informe o nome do consultor – Constat - responsável pelo cliente / projeto em questão )
Receptor da entrega: (Informe o nome e e -mail do responsável por receber a customização – Cliente)
Avaliador técnico: (Informe o nome e e -mail do responsável por realizar a avaliação técnica do projeto – Cliente)
Avaliador de negócio: (Informe o nome e e -mail do responsável por realizar a avaliação de negócio do projeto – Cliente)
Alternativas:
(Informe as alternativas a serem utilizadas , pelo cliente , caso esta customização seja classificada como inviável por questões técnicas , conceituais ou
comerciais ).
Marque esta opção caso o cliente aceite receber esta customização em versão BETA do sistema.
(Ver termo de comprimisso de versão BETA )
Marque esta opção se este projeto de customização necessitará de apoio para instalação / implantação / treinamento
após entregue.
Materiais de apoio (telas exibindo o cenário atual, tabelas e imagens explicando o escopo a ser desenvolvido):
Conteúdo:
(Descreva o conteúdo deste material de apoio sendo anexado à solicitação de customização )