SOFTWARE DE APOIO AO PROCESSO DE REVISÃO POR...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO

SOFTWARE DE APOIO AO PROCESSO DE REVISÃO POR

PARES NA CODIFICAÇÃO

CAMILA KLEINE

BLUMENAU 2011

2011/1-02

CAMILA KLEINE



Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação— Bacharelado.

Prof. Everaldo Artur Grahl, Mestre - Orientador

BLUMENAU 2011

2011/1-02



Por

CAMILA KLEINE

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Everaldo Artur Grahl, Mestre – Orientador, FURB

______________________________________________________ Membro: Prof. Wilson Pedro Carli, Mestre – FURB

______________________________________________________ Membro: Prof. Ricardo de Alencar Azambuja, Mestre – FURB

Blumenau, 29 de junho de 2011.

Dedico este trabalho especialmente a minha família e a todos que me ajudaram diretamente ou indiretamente na realização deste.

AGRADECIMENTOS

Á Deus pela força e motivação para seguir em frente.

À minha família, na compreensão de meus atrasos e da minha ausência de muitos

momentos.

Ao meu namorado Valcir, pelo apoio e grande companheirismo durante toda essa fase

de estudo e dedicação.

Aos meus amigos, pela força e incentivo.

A todos os professores do curso de Sistemas de Informação, pela amizade, dedicação e

profissionalismo demonstrado ao longo do curso, em especial ao professor Everaldo Artur

Grahl em ser meu orientador e acreditar na conclusão deste trabalho.

Investir em conhecimento pode nos tornar sábios, mas amor e fé nos tornam humanos.

Oriza Martins

RESUMO

Garantir que um software realmente vai fazer o que ele foi projetado para fazer é um grande desafio. Por isso, investir na qualidade de sua codificação é muito importante. Algumas empresas adotam modelos de processo de melhoria como o Capability Maturity Model Integration (CMMI), que sugere práticas para desenvolvimento e manutenção de produtos através da revisão por pares na codificação. Este trabalho apresenta uma solução aplicada a uma empresa de Blumenau que já possui o CMMI em seus processos e quer melhorar a qualidade de seu produto através de revisão por pares. O objetivo é apoiar o processo de revisão gerenciando os problemas encontrados, mantendo uma lista de verificação e definindo os papéis dos envolvidos. O software foi desenvolvido em Delphi e banco de dados MySql, e como resultado, agiliza o processo de revisão na área de desenvolvimento, identificando defeitos e sugestões de melhoria.

Palavras-chave: CMMI. Verificação. Revisão por pares. Qualidade de software.

ABSTRACT

Ensure that software will actually do what it was designed to do is a big challenge. Hence, investing in the quality of your coding is very important. Some companies adopt process improvement models like the Capability Maturity Model Integration (CMMI), which suggests practices for developing and maintaining products through peer review in the coding. This paper presents a solution applied to a company that already has Blumenau CMMI processes and want to improve the quality of your product through peer review. The goal is to support the review process by managing the problems encountered by keeping a checklist and defining the roles of those involved. The software was developed in Delphi and MySQL database, and as a result, speeds the review process in development, identifying shortcomings and suggestions for improvement.

Keywords: CMMI. Verification. Peer review. Software quality.

LISTA DE ILUSTRAÇÕES

Figura 1– Representação estagiada por níveis..........................................................................16

Figura 2 – Nível de maturidade três .........................................................................................18

Figura 3 – Tipos de revisão ......................................................................................................21

Figura 4 – Resumo das metas e práticas...................................................................................22

Figura 5 – Fluxo de trabalho do processo de revisão por pares ...............................................22

Figura 6 – Diagrama de atividades ...........................................................................................29

Figura 7 – Tarefa de revisão por pares efetuada no Help-Desk................................................30

Figura 8 – Tela de seleção das perguntas .................................................................................31

Figura 9 – Relatório de Auditoria.............................................................................................32

Figura 10 – Apoio de IBIS na detecção de defeitos .................................................................33

Figura 11 – Diagrama de casos de uso .....................................................................................37

Figura 12 – Diagrama de Atividades........................................................................................37

Figura 13 – Informações que serão carregadas do help-desk para a ferramenta ......................38

Figura 14 – Modelo entidade-relacionamento..........................................................................39

Figura 15 – Tabelas visualizadas no MySQL-Front.................................................................45

Figura 16 – Tela de login do sistema........................................................................................45

Figura 17 – Menu principal do sistema ....................................................................................46

Figura 18 – Manutenção de Grupos de Usuários .....................................................................47

Figura 19 – Manutenção de Usuários .......................................................................................48

Figura 20 – Manutenção de Grupo de Itens .............................................................................49

Figura 21 – Manutenção de Itens de Verificação .....................................................................50

Figura 22 – Manutenção de tipos de defeitos ...........................................................................50

Figura 23 – Cadastro de Tarefas de Revisão ............................................................................51

Figura 24 – Alerta de negação de cadastro de autor e revisor iguais .......................................52

Figura 25 – Trecho de código que retorna as informações do sistema help-desk ....................53

Figura 26 – Exemplo de chamada de consulta .........................................................................54

Figura 27 – Tela genérica de consultas – consulta simples......................................................54

Figura 28 – Tela genérica de consultas – consulta avançada ...................................................55

Figura 29 – Tela de manutenção da revisão .............................................................................56

Figura 30 – Painel de informações adicionais da tarefa ...........................................................57

Figura 31 – Tela de revisão com limitações para o autor.........................................................58

Figura 32 – Relatório de visualização da revisão .....................................................................59

Figura 33 – Tela de manutenção de não conformidades ..........................................................60

Figura 34 – Tela de manutenção de sugestões de melhoria .....................................................60

Figura 35 – Tela de consulta de revisões por período ..............................................................62

Figura 36 – Relatório de revisões por período .........................................................................62

Figura 37 – Relatório de itens de Verificação ..........................................................................62

Figura 38 – Relatório mensal de não conformidades por gestão..............................................63

Figura 39 – Seleção das versões para o relatório......................................................................63

Figura 40 – Relatório de revisões por versão ...........................................................................64

Figura 41 – Seleção do período para o relatório.......................................................................64

Figura 42 – Relatório de sugestões de melhoria por período ...................................................65

Figura 43 – Trecho do código fonte tratando campos obrigatórios..........................................76

Figura 44 – Documento de sugestão de melhoria ....................................................................78

LISTA DE QUADROS

Quadro 1– Área de Processos do CMMI..................................................................................15

Quadro 2 – Comparação das representações ............................................................................17

Quadro 3 – Resumo das metas e práticas .................................................................................23

Quadro 4 – Etapas da Inspeção.................................................................................................24

Quadro 5 – Itens de dados coletados de cada inspeção ............................................................27

Quadro 6 – Métricas calculadas a partir dos itens de dados coletados.....................................27

Quadro 7 – Requisitos funcionais.............................................................................................36

Quadro 8 – Requisitos não funcionais......................................................................................36

Quadro 9 – Dicionário de Dados da tabela usuário ..................................................................41

Quadro 10 – Dicionário de Dados da tabela grupousuário.......................................................41

Quadro 11 – Dicionário de Dados da tabela grupoverificacao.................................................41

Quadro 12 – Dicionário de Dados da tabela itemverificacao...................................................42

Quadro 13 – Dicionário de Dados da tabela sugestaomelhoria................................................42

Quadro 14 – Dicionário de Dados da tabela naoconformidade................................................43

Quadro 15 – Dicionário de Dados da tabela revisoes...............................................................43

Quadro 16 – Dicionário de Dados da tabela tipodefeito ..........................................................43

Quadro 17 – Dicionário de Dados da tabela tarefarevisao .......................................................44

Quadro 18 – Aderência ao CMMI............................................................................................65

Quadro 19 – Aderência ao processo de revisão........................................................................66

Quadro 20 – Descrição do caso de uso Manter revisão............................................................73

Quadro 21 – Descrição do caso de uso Manter sugestões de melhoria....................................74

Quadro 22 – Descrição do caso de uso Manter tarefa de revisão.............................................75

Quadro 23 – Planilha Excel utilizada para checklist ................................................................77

LISTA DE SIGLAS

CMMI - Capability Maturity Model Integration

EA – Enterprise Architect

ERP - Enterprise Resource Planning

IBIS - Based Inspection System

IPPD - Integrated Product and Process Development

ISO - International Organization for Standardization

MER - Modelo Entidade-Relacionamento

NC - Não conformidades

PA - Áreas de Processo

SE - Systems Engineering

SEI - Software Engineering Institute

SG - Metas Especificas

SM - Sugestões de Melhorias

SP - Práticas Especificas

SQL – Structured Query Language

SS - Supplier Sourcing

SW - Software Engineering

SW-CMM - Capability Maturity Model for Software

UML – Unified Modeling Language

VER - Verificação

SUMÁRIO

1 INTRODUÇÃO..................................................................................................................12

1.1 OBJETIVOS DO TRABALHO .........................................................................................13

1.2 ESTRUTURA DO TRABALHO .......................................................................................13

2 FUNDAMENTAÇÃO TEÓRICA....................................................................................14

2.1 O MODELO CMMI ...........................................................................................................14

2.1.1 Áreas de Processo............................................................................................................15

2.1.2 Metas e Práticas ...............................................................................................................16

2.1.3 Representação Contínua e Estagiada...............................................................................16

2.1.4 Nível 3 - Definido............................................................................................................17

2.2 A VERIFICAÇÃO E O PROCESSO DE REVISÃO POR PARES..................................18

2.2.1 Vantagens e recomendações de uso.................................................................................19

2.2.2 Metas e Práticas da Verificação.......................................................................................22

2.2.3 O emprego do checklist nas revisões...............................................................................25

2.2.4 Critérios de Saída ............................................................................................................26

2.3 SISTEMA ATUAL ............................................................................................................27

2.3.1 Problemas no processo ....................................................................................................30

2.4 TRABALHOS CORRELATOS.........................................................................................31

3 DESENVOLVIMENTO DO SISTEMA..........................................................................34

3.1 LEVANTAMENTO DE INFORMAÇÕES .......................................................................34

3.1.1 Requisitos principais do Sistema ....................................................................................35

3.2 ESPECIFICAÇÃO .............................................................................................................36

3.2.1 Diagrama de casos de uso ...............................................................................................36

3.2.2 Diagrama de Atividades..................................................................................................37

3.2.3 Modelo Entidade e Relacionamento – MER...................................................................39

3.2.4 Dicionário de Dados........................................................................................................40

3.3 IMPLEMENTAÇÃO .........................................................................................................44

3.3.1 Técnicas e ferramentas utilizadas....................................................................................44

3.3.2 Operacionalidade da implementação ..............................................................................45

3.4 RESULTADOS E DISCUSSÃO .......................................................................................65

4 CONCLUSÕES..................................................................................................................67

4.1 EXTENSÕES .....................................................................................................................68

REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................69

APÊNDICE A – Detalhamento dos casos de uso.................................................................72

APÊNDICE B – Validação dos Campos Obrigatórios........................................................76

ANEXO A – Planilha de CheckList .......................................................................................77

ANEXO B – Sugestões de Melhorias em documento anexado ...........................................78

12

1 INTRODUÇÃO

Muitas empresas de software começaram a se preocupar em estabelecer boas práticas

para permitir o correto desenvolvimento dos seus produtos. Esta preocupação ocorre porque

elas estão acompanhando a evolução da qualidade que não está somente no produto entregue

ao cliente, mas no processo de produção que é ainda mais importante. Garantir o apoio de

verificação do software durante todo o processo de desenvolvimento ou manutenção

possibilita um produto de melhor qualidade e confiabilidade (FURQUIM, 2002).

O Capability Maturity Model Integration (CMMI) é um modelo desenvolvido pelo

Software Engineering Institute (SEI), que possui como objetivo principal orientar as

organizações a conhecerem e melhorarem seus processos de software. O CMMI é um modelo

baseado em níveis de maturidade onde a área de processo que trata de assegurar que os

produtos de trabalho selecionados atendem aos seus requisitos especificados é a de

Verificação, e se encontra no nível de maturidade 3 (SOFTWARE ENGINEERING

INSTITUTE, 2008).

A revisão por pares é uma parte importante da verificação, pois permite a identificação

de desvios de qualidade e a adoção de ações corretivas de forma que os defeitos possam ser

prevenidos e a troca de conhecimento entre seus participantes é estabelecida. Realizada por

pares, consiste numa avaliação metódica de um produto, onde outra pessoa que executa as

mesmas funções irá revisar um artefato. Furquim (2002) destaca que, as revisões de software

são como filtros pelos quais os principais produtos do processo de desenvolvimento de

