UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA CURSO DE GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO

LEVANTAMENTO DE REQUISITOS DE SOFTWARE PARA GESTÃO DE LABORATÓRIOS DE CALIBRAÇÃO E ENSAIOS BASEADO NA ABNT NBR ISO/IEC 17025

TRABALHO DE CONCLUSÃO DE CURSO

Taís Guidolin Franchi

Santa Maria, RS, Brasil 2016

LEVANTAMENTO DE REQUISITOS DE SOFTWARE PARA GESTÃO DE LABORATÓRIOS DE CALIBRAÇÃO E ENSAIOS BASEADO NA ABNT NBR ISO/IEC 17025

POR

Taís Guidolin Franchi

Trabalho de conclusão de curso de graduação apresentado ao Centro de Tecnologia da Universidade Federal de Santa Maria, como requisito parcial para obtenção do grau de Bacharel em Engenharia de Produção.

Orientadora: Morgana Pizzolato Co-orientador: Vinícius Jacques Garcia

Santa Maria, RS, Brasil 2016

LEVANTAMENTO DE REQUISITOS DE SOFTWARE PARA GESTÃO DE LABORATÓRIOS DE CALIBRAÇÃO E ENSAIOS BASEADO NA ABNT NBR ISO/IEC 17025 TAIS GUIDOLIN FRANCHI (UFSM) [email protected] MORGANA PIZZOLATO (UFSM) [email protected] VINÍCIUS JACQUES GARCIA (UFSM) [email protected]

O levantamento e a documentação de requisitos de software de processos do Sistema de Gestão de Laboratórios do Centro de Tecnologia (SGLab CT) inserido na Universidade Federal de Santa Maria (UFSM) é o objetivo deste trabalho. Para isso, uma pesquisa foi realizada para conhecer quais as principais funcionalidades desejadas para um software de gestão com laboratórios de calibração e foram identificadas as cinco rotinas de trabalho dos laboratórios do SGLab CT para atendimento à ABNT NBR ISO/IEC 17025 e foram modelados os três principais processos do negócio. Os principais resultados desta pesquisa foram: (i) identificação de 22 funcionalidades importantes para um software de gestão que compõe cinco processos principais com a participação de oito agentes distintos e (ii) o levantamento e documentação dos requisitos de três processos do SGLab CT. Palavras-chave: ABNT NBR ISO/IEC 17025; LABORATÓRIOS DE ENSAIO E CALIBRAÇÃO; SOFWARE DE GESTÃO; REQUISITOS DE SOFTWARE

The current research aims the gathering and documentation of software requirements of process of Laboratories System of Management from Tecnology Center (SGLab CT) in Federal University of Santa Maria (UFSM). For this, a research was carry out to know the main functionalities desired for a management software with calibration laboratories and IES tests of Rio Grande do Sul, were identified the five work routines of laboratories of SGLab CT to attending ABNT NBR ISO/IEC 17025 and were modeled the three main business processes. The main results of this research were: (i) identification of 22 important functionalities for a management software that compose five main processes with the participation of eight distinct agents and (ii) the collection and documentation of the requirements of three SGLab CT processes. Keywords: ABNT NBR ISO/IEC 17025; TEST AND CALIBRATION LABORATORIES; MANAGEMENT SOFTWARE; SOFTWARE REQUIREMENTS

1

INTRODUÇÃO A adequação dos laboratórios que prestam serviços de ensaio e calibração à norma

ABNT NBR ISO/IEC 17025 é um diferencial competitivo no mercado, pois isso faz com que se tenha maior confiabilidade e garantia da qualidade dos resultados (JORNADA, 2008). Desse modo, cada vez mais os laboratórios ligados a Instituições de Ensino Superior (IES) têm buscado a acreditação a partir da adequação aos requisitos desta norma, conforme apresentado por Silva (2013), Jornada (2008) e Magalhães e Noronha (2006). Atualmente no Brasil são acreditados 382 laboratórios de calibração sendo que nenhum destes pertence à IES. Em relação aos laboratórios de ensaio, existem no Brasil 1045 laboratórios acreditados e 28 destes pertencem à IES (INMETRO, 2016). A construção de um sistema de gestão de laboratórios, em qualquer instituição, é trabalhosa e necessita de documentos, registros e respectivos controles. A necessidade de adequação aos requisitos da ABNT NBR ISO/IEC 17025, principalmente no que se refere ao controle de documentos e registros faz com que exista quantidade considerável de documentos digitais e impressos (OLIVARES, 2015). Sendo assim, é importante a utilização de uma sistemática de controle computacional para a gestão, sendo que este torna o sistema ágil e confiável. Porém, para a aquisição de um software de gestão são necessários altos investimentos (HAQUIN et al., 2008 apud FIORI et al., 2015). Essa questão dificulta a utilização desta ferramenta, principalmente para IES públicas. Além disso, existe dificuldade de encontrar softwares que atendam a todos os requisitos da norma ABNT NBR ISO/IEC 17025 e também todas as necessidades dos laboratórios. Dessa forma, o tema da pesquisa se refere a sistemas computacionais no contexto da gestão da qualidade de laboratórios de calibração e ensaios em IES. No que tange ao problema da pesquisa, se trata da pouca disponibilidade de sistemas computacionais acessíveis que gerenciam rotinas em laboratórios de calibração e ensaios em função dos requisitos específicos que cada área de estudo assume. Assim, para mitigar esse problema busca-se responder as seguintes questões:  Quais são as rotinas práticas e seus processos envolvidos no cotidiano de um laboratório de calibração e ensaios que podem ser facilitadas por um sistema computacional?  Quais são os requisitos que o sistema computacional deve atender em cada processo? As justificativas teóricas que apresentam a relevância para o desenvolvimento da pesquisa estão relacionadas às particularidades do processo de análise de requisitos de softwares (SCHACH, 2009), que contém vários desafios em se tratando das condições no e 1

para o levantamento de requisitos no processo de desenvolvimento de software. Um dos desafios deste projeto é a apuração das condições da análise do negócio envolvido que é preponderante no caminho para o sucesso da abordagem metodológica. As justificativas práticas da escolha do tema visam contribuir com um sistema de gestão de rotinas de laboratórios de calibração e ensaios que, de forma mais ampla, é, sobretudo relevante no contexto de Instituições de Ensino Superior, onde há vários laboratórios temáticos com particularidades próprias (FIORI et al., 2015). Conferir confiabilidade e facilidade de uso é definitivo para que o sistema desenvolvido tenha uma difusão significativa no uso. Por isso, algumas contribuições são particularmente relevantes do ponto de vista prático, como, um sistema amigável para controle dos documentos e registros que seja confiável e forneça a proteção contra a perda e acesso indesejáveis aos dados (ABNT, 2005); conveniência de redução do uso do controle por meio de documentos impressos, agilidade ao acesso das informações necessárias, rastreabilidade das modificações nos documentos e uma melhor comunicação entre os membros do sistema de gestão (FIORI et al.,2015). O objetivo geral dessa pesquisa é o levantamento e a documentação dos requisitos de processos do SGLab CT. Os objetivos específicos que a pesquisa pretende atender são: identificar as rotinas de trabalho dos laboratórios para atendimento a um sistema de gestão da qualidade de acordo com os requisitos da ABNT NBR ISO/IEC 17025; identificar as necessidades específicas do sistema de gestão da qualidade no que se refere a documentos, registros, clientes, controle de equipamentos, relatórios de ensaio e certificados de calibração e; modelar o negócio. Nas seções seguintes são apresentados o referencial teórico, a metodologia os resultados e a discussão.

2

2

REFERENCIAL TEÓRICO Nesta seção são apresentados os requisitos da norma ABNT NBR ISO/IEC 17025 e a

aplicação desta em IES, uma breve introdução aos métodos de desenvolvimento de software, requisitos de software de gestão e um aprofundamento sobre levantamento e análise de requisitos para o desenvolvimento de softwares.

2.1

Requisitos da norma ABNT NBR ISO/IEC 17025 e sua aplicação em IES Atualmente, cada vez mais laboratórios buscam a acreditação, por meio da adequação

a normas técnicas e regulamentos, sendo a ABNT NBR ISO/IEC 17025 uma destas normas. A acreditação é uma ferramenta internacionalmente utilizada para que as organizações, que acreditadas, apresentem garantia e confiabilidade dos resultados de suas medições (INMETRO, 2016). Acreditação é o reconhecimento formal por um organismo de terceira parte. Segundo os requisitos da ABNT NBR ISO/IEC 17025 é aplicável a laboratórios de ensaio e calibração que atende a estes requisitos previamente definidos e demonstra ser competente para realizar suas atividades com confiança (INMETRO, 2016). A norma ABNT NBR ISO/IEC 17025 pode ser utilizada para desenvolvimento de um sistema de gestão para a qualidade de operações técnicas e administrativas de laboratórios de calibração e ensaios, sendo que esta especifica por meio de seus requisitos a confirmação da competência técnica de laboratórios. Deste modo, a adequação a esta norma garante confiabilidade dos resultados da realização dos ensaios e calibrações destes laboratórios do ponto de vista de seus clientes (ABNT, 2005). A adequação a esta norma é de clara importância, pois a implantação de um Sistema de Gestão da Qualidade (SGQ) traz melhorias como padronização de processos, fazendo com que se reduzam custos de produção, aumento da produtividade, utilização adequada dos equipamentos, maior facilidade na detecção e correção de erros e maior confiabilidade das análises (SALGADO; SILVEIRA; AZEVEDO, 2011). A ABNT NBR ISO/IEC 17025 apresenta os requisitos gerais para a competência de laboratórios de ensaio e calibração, sendo que estes requisitos são divididos em Requisitos da direção (Seção 4) e requisitos técnicos (Seção 5) e estão apresentados na Figura 1. Os requisitos técnicos são mais específicos e apresentam as particularidades técnicas de cada tipo de laboratório de calibração e ensaios (ABNT, 2005).

3

Requisitos da direção 4.1 Organização 4.2 Sistema de gestão 4.3 Controle de documentos 4.4 Análise crítica de pedidos, propostas e contratos 4.5 Subcontratação de ensaios e calibrações 4.6 Aquisição de serviços e suprimentos 4.7 Atendimento ao cliente 4.8 Reclamações 4.9 Controle de trabalhos de ensaio/calibração nãoconforme 4.10 Melhoria 4.11 Ação corretiva 4.12 Ação preventiva 4.13 Controle de registros 4.14 Auditorias internas 4.15 Análise crítica pela direção

Requisitos técnicos 5.1 Generalidades 5.2 Pessoal 5.3 Acomodações e condições ambientais 5.4 Métodos de ensaio e calibração e validação de métodos 5.5 Equipamentos 5.6 Rastreabilidade de medição 5.7 Amostragem 5.8 Manuseio de itens de ensaio e calibração

Figura 1 - Requisitos ABNT NBR ISO/IEC 17025 Fonte: Autor (2016)

