1

Uma Ferramenta para Garantia da Qualidade Aplicada na Implementação de Sistemas

Aline Biondo

Orientador: Roberto Petry

Universidade Luterana do Brasil (ULBRA) – Curso de Sistemas de Informação alinebiondo@gmail.com

Resumo. O presente artigo descreve o desenvolvimento de uma técnica para implementação da garantia da qualidade no desenvolvimento de sistemas. Para tal, foi realizado um estudo das normas e modelos ISO/IEC 12207, Capability Maturity Model Integration (CMMi), Melhoria de Processo do Software Brasileiro (MPS.BR) e da metodologia Project Management Body of Knowledge (PMBOK) com enfoque na garantia da qualidade. Baseado nessa análise, foi desenvolvido um protótipo para a realização de auditorias de processos com o objetivo de apoiar o andamento das atividades a serem realizadas durante a implementação de projetos, indicando suas conformidades e não-conformidades, sendo esse, aplicado em uma empresa de desenvolvimento de software.

1 Introdução

Atualmente devido a grande quantidade de organizações desenvolvedoras de software, as empresas estão constantemente em busca de mais agilidade na entrega dos produtos e de uma maior qualidade nos mesmos, visto que, com a redução de erros (tanto de defeitos no software quanto de especificações mal realizadas) tem-se como conseqüência a redução de custos devido a diminuição do retrabalho e, também, a satisfação do cliente com o produto que foi adquirido.

Paralelo à competitividade nesse desafio de se manter com uma boa posição no mercado, existe também, o aumento da complexidade dos produtos, buscando o desenvolvimento de sistemas que facilitem e aprimorem cada vez mais as atividades desenvolvidas pelos humanos, tornando-se indispensável a implementação de processos de qualidade para garantir que os produtos sejam desenvolvidos conforme as expectativas dos usuários.

Para tal implementação, podem ser citadas como exemplos as normas e modelos ISO/IEC 12207, ISO/IEC 15504, Capability Maturity Model Integration (CMMI), Melhoria de Processo do Software Brasileiro (MPS.BR) e Project Management Body of Knowledge (PMBOK), que auxiliam no desenvolvimento de processos eficazes.

Sabendo-se do elevado índice de competitividade, do avanço das tecnologias existentes e da necessidade de se desenvolver produtos que atendam às necessidades dos clientes, foi definido e desenvolvido um modelo para garantia da qualidade de

2

processos. Pois apesar de atualmente existirem diversas normas e modelos que mostrem “o que” deve ser realizado para que sejam definidos processos de qualidade, o trabalho de “como” realizar é uma atividade adicional, o qual compete a cada organização definir como desenvolver e manter o software, de forma que os requisitos das normas e modelos existentes sejam atendidos com eficácia.

Dentro desse contexto é que se insere a importância deste trabalho, que além da análise das normas e padrões existentes, propõe um modelo para os processos de garantia da qualidade, visando avaliar periodicamente a aderência das atividades efetuadas na implementação de sistemas, no que diz respeito a processos, e requisitos estabelecidos. Desta forma se terá uma visão mais clara e objetiva em relação aos aspectos de melhoria com o intuito de visualizar a efetiva aplicação dos critérios de qualidade propostos pelo projeto.

Entre as ferramentas e técnicas empregadas para garantia da qualidade são incluídas as auditorias. Essas são realizadas por auditores que não estejam envolvidos com o projeto a ser avaliado e pela utilização de um conjunto de verificações pré-estabelecidas a serem empregadas, como por exemplo, um checklist.

Com o objetivo de desenvolver uma técnica eficaz, na qual fossem avaliadas de fato as não-conformidades das atividades realizadas na implementação de sistemas, foi criado um protótipo com a utilização do banco de dados My Structure Query Language (MySQL) e técnicas de programação em Hypertext Processor (PHP). Desta maneira foi possível a automatização do checklist para garantia da qualidade, o qual foi aplicado em uma empresa que desenvolve softwares na área médica.

Este trabalho está estruturado em 8 seções, que são: Seção 2: apresenta a fundamentação teórica para fornecer uma visão geral sobre as normas e modelos baseados na melhoria dos processos. Seção 3: mostra um quadro comparativo entre as normas e modelos estudados. Seção 4: é descrito o estudo de caso. Seção 5: é apresentado o desenvolvimento e escopo do modelo de checklist para garantia da qualidade, juntamente com as tecnologias utilizadas para a criação do mesmo. Seção 6: são descritas as validações e testes aplicados, para assegurar que o modelo desenvolvido foi realizado conforme o objetivo estipulado. Seção 7: são definidas as conclusões e são sugeridas possíveis alterações para trabalhos futuros. Por fim, na seção 8 são listadas as referências bibliográficas.

2 Fundamentação Teórica