software devem passar com o propósito de detectar erros durante o processo de

desenvolvimento o mais cedo possível.

As revisões garantem a qualidade do software e ainda aumentam o conjunto de boas

práticas de codificação, que são dicas simples de como melhorar o código, evitando erros e

aperfeiçoando técnicas. Segundo Panissa (2007, p. 1), "a razão principal para utilização de um

conjunto consistente de práticas de codificação é padronizar a estrutura e o estilo da

codificação para que outros programadores consigam ler e entender o código

espontaneamente".

Este trabalho apresenta um software que permite o gerenciamento das revisões por

pares efetuadas na empresa Senior Sistemas, situada em Blumenau, no estado de Santa

Catarina. No ano de 2010 a empresa já tinha o processo de revisão, mas utilizando um sistema

13

Help-Desk1 genérico na geração de tarefas2 de implantação ou alteração, porém não possuía

estrutura para manter e extrair as informações geradas nas análises.

11..11 OOBBJJEETTIIVVOOSS DDOO TTRRAABBAALLHHOO

O objetivo desse trabalho é desenvolver um software de apoio ao processo de revisão

que permita o gerenciamento por pares na codificação do Sistema de Gestão Empresarial

Sapiens (Enterprise Resource Planning - ERP)3, pertencente à empresa Senior Sistemas.

Os objetivos específicos do trabalho são:

a) disponibilizar um checklist que facilite a revisão por pares na codificação;

b) disponibilizar um relatório com os dados gerados numa revisão;

c) atender as metas estabelecidas pelo processo de verificação do CMMI.

11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO

Este trabalho está disposto em quatro capítulos.

No primeiro capítulo apresenta-se a introdução, os objetivos e a estrutura do trabalho.

No segundo capítulo apresenta-se a fundamentação teórica, destacando os conceitos e

estruturas do modelo CMMI, a técnica de revisão por pares e toda a sua organização e os

trabalhos correlatos.

No terceiro capítulo é apresentado o desenvolvimento do sistema, implementação

realizada e operacionalidades do sistema.

O quarto capítulo apresenta as conclusões e sugestões de extensão e melhorias para

trabalhos futuros.

1 Help-Desk é um sistema de atendimento voltado à melhoria da qualidade de atendimento a clientes, captando e armazenando informações. 2 Tarefa é uma delegação de atividades descritas num sistema de help-desk com ordem de execução e agendamento de atividades programadas para manutenção ou serviços. 3 ERP são sistemas de informação que integram os dados e processos de uma organização em um único sistema.

14

2 FUNDAMENTAÇÃO TEÓRICA

As seções deste capítulo abordam o conceito e definição do modelo CMMI, o método

de revisão por pares no processo de verificação, o sistema atual e alguns trabalhos correlatos

com objetivos semelhantes aos deste trabalho.

22..11 OO MMOODDEELLOO CCMMMMII

O Capability Maturity Model Integration (CMMI) é um framework de referência para

empresas que desejam orientação para o desenvolvimento de software mais eficiente e

controlado, e tem como objetivo eliminar suas inconsistências. Ele foi criado a partir da

evolução do Capability Maturity Model for Software (SW-CMM), e estruturou os seus

diferentes modelos, mas não definiu nenhum processo a ser implementado, apenas metas e

práticas que podem ser seguidas para a melhoria da qualidade de softwares. Até o presente

momento, são quatro as disciplinas incorporadas ao CMMI, a Systems Engineering (SE), a

Software Engineering (SW), a Integrated Product and Process Development (IPPD) e a

Supplier Sourcing (SS). Cada disciplina possui áreas de processo para descrever suas práticas

e metas a serem alcançadas. O CMMI é um modelo abrangente de qualidade desenvolvido

pelo SEI, que se baseia em um conjunto de capacidades da engenharia de software presentes à

medida que a organização alcança diferentes níveis de maturidade (PRESSMAN, 1995 p. 22).

O CMMI introduziu duas representações para orientar os esforços de melhoria da

organização; a representação contínua e por estágios. A representação contínua usa níveis de

capacidade para medir o processo de melhoria, enquanto a representação em estágio usa

níveis de maturidade, sendo a única que permite o reconhecimento por parte do SEI, pois

permite a comparação entre o nível de maturidade das organizações (BARTIÉ, 2002).

15

2.1.1 Áreas de Processo

Segundo Chrissis, Konrad e Shrum (2003) as Áreas de Processo (PA) são consideradas

um grupo de práticas relacionadas que quando implantadas coletivamente satisfazem metas

importantes para realizar uma melhora significativa naquela área ou tema. O Quadro 1

apresenta as áreas de processo do CMMI divididas em quatro categorias.

Fonte: Adaptado de Ahern, Clouse e Turner (2003). Quadro 1– Área de Processos do CMMI

As áreas de processos estarão vinculadas às disciplinas, e dependendo da versão do

CMMI e o conjunto de disciplinas que a empresa está utilizando, a quantidade de áreas de

processo pode variar, porém a descrição será sempre a mesma, independente da

representação.

16

2.1.2 Metas e Práticas

Dentro de cada área existem metas específicas que são únicas para cada área. São elas

que definem o resultado que deve ser alcançado para uma implementação adequada de uma

área de processo. Já as práticas específicas determinam que atividades devem ser realizadas

para atingir essa meta. Metas genéricas são aplicáveis indistintamente a todos os processos do

modelo, onde cada processo pode ser avaliado de forma individual em um nível de

capacidade. Essas metas definem o que o processo deve alcançar para considerar que ele está

em um determinado nível de capacidade. As práticas genéricas descrevem uma atividade

considerada importante para a satisfação da meta genérica associada, e a mesma prática se

aplica as várias áreas de processo (SOFTWARE ENGINEERING INSTITUTE, 2008).

2.1.3 Representação Contínua e Estagiada

A representação em estágio usa cinco níveis de maturidade, onde cada estágio inferior

estabelece a base para o estágio superior, permitindo que as organizações melhorem um

conjunto de áreas de processo por vez. Dentro de cada nível, existem áreas de processo que

contêm metas e práticas que quando alcançadas, permitem essa mudança de nível

(SOFTWARE ENGINEERING INSTITUTE, 2008). A figura 1 a seguir, apresenta a

representação estagiada do modelo CMMI.

Fonte: Software Engineering Institute (2008). Figura 1– Representação estagiada por níveis

17

Segundo Agnol e Herbert (2004, p. 109), a representação contínua usa seis níveis de

capacidade para medir o processo de melhoria, onde cada área de processo é tratada como

uma entidade isolada, sendo assim, cada área de processo pode estar em um nível distinto. A

organização nesse caso pode selecionar a ordem de melhoria que melhor atinge os seus

objetivos e minimizar as áreas de risco. Cada nível de capacidade é composto por uma meta

genérica e um conjunto de práticas genéricas, e conforme a organização satisfaz essa etapa,

ela assume a melhoria de processo para aquela área de processo.

O Quadro 2 compara os seis níveis de capacidade com os cinco níveis de maturidade,

onde é possível verificar que o ponto inicial de cada representação é diferente e que quatro

níveis possuem os mesmos nomes nas duas representações.

Fonte: Software Engineering Institute (2008, p. 49). Quadro 2 – Comparação das representações

2.1.4 Nível 3 - Definido

Neste trabalho será utilizada a representação por estágios, pois permite a comparação

do nível de maturidade das organizações e um melhor desempenho quanto aos esforços de

melhoria de processo em um número gerenciável de áreas de processo (SOFTWARE

ENGINEERING INSTITUTE, 2008). O nível de maturidade analisado é o nível 3, com foco

especifico na área de processo de verificação. A figura 2 apresenta as descrições e áreas de

processo integradas do nível 3.

18

Fonte: Software Engineering Institute (2008). Figura 2 – Nível de maturidade três

22..22 AA VVEERRIIFFIICCAAÇÇÃÃOO EE OO PPRROOCCEESSSSOO DDEE RREEVVIISSÃÃOO PPOORR PPAARREESS

O objetivo da verificação (VER) é garantir que o software, ou um determinado

processo do mesmo, esteja sendo implementado ou aplicado corretamente, garantir se o

produto cumpre com a sua especificação, com os requisitos e com os padrões estabelecidos. O

CMMI define alguns métodos para esta verificação, que incluem inspeções, revisões por

pares, análises, simulações, testes e demonstrações, dentre outros (SOFTWARE

ENGINEERING INSTITUTE, 2008).

Normalmente revisões são focadas em especificações de requisitos, projetos e código

fonte e podem variar em grau de formalidade do informal ao formal. Na revisão informal não

existe um processo estruturado, contrário ao formal, que inclui um processo definido e

documentado para detectar e remover erros. A organização pode até prover listas de itens a

serem verificados (GUIMARAES; ROSSI, 2008).

Um tipo de revisão mais formal é a inspeção desenvolvida por Fagan (1976), que é a

forma mais usada e detalhada de se realizar uma revisão. Ela tem sido usada por diferentes

empresas e em diferentes artefatos de software, porém mais freqüentemente em código. Para

19

Paula Filho (2005, p.373) "inspeção é um tipo de revisão em pares mais formais e rigorosas, e

tem o objetivo principal de identificação e remoção de defeitos. É obrigatória a geração de

uma lista de defeitos4 com classificação padronizada, requerendo-se a ação dos autores para a

remoção desses defeitos." Segundo Boehm e Basili (2001), as inspeções de software capturam

em torno de 60% dos defeitos de artefatos e o re-trabalho tende a crescer conforme o

desenvolvimento aumenta, a razão para isto é o aumento no esforço para corrigir defeitos nas

atividades finais do processo de desenvolvimento.

Em uma Inspeção, colegas de trabalho de uma pessoa que criou o produto de trabalho

examinam o produto para identificar defeitos e desvios, e vários critérios de análise são

possíveis de adotar para esta verificação. Numa revisão de codificação de um artefato,

segundo Martins (2005), é possível analisar as seguintes especificações na busca de alguma

irregularidade ou melhoria:

a) verificar iterações com múltiplos pontos de saída ou de entrada, como código

inacessível ou condições sempre verdadeiras;

b) verificar a seqüência de atribuição e usos de cada espaço de dado, como variáveis,

estruturas, etc.;

c) verificar a consistência das declarações das funções e procedimentos em relação às

chamadas;

d) verificar códigos de tratamento de exceção que não podem ser testado facilmente

ou que possuem um lógica mais complexa;

e) verificar artefatos candidatos a reuso ou que afetam várias partes do produto;

f) verificar artefatos criados por desenvolvedores menos experientes;

g) verificar artefatos com grande histórico de falhas;

h) verificar artefatos que usam novas tecnologias, técnicas ou ferramentas;

i) verificar artefatos com grande importância na estrutura do software.

2.2.1 Vantagens e recomendações de uso

Revisões e inspeções informam diretamente o defeito, e podem economizar perto de

40% do custo total de desenvolvimento, além de reduzirem o re-trabalho inútil. Também

4 Lista de defeitos é um conjunto de erros que pode ser encontrado no software.

20

possuem a vantagem de serem realizadas em artefatos não executáveis ou ainda incompletos,

conseqüentemente os erros não se propagam para outros artefatos. Mas é importante verificar

a maturidade do artefato, já que não adianta procurar defeitos em algo que não tem consenso

ou de baixa qualidade (WHEELER; BRYKEZYNSKI; MEESON, 1996). Segue mais alguns

fatores que são importantes para o sucesso das revisões efetuadas dentro de uma empresa

(MARTINS, 2005):

a) aumentar a qualidade de um produto de trabalho;

b) identificar e documentar defeitos;

c) identificar melhorias necessárias em um produto de trabalho;

d) verificar se o produto de trabalho está em conformidade com padrões,

especificações e requerimentos adotados;

e) atingir consenso em relação aos produtos de trabalho;

f) aumentar o conhecimento dos pares em relação ao produto;

g) ser uma "via" gerencial para formalmente completar uma tarefa;

h) papéis definidos e treinamento adequado para os participantes;

i) processo formal baseado em regras, check-list ou listas de verificação5 que servem

como ferramenta para encontrar erros;

j) cada revisão tem um objetivo claramente definido;

k) defeitos encontrados são encorajados e expressados objetivamente, evitando

problemas pessoais;

l) técnicas de revisão são aplicadas de forma a combinar com o tipo e nível do

software e revisores;

m) gerenciamento é importante para um bom processo de revisão, como alocação de

pessoas e carga horária;

n) ênfase em aprender e aprimorar o processo.

Quanto maior for o risco associado a uma falha não ser identificada, mais formal deve

ser a revisão, porém, a forma como as revisões são realizadas nas organizações ainda é pouco

