G4 - Atividade Prática 4

Prévia do material em texto

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS 
DEPARTAMENTO DE COMPUTAÇÃO 
 
Amanda Kelly Rodrigues Cândido 
Gabriel Teixeira Andrade Sousa 
Giovanna de Sousa Sampaio 
Giulianni dos Santos Oliveira 
Gustavo Gomes Cardozo dos Santos 
 
G4 – Atividade Prática 4 
 
 
 
 
 
 
 
André Luiz Alves 
 
 
 
 
 
 
 
 
 
 
GOIÂNIA, 
2020 
Amanda Kelly Rodrigues Cândido 
Gabriel Teixeira Andrade Sousa 
Giovanna de Sousa Sampaio 
Giulianni dos Santos Oliveira 
Gustavo Gomes Cardozo dos Santos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
G4 – Atividade Prática 4 
Relatório apresentado como requisito parcial 
para obtenção de aprovação na disciplina 
Validação e Testes de Sistemas no Curso de 
Engenharia da Computação, na Pontifícia 
Universidade Católica de Goiás. 
André Luiz Alves 
 
 
 
 
 
 
 
GOIÂNIA, 
2020 
Sumário 
1. INTRODUÇÃO ...................................................................................................... 4 
2. PROPÓSITO ........................................................................................................... 4 
3. DOCUMENTOS DE REFERÊNCIA ................................................................... 4 
4. GERENCIAMENTO ............................................................................................. 4 
4.1. Organização ....................................................................................................... 4 
4.2. Tarefas ............................................................................................................... 4 
4.3. Regras e responsabilidades ................................................................................ 5 
4.4. Recursos de garantia de qualidade estimados .................................................... 5 
5. DOCUMENTAÇÃO ............................................................................................... 5 
5.1. Propósito ............................................................................................................ 5 
5.2. Requisitos mínimos de documentação ............................................................... 5 
5.3. Padrões, práticas, convenções e métricas .......................................................... 6 
5.3.1 Propósito ..................................................................................................... 6 
5.3.2 Conteúdo ..................................................................................................... 6 
5.4. Revisões de Softwares ....................................................................................... 6 
5.4.1 Propósito ..................................................................................................... 6 
5.4.2 Requisitos mínimos .................................................................................... 7 
5.5. Teste ................................................................................................................... 8 
5.6. Relatório de problemas e ação corretiva ............................................................ 8 
5.7. Ferramentas, técnicas e metodologias ............................................................... 8 
5.8. Controle de mídia ............................................................................................... 8 
5.9. Controle de fornecedores ................................................................................... 9 
5.10. Coleção de registros, manutenção e retenção................................................. 9 
5.11. Treinamento (seção 13 do SQAP) .................................................................. 9 
5.12. Gerenciamento de riscos ................................................................................ 9 
5.13. Glossário......................................................................................................... 9 
5.14. Procedimento e histórico de alterações do PGQS .......................................... 9 
6. Documentos de Requisitos ................................................................................... 10 
7. Checklist ................................................................................................................ 11 
7.1. Requisitos Funcionais ...................................................................................... 11 
7.2. Requisitos não funcionais ................................................................................ 12 
8. Matriz Rastreabilidade ........................................................................................ 12 
9. Casos de uso .......................................................................................................... 13 
10. Checklist dos casos de uso ................................................................................. 14 
11. Diagrama de classe de Análise .......................................................................... 15 
12. Checklist do diagrama de classe de análise ..................................................... 16 
 
1. INTRODUÇÃO 
Este documento apresenta o plano de garantia de qualidade de Software (PGQS). 
Tal plano, compreende os processos, técnicas e ferramentas que são empregados para 
assegurar-se que um produto ou serviço, está alinhado com os requisitos definidos no 
documento de especificação de requisitos. 
As etapas do plano estão dispostas em seções ordenadas, que compreendem todo 
o processo para validar e verificar os produtos de softwares e garantir sua qualidade. 
2. PROPÓSITO 
Essa seção deve delinear o propósito específico e escopo do PGQS em particular, 
deste modo ele deve: 
● Listar o nome dos itens de software abordados pelo PGQS e uso pretendido 
do software; 
● Especificar a porção do ciclo de vida do software abordado pelo PGQS para 
cada item de software especificado; 
3. DOCUMENTOS DE REFERÊNCIA 
Essa seção deve listar os documentos utilizados como referência para a elaboração 
do PGQS. Deste modo, podem ser listados leis, normas ou outros planos utilizados como 
referência para a elaboração deste. 
4. GERENCIAMENTO 
 