Neste tópico será apresentada uma pesquisa bibliográfica referente a normas e modelos que auxiliam na melhoria da qualidade dos processos, com o intuito de fornecer uma visão geral sobre o desenvolvimento de processos de software eficazes que, conseqüentemente, resultam em produtos de qualidade, para uma melhor compreensão dos mesmos.

2.1 Melhoria de Processos de Software

Por meados da década de 70 a engenharia de software surgiu com o intuito de produzir software de qualidade e de forma econômica. Já na década de 90 a preocupação voltou-

3

se para a modelagem e melhorias no processo de software, pois detectou-se que a qualidade final do produto de software é resultado de processos bem definidos e aplicados durante o desenvolvimento de um projeto.

Com o intuito de aperfeiçoar o desenvolvimento de software e obter produtos com os níveis desejáveis de qualidade, a última década assistiu a uma mudança de enfoque com relação ao processo de software. Tem-se então uma nova abordagem na qual o enfoque principal das atenções está na garantia da qualidade do próprio processo produtivo, visto que este tem se mostrado o fator determinante para o alcance da qualidade do produto final. (ROCHA, 2001 p.101).

Para que os processos sejam estruturados, planejados e realizados de maneira eficaz foram criadas as normas e modelos ISO/IEC 12207, ISO/IEC 15504, Capability Maturity Model Integration (CMMI), Melhoria de Processo do Software Brasileiro (MPS.BR) e metodologias, como por exemplo, Project Management Body of Knowledge (PMBOK), as quais serão melhor especificadas nas subseções seguintes.

2.1.1 ISO/IEC 12207

A Norma ISO/IEC 12207 foi desenvolvida pela ISO (the International Organization for Standardization) e pelo IEC (International Electrotechnical Commission) e sua publicação como norma Internacional foi realizada em 1995. Em 1997 foi publicada como norma Nacional NBR ISO/IEC (ABNT, 1997).

Esta norma descreve o conjunto dos processos de ciclo de vida de software, estabelecendo atividades e tarefas a serem executadas durante os processos de aquisição, fornecimento, operação, desenvolvimento e manutenção de software.

Figura 1: Estrutura da Norma

Fonte: (ABNT, 1997)

4

A NBR 12207 está estruturada conforme Figura 1 visualizada anteriormente e seus processos baseiam-se em:

• Processos Fundamentais: composto por cinco processos que atendem as partes fundamentais (pessoa ou organização) durante o ciclo de vida de software.

• Processos de Apoio: cada um dos processos de apoio auxilia a um outro processo como uma parte integrante. Tal processo é empregado e efetuado, quando indispensável, por outro processo. Os processos de apoio contribuem para o sucesso e qualidade do projeto de software e se dividem em oito processos.

• Processos Organizacionais: formados por quatro processos de ciclo de vida e pessoal associados. Estes processos são utilizados para melhorar continuamente a estrutura e os processos.

2.2 ISO/IEC 15504

Em 1993 foi lançado o projeto SPICE (Software Process Improvement and Capability dEtermination), “com o objetivo de produzir, inicialmente, um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001” (ROCHA, 2001 p.29) elaborado pela futura norma ISO/IEC 15504 criada em 1998.

O projeto SPICE foi baseado em projetos já existentes, como por exemplo: CMM/SEI, STD/Compita, Trillium/Bell, SQPA/HP, ISO 9001, visando a melhoria contínua dos processos e a determinação da capacidade de processos de uma organização.

No modelo SPICE existem seis níveis de capacidade, os quais são descritos a seguir:

• 0 – Incompleto: existe falha no propósito do processo ou o mesmo não é efetuado.

• 1 – Executado: normalmente o propósito do processo é realizado. A realização talvez não seja planejada e acompanhada de forma rigorosa.

• 2 – Gerenciado: a realização é planejada e acompanhada de maneira eficaz e o processo gera produtos conforme procedimentos especificados.

• 3 – Estabelecido: o processo é definido e gerenciado com base nos melhores princípios da engenharia de software.

• 4 – Previsível: o processo definido é realizado de forma consistente, conforme controles definidos para atingir as metas estipuladas.

• 5 – Em Otimização: processos em melhoria contínua.

2.3 Capability Maturity Model Integration (CMMI)

O CMMI foi criado em 2002 pelo SEI (Software Engineering Institute) – centro de pesquisa e desenvolvimento – evolução do SW-CMM (Software Capability Maturity

5

Model), que foi originado do projeto com o Departamento de Defesa dos Estados Unidos DoD (Department of Defense) para integração de todos CMMs.

Segundo SAMARANI (2005), o CMMI é constituído pelas melhores práticas que abrangem o desenvolvimento e manutenção de produtos/serviços, englobando o ciclo de vida do produto desde a sua iniciação até a entrega e manutenção. Esse modelo pode ser representado por dois tipos de representação:

• Representação contínua: possibilita que uma organização melhore os processos correspondentes a uma área de processo específica selecionada pela organização, nesse tipo de representação é utilizado o termo de nível de capacidade. Existem seis níveis de capacidade: 0 (Incompleto), 1 (Executado), 2 (Gerenciado), 3 (Definido), 4 (Quantitativamente gerenciado) e 5 (Em otimização). Cada um desses níveis consiste em uma meta genérica e em um conjunto de práticas específicas e genéricas.

• Representação por estágio: permite que uma organização melhore um conjunto de áreas de processos. Na representação por estágio, utiliza-se o termo nível de maturidade, são no total cinco níveis: 1 (Inicial), 2 (Gerenciado), 3 (Definido) 4 (Quantitativamente gerenciado) e 5 (Em otimização). Cada nível de maturidade serve como base para que seja realizado o próximo nível, ou seja, para que uma organização implemente o nível de maturidade 3, por exemplo, é essencial que o nível 2 já esteja concluído.

2.4 Melhoria de Processo do Software Brasileiro (MPS.BR)

Em dezembro de 2003 iniciou-se a criação do modelo MPS.BR que encontra-se em continua evolução pela Sociedade para Promoção da Excelência do Software Brasileiro (SOFTEX), e conta com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e pelo Banco Interamericano de Desenvolvimento (BID), tendo como base os padrões NBR ISO/IEC 12207 emendas 1 e 2 da norma internacional ISO/IEC 12207, ISO/IEC 15504 (SPICE) e o CMMI-SE/SW (Capability Maturity Model Integration for Systems Engineering/Software Engineering).

O objetivo principal do MPS.BR é a melhoria dos processos de software em micro, pequenas e médias empresas com um custo acessível, tornando-se uma alternativa de qualificação com maior viabilidade financeira para as empresas brasileiras.

Conforme o guia geral do modelo (SOFTEX, 2006a, 2006b), o MPS.BR está dividido em três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Os componentes são descritos por meio de Guias e/ou de Documentos do MPS.BR.

• MR-MPS: composto pelo Guia Geral o qual contém sete níveis de maturidade (A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado), iniciando pelo nível G e progredindo até o nível mais alto A), processos e atributos do processo, e pelo Guia de Aquisição, o qual

6

é composto por práticas adequadas para a aquisição de software e serviços correspondentes.

• MA-MPS: composto pelo Guia de Avaliação o qual contém os requisitos para os avaliadores e Instituições Avaliadoras.

• MN-MPS: composto por Documentos do Programa, o qual apresenta as regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras.

2.5 Project Management Body of Knowledge (PMBOK)

O PMBOK é um guia de boas práticas relacionadas à gerência de projetos organizados pelo Comitê de Padronização do Project Managemente Institute (PMI).

Antes de explanar sobre gerenciamento de projetos é interessante definir o que é um projeto e o gerenciamento do mesmo. “Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo” e “um gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos” (PROJECT MANAGEMENT INSTITUTE, 2004). O gerenciamento de projetos é efetuado através do emprego e da integração dos seguintes processos: iniciação, planejamento, execução, monitoramento e controle, e encerramento.

Nele são abordados trinta e nove processos distribuídos em nove áreas de conhecimentos, as quais são listadas a seguir: Gerência da Integração, Gerência de Escopo, Gerência de Tempo, Gerência de Custos, Gerência da Qualidade, Gerência de Recursos Humanos, Gerência das Comunicações, Gerência de Riscos e Gerência das Aquisições. Entretanto será descrita apenas a Gerência da Qualidade que aborda informações significativas para este trabalho.

De acordo com o PMBOK 2004 (PROJECT MANAGEMENT INSTITUTE, 2004), a Gerência da Qualidade inclui três processos, descritos abaixo, que garantem que o projeto irá atender satisfatoriamente às necessidades para as quais ele foi empreendido:

• Planejamento da qualidade: identificação e determinação de como satisfazer os padrões de qualidade importantes para o projeto. Tal planejamento é realizado pela equipe do projeto ou pelo gerente.

• Garantia da qualidade: avaliação e aplicação das atividades de qualidade planejadas para garantir que o projeto atinja todos os requisitos de qualidade estipulados, a qual deve ser realizada no decorrer do projeto. A garantia da qualidade pode ser realizada interna ou externamente ao projeto e normalmente é aplicada por auditores internos à organização, que não estejam envolvidos no desenvolvimento do projeto em questão, ou por auditores externos.

• Controle da qualidade: monitoramento de resultados específicos do projeto realizado com o objetivo de determinar se os mesmos estão conforme os padrões de qualidade estipulados e identificar maneiras de suprimir os motivos de um resultado insatisfatório. O controle da qualidade assim como a garantia, deve ser realizado no decorrer do projeto.

7

Para uma melhor compreensão, a Figura 2, exibida abaixo, apresenta uma visão geral dos processos envolvidos no gerenciamento da qualidade.

Figura 2: Fluxograma de processo do gerenciamento d a qualidade do projeto

