Your SlideShare is downloading. ×
  • Like
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Trabalho Fábrica de Softwares baseado em ISO 9001:2008

  • 4,334 views
Published

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

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

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
4,334
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
177
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 10. 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
  • 11. LISTA DE QUADROS Quadro 1: Fatores explítitos........................................................................................19 Quadro 2: Fatores implícitos.......................................................................................20 Quadro 3: Indicadores de qualidade...........................................................................43
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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.
  • 16. 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)
  • 17. 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.
  • 18. 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.
  • 19. 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
  • 20. 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
  • 21. 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)
  • 22. 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.
  • 23. 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.
  • 24. 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.
  • 25. 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
  • 26. 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
  • 27. 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.
  • 28. 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)
  • 29. 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
  • 30. 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.
  • 31. 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
  • 32. 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
  • 33. 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)”.
  • 34. 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.
  • 35. 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.
  • 36. 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.
  • 37. 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.
  • 38. 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).
  • 39. 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.
  • 40. 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.
  • 41. 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
  • 42. 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.
  • 43. 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
  • 44. 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.
  • 45. 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.
  • 46. 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.
  • 47. 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.
  • 48. 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.
  • 49. 49 APÊNDICES
  • 50. 50 APÊNDICE A – Formulário de requisição de novas solicitações de sistemas
  • 51. 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 )