Segundo Felippes (2011) os laboratórios de IES, por ter a missão em dedicar-se em pesquisa, ensino e extensão, devem garantir a qualidade de seus resultados obtidos nos experimentos realizados pelos usuários, sendo que estes são geralmente os alunos, possibilitando que estes tenham acesso às suas dependências. Além disso, estes mesmos laboratórios prestam serviços a terceiros, devendo, da mesma forma, garantir a qualidade de seus resultados (FELIPPES, 2011). Desse modo, cada vez mais laboratórios buscam o reconhecimento de sua competência técnica por meio da acreditação, pela Coordenação Geral de Acreditação (CGCRE) do Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (INMETRO), ou o reconhecimento pelas Rede Metrológicas Estaduais como por exemplo, a do Rio Grande do Sul. Todos estes casos utilizam os requisitos da ABNT NBR ISO/IEC 17025 para este reconhecimento (PIZZOLATO, 2008). Felippes (2011) ainda mostra a importância dos laboratórios universitários, pois são um elo entre a instituição e a indústria. Isso se deve ao fato destas instituições utilizarem metodologias e tecnologias inovadoras em seus laboratórios e também, apresentam significativa importância, pois trazem a experiência prática para a universidade. A implantação da ABNT NBR ISO/IEC 17025 em laboratórios de universidades apresenta particularidades, como garantir que o acesso ao laboratório seja restrito, confidencialidade dos resultados e a necessidade da utilização de normas internacionais no SGQ (FELIPPES, 2011; GROCHAU, 2011). A acreditação de laboratórios de IES é mais crítica de se conseguir pelo fato de não possuir bem definidas as funções e responsabilidades do pessoal e por causa da alta rotatividade de pessoal o que leva a falta de motivação para conseguir a acreditação nestes 4

laboratórios. Uma característica particular desse tipo de laboratório é conciliar a pesquisa e o ensino com a prestação de serviços, sendo que este último não é o principal foco destes laboratórios. Mesmo com essas particularidades e pouca motivação ainda os laboratórios de IES buscam a acreditação, pois a maior motivação para a implantação de um SGQ em IES é a potencializar as atividades de extensão universitária e também atender aos requisitos definidos pelos órgãos regulamentadores (GROCHAU; CATEN, 2012). Nascimento et al. (2015) realizaram uma pesquisa em quinze laboratórios da Escola Politécnica da Universidade Federal da Bahia (EPUFBA), a qual objetivou verificar o índice de interesse destes laboratórios em implantar um sistema de gestão da qualidade. Desse modo, como resultados obtidos por esses autores foi que 13,3% dos laboratórios pesquisados utilizam ou utilizaram um SQG e dos outros 86,7%, que não utilizam nem utilizaram, apenas 15,4% não demonstraram interesse em implantar um SGQ. Os laboratórios de calibração e ensaios são, de uma maneira geral, organizações que prestam serviços. E como tal precisam se organizar para realizar seus serviços de forma que seja garantida a confiança das atividades desempenhadas e dos serviços oferecidos (VILAS BOAS; COSTA, 2013) a isso se denomina gestão organizacional. Segundo Pádua, Cazarini e Inamasu (2004) para a realização da gestão organizacional pode-se utilizar diferentes ferramentas, uma delas é a modelagem organizacional, por meio do detalhamento dos processos utilizando diagramas de atividades, que facilita a compreensão do negócio e é uma das atividades mais importantes da engenharia de requisitos a qual é apresentada na seção 2.2. Além disso, é possível melhorar os resultados e a satisfação das pessoas envolvidas no negócio por meio da revisão das rotinas dos processos de trabalho (ALMEIDA, 2013). Isso pode ser feito com o uso de ferramentas das etapas iniciais do desenvolvimento de software. Dentre as práticas para a melhoria do desempenho citadas por Almeida (2013) estão: (i) melhoria da gestão, (ii) mapeamento de processos de trabalho (com o uso do software Bizagi® para a modelagem) e (iii) melhoria de processos de trabalho (eliminando atividades que não agregam valor). 2.2

Metodologias de desenvolvimento de software Para desenvolver softwares deve-se optar por uma metodologia que melhor se adeque

ao cenário em questão. Sommerville (2001) menciona dois grandes grupos de metodologias para desenvolvimento de softwares, os ágeis e os tradicionais. As metodologias ágeis são caracterizadas por serem adaptativas e orientadas para pessoas. Como exemplo de métodos ágeis pode-se citar o Extreme Programming (XP) e o 5

Scrum, os quais são detalhados em Mainart e Santos (2010). Além dessas, também são encontradas outras metodologias ágeis em Sommerville (2011), Pfleeger (2004) e Pressman (2011). Como princípios dos métodos ágeis, Sommerville (2011) cita o alto nível de envolvimento do cliente com o processo de desenvolvimento. Nessas metodologias o software é desenvolvido por meio de entregas incrementais ao cliente especificando os requisitos a cada entrega, o desenvolvimento do software tem enfoque nas pessoas e não nos processos e utilização em desenvolvimento de sistemas simples. As metodologias tradicionais ou também conhecidas como modelos de ciclo de vida clássicos se caracterizam por ter caráter preditivo, prescritivo, burocrático, demorado e sequencial (PRESSMAN, 2011). Outra característica marcante deste tipo de metodologia é que se dividem em etapas e/ou fases. Cada uma dessas fases quando concluídas geram um documento. Um exemplo de uma metodologia tradicional do tipo cascata é apresentado na Figura 2, onde fica clara sua subdivisão em etapas ou fases.

Figura 2 - Abordagem de desenvolvimento de software tradicional Fonte: Adaptado de Bezerra (2007)

Outro tipo de metodologia tradicional é o ciclo de vida iterativo e incremental no qual se divide o desenvolvimento em ciclos. A cada ciclo é considerado um subconjunto de requisitos o que produz um incremento a cada um desses ciclos, podendo haver refinamentos e extensões sobre os requisitos anteriormente identificados. Deste modo, pode-se generalizar o modelo de desenvolvimento iterativo e incremental à abordagem em cascata, pois o aplicativo computacional é desenvolvido em incrementos e a cada um destes incrementos é desenvolvido em cascata (BEZERRA, 2007). O modelo de ciclo de vida iterativo e incremental é representado na Figura 3 e como se pode observar cada iteração é um “ciclo em cascata”. Algumas vantagens da utilização do 6

desenvolvimento iterativo incremental, quando comparado a outros modelos são: baixo custo na modificação dos requisitos; clientes auxiliam com feedbacks no desenvolvimento incremental e; entrega e implementação de software realizadas rapidamente ao cliente, pois isso é feito mesmo que não esteja totalmente concluída a sua funcionalidade.

Figura 3 - Abordagem de desenvolvimento de software incremental e iterativo Fonte: Adaptado de Bezerra (2007)

Outras metodologias tradicionais e ágeis podem ser encontradas na literatura com, por exemplo, em Sommerville (2011), Pfleeger (2004) e Pressman (2011). Segundo Bezerra (2007), atualmente os modelos de ciclo de vida mais utilizados para o desenvolvimento de sistemas complexos são os que utilizam uma abordagem incremental e iterativa. Porém, como o objetivo dessa pesquisa não é o desenvolvimento de software não se define a melhor abordagem a ser utilizada. A escolha da melhor abordagem é feita pelos desenvolvedores quando de fato for desenvolvido o software e depois de executadas as etapas de levantamento e análise de requisitos.

2.3

Requisitos de software Os requisitos de um software são as especificações dos serviços que o sistema deve

fornecer, bem como as restrições operacionais do negócio (SOMMERVILLE, 2011). Esses requisitos apresentam as necessidades do cliente de um sistema computacional que auxiliará a resolução de algum problema. Para que se consiga definir os requisitos na engenharia de requisitos, é necessário que se tenha criatividade, envolvimento de pessoas de diferentes setores, conhecimento e experiência no que se refere a transformar as informações em modelos que direcionem o desenvolvimento do software (SOMMERVILLE, 2011). 7

Os requisitos de sistema podem ser do tipo: (i) requisitos de usuário que são a declaração do que o cliente espera dos serviços do sistema utilizando uma linguagem natural com diagramas; (ii) requisitos de sistema são a definição detalhada das funções, serviços e restrições operacionais do sistema (SOMMERVILLE, 2011). Segundo Sommerville (2011), os requisitos de sistema e de usuário podem ser classificados em requisitos funcionais e não funcionais:  Requisitos funcionais: descrevem explicitamente o que o sistema deve e o que não deve fazer, as funções detalhadas do sistema, suas entradas e saídas, exceções, etc.  Requisitos não funcionais: definem as propriedades e restrições do sistema como segurança, desempenho, padrões do cliente, legislação, espaço, entre outros. A etapa de levantamento de requisitos é realizada pelos analistas (PFLEEGER, 2004), o que no caso desta pesquisa é caracterizado pelo pesquisador.

2.4

Levantamento e documentação de requisitos para o desenvolvimento de software O levantamento de requisitos é uma etapa significativa para a concepção dentro da

engenharia de requisitos, onde o analista deve utilizar todas as informações disponíveis que irão gerar os requisitos e com isso identificar as funções que o sistema irá disponibilizar (WAZLAWICK, 2011). Bezerra (2007) diz que o levantamento de requisitos pode ser feito por meio de (i) questionários, que tem por objetivo a descoberta de problemas a serem tratados, identificar procedimentos importantes e saber a opinião e as expectativas do entrevistado sobre o sistema; (ii) entrevistas, que consistem em conversas direcionadas com um propósito específico e com formato “pergunta-resposta” e que tem os mesmos objetivos dos questionários; (iii) observação, que consiste em observar o comportamento e o ambiente dos indivíduos de vários níveis organizacionais; entre outros. Malucelli et al. (2010) utilizaram diferentes técnicas para realizar o levantamento dos requisitos: (i) contato inicial para identificar os objetivos e restrições do software a ser desenvolvido juntamente com os envolvidos no negócio, (ii) observação para facilitar o entendimento dos desenvolvedores e buscar atender às necessidades dos usuários, (iii) workshops para delimitação dos objetivos, funcionalidades e usos do software e, (iv) a prototipagem do software, utilizando esboços em papel. A atividade de levantamento de requisitos é complexa, pois pode apresentar problemas como escopo mal definido, mau entendimento dos usuários quanto às capacidades e

8