sistematizada, e assim o verdadeiro potencial das revisões raramente é explorado. Este

argumento é baseado em um survey6 que foi realizado em 2002 visando avaliar o estado da

prática de revisões de software (CIOLKOWSKI; LAITENBERGER; BIFFL, 2003).

5 Lista de verificação é um conjunto de avaliações a serem aplicadas sobre o artefato a ser revisado. 6 Survey é um estudo de pesquisa de mercado, que formula perguntas a fim de receber informações sobre atitudes, motivos e opiniões.

21

Na figura 3 pode-se observar as recomendações de uso para alguns tipos de revisão, e

onde fica mais clara a idéia de revisões formais e informais.

Fonte: Wiegers (2002).

Figura 3 – Tipos de revisão

Segundo Paula Filho (2005, p.373), a revisão de apresentação (também chamada de

Walkthroughs), é uma revisão informal na qual o autor apresenta o material em ordem lógica

sem limite de tempo, a um grupo que verifica o material à medida que ele vai sendo

apresentado. Este tipo de revisão não exige muita preparação prévia, e pode ser feito com

maior número de participantes, que comentam e analisam a lógica do projeto procurando

apontar falhas e apresentar sugestões, porém a detecção de falhas não é o foco principal.

A revisão técnica é uma discussão que busca o consenso sobre o tipo de abordagem

técnica a ser utilizada. Esta revisão é muito parecida com a revisão por pares, exceto por

algumas diferenças, como a de não requer pessoal específico para cada função, não necessitar

de checklist, e por obter resultado com apenas uma lista de ações e ata das reuniões

(MARTINS, 2005).

22

2.2.2 Metas e Práticas da Verificação

Segundo Agnol e Herbert (2004, p. 109), essa área de processo de engenharia

“Verificação” é composta das seguintes metas e práticas especificas (SG e SP) dentro do

CMMI, apresentadas na Figura 4 e demonstradas através de um fluxo na Figura 5. No Quadro

3 essas metas e práticas são resumidamente descritas.

Fonte: Agnol e Herbert (2004, p.109).

Figura 4 – Resumo das metas e práticas

Fonte: Pires et al (2004, p. 7).

Figura 5 – Fluxo de trabalho do processo de revisão por pares

23

SG1 - Preparar para a Verificação

Assegurar que os meios para a verificação sejam incorporados aos requisitos do produto e de seus

componentes, bem como ao projeto, ao plano de desenvolvimento e ao cronograma.

SP1.1 - Selecionar os Produtos de Trabalho para Verificação

Selecionar e definir os produtos de trabalho a serem verificados, além dos métodos de verificação que

serão usados para cada um. Identificar os requisitos a serem satisfeitos por cada produto selecionado.

SP1.2 - Estabelecer o Ambiente de Verificação

Estabelecer um ambiente para que a verificação ocorra. Identificar os requisitos e recursos do ambiente

de verificação, se ele deve ser adquirido, desenvolvido, reutilizado, modificado ou qualquer combinação dessas

ações, dependendo das necessidades do projeto.

SP1.3 - Estabelecer Procedimentos e Critérios de Verificação

Desenvolver e refinar critérios de verificação para assegurar que os componentes e padrões do produto

de trabalho atendam aos seus requisitos.

SG2 - Realizar Revisão por pares

A Revisão por pares é realizada em diversos tipos de produto de trabalho..

SP2.1 - Preparar para Revisão por Pares

Manter critérios de entrada e saída para a revisão, identificando a equipe envolvida. Existe a preparação e

atualização dos documentos que serão utilizados durante a revisão, como as listas de verificação (checklist).

SP2.2 - Realizar Revisão por Pares.

Conduzir e gerenciar a revisão por pares nos produtos de trabalho selecionados e identificar e remover os

defeitos resultantes da revisão. Devem ser registrados dados suficientes e consistentes, onde os itens de ação

devem ser registrados.

SP2.3 - Analisar Dados de Revisão por Pares

Analisar dados sobre a preparação, condução e resultados de revisão por pares. Armazenando e protegendo os

dados para referências e análises futuras.

SG3 - Verificar os Produtos de Trabalhos Selecionados

Os produtos de trabalho são verificados com relação aos seus requisitos especificados.

SP3.1 - Realizar Verificação

Os produtos de trabalho são verificados em relação aos seus requisitos especificados. Analisando os resultados

da verificação e acompanhando os relatórios, propicia a detecção precoce de problemas e pode resultar na

remoção antecipada dos mesmos, diminuindo custos e re-trabalhos.

SP3.2 - Analisar Resultados de Verificação e Identificar Ações Corretivas

Analisar os resultados de todas as atividades de verificação, e ações corretivas são iniciadas para assegurar que

os requisitos sejam atendidos. São efetuados relatórios para identificar problemas com os métodos,

procedimentos, critérios e ambiente de verificação.

Fonte: Software Engineering Institute (2008).

Quadro 3 – Resumo das metas e práticas

24

Fagan (1976) desenvolveu o processo tradicional de inspeção de software, uma forma

detalhada de se realizar uma revisão seguindo algumas etapas. Com semelhança com o

presente trabalho e os processos do CMMI, segue quatro etapas dessas atividades

apresentadas no Quadro 4.

Fonte: Fagan (1976).

Quadro 4 – Etapas da Inspeção

Em uma revisão por pares, os participantes geralmente são os líderes do projeto e

membros da equipe, e consiste em um artefato revisado por um par, ou seja, outra pessoa que

executa as mesmas funções irá revisar o artefato. “As revisões de software devem acontecer

de forma controlada e deve-se assegurar que todos os papéis são desempenhados”

(FURQUIM, 2002).

As etapas de uma inspeção são mais formais e estruturadas e embora o processo de

revisão por pares estabeleça vários critérios assemelhando-se as inspeções, sua estrutura é um

pouco diferente. As inspeções envolvem uma pequena equipe e realizam reuniões para

confrontar opiniões e chegar a um consenso, além de possuir mais etapas durante o processo

de revisão. Já uma equipe de revisão por pares é composta por três a cinco componentes, onde

obrigatoriamente deve existir um líder, um autor e profissionais especializados que serão os

revisores. Sendo assim, neste tópico apenas serão relacionadas às etapas e papéis da inspeção

que possuem abordagens parecidas com revisão por pares e com os critérios da empresa.

Os papéis de uma inspeção são distribuídos em: autor, moderador, leitor, escritor,

revisor, coordenador das inspeções. Nesse trabalho o papel de coordenador é realizado pelo

analista. Essas definições podem variar conforme os processos que a organização estabelece.

Os papéis são citados por Fagan (1976):

25

a) autor: criador ou mantenedor do produto de trabalho a ser inspecionado. Esclarece

as dúvidas relativas ao produto a ser inspecionado, se necessário. Efetua as

modificações solicitadas no final do processo;

b) revisor: examina o artefato e registra a revisão, classifica os defeitos, desvios e

sugere melhorias;

c) coordenador das inspeções: responsável pelas métricas7 de inspeção do projeto,

gera relatórios de inspeção, identifica os artefatos a serem inspecionados, seleciona

inspetores, estabelece cronograma a serem inspecionados e se o processo é seguido

por todos.

2.2.3 O emprego do checklist nas revisões

Laitenberger e Atkinson (1998) constataram que a técnica de usar checklist, é a mais

empregada para a detecção de defeitos no contexto de inspeções de software, sob a

abordagem de aumentar a efetividade da revisão e diminuir a relação de custo por defeito ao

focar a atenção do revisor num conjunto pré-definido de questões. Os revisores respondem a

essas questões enquanto lêem um artefato de software, atribuindo uma das três opções de

resposta Sim, Não e Não se Aplica.

Normalmente as questões apresentadas em um checklist são baseadas no histórico de

defeitos verificados pela empresa ou extraídos da literatura. A forma mais eficaz dos revisores

levantarem esses dados é através do conhecimento adquirido pela experiência no ramo

(CHERNAK, 1996).

O padrão do Institute of Electrical and Electronic Engineers (IEEE) define atributos de

qualidade que um requisito deve possuir, onde a falta de uma dessas opções constituiria um

tipo de defeito. Conforme IEEE (1998), são eles:

a) omissão: artefato importante relacionado à funcionalidade, ao desempenho, às

restrições de projeto, ao atributo, ou à interface externa não foi incluído;

7 Métricas é uma indicação quantitativa de algum item específico através de uma unidade de medida padronizada.

26

b) ambigüidade: o artefato tem várias interpretações devido a diferentes termos

utilizados para uma mesma característica;

c) inconsistência: dois ou mais artefatos são conflitantes;

d) fato incorreto: um artefato descreve uma situação que não é verdadeira conforme

deve operar no sistema;

e) informação estranha: as informações no artefato não são necessárias ou mesmo

usadas;

f) outros: outros defeitos que não se enquadram nas opções anteriores.

Esta classificação não pretende ser definitiva e cada organização pode acrescentar mais

tipos de defeito de acordo com suas necessidades. Esse tipo de defeito pode ser classificado

em dois tipos de severidade: a alta, que pode causar falha no produto ou grande customização

e baixa, que pode ser um erro não-fatal, problema cosmético ou um aborrecimento.

2.2.4 Critérios de Saída

Os critérios de saída são solicitados a partir do final da segunda meta do CMMI, onde

os resultados e ações devem ser monitorados com os dados gerados. O acompanhamento é

fundamental para que o processo tenha estabilidade e seja executado por todos.

O coordenador de revisões ou analista (determinado pela empresa) acompanha os

dados de cada inspeção produzindo relatórios e consultas periódicas, repassando estatísticas e

resumos para os profissionais e gestores. È muito importante realizar essa medição, pois cada

organização deve verificar o benefício de cada método através de experimentos, deve haver

muita compreensão e paciência entre os envolvidos até que seja definido exatamente os itens

que devem ser coletados e que informações devem ser registradas (WIEGERS, 2002).

O coordenador ou analista deverá recolher os itens de dados do Quadro 5 a partir de

cada inspeção. Estes itens de dados são usados para calcular a métricas de processo do

Quadro 6 e para monitorar e melhorar o processo de inspeção, porém é apenas um exemplo de

critérios, não aplicado diretamente no presente trabalho. Métricas oferecem uma visão

excelente do estado e tamanho corrente do projeto e um bom entendimento do esforço que

ainda deverá ser realizado para completar o mesmo, identificar problemas ocorridos em áreas

especificas, tornando mais fácil o seu ajuste (SCHOEDER, 1999).

27


Quadro 5 – Itens de dados coletados de cada inspeção


Quadro 6 – Métricas calculadas a partir dos itens de dados coletados

22..33 SSIISSTTEEMMAA AATTUUAALL

A Senior Sistemas Ltda foi fundada em 1988 e desde então desenvolve e comercializa

quatro sistemas:

a) Regente: para administração de agências de viagens;

b) Segurança: para gestão de acesso e segurança;

c) Vetorh: para administração de recursos humanos;

d) Sapiens: para gestão empresarial.

Com o crescimento da empresa e as exigências do mercado, viu-se a necessidade de

melhores práticas de desenvolvimento de software e gerenciamento de projetos, obtendo em

maio de 2008, a certificação CMMI de nível 3 (SENIOR SISTEMAS, 2009).

Usar um processo gerenciado e ajustado para um conjunto padrão de processos é

fundamental para manter o nível 3 numa organização. Sendo assim, a Senior Sistemas vem

aprimorando o processo de verificação de software no Sistema Sapiens da qual desenvolve,

28

utilizando a revisão por pares nas análises de codificação de seus módulos. O ERP Sapiens

atende diversos segmentos de negócios nas áreas administrativa, financeira, entre outros

segmentos que são chamados de gestão, e sua aplicação é desenvolvida para a plataforma

Windows. Esse conjunto de módulos empresariais é composto por analistas e programadores

na área de desenvolvimento, que executam a revisão por pares sempre que houver

necessidade.

O processo inicia quando o analista de uma determinada área de negócio verifica a

documentação sobre alteração de código em uma tarefa, que é um registro feito e

acompanhado por um sistema de Help-Desk da empresa. O analista verifica se os artefatos

dessa tarefa devem passar por uma revisão por pares analisando se a tarefa trata de rotinas

novas, complexas ou críticas, rotinas com histórico de defeitos altos, entre outros aspectos.

Após isso, cria uma nova tarefa descrevendo a necessidade de revisão em determinados

artefatos e depois seleciona um revisor para efetuar a análise. A tarefa original em que o

analista verificou a necessidade de revisão segue para o setor da qualidade, seguindo outros

fluxos de processos. A escolha pelo revisor é baseada na experiência do profissional e

dependendo dos casos pode ser o próprio analista.

