SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS
POLO FREDERICO WESTPHALEN

MAURICIO EICH

PROJETO INTEGRADO II

Frederico Westphalen
2021

MAURICIO EICH
PROJETO INTEGRADO II

Trabalho apresentado ao Curso Superior em Análise e

Desenvolvimento de Sistemas da UNOPAR - Universidade
Norte do Paraná - Polo Frederico Westphalen, para a
disciplina Projeto Integrado II, abrangendo as seguintes
matérias:

Projeto de Software
Vanessa Matias Leite
Sistemas Operacionais
Patricia Valerio Martinez
Segurança e Auditoria de Sistemas
Adriana Aparecida Loper
Introdução ao Design de Jogos e Entretenimento Digital
Leonardo Santiago Sidon da Rocha
Tutor a Distância
Fernanda Caroline da Silva Fernandes
Projeto Integrado II
Dorival Magro Junior

Frederico Westphalen
2021
 SUMÁRIO

SUMÁRIO 3
INTRODUÇÃO 4
NORMAS - PLANEJAMENTO, DESENVOLVIMENTO E CONTROLE DE QUALIDADE 5
DIFERENÇA ENTRE CONCEITO DE PROCESSO E CONCEITO DE THREAD 6
TESTES - SEGURANÇA E AUDITORIA 6
CONCLUSÃO 8
REFERÊNCIAS BIBLIOGRÁFICAS 9
 1. INTRODUÇÃO

Este trabalho foi desenvolvido para a disciplina Projeto Integrado II do curso

Tecnólogo em Análise e Desenvolvimento de Sistemas da Universidade do Norte do
Paraná (Unopar). O mesmo tem por objetivo central, desenvolver as habilidades e
conhecimentos adquiridos no transcorrer do curso, assim como aplicar tais
conhecimentos em um caso concreto.

O desenvolvimento será ancorado em pesquisa bibliográfica, embasado em

referenciais teóricos, disponíveis em bibliotecas online, livros, artigos, documentos
eletrônicos e demais materiais utilizados como fonte de consulta, por julgar ser um
método ágil, acessível e de abundante conteúdo disponível.

Para Gil (2002):

A principal vantagem da pesquisa bibliográfica reside no fato de permitir ao

investigador a cobertura de uma gama de fenômenos muito mais ampla do que
aquela que poderia pesquisar diretamente. [...] A pesquisa bibliográfica também é
indispensável nos estudos históricos. Em muitas situações, não há outra maneira
de conhecer os fatos passados se não com base em dados bibliográficos (GIL,
2002, p.4).

Esta produção textual, parte da importância dos processos de desenvolvimento de

software, bem como a necessidade de controle de qualidade durante o planejamento e
desenvolvimento. A presente produção textual abordará a temática procurando
correlaciona-la aos temas abordados pelas disciplinas do semestre.

2. NORMAS - PLANEJAMENTO, DESENVOLVIMENTO E CONTROLE

DE QUALIDADE

ISO - International Organization for Standardization:

Ao se falar de qualidade e controle de qualidade temos algumas instituições
reconhecidas internacionalmente que tem por objetivo padronizar processos. As normas
ISO tem sua origem na International Organization for Standardization (Organização
Internacional para Padronização). Fundada em 23 de fevereiro de 1947 na Suíça.

Esta organização não-governamental, faz-se presente em mais de 200 países e é

a responsável por estabelecer padrões internacionais para indústria e comércio. A criação
da ISO foi um marco para o desenvolvimento da regulamentação de normas frente às
perspectivas de transformação que o mundo passaria a partir da década de 50.

No que tange ao controle de qualidade de software temos a norma ISO/IEC 9126-1

a qual descreve um modelo de qualidade de produto formado por duas partes: a primeira
trata-se de qualidade interna e externa, onde específica seis características que possuem
sub características. Tais sub características surgem quando o software é utilizado como
parte de um sistema computacional, sendo os resultados de informações internas do
software.

IEC - International Electrotechnical Commission:

São elaboradas em suas várias comissões técnicas (IEC/TC), as quais

organizam-se em bases temáticas com representações de seus integrantes. A aprovação
de uma norma ocorre por votação entre os membros. As normas IEC são de caráter
voluntário, cabendo a seus membros decidirem se as adotam como nacionais ou não.

3. DIFERENÇA ENTRE CONCEITO DE PROCESSO E CONCEITO DE

THREAD

Sobre o processo: o executável, quando chamado roda dentro de um processo.

Quando um executável é chamado dentro de outro, este pode rodar dentro do mesmo
processo ou em outro, isso ocorre utilizando-se de DLL.
 Os processos são controlados pelo SO, tanto em relação ao tempo de processador
quanto ao uso de memória, além do uso de recursos que ficam vinculados ao processo.
Tem reservado endereçamento de memória virtual exclusivamente para ele. A ideia é
como se ele rodasse sozinho no computador, o que não acontece, mas para o processo
sim.. Um mesmo executável é capaz de rodar vários processos.
Thread: é parecido com o processo por ter uma nova linha de execução, portanto
o SO o gerencia de forma igual ao processo para alocação de tempo de processamento.
Porém a responsabilidade de controle da memória é da aplicação. Acontece que em
algumas aplicações há um stack para cada thread, porém há apenas um heap para todo
o processo. Thread estão vinculados ao processo, pois o processo não deixa de ser um
thread (SCHEFFER, 2007).
Há alguns casos de aplicações em que o controle de thread é realizado
internamente e não há controle do sistema operacional/processador. Tal fato traz algumas
vantagens (como evitar a troca de contexto do SO que tem um custo alto) e
desvantagens (não poder usar outros processadores).
Diferença: Então dependendo de como se analisa, thread pode ser considerado
equivalente a um processo ou não. Do ponto de vista de agendamento do processador
podemos considerar que só existem threads. Simplificadamente, do ponto de vista de
gerenciamento de memória e acesso aos recursos externos, só existe o processo.
Processos são módulos separados e carregáveis, ao contrário de threads, que não
podem ser carregados. Múltiplas threads de execução podem ocorrer dentro de um
mesmo processo. Além das threads, o processo também inclui certos recursos, como
arquivos e alocações dinâmicas de memória e espaços de endereçamento.