limitações do sistema computacional e volatilidade dos requisitos, que mudam ao longo do tempo (CHRISTEL; KANG, apud PRESSMAN 2011). Em casos onde se utilizam diagramas de atividades que modelam os principais processos do sistema, o levantamento de requisitos deve identificar as funções necessárias para realizar as atividades destes processos (WAZLAWICK, 2011). Por este motivo, é ideal que a primeira atividade do levantamento de requisitos seja a modelagem do negócio, por meio da construção de diagramas de atividades dos processos do negócio. Pádua, Cazarini e Inamasu (2004) dizem que a modelagem organizacional ajuda no entendimento do negócio e é uma atividade considerada muito importante na engenharia de requisitos. Os diagramas de atividades são utilizados para descrever e simplificar a visualização da lógica de procedimentos, do processo de negócio e dos fluxos de trabalho (FOWLER, 2005). Esse tipo de diagrama é orientado para fluxos de controle e pode ser visto como uma “evolução” dos fluxogramas, incluindo a possibilidade de representação de ações paralelas (BEZERRA, 2007). A utilização de ferramentas como os diagramas de atividades para o mapeamento dos processos permite identificar as etapas do processo de trabalho, dos subprocessos e detalhar as atividades a serem executadas. Para a elaboração dos diagramas de atividades das rotinas do negócio pode-se utilizar diferentes ferramentas computacionais, sendo uma destas o Bizagi® que dá apoio à modelagem do negócio para posterior levantamento de requisitos e também serve de ferramenta de melhoria do sistema de gestão da qualidade do negócio (ALMEIDA, 2013). No levantamento de requisitos para o desenvolvimento de um software que dá apoio à sistematização da assistência de enfermagem no Sistema Único de Saúde (SUS), Malucelli et al. (2010) optaram por construir uma versão com funcionalidades básicas para atender à realidade do negócio. Por isso, listaram os requisitos básicos do software juntamente com os usuários (as enfermeiras, nesse caso) envolvidos no levantamento dos requisitos. Estes requisitos estão resumidos na Figura 4. Após a modelagem do negócio e o levantamento dos requisitos, deve-se descrever as rotinas e os requisitos elaborados nas fases anteriores em documentos, denominada etapa de documentação. Esta etapa é a oficialização dos resultados da engenharia de requisitos. Sugere-se a elaboração de um Documento de Requisitos que deve descrever os requisitos de usuário, isto é, os requisitos funcionais e os requisitos não funcionais (PFLEEGER, 2004).

9

Os benefícios oferecidos pela elaboração da documentação são, por exemplo, melhor comunicação entre os requisitos, menor trabalho no desenvolvimento, apresentar estimativas reais, serve como base para a próxima etapa de verificação e validação (BEZERRA, 2007).

Escopo Coleta de dados

Diagnóstico de enfermagem Planejamento da assistência

Implementação da assistência Avaliação da assistência

Requisitos Registrar dados da entrevista Registrar dados do exame físico Registrar dados complementares Possibilitar a importação dos dados do prontuário único Selecionar diagnóstico de enfermagem pré-elaborados por necessidade humana Possibilitar a formulação de novos diagnósticos Possibilitar a seleção de ações pré-elaboradas, por diagnóstico Possibilitar a formulação de novas ações de enfermagem Possibilitar a formulação de resultados de enfermagem Registrar as ações realizadas Registrar informações complementares Incluir escala para registro da avaliação do alcance de resultados por diagnóstico Possibilitar o registro de informações complementares

Figura 4 - Lista de requisitos do sistema Fonte: Malucelli et al. (2010)

Para a documentação dos requisitos pode-se utilizar a formatação desejada pelo analista, contendo os campos e informações que este considerar apropriado de modo a facilitar o entendimento. Desse modo, segundo Wiegers (2003) e Pfleeger (2004) os requisitos devem ser completos, corretos, consistentes, realistas, necessários, passíveis de serem priorizados, verificáveis e rastreáveis. Além disso, é recomendável que se realize revisões da documentação dos requisitos em busca de inconsistências e soluções para estas e se estipule os critérios de aceitação para os requisitos.

3

METODOLOGIA Nesta seção é apresentado o cenário onde foi aplicada a pesquisa, o método e as etapas

da pesquisa.

3.1

Cenário Quanto ao cenário em estudo, o local onde a pesquisa foi aplicada é o Sistema de

Gestão de Laboratórios do Centro de Tecnologia (SGLab CT). Trata-se de um sistema de gestão de laboratórios unificado do Centro de Tecnologia (CT) da Universidade Federal de Santa Maria (UFSM). A UFSM está localizada na cidade de Santa Maria, na região central do Rio Grande do Sul, e possui 29246 alunos divido entre 14 unidades universitárias. O CT possui 14 cursos de

10

graduação, dentre estes estão os cursos de engenharia, Sistemas de informação e Arquitetura e Urbanismo. Além disso, conta com seis Programas de Pós-graduação (UFSM, 2016). Atualmente, participam do SGLab CT quatro laboratórios (todos eles pertencentes ao CT) que visam a adequação aos requisitos da ABNT NBR ISO/IEC 17025, objetivando a acreditação, o reconhecimento ou a estruturação de um SG formal. O SGLab CT é um órgão suplementar de estrutura informal dentro da estrutura organizacional do CT, o qual caracteriza o negócio para esta pesquisa (SGLABCT, 2016). Os laboratórios que compõe o SGLab CT são: (i) Laboratório de Ensaios do Grupo de Eletrônica de Potência e Controle (LabEnsaios GEPOC): ensaios em inversores fotovoltáicos; (ii) Laboratório de Apoio ao Desenvolvimento e Inovação de Produtos e Processos (LADIPP): calibração e ensaios das grandezas dimensional, força, massa e volume; (iii) Laboratório de Materiais de Construção Civil (LMCC): ensaios na área da construção civil e; Laboratório de Meio Ambiente (LEMA): ensaios físico-químicos e biológicos. (SGLABCT, 2016). Para dar apoio à gestão do SGLab CT têm-se uma administração, denominada Escritório da Qualidade (EQ), composta por Gerente da Qualidade e Analistas da Qualidade. Esta equipe dá suporte a todos os laboratórios do SGLab CT na construção e manutenção do SGQ.

3.2

Método de pesquisa Esta pesquisa é de natureza aplicada, por se tratar da necessidade de aquisição de

conhecimentos com vistas à aplicação específica (GIL, 2010), e uma abordagem do tipo qualitativa, pois não tem métodos estatísticos estabelecidos para a análise dos dados (BRYMAN, 1989 apud MIGUEL, 2010). No que se refere aos objetivos, a pesquisa é exploratória, pois envolve levantamento bibliográfico, entrevista com pessoas que tiveram experiências práticas com o problema pesquisado (GIL, 2010) e, também, explicativa, pois visa identificar os fatores que determinam ou contribuem para a ocorrência dos fenômenos (GIL, 2010), no caso do problema da pesquisa se trata do levantamento dos requisitos. Quanto aos procedimentos técnicos, a pesquisa é do tipo pesquisa-ação, pois os membros do sistema que está sendo estudado participam ativamente e de forma cooperativa com os pesquisadores (RIORDAN, 1995 apud MIGUEL, 2010) e pelo fato de descrever o desdobramento de uma série de ações ao longo do tempo em um dado grupo (COGHLAN; BRANNICK, 2008 apud MIGUEL, 2010), que no caso da pesquisa se trata dos membros dos

11

laboratórios. Em suma, a pesquisa está relacionada com a resolução de um problema coletivo, e é necessário o envolvimento dos participantes do sistema e pesquisadores (GIL, 2010).

3.3

Etapas da pesquisa Esta pesquisa consiste em três etapas, sendo a primeira um levantamento do uso de

softwares de gestão por laboratórios de calibração e ensaios e na sequencia as duas etapas do método da engenharia de requisitos. Deste modo, a pesquisa foi realizada utilizando duas das primeiras etapas do processo de engenharia de requisitos de Kotonya e Sommerville (1998) devido a limitações de tempo da pesquisa e aplicação da metodologia. As etapas utilizadas são: (i) levantamento de requisitos, e (ii) documentação de requisitos. As etapas utilizadas nesta pesquisa são descritas em detalhe na sequência. Etapa 1 – Pesquisa e levantamento da gestão organizacional de laboratórios de calibração e ensaios. Para realizar essa etapa foi elaborado um instrumento de coleta de dados apresentado no Apêndice A o qual foi aplicado online por meio da ferramenta de Formulário do Google. Com realização dessa etapa desejou-se verificar se os laboratórios pesquisados utilizavam algum sistema de gestão e qual a sua percepção deste para gerenciar seu SGQ. Etapa 2 – Levantamento dos requisitos: esta etapa consiste em entender o negócio, os processos existentes, as necessidades, as possibilidades de melhoria, como os processos são gerenciados e as restrições do negócio. Nesta etapa foi realizada a modelagem do negócio, a qual dará apoio quando o software for desenvolvido. Para modelar o negócio foram construídos diagramas de atividades utilizando o software Bizagi®. A coleta de dados ocorreu por meio de entrevistas e observação local. A partir dos diagramas de atividades, foram levantados os requisitos funcionais e não funcionais. Etapa 3 – Documentação dos requisitos: depois do levantamento dos requisitos esses devem ser documentados para que os resultados obtidos sejam registrados de forma padronizada. A documentação dos requisitos foi gerada por meio de documento de texto do Word em formato definido pelos pesquisadores, contendo as informações necessárias e pertinentes aos objetivos da pesquisa.

12

4

RESULTADOS E DISCUSSÃO Nesta seção são apresentados os resultados e a discussão dos resultados acerca da

pesquisa. Os tópicos apresentados são: gestão organizacional de laboratórios de calibração e ensaio, levantamento dos requisitos e documentação dos requisitos.

4.1

Gestão organizacional de laboratórios de calibração e ensaio Para a verificação sobre a gestão organizacional de laboratórios de ensaio e calibração

em relação a uso de software foi enviado um questionário para 61 laboratórios, dos quais retornaram 29 (47,5%). Os laboratórios pesquisados estão instalados no Rio Grande do Sul, são privados e públicos, pertencentes e/ou não pertencentes a IES, acreditados e/ou não acreditados, de calibração e/ou ensaios. Responderam à pesquisa laboratórios tanto de ensaios (79,3%) como de calibração (20,7%) os quais são reconhecidos pela Rede Metrológica RS (24,1%), acreditados pela CGCRE/INMETRO (27,6%) e reconhecidos e acreditados (48,3%). Dentre os laboratórios pesquisados, os mesmos possuem quantidade de funcionários que variam de um a 50 e 62,06% destes laboratórios utilizam software de gestão. Como funcionalidades dos softwares, utilizadas pelos laboratórios, consideradas eficazes tem-se: gerenciamento das amostras e ensaios; liberação de resultados; controle de contato com clientes, pedidos, propostas e contratos; controle de documentos (internos e resultados de serviço); controle de pessoal, controle de equipamentos, rastreabilidade de medição; e edição de funções do software pelos próprios colaboradores. Em contrapartida, estes laboratórios citaram algumas funcionalidades em que o(s) software(s) utilizado(s) não se mostra(m) eficaz(es), como por exemplo: não possuir ferramenta para controle do faturamento dos serviços prestados, controle ineficaz dos documentos e não tem possibilidade de edição dos documentos no próprio software, software é lento para executar suas funcionalidades, não possuir chat para conversa com o cliente, não possuir ferramenta para treinamentos, não possuir ferramenta para avaliação de fornecedores, e dificuldade em gerar/cadastrar os certificados de calibração e relatórios de ensaio. A partir dos dados da pesquisa com os laboratórios foi possível elencar as principais funcionalidades e sua relação com os requisitos da norma ABNT NBR ISO/IEC 17025 (ver Figura 5). Na Figura 5, além das funcionalidades citadas pelos laboratórios foram incluídas aquelas que os pesquisadores consideram importantes, as quais foram identificadas a partir de sua vivencia com o negócio em estudo.

13