Apenas o analista pode selecionar o revisor adequado para a tarefa de revisão, e o

processo normal consiste em ser apenas um revisor por tarefa, pois a empresa assim

determinou. Foi constatado que um revisor responsável pela tarefa desde o início das revisões,

está mais familiarizado com a situação e possui mais conhecimento nos dados analisados.

Envolver mais revisores consiste em menos pessoas trabalhando em outras atividades e ainda

consumindo mais tempo para compreender a revisão em andamento. Se o revisor responsável

por uma revisão não conseguir efetuar a análise (acontecimento inesperado), o analista

imediatamente deve ser acionado para alterar a tarefa para outro revisor.

O analista então passa a tarefa criada ao revisor, e este por sua vez analisa os códigos

fontes alterados, conforme as boas práticas de programação e a lista de verificações

(checklist) que a empresa estabelece. O objetivo desse processo é identificar falhas na

codificação, sugerir melhorias, trocar conhecimento entre os envolvidos, padronizar técnicas e

utilizar mais as boas práticas de programação (SENIOR SISTEMAS, 2009). Essa análise

pode gerar dois resultados:

29

a) revisão sem sugestões de melhorias8 (SM) e sem não conformidades9 (NC) ou;

b) revisão com sugestões de melhoria e/ou não conformidades.

Esse resultado fica descrito na tarefa ou nela anexada em forma de documento ou

planilha, apresentados inclusive no anexo A e anexo B. Era restrito somente a esse número da

tarefa, que volta a ser enviada ao autor da mesma para realizar as correções ou, se não

necessitar de alterações, segue para outros processos. Normalmente esse fluxo tem

participação do revisor apenas duas vezes. A primeira vez que executa a revisão e a segunda

vez que analisa a correção que o autor da tarefa efetuou após passar pela revisão. Se houver

necessidade, o autor da tarefa pode corrigir e encaminhar quantas vezes que precisar,

conforme a figura 6.

Figura 6 – Diagrama de atividades

8 Sugestão de melhorias são idéias propostas pelo revisor numa revisão, que podem aperfeiçoar a codificação. 9 Não conformidade é um processo ou dado que não está de acordo com padrões estabelecidos e pode acarretar problemas se não for corrigido.

30

2.3.1 Problemas no processo

Desenvolver um sistema adotando uma prática de revisão auxilia no cumprimento de

prazos e custos acordados com o cliente, porém esse processo precisa ser organizado para que

as pessoas envolvidas não fiquem desmotivadas ao longo do tempo. Esse é um dos problemas

que ocorrem no desenvolvimento do Sistema Sapiens, a falta de um software de apoio no

processo de revisão por pares.

O sistema de Help-Desk utilizado na empresa para manter e acompanhar a revisão não

possui os recursos necessários para consultar e aproveitar os resultados das análises efetuadas.

As boas práticas não são divulgadas e nem monitoradas. A listagem de verificações

(checklist) é mantida num repositório e as boas práticas que o desenvolvimento mantém fica

em outro. Isto dificulta a análise do revisor que vai precisar acessar vários documentos, além

do tempo que sempre é escasso. A listagem e as boas práticas não serão atualizadas com

sugestões provenientes de uma revisão por pares, visto que a mesma fica restrita a um anexo

de uma tarefa conforme é possível visualizar na Figura 7.

Figura 7 – Tarefa de revisão por pares efetuada no Help-Desk

A seleção do revisor num artefato que necessita de análise deve ser feita por alguém

mais experiente na área em questão. Neste caso o analista, porém não existe controle de

acesso para esse tipo de situação e qualquer pessoa no desenvolvimento é capaz de selecionar

um revisor. Isso pode gerar problemas quando um revisor de alto conhecimento técnico é

alocado para uma análise de baixa complexidade, e o inverso também. A análise neste caso

fica comprometida.

31

Com um software de apoio para a equipe de desenvolvimento no processo de revisão

por pares, será possível efetuar uma análise mais rápida, com dados sempre atualizados e de

conhecimento a todos. Consultas e relatórios serão possíveis, garantindo controle no processo

e disponibilizando informações gerenciais.

22..44 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS

Nesta seção alguns trabalhos com características semelhantes ao do sistema são

apresentados.

Ebertz (2002) realizou um estudo comparativo do processo de verificação das normas

ISO/IEC 12207, ISO 9000-3, ISO/IEC 15504 e o modelo CMMI em seu trabalho de

conclusão de curso, “Protótipo de Apoio ao Processo de Verificação Baseado na Norma

ISO/IEC 12207”. Além disso, propôs um sistema de apoio ao processo de verificação onde

para cada atividade desse processo o software realizará um checklist para verificar se o

desenvolvimento está de acordo com a norma ISO/IEC 12207. O comparativo serve como

subsídio para ampliar o processo de verificação. O sistema foi desenvolvido em ambiente de

programação Visual Delphi 5.0 da Borland e para o armazenamento dos dados foi utilizado o

banco Paradox. Para selecionar as questões propostas para avaliação do processo de

verificação do software, foi implementada a tela apresentada na Figura 8.

Fonte: Ebertz (2002)

Figura 8 – Tela de seleção das perguntas

32

Outro trabalho pesquisado foi o de Junckes (1999) com o “Software de Apoio ao

Processo de Auditoria Segundo Normas de Qualidade”, que tem como objetivo auxiliar o

processo de auditoria de sistemas segundo recomendações das normas e modelos de qualidade

ISO/IEC 12207, ISO 9000-3, CMM e SPICE (JUNCKES, 1999). Ele realiza também um

estudo das técnicas e estratégias de verificação e validação, revisões, e demonstra importância

quanto aos procedimentos e padrões aplicáveis aos produtos de software. As ferramentas

utilizadas para a especificação e desenvolvimento do software foi a ferramenta

PowerDesigner 6.1 e ambiente Delphi 3.0, onde na Figura 9 é possível visualizar o relatório.

Fonte: Junckes (1999).

Figura 9 – Relatório de Auditoria

O objetivo do trabalho de conclusão de curso de Élen Filappi foi desenvolver um

modelo de avaliação de qualidade de abrangência ampla, podendo assim ser aplicado a

projetos de desenvolvimento. Nele são abordadas as técnicas de inspeções e revisões de

software, destacando um estudo sobre uma ferramenta web que já existe no mercado Internet

Based Inspection System (IBIS). Este aplicativo auxilia no processo de inspeções de software

com licença free e base de dados XML, e visa encontrar falhas antecipadamente em

softwares, além de focar o processo de verificação e diversas técnicas de revisão (FILAPPI,

2009).

O sistema IBIS apóia inspeções a distância, com equipes que necessariamente não

estão presentes. Isto porque utiliza a web em conjunto com notificações por e-mail e a

33

inspeção é tratada como tópicos de discussão (LANUBILE; MALLARDO; CALEFATO,

2003). A Figura 10 ilustra o apoio de IBIS na atividade de detecção de defeitos utilizando um

checklist.

Fonte: Lanubile; Mallardo; Calefato (2003).

Figura 10 – Apoio de IBIS na detecção de defeitos

34

3 DESENVOLVIMENTO DO SISTEMA

Neste capítulo são descritas as especificações do sistema, as suas características, os

principais requisitos, o diagrama de caso de uso, o modelo entidade relacionamento, a

operacionalidade do sistema, tecnologias utilizadas e resultados obtidos.

33..11 LLEEVVAANNTTAAMMEENNTTOO DDEE IINNFFOORRMMAAÇÇÕÕEESS

A solução desenvolvida consiste num sistema de apoio ao processo de revisão por

pares para a área de desenvolvimento do Sistema Sapiens, pois até o momento, esse processo

é realizado num sistema de Help-Desk genérico e sem recursos para organizar e gerenciar as

análises. Para isto, foram obedecidos os seguintes procedimentos:

a) manter os critérios para verificação: cadastrar esses itens tornando-os como um

checklist, mais eficiente e rápido nas revisões;

b) ambiente de revisão funcional: proporcionar um ambiente que gerencie o processo

de revisão por pares com o auxilio da metodologia proposta pelo CMMI, deixando

as atividades organizadas e com papéis definidos aos envolvidos;

c) acompanhar e gerenciar os resultados: emitir relatórios e efetuar consultas no

sistema, manter o ambiente sempre atualizado.

Com este apoio ao processo de revisão, existe a melhoria na qualidade da codificação

do artefato e consequentemente, a redução de defeitos no produto. A padronização e as

melhores práticas no desenvolvimento serão praticadas e disponíveis a todos, e se o processo

possui o seu devido acompanhamento, através dos relatórios é possível identificar onde

deverão existir melhorias na equipe.

35

3.1.1 Requisitos principais do Sistema

Nesta seção serão apresentados os principais requisitos funcionais (RF), requisitos não

funcionais (RNF), sua rastreabilidade com seus respectivos casos de uso. No quadro 7 são

apresentados os requisitos funcionais do Sistema.

Requisitos Funcionais Caso de Uso

RF01: O sistema deverá permitir acesso ao sistema através de login. UC01

RF02: O sistema deverá permitir ao analista, revisor e autor trocar de usuário. UC02

RF03: O sistema deverá permitir ao analista, revisor e autor manter as

revisões.

UC03

RF04: O sistema deverá permitir ao analista, revisor e autor gerar o relatório

da revisão.

UC04

RF05: O sistema deverá permitir ao analista, revisor e autor manter não

conformidades.

UC05

RF06: O sistema deverá permitir ao analista, revisor e autor manter sugestões

de melhoria.

UC06

RF07: O sistema deverá permitir ao analista manter tarefa de revisão. UC07

RF08: O sistema deverá permitir ao analista manter os usuários. UC08

RF09: O sistema deverá permitir ao analista manter os grupos de usuários. UC09

RF10: O sistema deverá permitir ao analista e revisor manter os itens de

verificação.

UC10

RF11: O sistema deverá permitir ao analista e revisor manter os grupos de

itens de verificação.

UC11

RF12: O sistema deverá permitir ao analista manter tipos de defeitos. UC12

RF13: O sistema deverá permitir ao analista gerar relatório mensal de não

conformidade por gestão.

UC13

RF14: O sistema deverá permitir ao analista gerar relatório de revisão por

período.

UC14

RF15: O sistema deverá permitir ao analista gerar relatório de sugestão de

melhoria por período.

UC15

RF16: O sistema deverá permitir ao analista gerar relatórios de revisão por

versão.

UC16

36

RF17: O sistema deverá permitir ao analista, revisor e autor consultar as

revisões em todas as situações.

UC17

RF18: O sistema deverá permitir ao analista gerar relatório de item de

verificação.

UC18

Quadro 7 – Requisitos funcionais

O Quadro 8 lista os requisitos não funcionais previstos para o sistema.

Requisitos Não Funcionais

RNF01: Deve-se ter controle de acesso, através do uso de senhas.

RNF02: O sistema deverá utilizar o banco de dados MySql.

RNF03: O sistema deverá ser implementado utilizando a linguagem Object Pascal, com a

ferramenta de desenvolvimento Borland Delphi 7.

RNF04: O sistema deverá ser executado em ambiente Windows.

RNF05: O sistema deverá acessar o banco de dados do sistema de Help-Desk da empresa

para extrair dados da tarefa.

Quadro 8 – Requisitos não funcionais

33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO

Nesta seção estão descritos os diagramas elaborados para desenvolvimento do sistema,

dentre eles o diagrama de caso de uso e seu detalhamento e o diagrama de atividades, ambos

com base na Unified Modeling Language (UML), utilizando a ferramenta Enterprise

Architect (EA).

3.2.1 Diagrama de casos de uso

Esta sub-seção apresenta na Figura 11 o diagrama de casos de uso do sistema. Para o

melhor entendimento do software, o detalhamento dos principais casos de uso (UC03, UC06,

UC07), encontram-se no Apêndice A.

37

Figura 11 – Diagrama de casos de uso

3.2.2 Diagrama de Atividades

A figura 12 contém o diagrama de atividades que representa o processo de cadastro de

uma tarefa de revisão até o seu fechamento dentro do sistema.

Figura 12 – Diagrama de Atividades

38

O fluxo deste processo inicia quando o analista verifica que os artefatos alterados de

uma tarefa devem passar por uma revisão por pares, a mesma situa-se no sistema de Help-

Desk da empresa. Através da aplicação desenvolvida, o analista acessa o sistema efetuando

login como administrador de sistema. Ele vai possuir acesso a todas as opções do software,

incluindo o cadastrado de usuários. Estes por sua vez, não podem gerar tarefas de revisão e

nem gerar relatórios. Estes usuários que não são analistas podem desempenhar dois papéis,

como revisores ou autores de tarefa.

