UNOPAR - UNIVERSIDADE NORTE DO PARANÁ

VIVIANE KLEIN

PROJETO INTEGRADO II

Xanxerê
2021
 VIVIANE KLEIN

PROJETO INTEGRADO II

Trabalho de Projeto Integrado II apresentado ao Trabalho de Projeto Integrado II apresentado ao

curso de CST Análise e Desenvolvimento de
Sistemas como requisito parcial para a obtenção
de média semestral para as matérias de: Projeto
de Software, Sistemas Operacionais e Segurança
e Auditoria de Sistemas.
curso de CST Análise e Desenvolvimento de
Sistemas como requisito parcial para a obtenção
de média semestral para as matérias de: Projeto
de Software, Sistemas Operacionais e Segurança
e Auditoria de Sistemas.

Professores: Adriane Aparecida Loper, Gilberto Professores: Adriane Aparecida Loper, Gilberto
Fernandes Junior, Vanessa Matias Leite, Fernandes Junior, Vanessa Matias Leite,
Leonardo Santiago Sidon da Rocha Leonardo Santiago Sidon da Rocha

Xanxerê
2021
 SUMÁRIO

1 INTRODUÇÃO.........................................................................................4
2 QUALIDADE - ATIVIDADE 1...................................................................5
2.1 NORMA ISO 12119.................................................................................5
2.1.1 Potenciais Usuários.................................................................................5
2.1.2 Requisitos de qualidade..........................................................................6
2.1.2.1 Descrição do produto...............................................................................6
2.1.2.1.1 Identificação e indicação.........................................................................6
2.1.2.1.2 Funcionalidades.......................................................................................6
2.1.2.1.3 Confiabilidade..........................................................................................7
2.1.2.1.4 Usabilidade..............................................................................................7
2.1.2.1.5 Eficiência..................................................................................................7
2.1.2.1.6 Manutenibilidade......................................................................................7
2.1.2.1.7 Portabilidade............................................................................................7
2.1.2.2 Documentação do usuário.......................................................................7
2.1.2.3 Programa e dados...................................................................................8
2.1.2.4 Instruções para teste...............................................................................8
2.2 ISO 15504 (SPICE)..................................................................................8
3 CONCEITO DE PROCESSO E DE THREAD - ATIVIDADE 02...........11
4 SEGURANÇA E AUDITORIA - TAREFA 03.........................................12
4.1 TESTE DA CAIXA BRANCA.................................................................12
4.1.1 Teste de condição..................................................................................12
4.1.2 Teste de ciclo.........................................................................................13
4.1.3 Teste do caminho básico.......................................................................13
4.1.4 Teste de estrutura de controle...............................................................13
4.1.5 Teste de decisão....................................................................................13
4.1.6 Teste de fluxo de dados........................................................................13
4.2 TESTE DA CAIXA PRETA OU TESTE FUNCIONAL...........................14
4.3 TESTE DA CAIXA CINZA......................................................................14
4.4 AUDITORIA...........................................................................................15
4.4.1 Como realizar e se preparar para uma auditoria...................................16
5 CONCLUSÃO........................................................................................18
6 REFERÊNCIAS.....................................................................................19
 4

1 INTRODUÇÃO

Todos os dias surgem novos softwares e empresas que prometem ser

a solução de todos os problemas. Claro que isso não é possível, nada é perfeito e
nenhum software vai atender 100% de absolutamente tudo o que uma organização
pode precisar.
Com o mercado de softwares em crescimento ascendente, a escolha do
melhor software para a empresa deixa os gestores muitas vezes em uma situação
que eles não conseguem escolher qual será o melhor e muitas vezes se arrependem
da escolha depois, mas daí o custo enorme e o tempo despedido já não podem
retornar.
Para dirimir estes e outros problemas com empresas e softwares, é preciso
que exista a imposição de padrões e certificações para ajudar os gestores e
proprietários na hora da escolha. Além de pensar apenas no cliente próximo,
algumas certificações também garantem o reconhecimento internacional, abrindo o
mercado de softwares para muitos desenvolvedores.
Na primeira parte deste trabalho serão apresentadas duas normas que
auxiliam a certificação de qualidade dos softers: a norma ISO 12119 e a ISO15504
(SPICE).
Em um segundo momento, serão apresentados os principais testes de
softwares: o teste da caixa branca, da caixa preta e da caixa cinza. E finalmente,
mas não menos importante, pelo contrario, uma ferramenta da máxima importância
para o gerenciamento, planejamento e desenvolvimento da empresa: a auditoria.
É preciso controle e organização para desenvolver e adquirir softwares de
qualidade e de confiança.
 5