Pode-se perceber que as funcionalidades apresentadas na Figura 5 podem ser consideradas requisitos funcionais e não funcionais do software de gestão a ser desenvolvido. Os requisitos não funcionais, bem como os funcionais, são apresentados por meio da documentação dos requisitos na seção 4.3. Analisando os itens da norma ABNT NBR ISO/IEC 17025 relacionados com as funcionalidades elencadas, não são citados apenas o 4.1 (Organização), pois se trata de todo o sistema, e o 5.1 (Generalidades), pois é apenas uma lista dos itens da seção 5 (Requisitos técnicos). Isso demonstra que as funcionalidades elencadas cobrem todos os requisitos da norma. As outras funcionalidades elencadas que não estão relacionadas diretamente a algum item da norma podem ser tanto requisitos funcionais como funcionais. Nº

Funcionalidades

Item da norma relacionado

1

Monitoramento de indicadores

2

Controle de documentos

4.3

3

Possibilidade de edição de documentos no próprio software

4.3

4

Controle de pedidos, propostas e contratos

4.4

5

Ferramenta para avaliação de fornecedores

4.6

6

Controle de aquisição de serviços e suprimentos

4.6

7

Controle de contato com clientes

8

Possuir chat para conversa rápida com cliente

9

Gerenciamento de ações corretivas, preventivas e de melhoria (cronograma)

4.2.2

4.7/4.8

10 Controle de pessoal 11 Ferramenta para treinamentos

4.7/4.8 4.9/4.10/4.11/4.12/4.14/4.15 5.2 5.2

12 Ferramentas estatísticas para realização da validação de métodos de ensaio/calibração 13 Controle de equipamentos 14 Gerenciamento de amostras 15 Ferramentas estatísticas para monitoramento dos resultados dos ensaios/calibrações 16 Controle e liberação de resultados, rastreabilidade de medição 17 Gerar/cadastrar certificados de calibração e/ou relatórios de ensaio 18 Controlar registros 19 Edição de funções do software pelos próprios colaboradores

5.3/5.4 5.5/5.6 5.7/5.8 5.9 5.10 5.10 4.13 Não se aplica

20 Controle de faturamento dos serviços prestados 21 Possuir ferramenta de busca rápida

Não se aplica

22 Acesso web e mobile

Não se aplica

Não se aplica

Figura 5 - Funcionalidades importantes/necessárias em um software de gestão Fonte: Autor (2016)

4.2

Levantamento dos requisitos O levantamento de requisitos iniciou com o entendimento do negócio e, para tanto,

foram realizadas atividades de: entrevista; observação das tarefas dos laboratórios do SGLab CT; identificação dos agentes, das tarefas e das rotinas dos laboratórios e; modelagem dos processos (elaboração dos diagramas de atividades). Os agentes são as funções das pessoas 14

que realizam as tarefas. As rotinas são os processos do SGLab CT, os quais são realizados por meio de tarefas. Com as entrevistas foram identificadas as rotinas, as tarefas e os agentes relacionados a cada tarefa. As rotinas identificadas no negócio são:  adquirir serviços de calibração;  adquirir serviços e suprimentos;  cadastrar cliente;  emitir certificado de calibração;  emitir relatório de ensaio;  gerar solicitação de serviço;  gestão de documentos;  gestão de pessoas;  atender cliente;  implantar plano de ação para oportunidade de melhoria;  monitorar indicador "Número de reclamações procedentes";  monitorar indicador "Resultados de ensaios de proficiência";  monitorar indicador "Satisfação de clientes";  monitorar indicador "Taxa de ações corretivas/preventivas implantadas";  monitorar indicador "Total de ensaios/calibrações realizados";  monitorar tendências dos resultados das medições;  participar de ensaio de proficiência;  realizar análise crítica do sistema de gestão;  realizar auditorias internas;  tratar não conformidades;  tratar reclamações de clientes;  tratar trabalhos não conformes. As rotinas identificadas foram organizadas por afinidade em cinco processos (grupos): gestão de pessoas; gestão de documentos; prestação de serviços; auditoria interna; e análise crítica pela direção. Também foram identificados oito agentes. Os processos (grupos) são apresentados na Figura 6 a qual traz uma ordem lógica para o levantamento dos requisitos deste software. Esta ordem foi definida com base na vivência prática no negócio e análise da ordem da execução das rotinas no dia-a-dia do SGLab CT.

15

Gestão de pessoas

Gestão de documentos

Prestação de serviço

Auditoria interna

Análise crítica pela direção

Figura 6 - Processos do SGLab CT Fonte: Autor (2016)

Foram escolhidos três processos para detalhamento do levantamento e documentação dos requisitos: a gestão de pessoas, gestão de documentos e prestação de serviços. Os agentes e as tarefas dessas três rotinas são apresentados na Figura 7.

Figura 7 - Principais rotinas e tarefas do SGLab CT Fonte: Autor (2016)

O processo de gestão de pessoas tem relação com os itens 4.2.2, 4.3, 4.13 e 5.2 da norma e nesse levantamento foram identificadas nove tarefas para sua realização. O processo de gestão de documentos tem relação com os itens 4.3, 4.13 e 5.2 da norma e nesse 16

levantamento foram identificas sete tarefas para sua realização. A rotina de prestação de serviço tem relação com os itens 4.2.2, 4.3, 4.4, 4.5, 4.6, 4.7/4.8, 4.13, 5.3/5.4, 5.7/5.8 5.9 e 5.10 da norma e nesse levantamento foram identificadas 11 tarefas para sua realização. Depois de elaborada a planilha (Figura 7), foi possível modelar as três rotinas por meio de diagramas de atividades com o Bizagi®. A Figura 8 apresenta o diagrama de atividades do processo de Gestão de Pessoas. As tarefas deste processo foram divididas por afinidade em cinco subprocessos: i) definir as funções do pessoal; ii) seleção de pessoal; iii) treinamentos; iv) autorizações e v) monitorar indicador. Esse processo é fundamental para o laboratório visto que a partir da definição das funções das pessoas elas serão alocadas para a realização dos serviços. Cada função tem autoridades e responsabilidades definidas, as quais serão utilizadas pelo software para definir as permissões de cada função.

Figura 8 – Diagrama de atividades do processo de Gestão de Pessoas Fonte: Autor (2016)

A Figura 9 apresenta o diagrama de atividades com a modelagem do processo de Gestão de documentos. Como se pode observar, ao elaborar este diagrama, foi necessário ajustar as tarefas previamente identificadas pela planilha da Figura 7. No primeiro momento 17

foram identificadas sete tarefas e depois da modelagem oito, as quais foram subdivididas em três subprocessos (elaborar documento; aprovar/distribuir documento; revisar documento). Este processo é essencial ao SGLab CT, pois define o padrão de execução das atividades de elaboração, revisão, aprovação e distribuição de todos os documentos utilizados.

Figura 9 – Diagrama de atividades do processo Gestão de documentos Fonte: Autor (2016)

A Figura 10 apresenta o diagrama de atividades do processo de Prestação de Serviço. Como se pode notar, comparando com a Figura 7, inicialmente foram identificadas 11 tarefas e depois da modelagem 12. Além disso, algumas tarefas tiveram seus nomes e consequentemente seu entendimento modificados durante a modelagem. Dentre as modificações, acrescentou-se o monitoramento do indicador “Número de ensaios/calibrações realizados” por esta tarefa estar diretamente ligado ao processo de Prestação de serviço, esse fato não havia sido notado pelos pesquisadores no momento da listagem das rotinas e tarefas apresentadas anteriormente pela Figura 7.

18

Figura 10 - Diagrama de atividades do processo de Prestação de serviço Fonte: Autor (2016)

A ocorrência das modificações e melhorias citadas anteriormente para o sistema de gestão são fatos que corroboraram com o que foi apresentado por ALMEIDA (2013) que é o uso da modelagem para a melhoria do processo o que incluiu a revisão do padrão de realização desses processos. Também é necessário ressaltar que os diagramas de atividades criados são fruto do entendimento que os pesquisadores tiveram do processo. Outros pesquisadores poderiam construir diagramas de atividades diferentes destes, mas com o mesmo resultado no final de cada processo. Por fim, em relação aos diagramas de atividades deve-se ressaltar que o resultado apresentado nessa seção já inclui as modificações que foram realizadas enquanto a documentação dos requisitos era elaborada.

4.3

Documentação dos requisitos Em seguida à elaboração dos diagramas de atividades dos processos elencados

anteriormente foi possível elaborar a documentação dos requisitos. Seguindo o que Pfleeger (2004) sugere, esta documentação contém os requisitos funcionais e não funcionais de cada um dos processos. Dessa forma, a documentação elaborada nesse trabalho é composta pela descrição do processo; pelos requisitos não funcionais e funcionais que se aplicam a todo o processo e pelos requisitos funcionais de cada subprocesso. Na documentação dos requisitos tomou-se o cuidado de que eles fossem documentados de maneira que ficassem completos, corretos, consistentes, realistas,

19

necessários, passíveis de serem priorizados, verificáveis e rastreáveis como recomendado por Wiegers (2003) e Pfleeger (2004). Durante a elaboração da documentação dos requisitos se observou a necessidade de retornar ao diagrama de atividades para refletir se a sequência proposta era adequada. Em alguns casos novos ajustes foram necessários e então se retornava à elaboração da documentação bem como sugerido Wiegers (2003) e Pfleeger (2004). A documentação dos requisitos foi elaborada de forma que estes tenham o maior número de detalhes possíveis de maneira que possam ser claramente entendidos e as lacunas minimizadas. Esse fato é importante porque nem sempre o analista de requisitos está à disposição do desenvolvedor do software para esclarecimentos dos requisitos. Esse fato atesta o que afirma Bezerra (2007). A documentação dos requisitos dos processos de gestão de pessoas, gestão de documentos e prestação de serviço estão apresentados no Apêndice B, C e D, respectivamente. Como se pode notar, se trata de uma lista extensa de requisitos levantados para atendimento dos objetivos desta pesquisa. A partir da documentação pode-se observar (ver Figura 11) que os processos apresentam um total de cinco requisitos não funcionais, 13 requisitos funcionais gerais (que se aplicam a todo o processo) e 91 requisitos funcionais específicos, onde se consideram os subprocessos de cada um destes processos. Sendo assim, foram levantados e documentados um total de 109 requisitos distintos para os três processos estudados nesta pesquisa.

Processo

Requisitos não funcionais

Requisitos funcionais gerais

Requisitos funcionais específicos

Gestão de pessoas Gestão de documentos Prestação de serviço TOTAL

1 2 2 5

4 3 6 13

18 44 29 91

Figura 11 - Quantificação de requisitos Fonte: Autor (2016)

Quando verificados os requisitos não funcionais dos três processos, pode-se perceber que os requisitos (i) Deve ser possível colocar nos documentos (MQ, PSQ, POP, IT) tabelas, figuras, fotos e (ii) Estar disponível para uso na web por computador, tablet e celular são requisitos não funcionais que se repetem em todos os processos. Já o requisito não funcional “possibilidade de emissão de certificados para os treinamentos do SGLab CT” está

20

