O termo engenharia de software surgiu pela primeira vez em 1968, após a crise do software (época que se referia às dificuldades em desenvolver programas sem falhas, facilmente compreensíveis e verificáveis) (KOSCIANSKI; SOARES, 2007). Do contexto da garantia de qualidade surgiram padrões como normas e modelos, que definem requisitos e boas práticas para a obtenção de um produto de qualidade com a qualidade do processo de desenvolvimento de software.
PROBLEMA DE PESQUISA
Solução Proposta
A solução proposta neste projeto teve como objetivo desenvolver uma solução computacional para apoiar a garantia de qualidade em processos de desenvolvimento de software no setor empresarial mencionado anteriormente como estudo de caso deste trabalho. Também não fez parte deste trabalho apoiar a garantia de qualidade dos produtos de trabalho gerados durante a execução dos processos de desenvolvimento de software.
Delimitação de Escopo
Ou seja, foi desenvolvida uma interface gráfica para controlar as fases do processo de desenvolvimento de software de acordo com as boas práticas da IEEE 730, ISO 90003, ISO 12207, IEC 15504, CMMI-DEV e MPS.BR.
Justificativa
Sua utilidade é grande, pois serve como uma ferramenta poderosa na auditoria de processos de desenvolvimento de software corporativo ou mesmo no processo de desenvolvimento de TCC. A diferença entre a ferramenta e as demais estudadas durante a implantação deste projeto é que, além do acesso web, ela atende às normas IEEE 730, ISO/IEC 12207, ISO/IEC 15504, ISO 90003 e CMMI-DEV e MPS.BR. modelos.
OBJETIVOS
Objetivo Geral
A motivação para o desenvolvimento desta ferramenta veio da necessidade de uma empresa desenvolver produtos na região de São José. Após estudar as ferramentas utilizadas, ficou claro que era necessário desenvolver uma ferramenta dedicada a esse fim, já que as empresas costumam utilizar ferramentas que não são muito adequadas para este fim, como são TESTLINK, MANTIS e BUGZILLA.
Objetivos Específicos
Desenvolver uma ferramenta de checklist para apoiar a execução de práticas de garantia de qualidade no processo de desenvolvimento de software da empresa alvo deste estudo, com base nos padrões e modelos investigados.
METODOLOGIA
Metodologia da Pesquisa
Procedimentos Metodológicos
PLANO DE TRABALHO
Estudo - Esta fase teve como objetivo definir com precisão o tema/problema deste projeto e obter os conhecimentos necessários para a Garantia da Qualidade em Processos de Software. Na seguinte sequência: (1) Desenvolver casos de teste, (2) Desenvolver diagramas de sequência do sistema, (3) Desenvolver o aplicativo e (4) Implementar o aplicativo.
ESTRUTURA DO TRABALHO
A Fase 1 e a primeira fase da Fase 2 foram realizadas no TCC I, no período definido entre abril/2012 e junho/2012. Documentação – Esta etapa teve como objetivo registrar todo o processo de pesquisa em documentação completa no TCC II (Atividade 5.1).
GARANTIA DA QUALIDADE
- IEEE 730
- ISO 90003
- ISO/IEC 12207
- ISO/IEC 15504
- CMMI-DEV
- MPS.BR
Ferramentas, técnicas e metodologias – devem definir as ferramentas, técnicas e métodos utilizados para apoiar a garantia da qualidade de software; A função da garantia de qualidade é garantir que os processos e produtos de software atendam aos requisitos e planos estabelecidos (MACIEL; VALS; SAVOINE, 2011).
ANÁLISE CRÍTICA ENTRE OS MODELOS
RNG.035 - A organização deve tomar medidas corretivas quando os objetivos da gestão da qualidade não forem atendidos; RNG.044 - Fornecer feedback à equipe e aos gerentes do projeto sobre os resultados das atividades de garantia de qualidade;
FERRAMENTAS PARA APOIAR A GARANTIA DA QUALIDADE
- ESTAÇÃO TABA
- MANTIS
- TESTLINK
- SPIDER-QA
- LOOS
- BIONDO
O TestLink é mais usado pelas organizações para controle de qualidade do que para garantia de qualidade, o foco deste trabalho. Ainda segundo Katsurayama (2008), o Testlink foi utilizado em organizações de desenvolvimento de software para planejar, executar e monitorar avaliações de conformidade fornecidas no processo de garantia de qualidade.
ANÁLISE CRÍTICA ENTRE AS FERRAMENTAS
Todos eles, inclusive o SPIDER-QA, que mesmo sendo uma ferramenta completa e focada na garantia da qualidade, não detecta a possibilidade de escalonamento nos casos em que as não conformidades não são resolvidas com as ações corretivas tomadas no prazo previamente estabelecido. A estação TABA é uma ferramenta completa na área de desenvolvimento de software, porém é muito complexa de utilizar e seus módulos são interdependentes, o que dificultaria a integração da ferramenta com as ferramentas de controle de projetos já utilizadas pela empresa que foca neste trabalhar. A fase de planejamento iniciou-se com a definição do escopo do projeto do instrumento proposto, definindo o trabalho a ser realizado.
Ao final desta fase, a versão final da ferramenta foi disponibilizada em www.reginaldo.net.br/RGQuality e todo o material gerado foi disponibilizado aos interessados.
MODELO PROPOSTO
Para tanto, foram selecionados e priorizados os cenários de utilização do sistema, definindo a sequência de desenvolvimento do software. Nesta fase foram gerados diversos artefatos, entre eles: diagrama ER, diagrama de classes, diagrama de casos de uso com seus cenários de utilização e testes completos e também diagramas de sequência da execução das principais atividades relacionadas ao uso da ferramenta. Esses testes ocorreram em duas fases. A primeira foi uma avaliação DEBUG da ferramenta, ou seja, validar se os casos de uso foram implementados corretamente e se a ferramenta era robusta e livre de erros.
Como esta estrutura foi desenvolvida para funcionar com os navegadores mais recentes, ela torna a ferramenta mais fácil de usar para o usuário final.
ANÁLISE DE REQUISITOS
- Regras de Negócio
- Requisitos Funcionais
- Requisitos não Funcionais
- Segurança
- Portabilidade
- Usabilidade
- Confiabilidade
- Desempenho
- Hardware e Software
- Relação entre Requisitos Negócios e os Requisitos do sistema
RNE.028 O relatório de desvios gerado pelo sistema deve incluir: projeto, descrição da NC, data de conclusão, status e ações corretivas; RNE.029 O relatório de ações corretivas gerado pelo sistema deve incluir: descrição do AC, status, responsável e NC conectado; REF.05 O sistema deve permitir que Admin cadastre usuários no sistema REF.06 O sistema deve permitir que Admin cadastre projetos no sistema.
REF.024 O sistema deve permitir ao Administrador cadastrar unidades de negócio, ou seja, setores da empresa;
DIAGRAMAS
WORKFLOW DA FERRAMENTA RGQUALITY
ATORES DO SISTEMA
CASOS DE USO DO SISTEMA
- USC.01 - Cadastros do sistema
- USC.02 - Execuções do Sistema
- USC.03 - Acesso ao Sistema
- USC.04 – Gerar Relatórios
O sistema retorna à página com a lista de revisões cadastradas. a) Sistema sinaliza campo com erro ao Supervisor; a) O supervisor insere os dados corretos; a) Retorne ao passo 5 do fluxo normal. A exceção 1 aparece na tela de registro. Clicar em Limpar excluirá todas as entradas. supervisor clica em registrar. o sistema atribui o status planejado à revisão. o sistema armazena os dados no banco de dados. o sistema retorna a página com a lista de. O sistema armazena os dados NC no BD; e) Sistema sinaliza o campo de erro ao Admin; e) Retorna ao passo 2 do fluxo normal.
Ação corretiva com status EXECUTADO; a) O sistema sinaliza uma mensagem informando o erro ao administrador; a) Retorne ao passo 3 do fluxo normal. Sistema exibe o site da ferramenta (TEL-004); a) Sistema identifica que o usuário não está cadastrado no sistema; a) O sistema sinaliza uma mensagem de erro ao administrador; a) Retorna ao passo 2 do fluxo normal. Na tela de alteração de senha, o funcionário clica em “Voltar”; e) O sistema carrega os dados deste usuário do banco de dados; e) Sistema exibe na tela os dados do usuário selecionado;
CASOS DE TESTE
- Efetuar login
- Cadastro de Auditoria
- Execução de Auditoria
- Cadastro de Não Conformidade
- Execução de Ação Corretiva
A Tabela 18 mostra o gráfico de rastreabilidade entre o caso de uso USC-04 e os requisitos do sistema. O caso de teste mostrado na Tabela 19 tem como objetivo servir de base para testar diferentes cenários quando um usuário efetua login no sistema. O caso de teste apresentado na Tabela 20 descreve os passos a serem seguidos para realizar testes de validação nos diversos cenários previstos durante o registro da auditoria.
O registo de não conformidades está diretamente relacionado com a realização da auditoria, pelo que não é possível criar uma não conformidade que não esteja relacionada com a auditoria.
MODELO ENTIDADE RELACIONAMENTO (MER)
DIAGRAMA DE CLASSES
Um projeto, entretanto, consistirá em artefatos que são implementados durante todo o processo de desenvolvimento de software. O diagrama da Figura 29 mostra uma visão geral do módulo de registro de usuários da ferramenta. O método utilizado pela ferramenta para apoiar a garantia de qualidade nos processos de desenvolvimento de software são as auditorias.
As medidas corretivas estão relacionadas a melhorias e desvios no processo de desenvolvimento.
DIAGRAMA DE SEQUÊNCIA
- VISÃO GERAL DO SISTEMA
- EXECUTAR LOGIN
- CADASTRO DE AUDITORIA
- EXECUÇÃO DE AUDITORIA
- RELATÓRIO DE AUDITORIAS, NÃO CONFORMIDADES E AÇÕES
O controlador recebe a entrada e aciona uma resposta ao usuário invocando objetos do modelo e, por fim, a visualização com base na entrada. A Figura 32 apresenta o Diagrama de Sequência de uma visão geral do sistema implementado, onde é claramente visível a utilização do modelo MVC. Para uma apresentação mais fácil e por não causar problemas de compreensão, substituímos as tabelas por um banco de dados (BD), que representa o armazenamento de todas as tabelas do sistema.
Diferentemente do registro, a execução é realizada pelo auditor, o que foi previamente definido durante o processo de registro da auditoria.
METODOLOGIA
ASPECTOS TECNOLÓGICOS DA FERRAMENTA
INTERFACES DA FERRAMENTA
- TELA PRINCIPAL DA FERRAMENTA
- TELA DE LOGIN DO SISTEMA
- TELA DE EXECUÇÃO DE AUDITORIA
- TELA DE CADASTRO DE NÃO CONFORMIDADE
- TELA DE VISUALIZAÇÃO DE NÃO CONFORMIDADE
Esta tela será exibida quando o colaborador acessar o site da ferramenta (www.reginaldo.net.br/RGQuality) ou quando o colaborador efetuar logout. Esta é a tela apresentada ao funcionário cadastrado como auditor sempre que realiza uma auditoria agendada para ele. É apresentado quando o auditor indica durante a auditoria do processo que algum item está não conforme.
IMPLEMENTAÇÃO DOS CASOS DE USO
USC-04.01 Relatório de Auditoria, Não Conformidade e Ações Corretivas 17 Concluído Tabela 2 - Status dos Casos de Uso do Sistema. Segundo SOFTEX (2011), o escalonamento deve ser utilizado quando uma ação corretiva não é aplicada no prazo especificado e, portanto, afeta os resultados da organização. USC-01.05 - Foi excluído o cadastro de escalonamento, pois a criação de um escalonamento já é feita automaticamente pela ferramenta RGQuality ao registrar um desvio, bem como editá-lo e excluí-lo.
O auditor de uma auditoria, ao editar a data esperada de resolução de uma não conformidade, edita indiretamente uma escalação.
AVALIAÇÃO DA FERRAMENTA
Primeiramente, a ferramenta foi disponibilizada em sua versão debug para testar as funcionalidades da ferramenta. Esses testes foram realizados por um profissional da área de testes de caixa preta de software. Como próximo passo nesta etapa de testes, com a ferramenta mais avançada, livre de erros que impediam sua utilização como ferramenta de apoio à garantia de qualidade, os testes e a implementação na empresa alvo foram iniciados desde o trabalho de conclusão do curso.
RESULTADOS DA AVALIAÇÃO
Os requisitos de negócios RNG.01 a RNG.04, RNG.07 e RNG.42 foram atendidos pelo plano de garantia de qualidade de software. Os requisitos RNG.29 a RNG.35 são políticas aprovadas pela empresa e não estão vinculados à ferramenta de garantia de qualidade e, portanto, não são atendidos pelo RGQuality. A solicitação RNG.64 não foi atendida, pois está registrada na ferramenta uma ação corretiva para eventuais discrepâncias encontradas.
Os requisitos RNG.68, RNG.70 e RNG.71 não foram atendidos porque o mecanismo de escalonamento desenvolvido era totalmente automático.
AVALIAÇÃO APLICANDO QUESTIONÁRIO
O questionário preparado com as perguntas do Apêndice B foi distribuído às pessoas envolvidas no processo de garantia de qualidade. O questionário qualitativo sobre a percepção de melhoria de processos pela equipe envolvida teve como objetivo coletar opiniões sobre a ferramenta de apoio à garantia de qualidade no processo de desenvolvimento de software aplicada na empresa. E desta forma é cumprido o segundo objetivo específico, nomeadamente aprimorar e analisar técnicas de garantia de qualidade em processos de desenvolvimento de software.
Cumprindo assim o objetivo específico de realizar um benchmark em ferramentas de checklist e garantia de qualidade de processos.
TRABALHOS FUTUROS
Instanciação de Processos de Software em Ambientes Configurados na Estação TABA, Dissertação de Mestrado em Engenharia de Sistemas e Computação. Suporte para garantia de qualidade de processos e produtos em ambientes de desenvolvimento de software orientados à organização. Melhorar a qualidade dos processos de produtos e software com base na análise de indicadores de teste.
É parte integrante do TCC: Ferramenta de apoio à garantia de qualidade dos processos de desenvolvimento de software de acordo com IEEE 730, ISO 90003, ISO/IEC 12207, ISO/IEC 15504, CMMI-DEV e MPS.BR.
FINALIDADE
DOCUMENTAÇÃO DE REFERÊNCIA
GESTÃO
Tarefas e Responsabilidades
As auditorias de processo serão realizadas pelo avaliador da qualidade do processo através da elaboração de um relatório, que será enviado ao cliente após confirmação do gestor da qualidade.
DOCUMENTAÇÃO
NORMAS, PRÁTICAS, CONVENÇÕES E MÉTRICAS
REVISÕES E AUDITORIAS
Com isso, facilita o planejamento e a possibilidade de revelar erros no processo de desenvolvimento de software em uma única fase.
TESTES
RELATÓRIO DE REGISTRO DE PROBLEMAS E AÇÕES
FERRAMENTAS, TÉCNICAS E METODOLOGIAS
CONTROLE DE MÍDIA
CONTROLE DE FORNECEDOR
REGISTROS DE COLETA, MANUTENÇÃO E RETENÇÃO
TREINAMENTO
GESTÃO DE RISCOS
GLOSSÁRIO
PROCESSO DE MUDANÇA E HISTÓRICO DO SQAP
Muito bom ( ) Bom ( ) Regular ( ) Ruim ( ) Muito ruim. 3) Como você avalia o processo de rastreabilidade de não conformidades e suas ações corretivas.