Fonte: Adaptado de ( PROJECT MANAGEMENT INSTITUTE, 2004)

3 Estudo Comparativo entre as Normas e Modelos

Este tópico mostra o mapeamento comparativo dos processos de gerência da qualidade dos seguintes modelos e normas: PMBOK, CMMI, MPS.BR e ISO/IEC 12207.

Para as normas e modelos citados, a garantia da qualidade visa documentar e identificar as não-conformidades de acordo com a qualidade planejada para o projeto. Para tal identificação, uma das técnicas utilizadas é a auditoria de qualidade.

8

As auditorias são realizadas por auditores que não estejam atuando na elaboração e no desenvolvimento do projeto que será avaliado. Essas podem ser previamente agendadas ou aleatórias e devem utilizar uma série de itens de verificação já definidos a serem avaliados, como por exemplo, um checklist para que a avaliação seja realizada de forma objetiva, com o intuito de minimizar a subjetividade e a influência da pessoa que está realizando a auditoria.

As auditorias devem ser realizadas ao longo do projeto. As não-conformidades detectadas devem ser registradas e o andamento de sua resolução deve ser acompanhado. Assim, a cada não-conformidade avaliada, deve-se informar a pessoa responsável por resolvê-la, o prazo para resolução e, também, o tipo de não-conformidade e demais informações que podem vir a auxiliar na gestão do processo da garantia da qualidade.

A seguir é ilustrado no Quadro 1 o mapeamento comparativo no que diz respeito ao gerenciamento da qualidade das normas e modelos apresentados.

Quadro 1: Mapeamento comparativo do PMBOK, CMMI, MP S.BR e ISO/IEC 12207

PMBOK CMMI MPS.BR ISO/IEC 12207

8.1 Planejamento da Qualidade.

6.3.1 Implementação do processo.

8.2 Realizar Garantia da Qualidade.

6.3.2 Garantia do produto.6.3.3 Garantia do processo.

8.3 Realizar Controle da Qualidade.

6.3.4 Sistemas de garantia da qualidade.

Nível F - Gerenciado (Processo: Garantia da

Qualidade - GQA)

Mapeamento - Gerência da Qualidade do Projeto

Nível 2 - Gerenciado (Área de processo: Garantia da qualidade do Processo e

do Produto)

Com base na análise das normas e modelos apresentados acima foi proposto um modelo para garantia da qualidade o qual será especificado nos tópicos seguintes.

4 Estudo de Caso

A realização deste trabalho envolve o desenvolvimento e a aplicação de um modelo para garantia da qualidade com base na metodologia PMBOK, sendo também, complementado com as abordagens que já foram mencionadas no tópico da fundamentação teórica.

Para que tal implementação fosse avaliada de maneira coerente e eficaz, a aplicação do modelo criado foi realizada em uma empresa de desenvolvimento de software, a qual desenvolve, comercializa e efetua suporte em programas específicos para a área médica há 16 anos.

Para não expor a empresa analisada no estudo de caso, optou-se por dar-lhe o nome de XYZ.

9

Atualmente a empresa XYZ desenvolve produtos para quatro tipos de segmentos: consultórios e clínicas médicas, empresas de médio e grande porte, hospitais, prefeituras e secretarias de saúde.

Com o intuito de qualificar, padronizar e futuramente certificar os processos de implementação dos sistemas da XYZ, foi desenvolvida a metodologia de implementação XYZ através de consultorias com profissionais certificados na gerência de projetos Project Management Professional (PMP®). Assim, foi iniciado todo o mapeamento e documentação dos processos realizados para a entrega dos produtos ao cliente, desde o início onde é estabelecido o acordo do escopo do projeto, até o final, onde dá-se a entrega, e conseqüentemente, o aceite do projeto pelo cliente.

Os consultores realizaram diversas entrevistas com os funcionários de cada uma das unidades de negócios da empresa, objetivando descrever exatamente todos os processos realizados durante todas as etapas dos projetos. O primeiro processo a ser mapeado foi do segmento de consultórios e clínicas médicas, após hospitais, prefeituras, secretarias de saúde e, por fim, empresas de médio e grande porte respectivamente.

Para implementação do sistema desenvolvido pela empresa XYZ, foi definida a seguinte estrutura:

Os projetos possuem duas fases, das quais cada uma tem quatro etapas, sendo estas nomeadas como: iniciação, planejamento, execução e encerramento. E cada uma das etapas possui seus processos relacionados, conforme pode ser visualizado na Figura 3 ilustrada abaixo.

Como a empresa desenvolve sistemas que atendem desde pequenas clínicas até grandes hospitais, o mapeamento e a documentação dos processos foram realizados para cada uma das unidades de negócios da empresa, mas seguindo sempre uma mesma estrutura.

Além de toda a análise e mapeamento dos processos realizados foram definidos, também, os papéis dos principais responsáveis pelo projeto. Os quais podem ser verificados a seguir:

Analista de Desenvolvimento : responsável pelo desenvolvimento do produto.

Gerente de Contas: representante comercial do projeto. Caso o cliente realize novas solicitações durante o andamento do projeto, as quais não estavam estipuladas no contrato, o gerente de contas deve ser acionado para nova avaliação de valores, e caso, necessário, deverá enviar uma nova proposta comercial.

Gerente do Projeto: responsável por um ou mais projetos, representante da empresa ao cliente.

Analista de Qualidade: responsável pela qualidade dos processos e produtos desenvolvidos pela empresa, para que o produto final seja entregue conforme o escopo aprovado.

Gerente Sênior: autoridade máxima de responsabilidade sobre os projetos da empresa, normalmente esse papel é desempenhado por um dos sócios-diretores da empresa.

10

Figura 3: Estrutura para implementação do sistema X YZ

Baseado na estrutura dos processos e definições dos papéis dos responsáveis pelos projetos explanada acima, foi realizado o modelo de checklist para a garantia da qualidade de processos na implementação de sistemas da empresa XYZ.

5 Desenvolvimento do Modelo para Garantia da Qualidade

Com a documentação dos processos realizada, detectou-se a necessidade de um acompanhamento para verificação da conformidade ou não-conformidade da aplicação dos mesmos, daí surgiu a idéia do desenvolvimento de uma técnica para implementação da garantia da qualidade.

Segundo Dinsmore e Cavalieri (2003), a auditoria pode ser classificada em três tipos:

• Auditoria de Sistema: são avaliações aplicadas para verificar se o sistema e a política da qualidade estão sendo efetuadas conforme o que foi estabelecido.

• Auditoria de Processo: são avaliações realizadas a um processo específico, sendo analisado, também, todos os elementos relacionados ao processo em questão,

11

com o intuito de analisar se as especificações do processo estão conforme ao que foi estipulado.

• Auditoria de Produto: são avaliações efetuadas em um produto específico, sendo examinados, também, os elementos relacionados aos produtos, para verificar se as especificações estão de acordo com os padrões estipulados ao produto.

O modelo de checklist desenvolvido corresponde a auditoria de processo. Esse possibilita registrar as conformidades e não-conformidades dos processos que devem ser realizados. Permite, também, um maior controle do andamento do projeto, para que o mesmo seja desenvolvido conforme o padrão de qualidade planejado.

Abaixo, pode ser observado na Figura 4 o modelo de checklist proposto, que foi primeiramente estruturado em Excel para o posterior desenvolvimento do protótipo.

Figura 4: Modelo do checklist para garantia da qualidade

Para o desenvolvimento do modelo foi definido o seguinte escopo:

• Recursos Humanos / Usuários: tem como objetivo registrar os responsáveis pelo projeto, ou até mesmo, um simples usuário do protótipo que poderá apenas visualizar as informações contidas na aplicação.

• Configurações Gerais da Auditoria: possibilita a realização dos cadastros de Fases, Etapas e Itens de Verificação.

• Projeto: permite armazenar os projetos em andamento na empresa e suas respectivas auditorias, além de fornecer um relatório com a quantidade dos itens de verificação que não se aplicam, das conformidades, das não-conformidades e das reincidências referentes as auditorias realizadas nos projetos.

12

Os Casos de Uso representam a interação dos atores (entidade externa ao sistema, como por exemplo: um usuário, um fornecedor ou receptor de informações) com o sistema.

O diagrama de Caso de Uso que mostra o cenário geral do protótipo pode ser visualizado na Figura 5 a seguir:

Figura 5: Diagrama de Caso de Uso

Os acessos dos usuários serão definidos dinamicamente na aplicação através do gerenciamento de permissões.

5.1 Tecnologias Utilizadas

O protótipo do projeto de auditoria de processos foi implementado de forma a atender às necessidades dos funcionários que atuam na área de qualidade da empresa XYZ, da melhor maneira possível, disponibilizando uma interface simples e de fácil compreensão, apresentando, apenas, as informações relevantes à auditoria.

Para a realização do protótipo do modelo para garantia da qualidade, foi utilizada a linguagem de desenvolvimento de aplicação Web PHP, que permite a criação de sites dinâmicos. O código PHP é executado no servidor, sendo enviado para o cliente apenas o HiperText Mark-up Language (HTML), tornando-se possível interagir com aplicações existentes no servidor e com o banco de dados sem a exposição do código fonte. (NIEDERAUER, 2004a).

O HTML será responsável por estruturar e mostrar os dados nas páginas exibidas no navegador. Para apresentação visual do documento será utilizado o Cascading Style Sheet (CSS), que é um mecanismo simples para adicionar estilos relacionados ao layout da página (SILVA, 2007).

13