documentado apenas no processo de Controle de pessoal. Assim, tem-se ao todo apenas três requisitos não funcionais distintos. Quanto aos requisitos funcionais gerais dos processos, o requisito “Possuir ferramenta de busca rápida” está presente em todos os processos estudados, pois é necessário que se possa buscar rapidamente dados e registros em todas as rotinas do SGLab CT. A partir da documentação pode-se notar que muitos dos requisitos levantados comprovam as funcionalidades encontradas por meio da pesquisa com os laboratórios na primeira etapa desta pesquisa (Figura 5). Deste modo, pode-se apresentar as funcionalidades encontradas anteriormente relacionando aos requisitos encontrados nesta pesquisa. A Figura 12 apresenta o mapa conceitual que relaciona os processos estudados (localizados ao centro do mapa) aos requisitos levantados e documentados. Como se pode notar, alguns requisitos são comuns a dois ou mais dos processos, como por exemplo, monitoramento de indicadores e controle de documentos. Já outros requisitos são encontrados em apenas um processo, como por exemplo, controle de contato com clientes e ferramenta para treinamentos. As funcionalidades “Gerenciamento de ações corretivas, preventivas e de melhoria (cronograma)” e “Controle de equipamentos” não estão presentes em nenhum dos requisitos. Isso se deve ao fato de que os processos estudados (Gestão de pessoas, Gestão de documentos e Prestação de serviço) não têm conexão com os itens 4.9/4.10/4.11/4.12/4.14/4.15; e 5.5, respectivamente, da ABNT NBR ISO/IEC 17025.

Figura 12 – Mapa conceitual dos processos relacionados às funcionalidades desejadas Fonte: Autor (2016)

21

5

CONCLUSÃO O presente trabalho propôs o levantamento e a documentação dos requisitos de todos

os processos do SGLab CT. Entretanto, foram levantados e documentados os requisitos dos três processos mais importantes do negócio: Gestão de pessoas, Gestão de documentos e Prestação de serviços. Durante a aplicação da metodologia escolhida foram atingidos os objetivos definidos para a pesquisa. O fato de os pesquisadores deste trabalho estarem inseridos e possuírem experiência no dia a dia do negócio foi um elemento facilitador para atingir o objetivo de identificação das rotinas de trabalho dos laboratórios para o atendimento do sistema de gestão da qualidade a que estes estão inseridos de acordo com os requisitos da norma. Além disso, foram entendidas as rotinas de trabalho, atividade facilitada pelo fato de que as rotinas do negócio estavam inicialmente descritas em procedimentos padrão. Foram obtidas, também, as principais funcionalidades desejadas para um software de gestão, por meio de pesquisas com laboratórios de ensaio e calibração de IES que já utilizam ou não algum software. Com a modelagem dos três processos do negócio por meio de diagramas de atividades, houve a necessidade de revisar estes procedimentos padrão e o modo de executar as atividades inseridas nos processos. Com isso, esta pesquisa contribuiu ao SGLab CT de modo a melhorar seus processos e torná-los mais aplicáveis na prática, corroborando assim com a gestão organizacional. Por fim, foram levantados e documentados os requisitos. Os processos apresentaram um total de cinco requisitos não funcionais, 13 requisitos funcionais gerais e 91 requisitos funcionais específicos, isto é, foram levantados e documentados um total de 109 requisitos distintos para os três processos estudados nesta pesquisa. Com o levantamento e documentação dos requisitos destes processos do SGLab CT, sugere-se que para trabalhos futuros sejam concluídos o levantamento e a documentação dos requisitos de todo o SGLab CT, fazendo isso para os dois processos restantes (auditoria interna e análise crítica pela direção). Em seguida a isso, sugere-se que para futuras pesquisas sejam realizadas, por pessoal com conhecimento nas áreas de tecnologia da informação, as próximas etapas do desenvolvimento de um software a ser utilizado neste negócio. As tarefas que dão seguimento a esta pesquisa são: (i) análise de requisitos; (ii) projeto; (iii) implementação; (iv) testes e; (v) implantação.

22

REFERÊNCIAS

ALMEIDA, P. A, Curso de mapeamento de processos de trabalho com BPMN e BIZAGI. Instituro Serzedello Corrêa, 2013. Disponível em: . Acesso em: 01 nov 2016. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 17025: Requisitos gerais para a competência de laboratórios de ensaio de calibração. Rio de Janeiro, 2005. BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2 ed. Rio de Janeiro: Elsevier, 2007. BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML Guia do Usuário, 2 ed. Rio de Janeiro: Elsevier, 2006. FELIPPES, B. A., AGUIAR, J. G., DINIZ, A. C. G. C. Sistema da qualidade em laboratórios universitários: incentivo ao ensino, pesquisa e extensão. Revista de Ensino de Engenharia, Brasília, v.30, n. 2, p. 14-23, 2011. FIORI, A. et al. A Case Study of a Laboratory Information System Developed at the Institute for Cancer Resech at Candiolo. In: MOUMTZOGLOU, A. et al. Laboratory Management Information Systems: Current Requirements and Future Perspectives. Hershey: IGI Global, 2015. cap. 13. GIL, A. C. Como elaborar projeto de pesquisa. 5 ed. São Paulo: Atlas, 2010. GROCHAU, I. H. Implementação de sistema de gestão da qualidade em laboratório de ensaio de instituição de ensino e pesquisa. 2011. 77f. Dissertação (Programa de PósGraduação em Engenharia de Produção) – Universidade Federal do Rio Grande do Sul, 2011. GROCHAU, I. H. CATEN, C. S. A process approach to ISO/IEC 17025 in the implementation of a quality management system in testing laboratories. Acreditation and Quality Assurance, v. 17, p. 519-527, 2012. Disponível em: < http://link.springer.com /article/10.1007/s00769-012-0905-3#page-1>. Acesso em: 20 out. 2016. INSTITUTO NACIONAL DE METROLOGIA, QUALIDADE E TECNOLOGIA (INMETRO). Laboratórios acreditados. Disponível em: Acesso em: 14 dez 2016. JORNADA, D. H., LERCH R. L., STEDILE, I., FERRARINI, C., PRATA, A. E., VIECELLI, A. Implantação da Norma ISO/IEC 17025 nos laboratórios da Universidade de Caxias do Sul. In: XII ENQUALAB. São Paulo: 2008. p. 1-4. Anais eletrônicos... Disponível em: . Acesso em 08 jun. 2016. LARMAN, C. Utilizando UML e padrões. Tradução: Rosana Vaccare Braga, et. al. 3 ed. Porto Alegre: Bookman, 2007. 23

MAGALHÃES, J. G., NORONHA, J. L. Sistema de Gestão da Qualidade para laboratório de metrologia de acordo com a NBR ISO/IEC 17025. In: XXVI ENEGEP. Out. 2006. Anais... Fortaleza – CE. p. 1-8, 2006. MAINART, D. A; SANTOS, C. M. Desenvolvimento de Software: Processos Ágeis ou Tradicionais? Uma visão crítica. In: VII Encontro Anual de Computação. Out. 2010. Anais...Catalão - GO: 2010. MALUCELLI, A. et al. Sistema de Informação para apoio à Sistematização da Assistência de Enfermagem. Revista Brasileira de Enfermagem, Brasilia, 63(4): 629-36, jul-ago. 2010. MIGUEL, P. A. C. et. al. Metodologia de pesquisa em Engenharia de Produção e Gestão de Operações. Rio de Janeiro: Elsevier, 2010. NASCIMENTO, H. d. S. et al. Gestão metrológica dos laboratórios experimentais da Escola Politécnica da UFBA: um estudo preliminar. In: 8º CONGRESSO BRASILEIRO DE METROLOGIA. Nov. 2015. Anais... Bento Gonçalves – RS. p. 1-4, 2015. OLIVARES, I, R, B. Gestão da Qualidade em Laboratórios. 3 ed. Campinas: Átomo, 2015. PÁDUA, S. I. D.; CAZARINI, E. W.; INAMASU, R. Y. Modelagem organizacional: Captura dos requisitos organizacionais no desenvolvimento de sistemas de informação. Gestão & Produção, São Carlos, v.11, n.2, p. 197-209, mai-ago. 2004. PFLEEGER, S. L. Engenharia de software: teoria e prática. Tradução: Dino Franklin; Revisão técnica: Ana Regina Cavalcanti da Rocha. 2 ed. São Paulo: Prentice Hall, 2004. PIZZOLATO, M. A influência do sistema de gestão de laboratórios nos resultados de ensaios de proficiência da construção civil. Revista Gestão e Produção, v. 15, n. 3, p. 579-589, 2008. PRESSMAN, R.S. Engenharia de Software. 7 ed. São Paulo: McGraw-Hill, 2011. ROCHA, A.R.C., MALDONADO, J.C., WEBER, K.C. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001. SALGADO, E. G.; SILVEIRA, L. d. A.; AZEVEDO, L. Implementação da ISO 9001:2008 em um laboratório de uma instituição pública federal. In: XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. Out. 2011. Anais... Belo Horizonte - MG, p. 10, 2011. SCHACH, S. R.; Engenharia de software: os paradigmas clássico & orientado a objetos. Tradução: Ariovaldo Griesi; Revisão técnica: Flávio Soares Corrêa da Silva. 7 ed. São Paulo: McGraw-Hill, 2009. SILVA, V. V. M. Acreditação de Laboratórios de Ensaio segundo a Norma ABNT NBR ISO/IEC 17025. 2013. 96 f. Dissertação (Programa de Pós-Graduação em Engenharia de Produção) – Universidade Federal do Rio Grande do Sul, 2013. SISTEMA DE GESTÃO DE LABORATÓRIOS DO CENTRO DE TECNOLOGIA (SGLABCT). Manual da Qualidade. Disponível em: . Acesso em: 01 jun. 2016. 24

SOMMERVILLE, I. Engenharia de software. Tradução: Ivan Bosnic e Kalinka G. O. Gonçalves; Revisão técnica: Kechi Hirama. 9 ed. São Paulo: Pearson Prentice Hall, 2011. UNIVERSIDADE FEDERAL DE SANTA MARIA (UFSM). Indicadores. Disponível em: . Acesso em: 20 mai. 2016. VILAS BOAS, G. A. R; COSTA, G. C. Modelo de autoavaliação para suporte à gestão organizacional: experimentação em indústria do segmento de malharia. Produção, Niterói, v. 23, n. 2, p. 297-311, abr-jun. 2013. WIEGERS, K.E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. 2 ed. Washington. Redmond: 2003.

25

APÊNDICE A Roteiro para elaboração da coleta de dados sobre a utilização de software de gestão em laboratório Parte 1: Pesquisa sobre a utilização de software de gestão em laboratório 1 Nome do laboratório 2 Área de atuação do laboratório 3 4 5 6

Laboratório 1 Laboratório 2 Laboratório n

Qual o número de colaboradores que atuam no laboratório? O laboratório é acreditado ou reconhecido? Quais são as ferramentas de apoio à gestão do laboratório? Se não utiliza software de gestão, qual o motivo pela não utilização?