2 QUALIDADE - ATIVIDADE 1

Hoje em dia tanto os consumidores finais quanto as empresas de qualquer

porte, buscam não apenas o melhor preço, mas também os produtos mais
competitivos e de melhor qualidade.
Para se ter um produto que seja destaque no quesito qualidade, todo o
processo de fabricação ou desenvolvimento também deve estar com garantia de
qualidade em cada etapa.
Esta regra da qualidade em todo o processo também está presente no
desenvolvimento de software. E o mais interessante nas instituições ou modelos que
certificam a qualidade, é que a certificação de processo de desenvolvimento ou
fabricação é mais valorizada e procurada do que aqueles processos que certificam
apenas o produto final.
Existem disponíveis hoje, diversas normas e regras internacionais e nacionais
que podem servir para nortear o processo de planejamento, desenvolvimento e
controle de qualidade de um software. Abaixo serão apresentadas duas normas ou
modelos com suas principais características: ISO 12119 e a ISO 15504 ou SPICE.

2.1 NORMA ISO 12119

Esta norma foi publicada no ano de 1994 e avalia os chamados pacotes de

softwares ou Softwares de Prateleira como, por exemplo, processadores de texto,
planilhas eletrônicas, programas utilitários. Ela descreve em detalhes as
características e subcaraterísticas que são citadas na ISO 9126 da qual deriva.
A norma estabelece os requisitos de qualidade e como realizar os testes de
qualidade. Estes testes poderão ser feitos pelo consumidor final. E esta norma trata
do produto final e não do processo de desenvolvimento do software.

2.1.1 Potenciais Usuários

Descreve quem são os possíveis usuários do produto:
a) fornecedores;
b) entidades certificadoras;
c) entidades de credenciamento;
d) laboratórios;
 6

e) auditores;
f) compradores;
g) usuários.

2.1.2 Requisitos de qualidade

2.1.2.1 Descrição do produto

É uma parte da documentação do produto que deve conter informações sobre
o programa e sobre os dados, se for o caso. E deve estar disponível para quem
estiver com interesse no produto.
Esta descrição deve ser completa e inteligível alem de estar bem organizada
de modo a esclarecer totalmente a pessoa que estiver interessada no software e
serve como base para os testes.

2.1.2.1.1 Identificação e indicação

Referente à identificação e indicações do produto oferecido, a norma
determina que apresente os seguintes itens:
a) uma única descrição do produto;
b) a identificação deve conter no mínimo nome e versão do software;
c) nome e contato de pelo menos um fornecedor;
d) identificar a tarefa que o software realiza;
e) pode fazer referência a documentos com os quais está em conformidade;
f) requisitos de software e hardware mínimos que precisam estar presentes
para o funcionamento do software;
g) caso seja citado que há compatibilidade com outras interfaces, as mesmas
precisam ser citadas;
h) lista dos componentes físicos que serão disponibilizados;
i) instalação;
j) deve ser indicado se existe ou não suporte par ao produto;
k) caso seja oferecida manutenção do produto, a mesma deve ser
especificada.

2.1.2.1.2 Funcionalidades
No produto devem constar as suas funcionalidades, valores-limites, se
 7

possível, e as informações de segurança.

2.1.2.1.3 Confiabilidade
Refere-se a informações sobre a preservação de dados, como por exemplo,
se é possível realizar, manter e recuperar backup.

2.1.2.1.4 Usabilidade
Deve ser informado o conhecimento necessário para que usuário possa
usufruir do programa bem como os idiomas disponíveis.

2.1.2.1.5 Eficiência
Informações como, por exemplo, tempo de resposta.

2.1.2.1.6 Manutenibilidade
Contem informações sobre as manutenções que estão ou não disponíveis.

2.1.2.1.7 Portabilidade

Indicar se existem outros produtos compatíveis e informar quais são eles.

2.1.2.2 Documentação do usuário