Esta seção deve descrever a organização do projeto, isso inclui os seguintes 
pontos: 
● Organização; 
● Tarefas; 
● Estrutura; 
● Regras e Responsabilidades; 
 
4.1. Organização 
Essa seção deve descrever a estrutura organizacional que influencia e controla a 
qualidade do software. Deste modo, deve incluir uma descrição de cada elemento 
principal da organização junto com as regras e responsabilidades delegadas. 
 
4.2. Tarefas 
 
Essa seção deve descrever os seguintes pontos: 
 
• Que porção do ciclo de vida do software o PGQS cobriu; 
• As tarefas para serem realizadas; 
• Os critérios de entradas e saídas para cada Tarefa; 
• As relações entre essas tarefas e os principais pontos de checagem planejados. 
• As sequências e relacionamentos de tarefas, como também, seus relacionamentos 
para com o plano de gerência do projeto, deve ser indicado. 
 
4.3. Regras e responsabilidades 
Identificar o elemento organizacional específico que é responsável por realizar 
cada tarefa. 
O plano de garantia de software é responsável por garantir conformidades do 
documento com os requisitos. Tal documento, avalia a qualidade do software entregável 
da documentação, softwares não entregáveis e a engenharia de processos usadas para 
produzir o software. 
 
4.4. Recursos de garantia de qualidade estimados 
 
Estimativa de recursos e de custo que serão expendidos na garantia de qualidade 
e nas tarefas de controle de qualidade. 
5. DOCUMENTAÇÃO 
5.1. Propósito 
 Essa seção deve realizar as seguintes funções: 
a) Identificar a documentação administrativa o desenvolvimento, verificação e 
validação, uso e manutenções do software; 
b) Listar quais documentos irão ser revisados e auditados para a adequação. 
Deste modo, para cada documento listado, se deve ter os seguintes pontos: 
▪ Identificar a revisão ou auditoria para ser conduzida;▪ Identificar o critério pelo qual a adequação o documento 
será considerado adequado; 
5.2. Requisitos mínimos de documentação 
 Para avaliar que a implementação do software satisfaz os requisitos 
técnicos, os seguintes artefatos, referente a documentação mínima, são 
requeridas: 
1) Descrição de requisito de software (DRS): Deve especificar os 
requisitos para um produto partículas de software, programa, ou 
conjunto de programas que realizam certas funções em um ambiente 
específico. Este documento está presente no Apêndice 1. 
2) Planos de verificação e validação: Tem o propósito de determinar se 
os produtos de softwares, foram desenvolvidos conforme seus 
requisitos. Cada plano, define as tarefas de verificação e validação e 
as entradas/ saídas necessárias para manter o nível de integridade de 
software apropriado; 
3) Relatórios de resultados de validação e verificação: Devem 
descrever os resultados obtidos de atividades de verificação e 
validação dos artefatos de software; 
5.3. Padrões, práticas, convenções e métricas 
5.3.1 Propósito 
 
• Identificação dos padrões, práticas, técnicas estatísticas a serem usadas, 
requisitos de qualidade, e métricas a serem aplicadas. As medidas de 
processo e produto devem ser incluídas nas métricas utilizadas e podem 
ser identificados em um plano de medição separado. 
• Aqui deve-se declarar como a conformidade com esses itens deve ser 
monitorada e garantida. 
 
5.3.2 Conteúdo 
 
Os conteúdos, abordados devem incluir as atividades de técnicas, de design e de 
programações básicas envolvidas, como, documentação, nomeação de variáveis e 
módulos e programação. De forma resumida, os seguintes pontos devem ser abordados 
por essa seção. 
a) Padrões de documentação; 
b) Padrões de designes; 
c) Padrões de codificação; 
d) Padrões de comentários; 
e) Padrões de testes e de práticas; 
f) Garantia de qualidade de software selecionada e métricas de processos. 
 
5.4. Revisões de Softwares 
5.4.1 Propósito 
 