O analista acessa a tela de cadastro de revisão e informa o número da tarefa original do

Help-Desk, automaticamente os principais dados dessa tarefa serão carregados, como autor da

tarefa, data vencimento, dentre outras informações conforme são apresentadas na Figura 13.

Com esses dados o analista então, cadastra uma tarefa de revisão na aplicação.

Figura 13 – Informações que serão carregadas do help-desk para a ferramenta

Após isso será possível selecionar um revisor, apenas o analista pode fazer esse

processo, já que o mesmo acessa o sistema como usuário administrador. Nessa situação, a

preparação da revisão foi efetuada, o ambiente foi estabelecido e os critérios definidos.

O revisor que tem acesso ao sistema apenas para efetuar revisões e alguns cadastros,

verifica que possui uma tarefa sob a sua responsabilidade e efetua a análise, acessa o

formulário com o questionamento e efetua a revisão, que pode gerar como resultado sugestões

de melhoria e/ou não conformidades. Se o resultado dessa revisão gerar a idéia de um novo

item do questionamento, o revisor pode efetuar o cadastro. Após isso encaminha a ocorrência

para o autor dos artefatos alterados para efetuar a devida correção, esse processo de revisão e

39

correção pode ser realizado quantas vezes se necessário, mas se não existir correções, o autor

encerra a tarefa de revisão que seguirá outro processo exigido pela empresa.

Com esse software o analista gera relatórios de erros e sugestões, revisões por períodos

e visualiza a revisão efetuada de uma tarefa com mais precisão. Com todas essas informações

centralizadas em uma única ferramenta, é possível acompanhar e gerenciar a revisão por pares

com dados atualizados e disponíveis em relatórios, e seguindo criteriosamente as práticas

estabelecidas pelo modelo.

3.2.3 Modelo Entidade e Relacionamento – MER

A figura 14 apresenta o modelo entidade e relacionamento que representam as

entidades que foram persistidas no banco de dados.

Figura 14 – Modelo entidade-relacionamento

40

A seguir é apresentada uma breve descrição das entidades utilizadas para o

desenvolvimento do sistema:

a) usuário: entidade responsável por armazenar informações referente aos usuários do

sistema;

b) grupousuario: entidade responsável por armazenar informações referente aos

grupos dos usuários do sistema;

c) itemverificacao: entidade responsável por armazenar informações referente aos

itens de verificação utilizados numa revisão;

d) grupoverificacao: entidade responsável por armazenar informações referente aos

grupos de itens de verificação utilizados numa revisão;

e) tipodefeito: entidade responsável por armazenar informações referente aos tipos de

defeitos que uma não conformidade pode ser classificada;

f) naoconformidade: entidade responsável por armazenar informações referente à não

conformidades que podem ser geradas numa revisão;

g) sugestaomelhoria: entidade responsável por armazenar informações referente à

sugestões de melhorias que podem ser geradas numa revisão;

h) tarefarevisao: entidade responsável por armazenar informações referente á tarefas

que já possuem, ou irão ter revisões;

i) revisoes: entidade responsável por armazenar informações referente as várias

revisões que uma tarefa pode obter.

3.2.4 Dicionário de Dados

O dicionário de dados de cada entidade do modelo de dados relacional encontra-se nos

quadros de 9 a 17. O tipo de dado de cada campo é definido por uma letra, que representa:

a) v: VARCHAR que armazena caracteres;

b) n: NUMBER que armazena somente números;

c) d: DATE que armazena uma data, composta de dia, mês, ano;

d) t: TIME que armazena uma hora, composta de hora, minuto e segundo;

e) pk: valor que nunca se repete e é usado como índice para os demais campos da

tabela;

f) fk: valor relacionado e do mesmo tipo da pk de outra tabela ou da mesma tabela.

41

TABELA usuario

Nome Tipo Descrição Chave

codigo N(4) Código do usuário PK

nome V(50) Nome usuário

codgrupousuario N(4) Código grupo FK

usuario V(15) Login de acesso

senha V(10) Senha de acesso

email V(100) E-mail

situacao V(1) Situação do cadastro do usuário

sugestao N(5) Quantidade sugestões de melhorias feitas pelo usuário

naoconformidade N(5) Quantidade não conformidades feitas pelo usuário

itemverificacao N(5) Quantidade de itens feitos pelo usuário

Quadro 9 – Dicionário de Dados da tabela usuário

TABELA grupousuario


codigo N(4) Código do grupo PK

funcao V(50) Função do usuário

observacao V(1024) Observações

situacao V(1) Situação

cadastros V(1) Acesso às telas de cadastros (S/N)

consultas V(1) Acesso às telas de consultas (S/N)

relatorios V(1) Acesso às telas de relatórios (S/N)

revisao V(1) Acesso às telas de revisão (S/N)

Quadro 10 – Dicionário de Dados da tabela grupousuário

TABELA grupoverificacao


codigo N(4) Código do grupo PK

descricaoabrev V(50) Descrição abreviada

descricao V(100) Descrição completa


Quadro 11 – Dicionário de Dados da tabela grupoverificacao

TABELA itemverificacao


codigo N(4) Código do item PK




42

codgrupoitem N(4) Código do grupo do item FK

localizacao V(50) Localização do item


datageracao Date Data geração do item

horageracao Time Hora geração do item

usuariogeracao N(4) Usuário gerador do item

dataalteracao Date Data da alteração do item

horaalteracao Time Hora da alteração do item

usuarioalteracao N(4) Usuário que alterou o item

Quadro 12 – Dicionário de Dados da tabela itemverificacao

TABELA sugestaomelhoria


codigo N(4) Código da sugestão de melhoria PK

codtarefa N(4) Código da tarefa FK

seqrevisao N(4) Seqüência da revisão

coditem N(4) Código do item de verificação

seqsugmelhoria N(4) Seqüência da sugestão de melhoria


localizacao V(50) Local onde o autor deve fazer a sugestão

situacaoenc V(1024) Situação encontrada pelo revisor


solucaoprop V(1024) Solução proposta pelo revisor

situacao V(1) Situação da sugestão

naoimplementado V(1024) Descrever o não uso da sugestão

datageracao Date Data geração da sugestão

horageracao Time Hora geração da sugestão

usuariogeracao N(4) Usuário gerador da sugestão

dataalteracao Date Data da alteração da sugestão

horaalteracao Time Hora da alteração da sugestão

usuarioalteracao N(4) Usuário que alterou a sugestão

Quadro 13 – Dicionário de Dados da tabela sugestaomelhoria

TABELA naoconformidade


codigo N(4) Código da não conformidade PK

codtarefa N(4) Código da tarefa


coditem N(4) Código do item de verificação FK

seqnaoconf N(4) Seqüência da não conformidade

43


localizacao V(50) Local onde o autor deve fazer a não conformidade

situacaoenc V(1024) Situação encontrada pelo revisor

descricao V(100) Descrição

solucaoprop V(1024) Solução proposta pelo revisor


codtipodefeito N(4) Código do tipo do defeito FK

prioridade V(1) Classificação da não conformidade

naoimplementado V(1024) Descrever a não utilização da não conformidade

datageracao Date Data geração da não conformidade

horageracao Time Hora geração da não conformidade

usuariogeracao N(4) Usuário gerador da não conformidade

dataalteracao Date Data da alteração da não conformidade

horaalteracao Time Hora da alteração da não conformidade

usuarioalteracao N(4) Usuário que alterou a não conformidade

Quadro 14 – Dicionário de Dados da tabela naoconformidade

TABELA revisoes


codigo N(4) Código da revisão PK

tarefa N(4) Código da tarefa FK


itemverificacao V(1) Código do item de verificação FK

respostaitem V(1) Resposta do item de verificação



Quadro 15 – Dicionário de Dados da tabela revisoes

TABELA tipodefeito


codigo N(4) Código dos tipos de defeitos PK




Quadro 16 – Dicionário de Dados da tabela tipodefeito

TABELA tarefarevisao


codigo N(4) Código da tarefa para revisão PK

codtarefa N(4) Código da tarefa

44

titulo V(50) Título da Tarefa


autor V(50) Autor dos artefatos a serem revisados

aberturatarefa Date Data abertura da tarefa

fechamentotarefa Date Data fechamento da tarefa

vencimento Date Data vencimento da revisão

aberturarevisao Date Data abertura da revisão

fechamentorevisao Date Data fechamento da revisão

gestao V(50) Gestão do sistema Sapiens

area V(50) Área do sistema Sapiens

caminho V(100) Local onde estão os fontes do sistema

versao V(50) Versão atual do sistema Sapiens

versaoliberacao V(50) Versão sistema Sapiens liberado para cliente

fontes V(100) Fontes do artefato a ser revisado

banco V(50) Dados referente ao banco utilizado nos artefatos

codrevisor N(4) Código do usuário FK

prioridade V(1) Prioridade da tarefa da revisão


Quadro 17 – Dicionário de Dados da tabela tarefarevisao

33..33 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO

A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

implementação.

3.3.1 Técnicas e ferramentas utilizadas

Para a implementação do sistema, foi utilizada a ferramenta Delphi 7 Enterprise da

empresa Borland, pois é uma ferramenta que auxilia no desenvolvimento do software com seu

conjunto de ferramentas integradas e a linguagem Object Pascal. Como banco de dados do

sistema desenvolvido, optou-se por utilizar o MySQL5.5.8 e para gerenciá-lo, foi utilizada a

ferramenta MySQL-Front, conforme apresentado na Figura 15.

45

Figura 15 – Tabelas visualizadas no MySQL-Front

3.3.2 Operacionalidade da implementação

A operacionalidade do sistema é inicialmente apresentada pela tela de login, onde o

usuário do sistema deve preencher o campo de usuário e senha, como é apresentado na figura

16. Se o usuário esquecer sua senha, o sistema permite o reenvio da senha no seu e-mail de

trabalho, conforme procedem todos os outros sistemas que a empresa utiliza. Para isso, o

usuário deve clicar na opção de “Esqueceu a Senha?” e digitar seu usuário e e-mail.

Figura 16 – Tela de login do sistema

46

Após a realização do login no sistema, todo usuário é direcionado para tela inicial,

porém os acessos são mais restritos quando o usuário for revisor ou autor. Na figura 17

apresenta-se o menu principal logado por um usuário analista (administrador). Isto pode ser

visto pela descrição no rodapé da tela. Para que o usuário não perca tempo procurando as

opções que deve acessar, o sistema permite diversas maneiras de acesso às telas:

a) ícones: localizados na parte superior da tela principal, demonstram a sua

importância pelo seu grande destaque, são as telas mais acessadas pelo usuário;

b) menu: para acessar uma tela por um perfil mais organizado, existe o menu que

separa cadastros, revisões e relatórios;

c) pop-up menu: com o clique do botão direito é possível acessar a tela que desejar,

seguindo a mesma organização do menu.

Figura 17 – Menu principal do sistema

A opção sair permite apenas sair do sistema. Se o usuário desejar trocar de usuário,

existe a opção “Trocar Usuário”, onde a tela de login é novamente apresentada.

Ainda na tela principal é apresentada uma listagem com todas as revisões ou tarefas

efetuadas pelo usuário, que podem ser ordenadas por Tarefa, Versão, Liberação ou Revisor.

Ou também podem ser listadas definindo sua data ou situação. O analista possui todas essas

47

opções ativas para utilizar, e visualiza todas as revisões do sistema. O revisor apenas visualiza

as suas revisões e as suas tarefas (quando efetuar o papel de autor), e o usuário só visualiza as

suas tarefas que estão passando por revisões. As informações que são apresentadas na

consulta são: a Tarefa, o Título da Tarefa, o Revisor, a Abertura da Revisão, o Vencimento da

Revisão, a Versão, a Versão de Liberação e a Situação da Revisão.

No menu superior da tela da tela principal do sistema encontra-se primeiramente, da

esquerda para a direita, o menu Cadastros. Através deste é possível realizar a manutenção das

telas essenciais para o funcionamento do sistema, como demonstrado na figura 18 onde é

apresentado o cadastro de grupos de usuários. Nesta tela apenas o analista realiza a inclusão

de novos grupos, alterações ou exclusões de grupos já existentes. Normalmente cada grupo

possui seus acessos distintos, que podem ser o de Cadastro, a Revisão, os Relatórios e as

Consultas. Quando o grupo não possuir mais relevância em certo momento, é possível apenas

desativá-lo, permitindo sua ativação em outra ocasião.

Figura 18 – Manutenção de Grupos de Usuários

Todas as telas do menu cadastros permitem incluir, alterar, excluir o seu registro,

conforme definição a seguir:

a) botão “OK”: confirma o registro apresentado em tela;