Esta documentação deve conter todas as informações necessárias para
utilização do produto, inclusive manual de instalação. Estes documentos devem
estar na forma impressa.
São características desta documentação:
a) completitude: deve conter todas as informações necessárias para uso,
instalação e manutenção do produto;
b) correção: a documentação não pode apresentar ambigüidades e deve estar
bem organizada;
c) consistência: coerência entre a documentação e a descrição do produto;
d) inteligibilidade: deve ser compreensível para o nível de usuário ao qual se
destina;
e) organização e apresentação: deve ser organizada e de fácil visualização.
 8

2.1.2.3 Programa e dados

As características destacadas neste item são:

a) funcionalidade deve conter os procedimentos para instalação, todas as
funções citadas na descrição e as mesmas devem funcionar corretamente, e não
podem ocorrer discrepâncias entre a descrição e a documentação do usuário.
b) confiabilidade: o usuário não pode perder os dados ou que os mesmos
sejam corrompidos, independente da utilização ter atingido os limites declarados.
c) usabilidade: a interface deve ser fácil de entender e utilizar.

2.1.2.4 Instruções para teste

Descreve como o software pode ser testado em relação a todos os itens que
constam em suas funcionalidades. Para a realização dos testes, todos os itens do
produto e de hardware devem estar instalados.
Após a realização dos testes, os resultados devem conter as informações
necessárias para que o teste possa ser repetido. Também deve ser possível
visualizar um relatório com indicações dos resultados e que não deve ser
parcialmente reproduzido.

2.2 ISO 15504 (SPICE)

A norma 15504 ou SPICE (Software Process Improvement & Capability

Determination) foi desenvolvida pela International Organization for Standardization
and the International Electrotechnical Comission (ISO/IEC) com o objetivo de trazer
melhorias do processo identificando os pontos fracos e fortes que serão utilizados
para a elaboração de um plano de melhorias e determinação da capacidade do
processo, viabilizando a avaliação de um fornecedor em potencial, obtendo o seu
perfil de capacidade.
Possibilita a avaliação do processo de desenvolvimento do software através
da facilitação de auto-avaliação, produz o perfil do processo, pode ser empregada
em variados tamanhos de organizações.
Este modelo é dividido em cinco grandes grupos de processo:
- cliente / fornecedor: processos que impactam nos produtos e serviços de
software do fornecedor para o cliente;
- engenharia: processos ligados ao desenvolvimento de um sistema ou
 9

produto de software e sua documentação;

- suporte: processos que podem ser utilizados por qualquer um dos outros
processos;
- gerência: contém práticas de natureza genérica que podem ser utilizadas
por quem gerencia os projetos ou processos;
- organização: estabelecem os objetivos dos negócios da empresa.
A norma estabelece requisitos para uma avaliação de processo e modelos de
avaliação, de modo que estes requisitos possam ser utilizados em qualquer modelo
de avaliação de uma empresa.
Divida em 10 partes entre 2003 e 2011, apenas as partes três e sete são
consideradas normativas e contem os requisitos, as demais partes são consideradas
elementos para consulta e guias de aplicação. Abaixo as 10 partes da norma:
 Parte 1: Conceitos e vocabulário
 Parte 2: Realização de uma avaliação
 Parte 3: Realização de uma avaliação. Guia para a realização da avaliação
 Parte 4: Orientação sobre o uso para melhoria de processo e determinação da
capacidade do processo
 Parte 5. Um exemplo de um modelo de avaliação de processo de ciclo de vida de
software (de acordo com ISO / IEC 12207)
 Parte 6. Um exemplo de um modelo de avaliação do ciclo de vida do sistema (de
acordo com a ISO / IEC 15288)
 Parte 7. Avaliação da maturidade organizacional
 Parte 8. Um modelo de avaliação de processo exemplar para gerenciamento de
serviços de TI (de acordo com ISO / IEC 20000)
 Parte 9. Perfis de processo de destino
 Parte 10. Extensão de segurança
A parte dois descreve os fundamentos para a realização de uma avaliação e
determinação do nível de capacidade e dimensão do processo, conforme visto na
Figura 01 - Níveis de Capacitação.
Para avaliar o nível de capacidade são definidos nove atributos que permitem
determinar se um processo alcançou ou não determinado nível de capacitação. Na
Figura 02 - Atributos de processo e níveis de capacidade, é possível verificar os
atributos necessários para medir se determinado aspecto de cada capacitação do
processo foi atingida.
 10

Nível 0 Incompleto: O processo está incompleto. Não está

totalmente implementado e não atinge seus objetivos;

Nível 1 Realizado: Processo geralmente atinge os objetivos, porém