Essa seção se trata das técnicas de revisão de software que serão 
empregadas ao longo do projeto. Tais técnicas, podem variar entre revisões, 
walkthrough e inspeções. Deste modo, essa seção deve conter os seguintes pontos: 
o Definir a revisão de software que será conduzida. Pode ser 
incluído, revisão gerencial, revisões de artefatos adquirido de 
patrocinadores, revisões técnicas, Inspeção, Walkthrough e 
auditorias; 
o Lista de escalonamento para revisões de software, baseado no 
esquema de escalonamento dos processos de software; 
o Estado de como a revisão de software deve ser aplicada; 
o Estado de quais ações futuras devem ser requeridas e como elas 
devem ser implementadas e verificadas; 
5.4.2 Requisitos mínimos 
 Como uma medida mínima, as seguintes categorias de revisão de software 
devem ser conduzidas: 
 
1) Revisão de especificações de software (RES): O RES é realizado 
para garantir a adequação dos requisitos estabelecidos no DRS; 
2) Revisão do projeto de arquitetura (RPA): Avaliar a adequação 
técnica do projeto preliminar (também conhecido como nível 
superior); 
3) Revisão detalhada do projeto (RDP): Determinar a aceitabilidade 
dos projetos detalhados de software, conforme ilustrado na descrição 
do projeto de software para atender aos requisitos do SRD; 
4) Revisão do plano de verificação e validação: avaliar a adequação e 
integridade dos métodos de verificação e validação definidos nos 
planos de verificação e validação; 
5) Auditoria funcional: verificar se todos os requisitos especificados no 
SRD foram cumpridos; 
6) Auditoria física: verificar a consistência interna do software e sua 
documentação, e sua prontidão para liberação; 
7) Auditorias em processo: São realizadas auditorias em processo de 
amostras do projeto para verificar a consistência do projeto, incluindo: 
a) Código versus documentação do projeto 
b) Especificações de interface (hardware e software) 
c) Implementar projetos versus requisitos funcionais 
d) Requisitos funcionais versus descrições de teste 
 
8) Revisões gerenciais: Avaliar a execução de todas as ações e os itens 
identificados no SQAP; 
9) Revisão do plano de gerenciamento de configuração de software 
(SCMPR): avaliar a adequação e integridade dos métodos de 
gerenciamento de configuração definido no SCMP; 
10) Revisão pós-implementação: avaliar as atividades de 
desenvolvimento desse projeto e para fornecer recomendações para 
ações apropriadas; 
 
5.5. Teste 
Identificar todos os testes não incluídos no plano de verificação e validação de 
software para o software coberto pelo SQAP e deve indicar os métodos a serem usados. 
 
5.6. Relatório de problemas e ação corretiva 
 Essa seção deve definir os seguintes pontos: 
• Descrever as práticas e procedimentos a serem seguidos para relatar, 
rastrear e resolver problemas ou problemas identificados nos itens de 
software e no processo de desenvolvimento e manutenção de software; 
 
• Declarar as responsabilidades organizacionais específicas relacionadas à 
sua implementação. 
 
5.7. Ferramentas, técnicas e metodologias 
Identificar as ferramentas, técnicas e métodos de software usados para dar suporte 
aos processos SQA. Para cada uma, deve ser indicado o uso, a aplicabilidade ou as 
circunstâncias pretendidas sob as quais deve ser usada ou não é limitações. 
 
5.8. Controle de mídia 
 
Métodos e instalações a serem usados para: 
 
• Identificar a mídia para cada produto de trabalho intermediário e entregue 
ao computador e a documentação necessária para armazenar a mídia, 
incluindo o processo de cópia e restauração; 
• Proteger a mídia física do programa de computador contra acesso não 
autorizado, danos ou desgastes inadvertidos durante todas as fases do ciclo 
de vida do software. Isso pode ser fornecido como parte do SCMP. Ou 
então, deve ser feita uma referência apropriada. 
 
5.9. Controle de fornecedores 
 
• Indicar as disposições para garantir que o software fornecido pelos 
fornecedores atenda às normas estabelecidas; 
• Indicar os métodos que serão utilizados para garantir que o software receba 
requisitos adequados e completos; 
• Preparar e implementar um PGQS de acordo com esta norma. (Para o 
software que ainda vai ser desenvolvido); 
• Indicar os métodos a serem empregados para garantir que os fornecedores 
cumpram os requisitos desta norma. 
 