4. TESTES - SEGURANÇA E AUDITORIA

Teste de Caixa Branca

O teste da caixa branca possui esse nome pois o testador tem conhecimento da
estrutura da aplicação. É normalmente feito utilizando o código fonte, o que exige certo
conhecimento técnico para ser realizado. Teste de condição: Essa técnica é simples, pois
sua proposta é avaliar se os operadores/variáveis lógicos (booleanos – true/false) estão
consistentes.

Teste de ciclo é dividido em 4 tipos:

O ciclo desestruturado é o conjunto de blocos de repetição utilizados de maneira

desordenada. Já o ciclo simples, como o próprio nome diz, é apenas uma estrutura de
repetição sendo testada. Ciclos aninhados são ciclos dentro de ciclos. E, por último mas
não menos importante, ciclos concatenados são estruturas de repetição dependentes, ou
seja, para testar o bloco 2, eu preciso garantir que o bloco 1 é coerente.

Teste de Caixa Preta

Segundo Inthurn (2001) trata-se em conferir se todas as funcionalidades do

sistema estão de acordo com o esperado. Normalmente é utilizado para encontrar
funções em desacordo ou não existentes, erros nas estruturas ou banco de dados, erros
na interface, erros de desempenho na inicialização e término.

O teste de caixa preta consiste em validar os requisitos funcionais do sistema, o

objetivo é encontrar erros de interface, erros relacionados ao desempenho, ao acesso ao
banco de dados, erros de inicialização e término, falha ou ausência de funções
(PRESSMAN, 1995).

Teste da Caixa Cinza

Segundo NETO (2007) seria um mesclado do uso das técnicas de caixa preta e
caixa branca, mas, como toda execução de trabalho relacionado à atividade de teste
utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os
conceitos primários de cada técnica. O teste da caixa cinza é quando o testador tem um
entendimento parcial da estrutura interna do sistema em teste. O teste de caixa cinza é
um processo para depurar aplicativos de software, fazendo uma entrada pelo front-end e
verificando os dados no back-end.

Sobre Auditoria de Sistemas

Segundo (GIL, 1998): “...é um instrumento da direção da entidade, dos acionistas, do

ambiente externo à organização, do povo para, independemente, opinar, isto é, validar e avaliar a
qualidade em termos de segurança, eficiência dos trabalhos desenvolvidos com a tecnologia dos
computadores.” Apesar de ser mais abrangente do que a definição apresentada pela SEI, esta
definição é bastante influenciada pelos objetivos e características da auditoria contábil, cuja
preocupação básica é com os resultados.
Mais abrangente do que a definição apresentada por (GIL, 1998), é o enfoque
dado por (ARIMA, 1994):

“A função Auditoria de Sistemas tem por finalidade promover a adequação, avaliação e

recomendações para o aprimoramento dos controles internos nos sistemas de informação da
empresa, bem como na utilização dos recursos humanos, materiais e tecnológicos envolvidos no
processamento dos mesmos.”

5. CONCLUSÃO

Com a pesquisa desenvolvida foi possível alcançar o objetivo proposto de estimular

as habilidades e conhecimentos adquiridos no transcorrer do semestre, assim como
aplicar tais conhecimentos em um caso concreto. Foi possível perceber a necessidade de
organização e planejamento no decorrer das etapas que englobam o desenvolvimento de
software, além de vasto conhecimento de ferramentas e métodos que proporcionam
integridade e flexibilidade de utilização do software para o fim do qual foi proposto.

Em vista dos argumentos apresentados, acredito que esta pesquisa contribuiu para
o desenvolvimento do conhecimento e das habilidades propostas, pois como acadêmico
do curso de análise e desenvolvimento de sistemas a presente pesquisa mostrou-se
enriquecedora no que tange o desenvolvimento de habilidades propostas ao longo do
curso assim como no desenvolvimento pessoal do acadêmico enquanto pesquisador.

REFERÊNCIAS BIBLIOGRÁFICAS

MYERS, G.F. The Art of Software Testing. 1a edição, John Wiley and Sons, 1979.

COUTINHO, Bruno Cardoso. Sistemas Operacionais. 2016.

PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, 2011.

SOMMERVILLE, I. Software engineering 9th Edition. ISBN-10, v. 137035152, 2011.

INTHURN, Cândida. Qualidade & teste de software.. Visual Books, 2001.

SCHIMIDT, Paulo; Santos, José Luiz; Arima, Carlos Hideo. Fundamentos de auditoria de
sistemas. p.22. São Paulo: Atlas, 2006.

ABNT - Associação Brasileira de Normas Técnicas. NBR ISO/IEC 9126 - Engenharia de

software - Qualidade de produto, NBR 9126. Rio de Janeiro, 2003.

NETO, Arilo; DIAS, C. Introdução a teste de software. Engenharia de Software Magazine, v. 1, p.

22, 2007.

SCHEFFER, Rosely. Uma visão geral sobre threads. Campo Digital, v. 2, n. 1, 2007.
GIL, Antônio de Loureiro. Auditoria de computadores. 3. Ed. São Paulo : Atlas, 1998.

ARIMA, Carlos Hideo. Metodologia de auditoria de sistemas. São Paulo : Érica, 1994