Foi utilizada a biblioteca Active Data Objects DataBase (ADODB) para abstração do banco de dados, assim a aplicação não fica limitada ao uso de apenas um único Sistema de Gerenciamento de Banco de Dados (SGBD), sendo possível utilizar o MySQL, PostgreSQL, Oracle, entre outros. MySQL foi o banco de dados escolhido para armazenar as informações cadastradas no protótipo.

Com o objetivo de facilitar a manutenção do código da aplicação desenvolvida, optou-se pela utilização da ferramenta de template Smarty, tornando-se possível separar a lógica do programa da lógica de exibição, ou seja, ao invés de ter uma única página PHP com o código da programação e HTML juntas, é possível ter uma página PHP contendo a programação e outra página do template com o layout estipulado. (NIEDERAUER, 2004b).

Na busca de desenvolver um protótipo que posteriormente pudesse ter uma fácil manutenção, foram realizadas diversas pesquisas para estruturar o mesmo de forma coerente. Algumas classes como a class.appPaginacao.php (PHP CLASSES, 2007) utilizada para realizar a paginação e class.appTabela.php (LINHA DE CÓDIGO, 2007) classe genérica para trabalhar com tabelas foram utilizadas e adaptadas para o desenvolvimento do protótipo.

Figura 6: Classe Projetos (com template Smarty)

14

Acima, ilustrada na Figura 6, pode ser verificada uma parte do código PHP na qual consta a classe class.projetos.php, com a função “selecionaUm” que retorna um projeto inserido no protótipo.

Para realizar a modelagem do banco de dados, foi utilizada a ferramenta CA ERwin Data Modeler, mais conhecida como ERWin. A partir dela, foi possível criar as tabelas e o relacionamento entre as mesmas.

Abaixo, pode ser visualizada a Figura 7 com o diagrama entidade relacionamento (DER), desenvolvido para a criação do protótipo.

Figura 7: Diagrama E-R do protótipo

5.2 Implementação do Protótipo

Conforme visto anteriormente e ilustrado na Figura 8, o escopo do protótipo engloba três módulos do sistema, os quais serão detalhados a seguir:

Figura 8: Módulos do protótipo

15

Recursos Humanos / Usuários: Nesse módulo é possível inserir e consultar os responsáveis pelo projeto, ou até mesmo, um simples usuário do sistema que poderá apenas visualizar as informações contidas na aplicação. Pode-se cadastrar os seguintes tipos de usuários ou responsáveis: Administrador(a), Gerente Sênior, Gerente de Contas, Gerente de Projetos, Analista de Desenvolvimento, Auditor(a) e Visitante. A configuração para permissão de acesso é realizada para cada um dos usuários do sistema, permitindo a liberação ou não de “Inclusão”, “Alteração” e “Visualização” de cada um dos módulos do protótipo.

Cada usuário poderá acessar o sistema mediante a informação do seu login e senha previamente cadastrados. Não é realizada a exclusão de usuários na aplicação. Caso o usuário não faça mais parte do grupo de colaboradores da empresa, o mesmo deve ser desativado para que não seja perdido o histórico de projetos que participou.

Configurações Gerais da Auditoria: Nesse módulo são realizados os cadastros apresentados a seguir:

Cadastro de Fases: possibilita incluir, alterar e consultar as fases dos projetos.

Cadastro de Etapas: nesse cadastro são realizadas inclusões, alterações e consultas nas etapas. Uma nova etapa é inserida mediante a informação de qual fase a mesma pertence.

Cadastro de Itens de Verificação: são efetuadas as inclusões, alterações e consultas dos itens de verificação. Para que um novo item de verificação seja registrado, é necessário selecionar a fase e a etapa correspondente ao item de verificação em questão.

Caso uma Fase, Etapa ou Item de Verificação não seja mais utilizado, é possível realizar a desativação do mesmo, alterando o seu status de “Ativo” para “Inativo”.

Apesar das descrições das Fases, Etapas e Itens de Verificação já estarem definidas, o cadastro das mesmas foi realizado de forma dinâmica, visto que, o mapeamento dos processos para implementação do sistema da empresa XYZ foi criado recentemente, podendo haver modificações com o objetivo de que os mesmos melhorem continuamente.

Na Figura 9, abaixo, pode ser observado o formulário desenvolvido para o cadastro de itens de verificação.

Primeiramente seleciona-se a fase e a etapa que foram previamente cadastradas correspondentes ao item a ser inserido. Após é realizado o registro do item de verificação a ser avaliado. A seguir é informada a ordem em que o item de verificação em questão deverá aparecer no checklist, esse já vem inicializado com o próximo valor da ordem a ser informada, e por fim é registrado o status do mesmo, sendo que tal informação já vem inicializada com “1 – Ativo”.

16

Figura 9: Tela de cadastro dos itens de verificação do protótipo

Projeto: Esse módulo engloba a criação dos projetos em andamento na empresa e suas respectivas auditorias. Para cada projeto existe a possibilidade de realizar uma ou mais auditorias de processos, sendo essas organizadas por datas.