sem padrão de qualidade e sem controle de prazos e custos;

Nível 2 Gerenciado: O processo produz os produtos de trabalho

NÍVEIS DE com qualidade aceitável e dentro do prazo. Isto é feito de forma
planejada e controlada. Os produtos de trabalho estão de acordo
CAPACIDADE com padrões e requisitos.

Nível 3 Estabelecido: O processo é realizado e gerenciado usando

um processo definido, baseado em princípios de Engenharia de
Software

Nível 4 Previsível: O processo é realizado de forma consistente,

dentro dos limites de controle, para atingir os objetivos. Medidas da
realização do processo são coletadas e analisadas.

Nível 5 Otimizado: A realização do processo é otimizada para

atender às necessidades atuais e futuras do negócio. O processo
atinge seus objetivos de negócio e consegue ser repetido. A
otimização do processo envolve o uso piloto de idéias e
tecnologias inovadoras.

Figura 1 - Níveis de Capacitação

Figura 2 - Atributos de processo e níveis de capacidade

O monitoramento e controle estão inseridos dentro do processo de gerência
 11

do projeto. O objetivo principal do processo de gerencia de projeto é: “identificar,

estabelecer, ordenar e monitorar as atividades, tarefas e recursos necessários para
que o projeto produza o produto e/ou serviço, no contexto dos requisitos e restrições
do projeto” (ISO, 2005). Esta norma apresenta principalmente o que deve ser
realizado, mas não como os processos devem ser executados.

3 CONCEITO DE PROCESSO E DE THREAD - ATIVIDADE 02

Processos podem ser conceituados como um módulo executável ou conjunto

de atividades ou programa que será executado por um único fluxo de execução. Os
processos envolvem métodos, práticas e tecnologias que são usadas por pessoas
no desenvolvimento e manutenção de softwares e produtos relacionados.
Os processos possuem um objetivo claro e definido que é a obtenção de um
produto e todas as atividades envolvidas no processo devem estar de acordo para a
realização deste objetivo.
Processos são apresentados em módulos separados e serão carregados e
executados, ao contrário dos threads que não podem ser carregadas. Os threads
ocorrem dentro dos processos, podem ser únicas ou múltiplas.
Threads são chamados também de linhas de encadeamento de execução e
pode ser entendido como as divisões de um processo em atividades e tarefas que
podem ou não ser executadas simultaneamente. Os threads podem utilizar o mesmo
espaço de memória que pertencem a um processo. Os threads muitas vezes são
considerados processos e do ponto de vista do processador, alguns autores
consideram que só existem threads.
As diferenças principais entre processo e threads são:
- a memória global para processos é própria e para threads é compartilhada;
- as threads consomem menos memória do que os processos;
- os processos são proprietários dos recursos externos que estão vinculados,
os threads utilizam os recursos do processo em que estão inseridas;
- os processos levam um tempo longo de criação, os threads têm tempo curto
quando comparadas as processo;
- os processos são programas executáveis, os threads funcionam dentro dos
processos;
- as threads podem funcionar paralelamente;
 12

- as threads se comunicam entre elas dentro do processo;

- somente o processo se comunica com o sistema operacional.

4 SEGURANÇA E AUDITORIA - TAREFA 03

4.1 TESTE DA CAIXA BRANCA

No teste da caixa branca, também chamado teste estrutural ou caixa de vidro,

open Box ou teste baseado em código, o testador tem acesso ao código fonte do
programa que será testado, pois testa os caminhos de execução. Sendo assim, o
objetivo principal é garantir que os componentes do software estejam concisos,
garantir a qualidade da implementação do sistema ou ainda validar a lógica do
produto, fortalecer o fluxo de entradas e saídas através da aplicação e melhorar o
design e usabilidade. Os dados de entrada são determinados para que possa ser
realizada a análise da lógica do software.
Neste teste exige-se bastante conhecimento técnico por parte do testador o
que gera um custo maior em relação a outros testes. E sempre que há necessidade
de alterar o código fonte, é preciso alterar o teste.
A desvantagem deste teste é que se limita apenas ao código fonte e não
verifica a lógica da especificação (LEWIS W VEERAPILLAI, 2005) além de ser
complexo e dispendioso.
As principais vantagens são:
- otimização do código ao encontrar erros ocultos;
- Facilidade na automatização dos testes;
- teste completo de caminho de código;
- podem ser implementados desde o início do projeto.
Pode ser dividido em teste de condição, teste de ciclo, do caminho básico,
teste de estrutura de controle, teste de decisão e teste de fluxo de dados.