5.10. Coleção de registros, manutenção e retenção 
 
Esta seção deve indicar os métodos e instalações a serem usados para montar, 
arquivar, salva e manter esta documentação. Também designará o período de retenção. 
 
5.11. Treinamento (seção 13 do SQAP) 
Atividades de treinamento necessárias para atender às necessidades do PGQS. 
 
5.12. Gerenciamento de riscos 
Esta seção deve especificar os métodos e procedimentos empregados para 
identificar, avaliar, monitorar e controlar áreas de risco que surgem durante a parte do 
ciclo de vida do software coberto pelo PGQS. 
 
5.13. Glossário 
Essa seção deve conter o significado dos termos utilizados para montagem do 
PGQS. 
 
5.14. Procedimento e histórico de alterações do PGQS 
Essa seção deve conter os processos para modificar o PGQS e manter um histórico 
de mudanças. 
6. Documentos de Requisitos 
Um documento de requisitos conte todos os requisitos de um certo produto 
software. Estes requisitos por sua vez permitem as pessoas envolvidas no projeto saber 
o que o produto deve saber, eles são separados da seguinte forma: 
• Requisitos funcionais: indica o que o produto deve fazer (login, carrinho 
de compras, produção de gráficos de dados); 
• Requisitos não funcionais: diz como o produto deve realizar as tarefas 
(tempo mínimo de resposta de 6ms, média aritmética dos dados, carrinho 
de comprar para 10 produtos); 
 
Figura 1- Tabela de Requisitos Funcionais 
 
 
Figura 2 - Tabela de Requisitos Não Funcionais 
 
7. Checklist 
Checklistssão documentos utilizados em revisões, inspeções, walkthroughs e 
entre outros, para verificar a validade dos requisitos ou produto que se esteja avaliando. 
As checklists deste presente plano de garantia são tabelas que reúnem todos os requisitos 
acrescentando um campo de conferência para eles (sim/não). 
 
7.1. Requisitos Funcionais 
A figura abaixo, mostra o checklist de requisitos funcionais gerado para este 
trabalho. 
 
Figura 3 - Checklist de Requisitos 
7.2. Requisitos não funcionais 
A figura abaixo, mostra o checklist de requisitos não funcionais gerado para este 
trabalho. 
 
Figura 4 - Checklist de requisitos não funcionais 
8. Matriz Rastreabilidade 
Uma matriz de rastreabilidade é um documento, geralmente em forma de tabela, 
usado para apoiar a determinação da completude de um relacionamento por meio da 
relação em quaisquer dois documentos, usando uma comparação do tipo muitos-para-
muitos. A utilização da matriz permite perceber a existência de relação entre dois ou mais 
artefatos por meio de uma marcação na coluna de interseção entre os artefatos. 
A matriz em questão, tem em sua coluna da esquerda e em sua coluna superior, 
os códigos dos requisitos funcionais. O que é avaliado é a relação entre requisitos com o 
propósito de facilitar a percepção de onde a mudança de um requisito iria influência o 
sistema como um todo. As Figuras 7, 8 e 10 mostram as matrizes de rastreabilidade. 
 
Figura 5 - Matriz de rastreabilidade de requisitos funcionais 
 
 
Figura 6 - Matriz de rastreabilidade de requisitos não funcionais 
9. Casos de uso 
Os casos de uso, ou casos de testes, são documentos que se baseiam nos requisitos 
para criar cenários com diversos atores (usuários, sistemas), para ilustrar as interações 
com o sistema e suas devidas resposta. Este tipo de documento tem o propósito de ilustra 
exatamente o que o sistema e o usuário devem fazer em diferentes situações de uso do 
sistema. A Figura abaixo mostra o modelo do documento criado para este projeto. 
 
Figura: CASOS DE USO 
 
 
 
 
Fonte: Autoral 
 
10. Checklist dos casos de uso 
A Figura abaixo mostra a modelo para o checklist para os casos de uso do projeto. 
 
Fonte: Autoral 
 
11. Diagrama de classe de Análise 
O diagrama de classes é utilizado na construção do modelo de classes desde o 
nível de análise até o nível de especificação. 
 
Fonte: Autoral 
12. Checklist do diagrama de classe de análise 
 A Figura abaixo mostra a modelo para o checklist para os casos de uso do projeto. 
 
 
Fonte: Autoral