Parte 2: Funcionalidades do(s) software(s) de gestão utilizado(s) 7 Se utiliza software de gestão, cite qual (is). 8 Já utilizou outro software de gestão? Qual? Qual foi o motivo da troca?

26

APÊNDICE B Documentação de requisitos – Gestão de pessoas Descrição Este documento tem por objetivo listar os requisitos funcionais e os requisitos não funcionais relacionados à gestão de pessoas que visa estabelecer os métodos e as diretrizes para assegurar a competência do pessoal que executa as atividades que influenciam nos resultados dos ensaios e calibrações realizados nos laboratórios que fazem parte do Sistema de Gestão de Laboratórios do Centro de Tecnologia (SGLab CT) de forma a atender ao item 5.2 da ABNT NBR ISO/IEC 17025. Requisitos não funcionais  Possibilidade de emissão de certificados para os treinamentos do SGLab CT;  Deve ser possível colocar nos documentos (MQ, PSQ, POP, IT) tabelas, figuras, fotos;  Estar disponível para uso na web por computador, tablet e celular. Requisitos funcionais  Possuir botão de seleção na tela inicial com título “Gestão de pessoas”;  Possuir interface e ferramenta de controle de indicador de “Horas de capacitação”;  O software deve atribuir as permissões de acesso para cada tarefa: 1) Documentar as funções do pessoal: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo, Analista da Qualidade, Metrologista; 2) Identificar necessidade de pessoal e selecionar pessoal: Gerente da Qualidade, Gerente Técnico e Gerente Administrativo; 3) Cadastrar pessoal selecionado: Gerente da Qualidade, Gerente Administrativo, Analista da Qualidade e Auxiliar Administrativo; 4) Planejar treinamentos, realizar treinamentos e verificar a eficácia dos treinamentos: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo, Analista da Qualidade e Auxiliar Administrativo; 5) Dar/atualizar as autorizações do colaborador: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo; 6) Monitorar indicador “horas de capacitação”: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo, Analista da Qualidade, Auxiliar Administrativo;  Possuir ferramenta de busca rápida. Definir as funções do pessoal O software deve:  Solicitar que o usuário (apenas os gerentes possuem esta permissão) informe quais são as atribuições/responsabilidades e autoridades de cada função que está inserida no SGLab CT, as funções que devem ser preenchidas são: Gerente da Qualidade, Gerente Administrativo, Gerente Técnico, Assistente Administrativo, Analista da Qualidade, Metrologista, Auxiliar de Metrologia e Auditores (Líder, Assistente e Especialista). Essas atribuições devem ficar registradas na IT 5.2 001 CT – Descrição das funções do pessoal e suas correspondentes de cada laboratório (as funções do GA e/ou GT devem conter minimamente as seguintes autoridades: Gerenciar o tratamento de Trabalho Não Conforme do seu laboratório/setor; Tratar reclamações de clientes; Manusear itens de ensaio do seu laboratório/setor; Aprovar a validação/confirmação de métodos de ensaio/calibração do seu laboratório/setor; Aprovar relatórios de ensaio e certificados de calibração do seu laboratório/setor; Acessar e recuperar os registros do Sistema de Gestão da Qualidade; Aprovar contratos do seu laboratório/setor; Autorizar a realização das atividades do pessoal do seu laboratório/setor; Selecionar pessoal para o quadro de colaboradores do seu laboratório /setor);  Solicitar que o usuário informe, para cada função: a educação formal, a especialização desejada, a experiência desejada, e os treinamentos necessário para essa função.

27

Seleção de pessoal O software deve:  Possuir botão de seleção para que sempre que seja necessária seleção de pessoal a alta direção e os gerentes do SGLab CT definam as necessidades de pessoal, sua formação, conhecimentos e habilidades. A necessidade de seleção de pessoal deve levar em consideração tipo e o volume de trabalho contratado ou a ser contratado. Os colaboradores do SGLab CT podem ser professores, pesquisadores, técnicos administrativos em educação, alunos de iniciação científica, de mestrado e de doutorado, todos vinculados a UFSM e ainda profissionais contratados via fundação e profissionais de empresas com convênio com a UFSM;  Solicitar que o gerente cadastre o nome completo da(s) pessoa(s) selecionada(s) e sua(s) respectiva(s) funções no SGLab CT e o laboratório/setor ao qual este pessoal será inserido;  Permitir e solicitar que o usuário com a função para isso cadastre todos os dados do pessoal selecionado por meio da aba “Dados Pessoais” do FOR 5.2 006 CT – Banco de dados do pessoal do SGLab CT, localizando o mesmo a partir do cadastro do nome do mesmo cadastrado anteriormente pelo gerente. Os dados a serem solicitados que o usuário preencha são: CPF, matrícula/SIAPE e e-mail;  Gerar o Termo de confidencialidade e imparcialidade (FOR 5.2 001 CT) e solicitar que o usuário imprima para que o novo pessoal cadastrado assine. Este registro deve ser armazenado na pasta do colaborador no arquivo físico do EQ. Treinamentos O software deve:  Possuir ferramenta de gerenciamento de cronograma de treinamentos (FOR 5.2 002 CT Cronograma de treinamentos do SGLab CT e FOR 5.2 003 CT Cronograma de treinamentos do Laboratório FOR 5.2 003 CT). Neste formulário consta a descrição dos treinamentos que serão realizados, a previsão da semana de realização e da semana efetiva realização dos treinamentos. Quando um treinamento não for realizado, deve ser registrada uma justificativa no formulário. O FOR 5.2 002 CT é preenchido pelo EQ. Com base neste, os laboratórios elaboram e preenchem seus respectivos cronogramas de treinamento (FOR 5.2 003 CT). Neste cronograma o laboratório deve levar em consideração os treinamentos já previstos pelo EQ e suas necessidades específicas. Os treinamentos necessários são do tipo internos (quando ministrados por pessoal do SGLab CT) e externos (quando ministrados por pessoal externo ao SGLab CT);  Fornecer/disponibilizar os treinamentos para as funções que tem a necessidade dos mesmos;  O usuário deve alimentar um banco de dados com os programas de treinamentos de acordo com os treinamentos estabelecidos na IT 5.2 001 LAB – Descrição das funções do pessoal do laboratório. Devem ser treinados os colaboradores que iniciam a operação de equipamentos ou procedimentos novos ou quando é revisado total ou parcialmente qualquer procedimento, formulário ou Manual da Qualidade, independentemente do cronograma de treinamento estabelecido. As necessidades de treinamento também podem surgir em outras situações como, por exemplo: na Reunião de Análise Crítica da Alta Direção do SGLab CT conforme definida no PSQ 4.15 CT; a partir da detecção de trabalho não conforme e após a avaliação do Gerente Técnico conforme definido no PSQ 4.9/4.11/4.12 CT; após sugestão de auditoria interna ou ainda de qualquer colaborador do laboratório, a ser analisada pelo Gerente Técnico, pelo Gerente Administrativo ou pelo Gerente da Qualidade;  Permitir que usuário insira questões acerca de cada procedimento (PSQ, IT, POP) para abastecer o banco de questões para verificação da eficácia de cada treinamento a ser aplicado. A cada revisão de documento as questões devem ser analisadas criticamente pelo usuário para verificar a aplicabilidade das questões;  Possuir ferramenta de aplicação de questionário para a verificação da eficácia dos treinamentos;  Registrar as horas de treinamentos por pessoa no FOR 5.2 006 CT Banco de dados do pessoal do SGLab CT;  Treinamento interno presencial: Quando for necessário realizar treinamentos internos presenciais, seu registro é realizado no FOR 5.2 005 CT – Controle de treinamentos presenciais;

28

 Treinamentos externos: No caso de treinamentos externos (fornecidos por terceiros), o colaborador entrega cópia do certificado de realização do treinamento no EQ para ser incluído em sua pasta, o que configura o registro do treinamento. Autorizações O software deve:  Solicitar que os gerentes autorizem os colaboradores a desempenharem suas respectivas funções, esse registro é feito por meio do FOR 5.2 004 CT - Autorizações do colaborador. Essas autorizações indicam que o colaborador está apto a realizar todas as atribuições/responsabilidades descritas na IT 5.2 001 CT e dos laboratórios de sua função, e ainda indica suas autoridades;  Enviar “mensagem” para que os gerentes do SGLab CT e os coordenadores dos laboratórios solicitem suas designações ao Diretor do CT. Este é um documento externo e deve ser armazenado no arquivo físico do EQ. Monitorar indicador de horas de capacitação O software deve:  Calcular o indicador de horas de capacitação por meio do somatório das horas de capacitação por colaborador por ano registradas no FOR 5.2 006 CT - Banco de dados do pessoal do EQ e demais treinamentos realizados registrados nas pastas dos colaboradores. Esse cálculo é realizado por meio das horas de treinamentos eficazes de cada colaborador ativo. A meta deste indicador é ter uma média de no mínimo sete horas de capacitações por colaborador por ano;  Armazenar os dados deste indicador no FOR 4.2.2 CT - Indicadores da Qualidade e apresentado na reunião de análise crítica da alta direção.

29

APÊNDICE C Documentação de requisitos – Gestão de documentos Descrição Este documento tem por objetivo listar os requisitos funcionais e os requisitos não funcionais relacionados à gestão de documentos que visa estabelecer os métodos e as diretrizes para a elaboração, identificação, aprovação, distribuição, revisão e controle dos documentos que fazem parte do Sistema de Gestão dos Laboratórios do Centro de Tecnologia (SGLab CT).

Requisitos não funcionais  Deve ser possível colocar nos documentos (MQ, PSQ, POP, IT) tabelas, figuras, fotos;  Estar disponível para uso na web por computador, tablet e celular. Requisitos funcionais  O software deve atribuir as permissões de acesso para cada tarefa: 1) Elaborar, revisar, distribuir e cancelar documentos internos e monitorar documentos externos: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo, Analista da Qualidade, Auxiliar Administrativo, Metrologista, Assistente de Metrologista; 2) Analisar criticamente os documentos internos: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo, Analista da Qualidade, Auxiliar Administrativo, Metrologista, Assistente de Metrologia; 3) Aprovar documentos internos: Gerente da Qualidade, Gerente Técnico, Gerente Administrativo;  Possuir botão de seleção na tela inicial com título “Gestão de documentos”;  Possuir ferramenta de busca rápida.