4.1.1 Teste de condição

É o mais simples e consistem em testar a consistência dos operadores
variáveis lógicos nas condições booleanas simples ou compostas (true/false) para
analisar os desvios existentes.
 13

4.1.2 Teste de ciclo

Testa as estruturas de repetição ou de ciclo. Este teste valida as estruturas de
repetição. Este teste é importante, pois muitos erros são cometidos na construção
das estruturas de repetição. E se divide em desestruturado, simples, aninhado e
concatenado.
O teste de ciclo desestruturado identifica os blocos de repetição que não
estão sendo utilizados de maneira ordenada. Ao serem identificados exige-se uma
reestruturação.
O ciclo simples ocorre quando apenas uma estrutura de repetição é testada.
O teste de ciclos aninhados ocorre quando são realizados nos ciclos que
estão dentro de ciclos.
O teste de ciclos concatenados ocorre quando é necessário que o ciclo
anterior esteja testado e que seja coerente para realizar o teste em outro ciclo.

4.1.3 Teste do caminho básico

É utilizado para verificar a complexidade lógica do software ou descobrir os
caminhos básicos e fazer com que todos os caminhos sejam efetuados.

4.1.4 Teste de estrutura de

controle
Serve de complemento para o teste de caminho básico e garante uma alta
qualidade para a técnica de caixa branca (PRESSMAN, 2006).

4.1.5 Teste de decisão

Testa a cobertura inteira dos comandos sem executar os desvios do código
fonte.

4.1.6 Teste de fluxo de dados

Este teste torna o teste da caixa branca mais poderoso. Ele encontra
caminhos para testar o código fonte, selecionar as variáveis e seu uso dentro do
código fonte. Ele identifica o comportamento das variáveis e busca erros que
possam não ter sido identificados em outros testes ou durante a criação do código.
 14

4.2 TESTE DA CAIXA PRETA OU TESTE FUNCIONAL

Este tipo de teste é realizado introduzindo-se dados de entrada e observando

se o resultado ou saída obtida é a esperada. Não se leva em consideração o
comportamento interno do software a ser testado. As entradas são fornecidas a
partir de um conhecimento sistemático e direto, sendo gerados resultados que
devem ser típicos do sistema.
Através deste teste, pode-se aferir o desempenho de métodos, funções
internas, programas, processos e até mesmo uma funcionalidade. Este teste é
voltado para avaliar o ponto de vista do usuário com o software ou interface do
produto.
São levados em conta os requisitos básicos do sistema com foco nas ações e
funcionalidades que deve desempenhar. Os níveis de teste da caixa preta são:
integração, sistema, alfa, beta.

4.3 TESTE DA CAIXA CINZA

Este teste engloba uma parte de cada um dos testes anteriores: caixa branca
e caixa preta. Isto porque o teste tem um conhecimento prévio sobre a estrutura
interna do software alem de poder utilizar a interface do usuário.
O teste da caixa cinza é realizado com a introdução de uma entrada através
da interface do usuário e o processamento desta entrada é analisando dentro do
software.
As principais vantagens do teste da caixa cinza são:
 Poder ser realizado a partir do ponto de vista do usuário, utilizando a interface
do software;
 Proporciona uma interação entre os designers da interface ou front-end e os
engenheiros ou designers do programa ou back-ends;
 É uma integração entre o teste da caixa preta e da caixa branca, com
menores custos e trazendo os pontos fortes de cada um destes testes;
 O testador poderá verificar os requisitos originais do software trazendo um
produto com mais qualidade.
As principais técnicas da caixa cinza são:
 Teste de matriz: indica o relatório de status do projeto;
 15

 Teste de regressão: implica uma nova execução dos casos de teste se novas
alterações forem feitas;
 Teste de padrão: verifique a boa aplicação para seu design ou arquitetura e
padrões;
 Teste de matriz ortogonal: usado como subconjunto de todas as combinações
possíveis.

4.4 AUDITORIA

Auditoria é um processo de verificação e análise que uma empresa ou