b) botão “NOVO”: limpa todos os campos e carrega na tela o próximo código a ser

registrado;

48

c) botão “CANCELAR”: possui a mesma funcionalidade do botão “novo”;

d) botão “SAIR”: a tela apresentada é fechada e o usuário volta no menu principal;

e) botão “EXCLUIR”: antes de excluir algum registro, o sistema sempre verifica se

existem dependências desta informação com outro cadastro, em caso afirmativo,

uma mensagem de “Registro vinculado” é apresentado abortando a exclusão;

f) campo “SITUAÇÃO”: todos os cadastros possuem a opção de ativar ou desativar

o seu registro.

A navegação pelos campos de todas as telas do sistema pode ser acompanhada

observando a barra de status localizada no canto inferior de cada tela. A cada campo

posicionado aparece a sua descrição e o estado que o registro está no momento, que só podem

ser dois a Edição ou a Inclusão.

O sistema também possui uma rotina que opera em todas as telas que é a verificação de

campos obrigatórios. Nenhuma ação de alteração ou inclusão é sucedida enquanto todos os

campos (particulares de cada tela) estejam preenchidos. No apêndice B, é possível visualizar

parte do código fonte onde é feita esta verificação.

Na tela de manutenção de usuários apenas o analista possui acesso, e as informações

apresentadas serão usadas no processo de revisão, por isso, existe a obrigação de todo o seu

preenchimento. Quando o analista efetuar a inclusão de um novo usuário, é solicitada sempre

a confirmação da senha informada. Se a mesma não for idêntica, o sistema exibe a mensagem

comunicando essa diferença. Ainda nesta tela, o usuário deve ser associado com seu

respectivo grupo, conforme demonstra a figura 19.

Figura 19 – Manutenção de Usuários

49

Na tela de manutenção de grupos de itens de verificação, tanto analista como revisor

podem efetuar cadastros, pois são informações que ambos possuem conhecimento e podem

controlar. Esse grupo define o assunto que vai tratar o item de verificação, que será sugestivo

e prático na hora de efetuar o checklist na revisão. A tela referida é apresentada na figura 20.

Figura 20 – Manutenção de Grupo de Itens

Assim também na tela demonstrada na figura 21, analista e revisor podem controlar a

manutenção dos itens de verificação, que são perguntas ou afirmações simples e diretas onde

o usuário possa ler e interpretar o que está sendo analisado com facilidade. Esses itens são

listados depois no relatório de revisão por isso recomenda-se que seja breve e objetivo. Se

existem mais detalhes, que sejam descritos no campo de observação onde o revisor pode

consultar caso apresentar dúvidas quanto à questão. Os itens devem ser informados de modo

que a resposta correta e esperada seja “S”, e que quando o artefato está fora do esperado, a

resposta seja “N”.

O campo de localização refere-se ao conteúdo dos itens que possuem mais

informações ou arquivos que ás vezes existe a necessidade de consultar, o botão com a

imagem de uma pasta já facilita o preenchimento do mesmo. Algumas rotinas, funções ou

processos que já são modelos na empresa e que devem ser seguidos são exemplos deste

preenchimento. Como a empresa deseja que a equipe siga um padrão de desenvolvimento, é

necessário que todos concordem com os itens definidos na revisão, e para isso, a cada item

cadastrado ou alterado, são registrados o usuário logado, a data e a hora para controle. Se

alguma inclusão ou alteração inadequada ocorrer, existe a possibilidade de entrar em consenso

com o usuário que realizou tal ação.

50

Figura 21 – Manutenção de Itens de Verificação

A manutenção de tipos de defeitos é apresentada na figura 22, onde apenas o analista

possui acesso. Cada não conformidade identificada numa revisão deve ser devidamente

categorizada conforme a falha encontrada. Essa ação permite uma visão mais clara ao

gerenciar o processo de revisão por pares, pois permite identificar onde a equipe tem mais

dificuldade em produzir seus artefatos e como proceder.

Figura 22 – Manutenção de tipos de defeitos

51

O próximo item do menu a Revisão, possui o cadastro de tarefas para revisão, que é

realizado somente pelo analista através da tela demonstrada na figura 23. O analista verifica

no sistema Help-Desk da empresa as tarefas que necessitam de revisões por pares, utilizando

os critérios que achar relevante para o módulo que trabalha, e depois disso, loga no sistema

proposto neste trabalho.

Acessa a tela de cadastro de revisão, preenchendo o campo “Tarefa 0800net” a tarefa

escolhida para o processo. Ao pressionar a tecla “TAB” automaticamente o sistema carrega os

demais campos com as informações necessárias para realizar uma revisão, sendo necessário

apenas preencher a data de vencimento e o revisor responsável.

Figura 23 – Cadastro de Tarefas de Revisão

Caso o autor dessa tarefa não possua cadastro no sistema, um alerta é acionado

solicitando o cadastramento do mesmo. Se o autor da tarefa é a mesma pessoa que vai realizar

a revisão, um alerta também é acionado não permitindo a inclusão deste registro, conforme

apresentado na Figura 24.

52

Figura 24 – Alerta de negação de cadastro de autor e revisor iguais

Esta é a tela de cadastramento de tarefas de revisão. Isto porque o analista está ciente

que determinada tarefa necessita passar pelo processo. As demais ações de alteração e

exclusão são feitas na própria tela de revisão, adaptada para esses tipos de operacionalidade.

Na codificação da tela de cadastro de tarefas de revisão, encontra-se a conexão

realizada com o sistema de help-desk que a empresa utiliza. No evento “OnExit” do campo

“Tarefa 0800net”, a função informada na figura 25 é acionada, carregando todas as

informações referente ao código passado como parâmetro. Caso a tarefa informada não seja

localizada, uma mensagem de alerta é apresentada solicitando para redigir um código válido.

É possível verificar que no select apresentado são efetuados muitos filtros, dentre eles

destaca-se o filtro que retorna somente as tarefas que se destinam ao produto Sapiens (linha

20) e que sejam nativas de tarefas de implementação ou erro (linha 21).

53

Figura 25 – Trecho de código que retorna as informações do sistema help-desk

É de relevância citar que essa conexão apenas será bem sucedida quando o sistema

estiver conectado a rede interna da empresa, conforme procedem as demais aplicações que

utiliza.

Ao realizar a inserção deste registro, a tarefa é gravada na tabela “tarefarevisao” com a

situação de “ABERTA”. Isto porque o revisor responsável não efetuou nenhuma revisão e

está pendente para o processo. Automaticamente após o registro ou alteração de qualquer

informação referente a tarefas, a grid de consulta apresentada na tela principal do sistema é

atualizada e apresenta os dados para o usuário logado (informações conforme o perfil

permite).

Para cada tela do sistema existe a possibilidade de consultar os dados quando existir o

botão de consulta, caracterizado pelo desenho de uma lupa. A informação que está presente

no campo ao lado do botão é que define os dados que serão apresentados na tela de consulta,

conforme demonstrado de exemplo à figura 26.

54

Figura 26 – Exemplo de chamada de consulta

Sendo assim essa tela é genérica para qualquer consulta e usuário, o layout sempre será

o mesmo e os dados serão apresentados conforme o assunto relacionado, como é possível

observar na figura 27.

Figura 27 – Tela genérica de consultas – consulta simples

A tela apresenta duas opções de consulta (simples e avançada), conforme o campo de

cada tabela, ou seja, todos os campos da tabela do registro em questão são apresentados num

campo de seleção, assim a consulta não fica limitada a apenas alguns filtros. O usuário neste

caso pode procurar um valor ou ordenar uma consulta conforme o campo selecionado, e

também pode definir a posição que o valor se encontra, como: “que contenha”, “terminado

por”, conforme demonstra a figura 28.

55

Figura 28 – Tela genérica de consultas – consulta avançada

A tela de revisões apresentada na figura 29 é a principal tela do sistema. Ela pode ser

acessada além dos acessos já descritos, também ao clicar duas vezes sobre a grid de consulta

na tela principal, apresentando como título da tela, o número da tarefa selecionado.

Esta tela opera de maneiras diferentes quando se trata do perfil logado e a situação que

se encontra a revisão, que podem ser:

a) aberta: a tarefa de revisão ou uma nova revisão foi criada, tarefas não possuem

limite de seqüências de revisão;

b) pendente revisor: já houve alguma alteração pelo revisor na seqüência de revisão

pendente, porém, o mesmo ainda não finalizou a análise. A tarefa também recebe

essa situação quando a revisão foi realizada pelo revisor, repassada para o autor

corrigir seus artefatos, e este por sua vez, passou a revisão novamente para o

revisor avaliar suas alterações. Este processo cria automaticamente uma nova

seqüência de revisão e deixa a tarefa como “pendente revisor”;

c) pendente autor: a revisão depois de avaliada e fechada pelo revisor, atualiza a

situação da tarefa para “pendente autor”, aguardando sua verificação;

56

d) fechada: a tarefa é encerrada apenas quando não existir nenhum item da última

revisão com resposta “N”, e quem finaliza é o autor, pois sempre deve receber o

retorno das análises realizadas.

Figura 29 – Tela de manutenção da revisão

Ao preencher o número da tarefa no campo “código”, automaticamente as informações

referentes a essa tarefa são carregadas num painel que apenas é apresentado quando o botão

“Tarefa” estiver pressionado. São informações como: gestão da tarefa, vencimento, versão

entre outros, e quando o analista for o usuário logado e a tarefa selecionada ainda está com a

situação aberta, é possível alterar o revisor através do botão “Alterar Revisor”, conforme é

possível observar na figura 30.

57

Figura 30 – Painel de informações adicionais da tarefa

Como uma tarefa possui várias seqüências de revisão, o campo de seleção “revisão” é

que vai determinar a análise apresentada no momento, juntamente com sua situação e sempre

carregando a primeira seqüência. Após a criação da tarefa, quando o analista ou revisor

acessar essa tela, terá disponível todas às opções necessárias para efetuar a revisão, o autor se

acessar a mesma tarefa, essas opções estarão indisponíveis, conforme demonstra a Figura 31.

Enquanto a tarefa estiver aberta, sem nenhum item revisado, apresentando somente a primeira

seqüência da revisão, o analista pode excluir a revisão através do botão “Exclui Revisão”, mas

se a revisão já foi iniciada com a gravação de algum registro, ou já possui mais seqüências de

revisões e o usuário logado não é analista, a exclusão não será permitida.

58

Figura 31 – Tela de revisão com limitações para o autor

O revisor inicia a análise incluindo um grupo de itens para efetuar o checklist. Para

navegar entre os itens deve pressionar as setas de esquerda e direita, e para navegar entre os

grupos de itens, deve pressionar as setas da esquerda e da direita que estão abaixo do campo

de grupos. Toda vez que o botão da seta for pressionado e não tiver mais itens, o botão ficará

desabilitado e um alerta informando o fim dos itens é apresentado. O usuário pode

acompanhar esse progresso entre os itens observando a situação “Questão 1 de 3” e pode

responder três possíveis respostas Sim, Não e Não se Aplica (nem sempre todos os itens que

existem em determinado grupo se referem exatamente ao conteúdo do artefato analisado).

Se houver a necessidade de excluir um grupo de itens, essa ação será apenas permitida

se a seqüência de revisão apresentada no momento não está fechada e não existem não

conformidades ou sugestões de melhoria cadastrada.

59

Enquanto o revisor está efetuando a análise do artefato ou até mesmo depois que a

revisão estiver fechada, pressionando o botão de “Visualizar” um relatório da situação atual

da revisão é apresentado, conforme demonstra a figura 32.

Figura 32 – Relatório de visualização da revisão

Ao perceber que a codificação do artefato não está de acordo com o que sugere os itens

ou ainda, a codificação precisa de algumas melhorias, é possível cadastrar não conformidades

ou sugestões de melhorias conforme demonstra as figuras 33 e 34. Apenas revisor e analista

efetuam esse processo, e é muito importante ambos expressarem objetividade ao utilizarem

desse recurso. A solução proposta deve ser descrita de tal forma que autor compreenda a

alteração que deve ser feita, evitando a criação de novas revisões em função da má

comunicação entre as partes.

60

Figura 33 – Tela de manutenção de não conformidades

Figura 34 – Tela de manutenção de sugestões de melhoria

61

Para finalizar a revisão, o revisor deve pressionar o botão “finalizar revisão”, e assim a

seqüência de revisão é fechada e a tarefa passa a ter a situação de “Pendente Autor”. Tanto

analista como revisor não conseguem efetuar nenhuma alteração com a tarefa neste estado, o

autor então acessa a tela de revisão e verifica a análise feita sobre os seus artefatos.