Elaborar documento interno O software deve:  Possuir Ícone de seleção para usuário informar se é documento externo ou documento interno;  Caso o usuário selecione “Documento interno”, abrir documento em formato de texto.  Ser capaz de elaborar documento em formato de texto;  Solicitar que o usuário informe o tipo de documento: PSQ (procedimento do sistema da qualidade), POP (procedimento operacional padrão) ou IT (instrução de trabalho);  Solicitar que o usuário preencha os campos do cabeçalho: título do documento, quando possível relacionado com o item da norma; código do documento: de acordo com o tipo de documento (PSQ, POP, IT);  Ser capaz de gerar um código unívoco para cada documento. Os procedimentos de sistema são identificados com as letras ‘PSQ’ e um número, de acordo com o requisito da norma ao qual o PSQ se refere (se um PSQ atender a mais de um requisito da norma, o usuário deve informar quais são, sendo que estes devem ser separados por uma barra automaticamente, por exemplo, PSQ 4.5/4.6 CT) seguido da sigla CT que o identifica como documento aplicado a todos os laboratórios do SGLab CT (exemplo: PSQ 4.3 CT). Quando houver necessidade de um laboratório utilizar um PSQ próprio, deve ser acrescida a sigla do laboratório, por exemplo: PSQ 5.4 CT LADIPP. Caso o usuário informe que o documento é um POP ou IT: Além das letras, deve haver um número, de acordo com o requisito da norma ao qual o POP/IT se referem seguido de três dígitos, utilizados em ordem crescente de elaboração, além da sigla do CT ou do laboratório. Caso um procedimento ou instrução atenda a mais de um requisito, deverão ser indicados ambos os requisitos separados por uma barra, por exemplo, POP 4.5/4.6 001 CT. O número 000 não é utilizado para identificar quaisquer documentos do SGLab CT bem como de seus laboratórios;  Solicitar que o usuário preencha os campos do rodapé: No caso da elaboração/revisão de quando o documento for gerado no Manual da Qualidade, PSQ, POP e IT (no formato de Word), no rodapé

30



  

  

devem constar os nomes dos responsáveis pela elaboração e aprovação, a data da data da revisão do documento, bem como o número da página e o número total de páginas do documento; Solicitar que o usuário preencha os campos do corpo do documento: o corpo do PSQ, do POP e da IT contém os (1) Objetivo: definir o propósito do documento e sua abrangência; (2) Referências: listar as referências externas ao SGLab CT; (3) Descrição: descrever as atividades necessárias para atingir os objetivos do documento; (4) Documentos vinculados e localização: citar os documentos internos vinculados ao documento; (5) Histórico das modificações: informar a data da aprovação da revisão e a descrição simplificada das modificações do documento. Os procedimentos de ensaio/calibração (POP) devem conter no campo descrição as condições ambientais de realização do ensaio/calibração e, quando pertinente, condições de armazenamento antes e depois do ensaio/calibração; o método de ensaio/calibração; os componentes de incerteza; informações sobre o preenchimento do Relatório de Ensaio/Certificado de Calibração; como devem ser encaminhados os itens de ensaio/calibração. A interface do software deve conter um ícone de seleção para elaboração de formulário, em casos em que o documento necessite de formulário para registros de dados. Ser capaz de elaborar formulário no formato de colunas e linhas. Solicitar que o usuário preencha os campos do cabeçalho do formulário: o título e o PSQ, POP ou IT ao qual este formulário está vinculado, para que gere automaticamente o código do formulário no cabeçalho, contendo inclusive o número da revisão e a data de aprovação do formulário. O código dos formulário gerados automaticamente devem ser identificados com as letras ‘FOR’ e um número, de acordo com o requisito da norma ao qual o procedimento se refere, seguido de três dígitos, utilizados em ordem crescente, além da sigla CT que o identifica como formulário aplicado a todos os laboratórios, por exemplo: FOR 4.3 001 CT. Quando houver necessidade de um laboratório utilizar um FOR próprio, a sigla CT deve ser substituída pela sigla do laboratório correspondente, por exemplo: FOR 4.5/4.6 001 LEMA, essa informação deve ser solicitada ao usuário. O número 000 não pode ser utilizado para identificar quaisquer formulários. Em seguida à criação do código, o software deve registrar este código como já utilizado para que não ocorra a repetição do mesmo código para outros documentos e que o próximo formulário a ser criado com relação ao mesmo item da norma tenha um número procedente na sequencia deste. Permitir que cada formulário a ser criado no software possa ter seus campos específicos. Como atualmente estes formulários estão em planilha eletrônica, estas planilhas serão convertidas uma a uma para que se adeque ao software. Os formulários não apresentam os nomes dos responsáveis no rodapé, entretanto, são os mesmos que elaboraram o documento ao qual esse está vinculado. O software deve finalizar o processo de elaboração de documento, salvando este no banco de dados de documentos “Em elaboração”.

Revisar documento interno  O responsável pela análise crítica deve visualizar se o documento é válido e se necessita ou não de revisão.  Quando da análise crítica de documentos (PSQ, POP e IT), seus respectivos formulários são automaticamente analisados criticamente, por isso o software deve informar ao usuário para que faça a análise crítica em todos os documentos vinculados a este documento que já foi analisado criticamente. Deve-se repetir esta etapa até que todos os documentos vinculados sejam também analisados criticamente.  O software deve solicitar que o usuário registre o resultado na análise crítica na LM001 - Lista mestra de documentos internos. A LM 001 deve conter os campos para que o software solicite o preenchimento do usuário responsável pela análise crítica: data da revisão ou (i) no caso da revisão 00, a data da elaboração do documento; (ii) no caso de revalidação, a data em que a análise crítica do documento, que não necessitou de revisão, foi realizada; Resultado da análise crítica: deve conter as opções a serem escolhidas pelo usuário “adequado” ou “alterar”; Prazo para a próxima análise crítica: registrar a data limite (mm/aaaa) que a análise crítica deve ser realizada levando em

31



   

       



consideração a frequência de 1 ano; Responsável pela análise/aprovação a função do responsável pela análise/aprovação: deve conter o nome do responsável pela análise crítica. Após a análise crítica deve-se tomar a decisão se o documento é válido, obsoleto ou cancelado. Para isso, o software deve possuir botão de seleção com as opções “válido” para o caso de não precisar de revisão e ainda estar sendo utilizado e “obsoleto” para aqueles documentos que precisam de revisão e “cancelado” para aqueles documentos que não são mais utilizados; O software deve preencher automaticamente a situação (válido, obsoleto ou cancelado) do documento após esta análise crítica na LM001; Se o usuário marcar a opção “obsoleto” deve-se fazer as alterações necessárias e tornar a revisão anterior obsoleta e armazená-la na pasta “Obsoletos” e também atualizar a situação deste na LM001. Se o usuário marcar a opção “cancelado”, este documento deve ser automaticamente enviado para a pasta “Cancelados”. Se na etapa de análise crítica o usuário informar que o documento é “obsoleto”, o software deve enviar mensagem automática para o pessoal (inclusive a pessoa que está realizando a análise crítica, que pode fazer as alterações no mesmo instante) com autorização para realização de revisão em documentos para que os mesmos façam as revisões/alterações pertinentes. Informar aos responsáveis pela revisão (previstos de acordo com o PSQ 5.2 CT) que existe um documento a ser revisado quando o documento que passou pela análise crítica foi identificado como “obsoleto”; Registrar quem e quando fez a alteração. Abrir um campo “histórico” para que o usuário descreva a alteração. Identificar o documento revisado com o número da revisão. Excluir os obsoletos depois do tempo determinado para tal. Atualizar situação do documento automaticamente na LM001. Informar aos responsáveis para tal função que as cópias físicas dos documentos obsoletos devem ser recolhidas dos locais de uso. As cópias físicas dos documentos internos e externos obsoletos e/ou cancelados do SGLab CT são recolhidas dos locais de uso pelo pessoal do Escritório da Qualidade/Laboratório, e as cópias dos documentos internos e externos obsoletos e/ou cancelados específicos de cada laboratório são recolhidas pelo pessoal do laboratório. Todas as cópias físicas são armazenadas no arquivo morto do SGLab CT (no Escritório da Qualidade) por cinco anos. Documentos internos e externos obsoletos de retenção obrigatória por motivos legais devem ser identificados como não utilizáveis e arquivados no arquivo morto do SGLab CT pelo tempo definido por lei. O software deve finalizar o processo de elaboração de documento, salvando este no banco de dados.

Aprovar e distribuir documento interno O software deve:  Enviar mensagem para o responsável da aprovação para que ele leia o procedimento que foi elaborado/revisado e realize a aprovação das alterações;  Caso sejam necessárias mais modificações, o software deve retornar o documento para que o elaborou com as anotações do revisor que devem ser incluídas ou ajustadas;  Registrar a situação do documento na LM001 depois que o documento for aprovado;  No campo “Aprovado por” no rodapé do documento deve conter o nome do responsável pela aprovação;  Mostrar ao usuário um botão de seleção “aprovar documento” que deve ser selecionado pelo mesmo no momento em que o documento é aprovado.  O software deve disparar a todos usuários (membros do SGLab CT) uma mensagem indicando que existe um documento novo/revisado.  O software deve finalizar o processo de elaboração/revisão e aprovação de documento, salvando este no banco de dados.

32

Monitorar documento externo  Os documentos externos ao SGLab CT (como normas, portarias, documentos da UFSM, entre outros) são identificados de acordo com a designação do organismo emissor.  O software deve solicitar ao usuário que informe os dados dos documentos internos no momento em que se adiciona para que se preencha a LM002:  ‘Identificação’: identificação do documento;  ‘Organismo’: nome do organismo emissor do documento;  ‘Título’: o título do documento;  ‘Data do documento’: data da emissão do documento;  ‘Localização’: onde, no Escritório da Qualidade ou no laboratório, este documento deve ser armazenado;  ‘Data de verificação da atualização’: data em que foi verificada a atualização do documento, levando em consideração a frequência de seis meses;  ‘Situação’: situação do documento externo após a verificação da atualização.  Os documentos externos estão listados na LM 002 CT e os documentos externos, específicos dos laboratórios, estão na lista mestra de documentos externos de cada laboratório;  O software deve solicitar ao responsável pela verificação da atualização dos documentos internos semestralmente que deve realizar esta tarefa;  Quando o usuário informar que o documento externo foi tornado obsoleto/cancelado, deve atualizar a sua situação na LM002;  O software deve informar aos responsáveis pelo recolhimento que as cópias físicas dos externos obsoletos e/ou cancelados do SGLab CT devem ser recolhidas dos locais de uso e que as cópias físicas devem ser armazenadas no arquivo morto do SGLab CT (no Escritório da Qualidade) por cinco anos;

33

APÊNDICE D Documentação de requisitos – Prestação de serviço Descrição Este documento tem por objetivo listar os requisitos funcionais e os requisitos não funcionais relacionados à rotina de prestação de serviço visa estabelecer os métodos e as diretrizes para: cadastro do cliente, solicitação do serviço, análise crítica da solicitação do serviço, envio da proposta, contrato, realização do serviço e envio dos resultados dos laboratórios que fazem parte do Sistema de Gestão de Laboratórios do CT (SGLab CT). Requisitos não funcionais  Deve ser possível colocar nos documentos (MQ, PSQ, POP, IT) tabelas, figuras, fotos;  Estar disponível para uso na web por computador, tablet e celular. Requisitos funcionais  O software deve atribuir as permissões de acesso para cada tarefa: 1) Cadastrar clientes: Gerente Administrativo, Analista da Qualidade, Auxiliar Administrativo; 2) Gerar solicitação de serviço: Gerente Técnico, Gerente Administrativo, Analista da Qualidade e Metrologista; 3) Realizar análise crítica do pedido, informar cliente e elaborar/alterar proposta de prestação de serviço: Gerente Técnico; 4) Enviar proposta de prestação de serviço: Gerente Técnico, Gerente Administrativo, Analista da Qualidade, Auxiliar Administrativo, Metrologista, Assistente de Metrologista; 5) Elaborar contrato, realizar serviço e emitir Certificado de calibração/Relatório de ensaio: Gerente Técnico e Metrologista; 6) Enviar certificado de calibração/relatório de ensaio: Analista da Qualidade Auxiliar Administrativo;  Possuir botão de seleção na tela inicial com título “Prestação de serviço”;  Permitir a utilização de Formulário de solicitação de serviço específicos e diferentes para cada tipo de serviço, com as especificações necessárias e definidas por cada laboratório;  Possuir interface e ferramenta de controle de indicador de “Total de ensaios/calibrações realizadas”;  Permitir a utilização de formulário de coleta de dados específico para cada serviço (isso deve ser previamente definido no momento de elaboração dos procedimentos de ensaio e calibração);  Possuir ferramenta para controle de aquisição de serviços e suprimentos para a realização dos serviços oferecidos pelo SGLab CT;  Possuir ferramenta de busca rápida.