organização realiza para avaliar se as atividades desenvolvidas pelos diversos
setores da empresa estão de acordo com o planejamento, princípios ou metas,
determinados anteriormente pela mesma.
A auditoria aponta possíveis irregularidades ou falhas não apenas na área
contábil, mas em qualquer processo da empresa. Permite ainda que estes erros ou
falhas sejam corrigidos e o processo seja acertado ou melhorado, para que não
afete a lucratividade ou a qualidade dos produtos ou serviços oferecidos pela
organização.
Os processos internos de uma empresa que são auditados demonstram
transparência e transmitem segurança não apenas aos colaboradores, mas
principalmente para clientes e fornecedores, pois certifica que a empresa é
organizada e visa o cumprimento do seu planejamento estratégico.
Todas as atividades da empresa devem ser examinadas de forma cuidadosa
e sistemática, e não apenas o que está sendo realizado é examinado, mas também,
é acompanhado o processo, o registro, as anotações e os procedimentos da
organização.
Com os dados levantados durante uma auditoria, os gestores podem tomar
decisões mais assertivas porque estes dados são reais e concretos sobre a situação
interna da organização, sendo possível realizar planejamentos de médio e longo
prazo e conseguindo eliminar possíveis riscos e identificando as oportunidades.
A auditoria pode ser classificada em interna quando é realizada por
funcionários da empresa que possuem treinamento ou certificação e que visam
analisar os procedimentos, regulamentação interna e registro realizados buscando
 16

melhorar os diferentes processos de rotina, corrigir falhas e monitorar as atividades.

Ela é subordinada aos interesses da alta administração.
Na auditoria classificada como externa, ela é realizada por empresa ou
profissionais independentes que sejam especialistas e regulamentados. Em muitos
casos, a auditoria interna é uma preparação para uma certificação concedida por
algum órgão ou instituição. O principal objetivo da auditoria externa é validar a
veracidade dos dados fornecidos pela empresa. Empresas que tem receita bruta
acima de R$ 300.000.000,00 são legalmente obrigadas a passar por auditorias
externas.
O principal é que as auditorias são uma oportunidade para conhecer a fundo
os processos da empresa e identificar e corrigir possíveis problemas, deixando os
gestores com uma visão mais clara e real sobre a situação em cada processo.

4.4.1 Como realizar e se preparar

para uma auditoria

Por ser um recurso valioso e uma ferramenta com diversas vantagens como
citadas anteriormente, a auditoria de estar presente no dia-a-dia de qualquer
empresa, pois oferece garantias e registros de que os processos estão de acordo
com as propostas da empresa e estão em melhoria continua, pois estão sempre
sendo revisados e melhorados.
Algumas etapas podem ajudar a melhorar a preparação e manter-se sempre
pronto para a auditoria, seja interna ou externa.
Um passo importante é ter um plano anual de atividades onde consta um
calendário com as áreas que serão auditadas e os motivos para a auditoria. Devem
possuir data de inicio e fim, bem como o prazo para o relatório final do auditor.
A formalização das atividades de cada colaborador ou a descrição do que
cada área deve fazer é uma ferramenta poderosa, pois organiza e define
responsabilidades. Torna mais fácil também o treinamento e a disponibilidade de um
manual para consulta, deixando o funcionário com mais segurança e com um
instrumento para sanar suas duvidas.
Optando por uma auditoria interna, é possível treinar um funcionário dedicado
apenas a este trabalho, sendo desta forma alguém que conhece a fundo os
problemas e oportunidades da empresa. Este funcionário deverá trabalhar junto aos
 17

colaboradores de casa setor para identificar melhorias e falhas dos processos,

trazendo mais qualidade para os produtos e serviços oferecidos, sabendo-se que
todo o processo de fabricação também impacta sobre o produto final direta ou
indiretamente.
O cronograma é parte muito importante da auditoria, pois ela também deve
demonstrar organização. Sendo assim é importante apresentar um calendário
elaborado previamente para os setores e funcionários que serão auditados.
Realizar testes prévios, observando os riscos e controles internos é possível
através de testes com características específicas para cada setor.
 18

5 CONCLUSÃO

Para ser um profissional reconhecido em desenvolvimento de softwares, mais

do que apenas estudar muito e criar experiências, é preciso buscar a certificação
nacional e internacional seja através de processos internos ou externos.
É preciso conhecer os testes de software para apresentar produtos finais com
mais qualidade e transparência para os clientes. Os testes e auditorias, não apenas
apontam erros, mas trazem melhorias e crescimento profissional para os
profissionais e colaboradores, alem da melhoria continua da organização.
Para ter sucesso e se destacar no mercado super concorrido atual, é preciso
ser e saber mais do que apenas desenvolver códigos, é preciso ser organizado e
conhecer todas as particularidades do desenvolvimento do software, desde a
primeira concepção até o pós venda do produto.
 19