Se houve sugestões de melhorias ou não conformidades, o autor deve acessar as

devidas telas e informar uma situação que pode ser “Utilizada” ou “Ignorada”, habilitando em

seguida o campo de justificação da negação. Esse controle é efetuado para fins gerenciais, não

adianta uma empresa possuir revisão por pares e não saber se o processo realmente tem obtido

sucesso, e se existem dificuldades, onde elas aparecem mais.

Finalizada a verificação dos artefatos com apoio da revisão, o autor envia de volta a

revisão através do botão “Volta Revisor”, e automaticamente uma nova seqüência de revisão

é gerada e a situação da tarefa atualiza com “Pendente Revisor”. Caso os itens não necessitem

mais de revisão, o autor pode fechar a tarefa através do botão “Finaliza Revisão”, encerrando

o ciclo de uma revisão por pares. Ação que apenas o autor pode executar após ter passado

uma situação a todas não conformidade ou sugestão de melhoria, caso contrário, um alerta é

apresentado na tela informando da pendência e rejeitando a finalização. Para revisões

fechadas, independente do usuário logado, as informações ficam em modo de consulta, sem

opção de excluir ou iniciar uma nova seqüência de revisão.

Para gerenciar todo esse processo de revisão, o analista (somente ele) emite relatórios

para acompanhar a equipe e ter conhecimento onde a qualidade do produto está precisando de

mais atenção, sendo assim é possível emitir cinco relatórios localizados no canto direito da

tela principal.

No relatório de revisões por período, o analista clica na opção de “Revisões Período”,

e seleciona um período para consultar as tarefas e outras informações durante esse intervalo,

demonstrado na figura 35. Ao clicar na opção de “Imprimir”, um relatório contendo as

mesmas informações é apresentado e com as opções de impressão no cabeçalho, conforme

Figura 36.

62

Figura 35 – Tela de consulta de revisões por período

Figura 36 – Relatório de revisões por período

No relatório que emite a listagem de itens de verificação é possível visualizar os itens

que o processo possui até o momento. Agrupado pelo grupo, cada item é apresentado

conforme seu código de cadastro. Quando o analista clicar na opção de “Itens Verificação”, é

apresentado o relatório conforme a Figura 37.

Figura 37 – Relatório de itens de Verificação

63

No relatório de não conformidades geradas mensalmente de cada gestão, o analista

clica na opção de “NC mensal”, e um relatório é apresentado listando a quantidade de não

conformidades geradas em cada gestão, conforme o tipo de defeito, sua prioridade e situação.

Através desses resultados o analista consegue verificar em que área a sua equipe está com

dificuldades e que tipos de erros ela normalmente comete, conforme demonstra a Figura 38.

Figura 38 – Relatório mensal de não conformidades por gestão

O Sistema Sapiens sempre está em manutenção e gerando novas versões para seus

clientes, e revisões são feitas durante o desenvolvimento de cada versão. Através do relatório

que pode ser acessado pela opção de “Revisões Versão”, é possível identificar em cada

gestão, que versão a revisão foi prevista para ser executada e em qual versão de liberação

deverá ser finalizada. A Figura 39 demonstra onde o usuário deve selecionar as versões, e a

Figura 40 demonstra o relatório emitido após clicar na opção de “Imprimir”.

Figura 39 – Seleção das versões para o relatório

64

Figura 40 – Relatório de revisões por versão

No relatório de sugestão de melhoria por período, o analista clica na opção de “SM

Período” e seleciona o período de datas que deseja visualizar as sugestões de melhoria,

conforme demonstra a Figura 41. Ao pressionar o botão de impressão, o relatório é emitido

apresentando a quantidade de sugestões geradas conforme cada gestão, informando se ela foi

utilizada e por qual usuário gerado, Figura 42. O analista tem conhecimento de quais pessoas

estão colaborando com mais sugestões e se elas realmente são utilizadas nas revisões.

Figura 41 – Seleção do período para o relatório

65

Figura 42 – Relatório de sugestões de melhoria por período

33..44 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO

O objetivo deste trabalho foi auxiliar o processo de revisão por pares da empresa

Senior Sistemas. Como a empresa já havia obtido o nível 3 do CMMI, as metodologias

propostas na área de verificação eram ideais para organizar o processo de revisão por pares no

presente trabalho, porém não abrange totalmente o software. O Quadro 18 demonstra algumas

relações do processo e do software com os objetivos na área de Verificação do CMMI.

Quadro 18 – Aderência ao CMMI

A meta de preparação para a verificação não é totalmente atendida pela ferramenta,

pois a prática de selecionar os artefatos já é realizada num processo anterior ainda no sistema

help-desk por um analista responsável de sua área. Após cadastrar uma tarefa para a revisão, a

ferramenta se torna o ambiente responsável em realizar a verificação do produto de software,

e através dos itens de verificação é possível estabelecer os seus procedimentos e critérios.

66

As etapas da inspeção que são similares ao de revisão por pares, a ferramenta atende

na grande parte do processo, conforme é apresentado no Quadro 19.

Quadro 19 – Aderência ao processo de revisão

Comparando com os trabalhos correlatos apresentados, Ebertz (2002) desenvolveu um

protótipo de apoio ao processo de verificação de softwares, que seria na análise de contratos,

requisitos, projetos entre outros, diferente da aplicação deste trabalho, que aplica a verificação

somente no processo de codificação do software. Porém, um fator em comum e importante

com o trabalho correlato, foi à necessidade de utilizar um checklist para a organização e

controle do processo.

Outro trabalho analisado foi o de Junckes (1999) com o processo de auditoria de

sistemas. Um sistema mais voltado para normas e auditorias dentro da empresa, mas com

objetivo comum a este trabalho: a melhoria da qualidade no processo seguindo as diretrizes de

um modelo de qualidade.

Filappi (2009) desenvolveu um modelo de avaliação de qualidade de abrangência mais

ampla, e comenta um pouco sobre a revisão por pares porém com uma visão mais aplicada em

empresas, muito parecido com o presente trabalho desenvolvido. A ferramenta web IBIS

estudada por Filappi também auxilia no processo de inspeção de software, porém a detecção

de defeitos é feito por tópicos de discussão e notificações por e-mail, diferente do presente

trabalho.

Durante o período de desenvolvimento do software, eram constantes as análises com

os principais responsáveis em adotar o processo de revisão por pares no setor. Como o

processo ainda não estava definido na empresa, muito estudo foi realizado sobre diferentes

modelos e métricas, sendo o CMMI o mais adequado com a empresa. Existia a necessidade de

um ambiente único que armazene as boas práticas de codificação, agilidade no ato de revisar e

definir não conformidade e sugestões de melhorias, e principalmente, permitir consultar e

extrair essas informações que antes estavam presas a tarefas e anexos.

Por fim, o sistema desenvolvido para a empresa Senior no setor do produto Sapiens,

pode ser facilmente integrado á estrutura atual sem alterações significativas, e ainda agregar

valor aos serviços oferecidos de maneira mais ágil e organizada.

67

4 CONCLUSÕES

De acordo com Boehm e Basili (2001), a melhoria da qualidade de um produto de

software é obtida quando se elimina as causas que geram os defeitos, e a redução destes

defeitos vem acompanhado da redução de custos e de re-trabalhos. Através da ferramenta

apresentada neste trabalho é possível identificar todos esses benefícios, pela disseminação do

conhecimento, a padronização alcançada, o gerenciamento e controle de informações e a

adoção de um processo com base em um modelo que já é aplicado na empresa, o CMMI.

O sistema desenvolvido automatizou um processo que antes era feito por meio de

planilhas e sem condições de ser gerenciado, permitiu organizar as atividades conforme o

nível do usuário com restrições de acesso, aumentando a segurança e principalmente a

organização dos dados. Como a empresa ainda estava procurando uma forma de realizar as

revisões no setor, algumas funcionalidades não fazem parte do sistema, como o cálculo de

métricas utilizando tempo de atividade entre os envolvidos. Este fato foi uma das dificuldades

apresentadas na definição de regras e atividades no sistema, e também pelo fato de não haver

um modelo de sistema que servi-se como exemplo na compreensão do processo de revisão

por pares.

O trabalho foi concluído com sucesso, atingindo todos os seus objetivos iniciais. Obter

um fluxo do processo de revisão capaz de definir onde inicia e termina as revisões, que foi

estruturado através das metas e práticas do CMMI. Disponibilidade de um checklist que

facilite as revisões, onde com os critérios de verificação e a extinção das planilhas Excel essa

situação foi obtida. Gerenciar e acompanhar as informações através de relatórios e consultas,

explorando o verdadeiro potencial que as revisões proporcionam, obtendo os resultados

esperados também na sua prática.

Os objetivos pessoais também foram alcançados. Conhecimento foi adquirido com o

pouco tempo para desenvolver uma aplicação, e obteve-se aprendizagem com novas técnicas

de programação e maior percepção na correção de defeitos. Além disso, o fato de documentar

todas as etapas do desenvolvimento com muito cuidado e precisão, algo que normalmente não

acontece no cotidiano de quem trabalha na área.

68

44..11 EEXXTTEENNSSÕÕEESS

O processo de revisão por pares pode ser gerenciado e praticado em diversas áreas no

desenvolvimento do produto de software. Neste trabalho, o sistema desenvolvido apenas

concentrou a atenção sobre a revisão na codificação de artefatos, no gerenciamento de um

padrão de boas práticas e a redução de defeitos através do controle de não conformidades e

sugestões de melhorias. Restrição também oriunda da empresa, que ainda está verificando

como implantar o processo dentro do setor e como cobrar resultados após a implantação.

Sendo assim, outras funcionalidades ou aperfeiçoamento das técnicas já presentes no

trabalho podem ser elaborados, como:

a) controle do tempo nas revisões: com esses dados seria possível gerenciar quantas

horas uma equipe ou funcionário gasta realizando esse processo;

b) adaptação para novos tipos de revisões e grupos de trabalho: inclusão da revisão de

documentações, por exemplo, assim a equipe da qualidade aproveitaria o mesmo

processo;

c) versão em ambiente web: o sistema desenvolvido poderia ser acessado em

ambiente web sem a necessidade de possuir o sistema operacional Windows

instalado;

d) abrangência nos itens de verificação: além de revisar a codificação dos fontes do

software, seria interessante a inclusão de revisões de regras de negócio. Porém,

necessitaria de mais uma classificação para os itens, que ainda seriam distintos

conforme a gestão selecionada;

e) anexar figuras e texto na revisão: o sistema desenvolvido poderia armazenar

diversas extensões de arquivo que seriam o artefato a ser revisado. O usuário neste

caso não precisaria procurar pelo material a ser revisado;

f) envio de instruções por e-mail: a cada revisão criada ou quando a situação da

mesma é alterada, o sistema poderia enviar um e-mail de alerta a pessoa envolvida.

69

REFERÊNCIAS BIBLIOGRÁFICAS

AGNOL, S. D.; HERBERT, J. S. Utilização do TSP para a gerência de equipes nível 2 do CMMI. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, São Paulo. Anais... São Leopoldo: ESICenter UNISINOS, 2004. p. 108-118.

AHERN, D.M; CLOUSE, A.; TURNER, R. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. 2. ed. Boston: Addison-Wesley, 2003.

BARTIÉ, A. Garantia da qualidade de software: adquirindo maturidade organizacional. Rio de Janeiro: Elsevier, 2002.

BOEHM, B. W.; BASILI, V.R. Software Defect Reduction Top 10 List, IEEE Computer 34 (1). Washington, D.C., 2001. p.135-137.

CHERNAK, Y. A Statistical Approach to the Inspection Checklist Formal Synthesis and Improvement: IEEE Transactions on Software Engineering 22(12). Washington, D.C., 1996. p.866-874.

CHRISSIS, M.B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003.

CIOLKOWSKI, M.; LAITENBERGER, O.; BIFFL, S. Software Reviews: the state of the practice. IEEE Software 20 (6). Washington, D.C., 2003. p. 46-51.

EBERTZ, I. C. Protótipo de apoio ao processo de verificação baseado na norma ISO/IEC 12207. 2002. 110 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

FAGAN, M. Advances in Software Inspection, IEEE Transactions on Software Engineering. Washington, D.C., v. SE-12, n. 7, Jul. 1976.

FILAPPI, É. Inspeções e revisões técnicas de software visando à minimização de defeitos em artefatos de desenvolvimento. 2009. 81 f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) – Centro Universitário Feevale, Novo Hamburgo.

FILHO, W. P. Engenharia de Software: fundamentos, métodos e padrões. 2. ed. Rio de Janeiro: LTC, 2005. p.373.

70