Cadastro de cliente O software deve possuir ferramenta de cadastro de cliente de modo que:  Os novos clientes devem ser cadastrados por meio do preenchimento dos campos do FOR 4.4 001 CT (que irá gerar o registro REG 4.4 001 CT). O software deve solicitar ao usuário os seguintes dados: código do cliente; data do cadastro; laboratório; CPF/CNPJ; nome do cliente; endereço; email; telefone; responsável pelo contato (registrar o nome do responsável pelo contato na empresa cliente e responsável pelo contato no laboratório/EQ). A lógica a ser utilizada para o código do cliente deve ser gerada automaticamente pelo sistema a partir da seleção do usuário do tipo de cliente que está sendo cadastrado. A lógica utilizada para o código do cliente é como segue e a numeração é em ordem crescente do cadastro (10.000.000 a 19.999.999: empresas em geral; 20.000.000 a 29.999.999: outras Instituições de Ensino Superior; 30.000.000 a 39.999.999: laboratórios da UFSM; 40.000.000 a 49.999.999: alunos da UFSM).

34

Solicitação de orçamento O software deve:  Permitir que o cliente solicite orçamento para realização dos serviços do SGLab CT pelo site, por e-mail, por telefone ou pessoalmente no EQ. As informações necessárias para a elaboração do orçamento são específicas para cada laboratório do SGLab CT, por isso deve ser possível modificar os campos do formulário de solicitação de serviço para cada tipo de serviço pelos usuários autorizados para isso. O formulário deve ter as informações mínimas necessárias para a realização da análise crítica do pedido, prazo que deseja receber os resultados, se deseja contrato formal, se o cliente deseja receber os resultados também por e-mail e a forma de devolução dos itens de ensaio/calibração, quando necessário. O formulário deve poder ser preenchido pelo cliente e enviado por e-mail ao [email protected] ou pela pessoa que recebe o contato;  Permitir que o usuário preencha os campos 1 “Identificação do serviço” e 2 “Dados técnicos do serviço” do FOR 4.4 002 CT, a partir dos dados fornecidos pelo cliente. Lembrando que os dados técnicos devem ser transcritos do formulário disponibilizado no site com as informações fornecidas pelo cliente para o FOR 4.4 002 CT;  Gerar o código da solicitação de serviço: aaaammddhhmm seguido do nome do cliente e salvar o arquivo do formulário na pasta “REG 4.4 002 LAB - Análise crítica de pedidos” com o nome “aaaammddhhmm - Nome do cliente”. Este código identifica o item enquanto estiver no SGLab CT e deve ser enviado por e-mail ao Gerente Técnico do laboratório que o mesmo realize a análise crítica. Análise crítica O software deve solicitar que o gerente técnico realize a análise crítica do pedido no campo 3. “Análise Crítica” do FOR 4.4 002 CT. Para isso, o software deve perguntar ao usuário: “Os prazos solicitados podem ser atendidos? ”; “O laboratório possui os recursos físicos, de pessoal e de informação necessários para a realização do serviço solicitado?”; “O laboratório possui pessoal com habilidades e especializações necessárias?”;”O laboratório possui os padrões e métodos definidos para a realização do serviço solicitado?”; “O método de ensaio/calibração é adequado para uso pretendido dos resultados pelo cliente?”. Todas essas questões são objetivas e devem ser respondidas com “Sim” ou “Não”. Não será possível a realização do serviço em casos em que exista pelo menos um “Não” como resposta. Quando isso acontecer, o responsável pela análise crítica deve preencher o campo 4. “Justificativa para a não realização do serviço”. O cliente deve ser informado, preferencialmente pelo EQ, do motivo da impossibilidade da prestação deste serviço. O código deste contato e sua localização devem ser informados no campo 5. “Contato com o cliente”. Elaboração da proposta para prestação de serviço O software deve:  Permitir a elaboração da proposta para prestação de serviço apenas nos casos em que todas as questões tenham sido respondidas de forma positiva na análise crítica;  Solicitar que o usuário elabore a proposta para prestação do serviço no FOR 4.4 003 CT. A proposta contém, além do nome e assinatura do Gerente Técnico do laboratório, os seguintes campos: Campo 1 - Informações gerais: nome do laboratório que realizará o serviço; código do cliente; nome do cliente; CPF/CNPJ do cliente; código da solicitação de serviço; data da proposta; Campo 2 - Descrição do serviço: descrever o serviço conforme previsto no escopo do laboratório; Campo 3 - Preço: informar o preço do serviço solicitado; Campo 4 - Prazo: informar prazo para envio do relatório de ensaio/certificado de calibração; Campo 5 - Métodos utilizados: descrever os procedimentos internos e/ou as normas utilizadas para realização do serviço; Campo 6 - Condições de pagamento: cada laboratório define as condições de pagamento e registra neste campo para que o cliente tenha conhecimento; Campo 7 - Condições gerais: cada laboratório define as condições gerais para a realização do serviço como, por exemplo, validade da proposta, confirmação da realização do serviço, dentre outros;  Enviar mensagem ao GT para que assine a proposta;  Após a assinatura do GT, enviar a proposta ao cliente por e-mail ao cliente para análise e ajustes, caso necessário. Todo ajuste na proposta de prestação de serviço deve ser registrado conforme

35

definido no PSQ 4.7/4.8 CT e seu código e sua localização devem ser informados no FOR 4.4 002 CT, campo 5. “Contato com o cliente”. Contrato O software deve:  Solicitar que o usuário (do EQ ou do laboratório) gere o contrato por meio do documento externo “Contrato FATEC”, quando um contrato formal é solicitado (Lembrar ao usuário que o contrato deve ser assinado pelo GT do laboratório e enviado para a FATEC que encaminha ao cliente. O recebimento na FATEC do contrato assinado pelo cliente é a condição para a realização do serviço. Uma cópia do contrato assinado pelo cliente deve ser armazenada pelo laboratório. O contrato é utilizado quando o laboratório desejar ou para um cliente que fará serviços com o laboratório frequentemente. Quando for um serviço único pode-se utilizar a “Solicitação de faturamento” disponível no site da FATEC.);  Permitir modificações no contrato nos casos em que seja necessário modificar o contrato depois do serviço ter sido iniciado. Solicitar que o usuário repita o processo de análise crítica do pedido deve ser repetido e qualquer emenda deve ser comunicada ao pessoal envolvido. Realizar serviço e elaboração de relatório de serviço O software deve:  Permitir acesso aos procedimentos de ensaio/calibração ao usuário em sua interface, para que o mesmo realize o serviço (ensaio/calibração) acompanhando à rotina de execução do mesmo. Os campos mínimos necessários a serem preenchidos nos procedimentos de ensaio e/ou calibração estão definidos na documentação dos requisitos da rotina de Gestão de documentos;  Permitir o registro dos dados originais (que serão utilizados no relatório de serviço a ser entregue ao cliente) em formulários previamente elaborados pelo usuário para o serviço (é possível que cada serviço possua um formulário de coleta de dados específico);  Permitir o preenchimento dos dados solicitados no relatório de serviço (FOR 5.10 001 CT Relatório de ensaio e FOR 5.10 002 CT Certificado de calibração). O código do relatório de serviço é o mesmo código gerado na solicitação do serviço que acompanha o item enquanto está nas dependências do SGLab CT Os dados a serem solicitados ao usuário sobre o ensaio no FOR 5.10 001 CT são: 1. Dados do solicitante (cliente e endereço); 2. Dados do item de ensaio (descrição, quantidade, condição, identificação, outras informações, data entrada, número da solicitação do serviço); 3. Condições ambientais (temperatura e umidade relativa); 4. Equipamentos de medição utilizados (identificação, descrição e rastreabilidade); 5. Método de ensaio; 6. Resultados e Informações adicionais. Os dados a serem solicitados ao usuário sobre a calibração no FOR 5.10 002 CT são: 1. Dados do solicitante (cliente e endereço); 2. Dados do instrumento a ser calibrado (Descrição, data de entrada, código da solicitação do serviço, fabricante, número de série, modelo, identificação, faixa de indicação, faixa de calibração e resolução); 3. Condições ambientais (temperatura e umidade relativa); 4. Padrões utilizados (identificação, descrição, rastreabilidade e validade); 5. Método de calibração; 6. Incerteza de medição; 7. Resultados e 8. Informações adicionais;  Possuir ferramentas estatísticas para monitorar os resultados dos ensaios e calibrações realizados pelos laboratórios do SGLab CT;  Ferramenta para avaliação de fornecedores. Divulgação dos resultados do serviço, pagamento e nota fiscal O software deve:  Gerar registro do relatório de serviço (relatório de ensaio e/ou certificado de calibração);  Permitir a divulgação dos resultados após a confirmação do pagamento;  Armazenar e enviar o relatório de serviço ao cliente por e-mail (caso tenha sido solicitado) ou apenas armazenar registro e solicitar que usuário envie o mesmo por correio ao cliente.  Controle de faturamento dos serviços prestados.

36

Devolver item  O software deve enviar mensagem para o usuário em casos em que o item deve ser devolvido. Essa informação é fornecida ao software pelo usuário no início do processo de solicitação de serviço. Nesse momento deve ser informada a forma de devolução do item, caso este precise ser devolvido ao cliente. Monitorar indicador “número de ensaios/calibrações realizados”  O software deve manter o armazenamento do indicador “número de ensaios/calibrações realizados” a partir do número de relatórios de ensaio e certificados de calibração emitidos. Como meta para esse indicador deseja-se uma tendência de aumento anual e a periodicidade da análise desse indicador é mensal. No final de cada mês o responsável de cada laboratório por esse indicador deve registrar esse indicador. A contagem deve ser realizada diretamente na pasta de registro dos relatórios de ensaios emitidos (REG 5.10 001 LAB) e/ou na pasta de registro dos certificados de calibração emitidos (REG 5.10 002 LAB).  O resultado mensal desse indicador é a soma dos ensaios e/ou calibrações realizadas por escopo do laboratório e é registrado na aba “A2 N. ensaios-cal. Realizados” do FOR 4.2.2 001 CT.

37