O modelo de checklist é gerado automaticamente no protótipo com base nas fases, etapas e itens de verificação previamente cadastrados.

Para cada item de verificação pode-se realizar as seguintes avaliações:

Não se aplica (NA): o item de verificação descrito não se aplica.

Conforme (C): o item de verificação em questão está em conformidade.

Não-conforme (NC): ocorrência de não-conformidade no item de verificação.

Classificação da NC: classificação da gravidade da não-conformidade detectada, essa pode ser avaliada como: baixa, média, alta ou urgente.

Reincidente (R): não-conformidade já avaliada volta a ocorrer.

Causa da NC: descrição do motivo pelo qual a não-conformidade ocorreu.

Ação: descrição da ação a ser realizada para correção da não-conformidade.

Responsável: nome do responsável pela correção da não-conformidade.

Prazo: data limite para solução da não-conformidade.

Com o intuído de facilitar e agilizar o trabalho do auditor da qualidade, foi criado o recurso de impressão do checklist da auditoria realizada, já com as respostas registradas. Para cada fase/etapa são contabilizados os subtotais de itens de verificação que não se aplicam, conformidades, não-conformidades e reincidências.

Para os projetos já finalizados, existe a possibilidade de desativação dos mesmos.

17

Na Figura 10 é apresentado o modelo de checklist estabelecido para que as verificações de conformidades e não-conformidades na implementação dos sistemas pudessem ser efetivadas.

Figura 10: Tela de auditorias do protótipo

Ainda nesse módulo, existe o recurso de geração de relatório com a quantidade dos itens de verificação que não se aplicam, das conformidades, das não-conformidades e das reincidências referentes as auditorias realizadas nos projetos, fornecendo totais por fases e etapas, baseando-se em todas as auditorias realizadas para o mesmo.

Tomando como exemplo o projeto Controle de Ocorrências da empresa XYZ, ilustrado na Figura 11, na auditoria realizada em 22 de outubro de 2007, fase 01 (Preparação e dimensionamento da implantação) e etapa 01 (iniciação), tem-se 1 item de verificação que não se aplica, 18 conformes, 3 não-conformes e 0 reincidentes em um total de 22 itens de verificação avaliados. Já na auditoria do dia 06 de novembro de 2007, consta 1 item de verificação que não se aplica, 20 conformes e 1 não-conforme, sendo esse, reincidente. Na auditoria do dia 06 de novembro, também foram avaliados 22 itens de verificação.

Ao final de cada fase/etapa, é contabilizado o total de itens NA, C, NC e R. Informações essas, podem ser melhor visualizadas na imagem abaixo.

18

Figura 11: Tela do relatório consolidado das audito rias de um projeto

6 Validações e Testes

Para que o modelo de checklist desenvolvido fosse avaliado de acordo com o escopo estabelecido anteriormente, optou-se por aplicá-lo em dois projetos da empresa XYZ.

Primeiramente a aplicação foi disponibilizada em um provedor de hospedagem para que a mesma pudesse ser acessada pelos funcionários da empresa, para então, realizarem a homologação do protótipo.

Em seguida foram cadastrados os usuários do sistema e suas respectivas permissões de acessos aos módulos. Após foram registradas as fases, etapas e itens de verificação dos projetos. E, por fim foram feitas as aplicações das auditorias em dois projetos distintos pela analista de qualidade da empresa.

Ao término das auditorias realizadas, foi repassado um questionário de avaliação do protótipo desenvolvido com o intuito de ponderar os reais benefícios do modelo proposto, no qual constavam as seguintes questões:

1. O modelo para garantia da qualidade proposto foi suficiente para que se possa, com este modelo, avaliar periodicamente o andamento dos projetos?

2. A estrutura do modelo de checklist está adequada às necessidades da empresa?

3. Quais são os benefícios proporcionados pelo protótipo?

4. O relatório consolidado de auditorias auxiliou para avaliação da quantidade de itens conformes e não-conformes nos projetos?

5. Quais as melhorias podem ser realizadas na aplicação?

A partir das respostas desse questionário pôde-se concluir que:

19

Apesar do protótipo permitir que a impressão da auditoria seja realizada, detectou-se a necessidade de gerar um relatório que apresentasse apenas os registros das não-conformidades avaliadas, para que essas pudessem ter um acompanhamento especial. Sendo assim, foi implementado o relatório de não-conformidades da auditoria, e posteriormente, disponibilizou-se a atualização do protótipo para avaliação.

Verificou-se que as funcionalidades esperadas e definidas no escopo do protótipo foram atingidas e a estrutura do modelo proposto estava de acordo com as necessidades. Além disso, foi possível ter um maior controle e acompanhamento sobre as atividades a serem desempenhadas, desde a iniciação até o encerramento do projeto.