FURQUIM, T. A. Processos de revisão de software e a técnica wakthrough. Tematec, Brasília, n. 64, 2002. Disponível em: <http://www.serpro.gov.br/imprensa/publicacoes/tematec/2002/ttec64/>. Acesso em: 23 abr. 2011.

GUIMARAES, L. M.; ROSSI, A. C. Testes: uma abordagem para melhoria da qualidade do software. 2008. 163 f. Monografia de Especialização (Especialista em Engenharia Elétrica e Qualidade de Software) – Curso de Especialização em Engenharia Elétrica Área de Engenharia e Qualidade de Software, Universidade de Brasília, Faculdade de Tecnologia. Departamento de Engenharia Elétrica, Brasília.

IEEE. IEEE Standard Collection. Software Engineering. IEEE, New York, 1998.

JUNCKES, F. A. Software de apoio ao processo de auditoria segundo normas de qualidade. 1999. 76 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

LAITENBERGER, O.; ATKINSON, C. Generalized Perspective Based Inspection to handle Object Oriented Development Artifacts. Los Angeles: ICSE 99, 1998. p.494-503.

LANUBILE, F.; MALLARDO, T.; CALEFATO, F. Tool support for Geographically Dispersed Inspection Teams, Software Process Improvement and Practice. Wiley InterScience: 2003. p. 217-231.

MARTINS, E. Verificação Estática. Campinas, 2005. Disponível em: <http://www.ic.unicamp.br/~ranido/mc626/VerifEstatica.pdf/>. Acesso em: 01 maio 2011.

PANISSA, M. T. Qualidade de codificação e melhores práticas em .NET framework (Parte 1). MCP Brasil.com, São Paulo, abr. 2007. Disponível em: <http://www.mcpbrasil.com/integra.asp?id=186>. Acesso em: 14 jun. 2011.

PIRES, C.G. et al. Uma Arquitetura de Processos para ISO 9001:2000 e SWCMM Nível 3. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, São Paulo. Anais... São Leopoldo: ESICenter UNISINOS, 2004. Disponível em: <http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_18_Simpros2004.pdf>. Acesso em: 02 jun. 2011.

PRESSMAN, R. S. Engenharia de Software. 5. ed. São Paulo: Makron books, 1995.

SCHOEDER, M. A Practical Guide to Object-Oriented Metrics, IT Professional - IEEE, v.1, n.6, dez. 1999.

SENIOR SISTEMAS. Intranet da Senior, Blumenau, Dez. 2009. Disponível em: <http://webserver/intranet>. Acesso em: 22 maio 2011.

71

SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model Integration, CMMI® para desenvolvimento, versão 1.2. Carnigie Mellon. Campinas. abr. 2008. Tradução André Villas Boas e José Marcos Gonçalves. Disponível em: <http://www.mct.gov.br/upd_blob/0024/24396.pdf>. Acesso em: 09 maio 2011.

WIEGERS, K. E. Peer Reviews in Software: a pratical guide. London: Pearson Education, Inc, 2002. p.232.

WHEELER, D.A.; BRYKEZYNSKI, B.; MEESON, R.N. Software Inspections: An Industry Best Practice. Washington, D.C., IEEE Computer Society, 1996.

72

APÊNDICE A – Detalhamento dos casos de uso

No Quadro 20 apresenta-se o caso de uso "Manter revisão".

Nome do Caso de Uso UC03 – Manter revisão

Descrição Usuário acessa a aplicação e seleciona uma tarefa para efetuar a revisão.

Ator Usuário – analista ou revisor

Pré-condição Usuário deve fazer login no sistema.

Tarefa de revisão cadastrada na aplicação.

Aplicação conectada na rede interna da empresa.

Fluxo principal 1. Usuário informa o código da tarefa para efetuar a revisão.

2. O sistema apresenta os dados da tarefa.

3. Usuário informa o código do grupo de itens que deseja utilizar para a revisão.

4. O sistema apresenta os itens do grupo.

5. Usuário responde o questionário.

6. O sistema grava as respostas conforme o usuário navega pelos itens.

7. Usuário clica na opção de “FINALIZA REVISAO” e confirma a operação.

8. O sistema fecha a seqüência de revisão e deixa a tarefa com a situação de

“PENDENTE AUTOR”.

Cenário – Visualização No passo 2 do fluxo principal, o usuário opta por visualizar a revisão atual.

1. Usuário clica na opção de “VISUALIZAR”.

2. Sistema mostra os dados da tarefa e da revisão atualmente cadastradas no

sistema.

Cenário – Edição No passo 2 do fluxo principal, o usuário opta por editar a revisão.

1. Usuário altera registro;

2. Sistema valida as informações digitadas pelo Usuário;

3. Sistema persiste os dados no banco de dados;

Cenário – Exclusão do

grupo de itens.

No passo 6 do fluxo principal, o usuário opta por excluir o grupo de itens da

revisão.

1. Usuário clica na opção de “EXCLUI GRUPO” e confirma a exclusão.

2. Sistema exclui o grupo selecionado.

Fluxo Alternativo 1. No passo 2 do fluxo principal, caso a tarefa já tenha uma seqüência de tarefa

cadastrada, o usuário deverá selecionar a seqüência de revisão que deseja realizar a

manutenção.

2. No passo 2 do fluxo principal, caso a seqüência de tarefa esteja com a situação de

“FECHADA”, todas as operações estarão indisponíveis para realizar qualquer

alteração.’

3. No passo 6 do fluxo principal, caso o usuário deseja incluir uma não

73

conformidade, deve clicar na opção de “Não Conf.”.

4. No passo 6 do fluxo principal, caso o usuário deseja incluir uma sugestão de

melhoria, deve clicar na opção de “Sug. Melhoria.”.

5. No passo 1 do fluxo principal, usuário pode clicar na opção de consultar a tarefa

desejada.

6. No passo 3 do fluxo principal, usuário pode clicar na opção de consultar o grupo

de itens desejado.

Cenário - Exceção No passo 1 do fluxo principal, caso a tarefa digitada não exista no sistema,

apresenta mensagem (“Tarefa selecionada não encontrada!”).

No passo 6 do fluxo principal, caso o usuário não tenha respondido a questão,

sistema apresenta a mensagem (“É necessário responder o questionário”).

No passo 3 do fluxo principal, caso o grupo não possui itens de verificação, sistema

apresenta a mensagem (“Grupo selecionado não possui itens de verificação!”).

No passo 3 e 4 do fluxo alternativo, caso o usuário não tenha selecionado um item e

respondido, ocorre a mensagem (“É necessário selecionar e responder um item!”).

Pós-condição Usuário visualizou, alterou dados da revisão.

Quadro 20 – Descrição do caso de uso Manter revisão

No Quadro 21 apresenta-se o caso de uso "Manter sugestões de melhoria".

Nome do Caso de Uso UC06 – Manter sugestões de melhoria

Descrição Usuário acessa uma Sugestão de Melhoria.

Ator Usuário

Pré-condição Usuário deve fazer login no sistema.


Fluxo principal -

Sugestões

1. Sistema apresenta as sugestões de melhoria cadastradas.

2. Usuário opta por localizar o registro da sugestão de melhoria;

3. Usuário seleciona a opção de pesquisa(número da sugestão) e informa os dados

para a pesquisa.

4. O sistema apresenta os dados da sugestão relacionada com a consulta.

5. Usuário opta por uma operação ou encerra o caso de uso.

Cenário – Inclusão No passo 2 do fluxo principal, o usuário opta por incluir uma sugestão de melhoria.

1. Usuário informa os dados de uma nova sugestão de melhoria.

2. O sistema valida as informações.

3. O sistema grava as informações.

Cenário – Edição No passo 4 do fluxo principal, o usuário opta por editar uma sugestão de melhoria.

1. Usuário seleciona um registro para edição.

2. O sistema apresenta os dados para alteração.

3. Usuário edita os dados e confirma a operação.

74

4. O sistema altera os dados da sugestão de melhoria.

Cenário – Exclusão No passo 4 do fluxo principal, o usuário opta por excluir uma sugestão de melhoria.

1. Usuário seleciona um registro para exclusão.

2. O sistema apresenta os dados para exclusão.

3. Usuário seleciona a opção de “EXCLUIR” e confirma a operação.

4. O sistema exclui a sugestão de melhoria.

Cenário – Exceção No passo 3 do Cenário - Inclusão, se algum dos campos obrigatórios não forem

informados, o sistema exibe o nome do campo que falta informar.

Pós-condição Usuário consultou, editou, apagou ou cadastrou uma sugestão de melhoria.

Quadro 21 – Descrição do caso de uso Manter sugestões de melhoria

No Quadro 22 apresenta-se o caso de uso "Manter tarefa de revisão".

Nome do Caso de Uso UC07 – Manter tarefa de revisão

Descrição Usuário acessa a aplicação e seleciona uma tarefa de revisão.

Ator Usuário – analista

Pré-condição Usuário deve fazer login na aplicação.

Tarefa de revisão cadastrada no sistema help-desk da empresa.


Fluxo principal –

Inclusão

1. Usuário acessa a tela de “Tarefa para Revisão” e informa o código de uma

tarefa

2. O sistema apresenta os dados da tarefa informada, conforme consulta que a

aplicação realiza na base de dados do sistema help-desk.

3. Usuário informa data de vencimento da revisão;

4. Usuário informa o código do revisor responsável pela revisão.

5. O sistema apresenta os dados do revisor.

6. Usuário clica na opção de “GERAR REVISAO” e confirma a operação.

7. Sistema apresenta a mensagem “Tarefa cadastrada com sucesso para revisão”.

Cenário – Exclusão No passo 7 do fluxo principal, o usuário opta por excluir a tarefa recém gerada.

1. Usuário acessa a tela de “Revisão para Tarefa”, e informa o código da tarefa de

revisão.

2. O sistema apresenta os dados da tarefa informada.

3. Usuário clica na opção de “EXCLUI REVISÃO” e confirma a operação.

4. Sistema exclui a tarefa selecionada.

75

Cenário – Alterar Revisor No passo 7 do fluxo principal, o usuário opta por alterar o revisor da tarefa.

1. Usuário acessa a tela de “Revisão para Tarefa” e informa o código de uma tarefa.

2. O sistema apresenta os dados da tarefa informada.

3. Usuário clica na opção de “TAREFA” e visualiza as informações da tarefa.

4. Usuário informa o novo código do revisor.

5. O sistema apresenta os dados do revisor.

6. Usuário clica na opção de “ALTERAR REVISOR” e confirma a operação.

7. Sistema grava o registro e mostra o registro alterado.

Fluxo Alternativo No passo 4 do fluxo principal, e no passo 4 do cenário de Alterar Revisor, usuário

pode clicar na opção de consultar o revisor desejado.

No passo 1 do cenário exclusão, e no passo 1 do cenário de Alterar Revisor, usuário

pode clicar na opção de consultar a tarefa para revisão.

Cenário – Exceção No passo 1 do fluxo principal, caso a tarefa digitada não exista no sistema help-desk

da empresa, apresenta mensagem (“Tarefa digitada não encontrada!”).

No passo 5 do fluxo principal e no passo 6 do cenário alteração, caso o revisor for

igual ao autor, apresenta a mensagem (“Revisor selecionado igual ao Autor”).

No passo 6 do fluxo principal, se algum dos campos obrigatórios não forem

informados, o sistema exibe o nome do campo que falta informar.

No passo 3 do Cenário – Exclusão, caso a tarefa selecionada já possui registros de

revisão, o sistema apresenta a mensagem: “Tarefa não pode ser excluída pois já foi

iniciada ou concluída.”. Sistema volta ao passo 2.

Pós-condição Usuário editou o revisor, apagou ou cadastrou uma tarefa para revisão.

Quadro 22 – Descrição do caso de uso Manter tarefa de revisão.

76

APÊNDICE B – Validação dos Campos Obrigatórios

A Figura 43 apresenta trecho da validação dos campos obrigatórios utilizado em todas

as telas através de uma função genérica.

Figura 43 – Trecho do código fonte tratando campos obrigatórios

77

ANEXO A – Planilha de CheckList

O Quadro 23 apresenta uma parte da planilha de Excel utilizada pela equipe de

desenvolvimento para efetuar a revisão.

Quadro 23 – Planilha Excel utilizada para checklist

78

ANEXO B – Sugestões de Melhorias em documento anexado

A Figura 44 apresenta um documento de sugestão de melhoria que era anexado na

tarefa de revisão do sistema help-desk.

Figura 44 – Documento de sugestão de melhoria

SOFTWARE DE APOIO AO PROCESSO DE REVISÃO POR...

Documents

Transcript of SOFTWARE DE APOIO AO PROCESSO DE REVISÃO POR...