6 REFERÊNCIAS

UNIVERSIDADE FEDERAL DO PARANÁ. Biblioteca Central. Normas para

apresentação de trabalhos. 2. ed. Curitiba: UFPR, 1992. v. 2.

MOREIRA FILHO, T. R.; RIOS, E. Projeto & Engenharia de Software: teste de

software. Rio de Janeiro: Alta Books, 2003.

PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prática. Rio de

Janeiro: Campus, 2001.

PEZZÈ, M.; YOUNG, M. Teste e Análise de Software: processos, princípios e

técnicas. Porto Alegre: Bookman, 2008.

PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: McGraw-

Hill,2006.

ANISIO, IAHN. Avaliação de processos de software utilizando a norma ISO/IEC

15504. 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, 1999.

CÂNDIDO, Celso. Qualidade de software. 20--. Disponível em:

<http://profcelso.orgfree.com/Arquivos_Aulas/06-Qualidade_Soft/Normas.pdf.>
Acesso em 15 de ago. de 2021.

LEITE, Andreza. Sistemas Operacionais: processos e Threads. 20--. Disponível

em: <http://www.univasf.edu.br/~andreza.leite/aulas/SO/ProcessosThreads.pdf>.
Acesso em 20 de set. de 2021.

ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ISO/IEC

12119:1998. Tecnologia da informação - Pacotes de software - Teste e requisitos de
qualidade.

FRANCO, Alexandre. ISO/IEC 12119. 2010. Disponível em:

<https://mmpsw.files.wordpress.com/2010/04/aula-15-12119.pdf>. Acesso em 10 de
set. de 2021.

RAMOS, Ricardo A. Padrões de qualidade de software. 2011. Disponível em

<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_I_2011_2/
Aula03_PadroesQualidadeSoftwareMetricasSoftware.pdf>. Acesso em 20 de set. de
2021.
 20

AUDITORIA - Conceitos - Objetivos. Portal da Contabilidade, (S.I.). Disponível em

<http://www.portaldecontabilidade.com.br/guia/auditoria.htm>. Acesso em 05 de out.
de 2021.

OBJETIVOS da Auditoria. RSM Consultoria. c2012. Disponível em

<http://www.rsmconsultoria.com/nsite/pt-br/auditoria-empresarial/52-auditoria.html>
Acesso em 5 de set. de 2021.

SILVA, Célio. Quais São As Normas De Qualidade E Para O Que Servem? Delogic.
Disponível em: <https://blog.delogic.com.br/quais-sao-as-normas-de-qualidade-e-
para-o-que-servem/>. Acesso em 5 de set. 2021.

CARDOSO, Filipa. Thread e Processos – Quais as diferenças. Proddigital.

Disponível em : < https://proddigital.com.br/tecnologia/thread-e-processos-quais-as-
diferencas>. Acesso em 05 de set. de 2021.

ISO/IEC 15504 SPICE. Normas ISO. [s.d.]. Disponível em:< https://www.normas-

iso.com/iso-iec-15504-spice/> Acesso em 10 de set. de 2021.

Rodrigues, Caroline. Testes de software: entenda as diferenças entre Black, Gray e

White Box. Boa Vista Tecnologia, 2019. Disponível
em:<https://boavistatecnologia.com.br/blog/teste-de-softwares/>. Acesso em 05 de
set. de 2021.
 21

ANEXO 1 - PROJETO INTEGRADO II

ATIVIDADES

1 - A qualidade é um elemento essencial para o projeto e produto. Para isso, existem

inúmera instituições reconhecidas que disponibilizam normas para permitir o
planejamento, desenvolvimento e controle da qualidade, inclusive específicas para
softwares. Sobre este tema, escolha duas instituições/modelos e descreva suas
principais características.
2 - Explique a diferença entre o conceito de processo e o conceito de thread.
3 - Temos sempre que pensar muito em segurança e auditoria. Temos que pensar
em fazer testes em tudo o que produzimos. Responda:
O que é o teste de caixa branca?
O que é o teste de caixa preta?
O que é o teste de caixa cinza?
Quais os objetivos e para que serve uma auditoria?