Foram também mencionadas algumas sugestões que poderão contribuir para a melhoria da aplicação, tais como: sinalizadores que informem quando uma verificação está com seu prazo de resolução em atraso, exportação das auditorias realizadas para planilhas em Excel e arquivos com extensão .pdf e a geração de relatórios gráficos com o percentual das não-conformidades detectadas.

7 Conclusão

Este artigo apresentou inicialmente a importância de processos bem definidos para que um software seja desenvolvido com qualidade. Para isso, foram descritas as principais características das normas e modelos ISO/IEC 12207, ISO/IEC 15504, CMMI, MPS.BR e PMBOK.

Com enfoque na garantia da qualidade, foram avaliadas as normas e modelos expostos acima para que essas informações fossem contempladas no desenvolvimento de um protótipo. Concluiu-se que para que a garantia da qualidade seja efetiva é necessário avaliar periodicamente o desempenho geral dos projetos, baseando-se em questões pré-definidas, visando a objetividade.

Assim, foi desenvolvido um modelo de checklist com itens de verificação a serem auditados durante o andamento de um projeto.

Com a aplicação do protótipo em uma empresa desenvolvedora de softwares, pôde-se avaliar as funcionalidades, bem como as vantagens do mesmo. O modelo proposto foi desenvolvido conforme a estrutura utilizada na empresa XYZ, sendo separado por fases, etapas e itens de verificação, permitindo que o próprio usuário do sistema realize o registro dessas informações, ou seja, se for necessário incluir ou alterar algum item de verificação, por exemplo, esse pode ser realizado pelo próprio usuário do sistema.

Conforme avaliação dos usuários, o protótipo permitiu o acompanhamento do andamento dos projetos de forma que as não-conformidades encontradas fossem informadas e apontadas com antecedência, através do registro das mesmas e da possibilidade da emissão do relatório dos itens não atendidos.

Foi sugerida a exportação do checklist para planilhas em Excel ou arquivos com extensão .pdf, um alerta dos itens não-conformes com o prazo de término pendente e, também, a possibilidade de gerar relatórios gráficos com o percentual das não-conformidades detectadas nas auditorias realizadas. Essas e outras questões, como o

20

envio de e-mail diretamente aos responsáveis pelas atividades não-conformes, são evoluções a serem exploradas para trabalhos futuros ou em uma nova versão do protótipo.

Desta forma, pode-se dizer que através deste trabalho foi possível compreender a real importância do acompanhamento periódico das atividades a serem realizadas na implementação de sistemas e da aplicação de ao menos uma das normas e modelos ISO/IEC 12207, ISO/IEC 15504, CMMI, MPS.BR e PMBOK para que as organizações desenvolvedoras de softwares desenvolvam programas que atendam as reais necessidades dos usuários.

8 Referências Bibliográficas

ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207:1997. Tecnologia da Informação – Processos de Ciclo de Vida de Software. Rio de Janeiro: ABNT, 1997, 40 p.

DINSMORE, Paul Campbell; CAVALIERI Adriane. Como se Tornar um Profissional em Gerenciamento de Projetos. 1. ed Rio de Janeiro: Qualitymark, 2003, 412 p.

LINHA DE CÓDIGO. Miniframework PHP . Disponível em: <http://www.linhadecodigo.com.br/Artigo.aspx?id=1099>. Acessado em 02 de agosto de 2007.

NIEDERAUER, Juliano. Desenvolvendo Websites com PHP. São Paulo: Novatec, 2004, 269 p.

NIEDERAUER, Juliano. PHP para quem conhece PHP. 2. ed São Paulo: Novatec, 2004, 480 p.

PHP CLASSES. Generic Easy Pagination. Disponível em: <http://www.phpclasses.org/browse/package/1456.html>. Acesso em: 02 de agosto de 2007.

PROJECT MANAGEMENT INSTITUTE. PMBOK 3 rd Edition – A Guide to the Project Management Body of Knowledge, 2004. Disponível em: <http://www.pmi.org>. Acesso em: 05 de maio de 2007.

ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves. Qualidade de software teoria e prática. São Paulo: Pretince Hall, 2001, 303 p.

SAMARANI, Paulo Roberto de Miranda. Um modelo de implementação do Capability Maturity Model Integration nível 2. Dissertação de Mestrado. Porto Alegre, 2005, 135 p.

SILVA, Maurício Sami. CSS para Web Design. Disponível em: <http://www.maujor.com>. Acesso em: 17 de junho de 2007.

SOFTEX. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE

21

BRASILEIRO. MPS.BR – Guia de Implementação – Parte 2: Nível F, versão 1.0, dezembro 2006. Disponível em: <http://www.softex.br>. Acesso em: 7 de abril de 2007.

SOFTEX. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS.BR – Guia Geral, versão 1.1, maio 2006. Disponível em: <http://www.softex.br>. Acesso em: 18 de março 2007.