Desenvolvimento de Software

Variáveis definidas dentro de funções têm seu escopo delimitado pelo corpo da função onde foram
definidas.
O fluxograma passou a ser usado para eliminar ambiguidades dos algoritmos. São símbolos gráficos
padronizados, cada um representado por uma forma geométrica que implica em uma ação, instrução
ou um comando distinto.

 Algoritmo de Peterson. Verdadeiro. O algoritmo de Peterson é um algoritmo de programação concorrente para

exclusão mútua, que permite a dois ou mais processos ou subprocessos compartilharem um recurso sem conflitos, utilizando
apenas memória compartilhada para a comunicação.
Assim como no algoritmo de Dekker, variáveis de curva (curva) e sinalizadores de status (bandeira) são condições ou variáveis
usadas no algoritmo de Peterson. Por causa dessas duas condições, e por causa da espera por uma curva somente se outras
bandeiras forem definidas, a necessidade de limpar e redefinir as bandeiras é evitada. Depois que uma bandeira é definida, a
volta é imediatamente dada ao usar o algoritmo de Peterson.
Exclusão mútua, nenhum progresso e espera limitada são três critérios essenciais usados para resolver o problema da seção
crítica ao usar o algoritmo.

Algoritmo de Dekker. O algoritmo de Dekker permitirá que apenas um único processo use um recurso se dois processos
estiverem tentando usá-lo ao mesmo tempo. O destaque do algoritmo é como ele resolve esse problema. Ele consegue
prevenir o conflito ao impor a exclusão mútua, o que significa que apenas um processo pode usar o recurso por vez e
aguardará se outro processo o estiver usando. Isso é obtido com o uso de dois "sinalizadores" e um "token". Os sinalizadores
indicam se um processo deseja entrar na seção crítica (CS) ou não; um valor de 1 significa TRUE que o processo deseja entrar
no CS, enquanto 0, ou FALSE, significa o oposto. O token, que também pode ter um valor de 1 ou 0, indica a prioridade
quando ambos os processos têm seus sinalizadores definidos como TRUE.
Este algoritmo pode impor com sucesso a exclusão mútua, mas testará constantemente se a seção crítica está disponível e,
portanto, desperdiça um tempo significativo do processador. Ele cria o problema conhecido como sincronização lockstep,
em que cada thread só pode ser executado em sincronização estrita. Também não é expansível, pois suporta apenas no
máximo dois processos de exclusão mútua.

Algoritmo do Padeiro de Lamport. Os princípios operacionais por trás do algoritmo de padaria de Lamport são muito
simples. Todos os threads de processo devem pegar um número e esperar sua vez para usar um recurso de computação
compartilhado ou para entrar em sua seção crítica. O número pode ser qualquer uma das variáveis globais e os processos
com o número mais baixo serão processados primeiro. Se houver empate ou número semelhante compartilhado por ambos
os processos, ele é gerenciado por meio de seu ID de processo. Se um processo termina antes de sua vez, ele deve começar
novamente na fila de processos.

(2) Proxy: Envelopa outro objeto para controlar acesso a ele.

1. O padrão Proxy fornece um objeto intermediário para controlar o acesso a outro objeto, permitindo
que as chamadas sejam filtradas, autenticadas ou manipuladas de outras formas.

(4) Decorator: Envelopa outro objeto e lhe fornece comportamentos adicionais.

1. O padrão Decorator permite que um objeto seja envelopado por outro objeto que adiciona
comportamentos adicionais a ele. Isso é útil quando é necessário adicionar comportamentos a um
objeto existente sem modificar sua estrutura interna.

(1) Adapter: Envelopa um objeto e fornece uma interface diferente para acessá-lo.
1. O padrão Adapter permite que uma classe utilize a interface de outra classe de forma transparente,
sem precisar conhecer a implementação subjacente. Isso é útil quando uma classe precisa interagir
com outra classe que possui uma interface diferente da que ela espera.

(3) Facade: Envelopa um grupo de objetos para simplificar sua interface.

 1. O padrão Facade fornece uma interface simplificada para um conjunto de classes complexas. Ele
encapsula as complexidades dessas classes e fornece uma interface mais fácil de usar para o cliente.
De acordo com Bezerra (2014), durante o desenvolvimento iterativo e incremental de um Sistema de Software Orientado a
Objetos (SSOO), o modelo de classes é utilizado durante a maior parte do processo. Esse modelo evolui ao longo das
iterações do desenvolvimento do sistema e passa por três estágios sucessivos de abstração: Análise, Projeto e
Implementação.

No estágio de Análise, o foco é na compreensão dos requisitos do sistema e na modelagem do domínio do problema. O
objetivo é criar um modelo conceitual que represente os conceitos relevantes do domínio e suas relações.

No estágio de Projeto, o foco é na definição da arquitetura do sistema e na criação de um modelo de design que represente
as classes e objetos que serão implementados no código. O objetivo é criar um modelo que seja eficiente, escalável e fácil de
manter.

No estágio de Implementação, o foco é na codificação das classes e objetos definidos no modelo de design. O objetivo é
criar um sistema funcional que atenda aos requisitos especificados.

Java
Todos os membros de uma interface em Java devem (obrigatório) ser public por padrão e não podem ser definidos com
outro modificador de acesso.

Em geral, os operadores equals() e “==” em Java são usados para comparar objetos para verificar a igualdade. A principal
diferença entre o método .equals() e o operador == é que um é um método e o outro é o operador.

Podemos usar operadores == para comparação de referência ( comparação de endereço ) e método .equals() para
comparação de conteúdo . Em palavras simples, == verifica se ambos os objetos apontam para a mesma localização da
memória, enquanto .equals() avalia a comparação de valores nos objetos.

Vale lembrar que no código da questão também foi utilizado o operador ternário (?:). O que vem depois da interrogação é
verdadeiro e o que vem depois dos dois pontos é o valor para falso.

Diante disso, teremos no código da questão as seguintes operações:

INTEIROS --> n1= 1; n2=1; n3=1; n4=1; n5=1; n6=1

STRING --> n7= "1"

r1=(n1.equals(n2)? 'm': 'b'); --> VERDADEIRO, logo é "m"

r2=(n1.equals(n3)? 'm': 'b'); --> VERDADEIRO, logo é "m"
r3=(n1==n4?'b':'m'); --> VERDADEIRO, logo é "b"
r4=(n1==n5?'b':'m'); --> VERDADEIRO, logo é "b"
r5=(n1.equals(n7)?'m': 'b'); --> FALSO, logo é "b"
r6=(n1==n6?'m': 'b'); --> VERDADEIRO, logo é "m"

Portanto, a mensagem após a execução do programa é: mmbbbm (Letra D).

 Cloud Computing
A realocação de recursos para processos de negócios chave é um benefício do uso de computação
em nuvem, que inclui, ainda, menor necessidade de vultuosos investimentos em TI, aumento da
escalabilidade e flexibilidade no uso de recursos computacionais e redução drástica dos custos de TI.

Características de um padrão de projeto

Embora um padrão seja a descrição de um problema, de uma solução genérica e sua justificativa, isso
não significa que qualquer solução conhecida para um problema possa constituir um padrão, pois
existem características obrigatórias que devem ser atendidas pelos padrões: .
1. Devem possuir um nome, que descreva o problema, as soluções e consequências. Um nome
permiti definir o vocabulário a ser utilizado pelos projetistas e desenvolvedores em um nível
mais alto de abstração.
2. Todo padrão deve relatar de maneira clara a qual (is)problema(s) ele deve ser aplicado, ou
seja, quais são os problemas que quando inserido em um determinado contexto o padrão
conseguirá resolvê-lo. Alguns podendo exigir pré-condições.
3. Solução descreve os elementos que compõem o projeto, seus relacionamentos,
responsabilidades e colaborações. Um padrão deve ser uma solução concreta, ele deve ser
exprimido em forma de gabarito (algoritmo) que, no entanto, pode ser aplicado de maneiras
diferentes.
4. Todo padrão deve relatar quais são as suas consequências para que possa ser analisada a
solução alternativa de projetos e para a compreensão dos benefícios da aplicação do projeto.
Engenharia de Software 
o modelo abaixo mostra um modelo do processo de teste de software.

Segundo Sommerville: "Um conjunto específico de atributos que você pode esperar de um software
obviamente depende da aplicação. Portanto, um sistema bancário deve ser seguro, um jogo interativo
deve ser ágil, um sistema de comutação de telefonia deve ser confiável, e assim por diante." Ele
define esses atributos como:
1. Manutenibilidade: O software deve ser escrito de forma que possa evoluir para atender às
necessidades dos clientes. Esse é um atributo crítico, porque a mudança de software é um
requisito inevitável de um ambiente de negócio em mudança.
2. Confiança e proteção: A confiança do software inclui uma série de características como
confiabilidade, proteção e segurança. Um software confiável não deve causar prejuízos físicos
ou econômicos no caso de falha de sistema. Usuários maliciosos não devem ser capazes de
acessar ou prejudicar o sistema.
3. Eficiência: O software não deve desperdiçar os recursos do sistema, como memória e ciclos
do processador. Portanto, eficiência inclui capacidade de resposta, tempo de processamento,
uso de memória etc.
4. Aceitabilidade: O software deve ser aceitável para o tipo de usuário para o qual foi projetado.
Isso significa que deve ser compreensível, usável e compatível com outros sistemas usados
por ele.
O teste de release é um tipo de teste de software que é realizado antes que uma nova versão do sistema seja liberada para os
usuários. Durante o teste de release, a equipe de teste verifica se o sistema atende aos requisitos especificados e se todas as
funcionalidades estão funcionando corretamente. A equipe de teste pode ser independente ou fazer parte da equipe de
desenvolvimento.

O teste de release pode incluir diferentes tipos de testes, como testes de caixa-preta, testes de caixa-branca, testes de
integração, testes de desempenho e testes de usabilidade. Os testes podem ser derivados das especificações do sistema ou
baseados em cenários de uso ou casos de teste desenvolvidos pela equipe de teste.

O objetivo do teste de release é garantir a qualidade do sistema antes que ele seja entregue aos usuários e evitar problemas
na produção. Além disso, o teste também pode ajudar a identificar possíveis melhorias no sistema para versões futuras.

ITIL

Ciclo de Vida do Serviço de TI da ITIL

a ITIL possui 5 livros e os nome das etapas são:
 1.Service Strategy (Estratégia de Serviços)
2.Service Design (Desenho de Serviços)
3.Service Transition (Transição de Serviços)
4.Service Operation (Operação de Serviços)Operação de serviço
5.Continual Service Improvement (Melhoria Contínua de Serviços)
Cada uma possui explicações de processos, papéis, técnicas, insights e recomendações para uma
boa gestão de TI.

1º Ciclo de Vida do Serviço de TI da ITIL: Estratégia de Serviços

Então, a primeira etapa do ciclo de vida contempla as boas práticas de mercado relacionadas à
concepção do serviço, seja ele novo ou alterado.
Nesse caso, esse estágio desenvolve uma estratégia de TI alinhada com a do negócio, e é capaz de
identificar quais serviços precisamos criar com o intuito de atender as necessidades e demandas tanto
do cliente quanto do negócio.Usando uma estratégia adequada, o provedor de serviços de TI garante
uma correta gestão da perspectiva, planos, posição e padrões necessários para os resultados de
negócio da organização.

2º Ciclo de Vida do Serviço de TI da ITIL: Desenho de Serviços

Posteriormente, a segunda fase é onde o serviço é onde projetamos e desenhamos o serviço para
que cumpra com os seus valores e metas.
No ciclo de vida explicado pela ITIL, os serviços de TI precisam ser projetados com seus objetivos em
mente, pois só assim eles irão gerar valor.
Por isso, o service design liga a estratégia de serviços (primeira etapa) com a entrega dos objetivos
do negócio.
É claro que o desenho de serviço não é apenas o desenho em si, mas também todas as práticas que
o regem, processos, procedimentos e políticas necessárias para realizar a estratégia do provedor de
serviço.

3º Ciclo de Vida do Serviço de TI da ITIL: Transição de Serviços

Na terceira etapa da ITIL, é enfim a hora da prática. Ou seja, é quando inserimos o serviço na vida da
empresa e o ensinamos para a equipe de funcionários.
Também, é nesta fase que alguns clientes avaliam o serviço como objeto de experimentação, assim
determinando-se os prós e contras.
A transição de serviço garante que possamos preparar os novos serviços ou alterados, para atender
às expectativas do negócio, levando em consideração o que acordamos e registramos nas duas
etapas anteriores.
Além disso, essa etapa cuida dos riscos envolvidos para prevenir impactos negativos.

4º Ciclo de Vida do Serviço de TI da ITIL: Operação de Serviços

A fase de operação de serviço visa coordenar e desempenhar as atividades e processos solicitados
para que o serviço se mantenha em um bom estado operacional.
Na ITIL, a etapa é explicada como o momento em que o valor do serviços será finalmente percebido e
avaliado pelos usuários e clientes. Toda a questão operacional já é feita com total eficiência pelos
funcionários.

5º Ciclo de Vida do Serviço de TI da ITIL: Melhoria Contínua do Serviço

Eventualmente, a quinta fase é quando se documenta as melhores práticas solicitadas para melhorar
a eficiência e a eficácia dos serviços e processos, assim como a relação custo-benefício. O foco
dessa etapa é garantir que o serviço de TI continue gerando valor.
Como o serviço está em plena execução, é necessário avaliá-lo, coletar dados e informações, analisar
o tempo de cada processo, lucros, custos e opiniões para determinar estratégias de melhoria e
garantir mais diferencial em qualidade.

PMBOK
De acordo com o PMBOK, os ciclos de vida do projeto podem ser preditivos ou adaptativos. Em um ciclo de
vida do projeto, há geralmente uma ou mais fases associadas com o desenvolvimento do produto, serviço ou
resultado. Essas fases são chamadas de ciclo de vida de desenvolvimento. Os ciclos de vida de
desenvolvimento podem ser preditivos, iterativos, incrementais, adaptativos ou um modelo híbrido. Em um
ciclo de vida preditivo, o escopo, prazo e custo do projeto são determinados nas fases iniciais do ciclo de vida.
Quaisquer alterações ao escopo são cuidadosamente gerenciadas. Os ciclos de vida preditivos são também
chamados de ciclos de vida em cascata.

Tipos de Estruturas Organizacionais

Estrutura Funcional
Na estrutura funcional os funcionários possuem um superior imediato e são agrupados por especialidade, como
produção, marketing, engenharia e contabilidade. Cada setor na organização funcional desenvolve a sua parte do
projeto de modo independente dos outros setores, ficando o projeto sob a responsabilidade dos gerentes de cada
departamento.
 Estrutura Matricial
Conforme o guia PMBOK (2008) as organizações matriciais, herdam as características das organizações
funcionais e projetizadas. Nas matrizes fracas as características da organização funcional são mantidas e o
gerente de projetos desempenha o papel parecido com a de um coordenador ou facilitador. As matrizes fortes
resgatam inúmeras características da organização projetizada podendo ter gerentes de projetos e pessoal
administrativo trabalhando para o projeto em tempo integral, onde o gerente poderá ter uma autoridade
considerável sobre o projeto. Enquanto a organização matricial balanceada reconhece a necessidade de um
gerente de projetos, más não deliberar ao mesmo a autoridade total sobre o projeto e sobre seu financiamento.
Estrutura Projetizada
Na estrutura projetizada a maior vantagem é que a autoridade total sobre o projeto está nas mãos do gerente de
projeto, este por sua vez define as tarefas que devem ser realizadas e os meios de controle, desta forma, cada
indivíduo se reporta à apenas uma pessoa o que reduz os canais de comunicação possibilitando repostas mais
rápidas pela equipe de projeto.
Para Mulcahy (2009), em uma organização por projetos, toda empresa é organizada por projetos. O gerente de
projetos detém o controle sobre os projetos. O pessoal é designado e fica subordinado a um gerente de projeto. As
vantagens são organização eficiente de projetos, fidelidade ao projeto e comunicação mais eficaz do que a
funcionais. Enquanto as desvantagens são não há “lar” quando o projeto é terminado, falta de profissionalismo
em disciplinas, duplicação de instalações e funções e uso menos eficaz do recurso.
Está é a forma de organização da maioria das empresas que são “orientadas por projeto”, como empresas de
construção pesada, empresas que constroem e vendem grandes equipamentos, navios, etc. Nesta forma de
organização temos a figura do gerente de projeto que conserva o cargo mesmo após o término do projeto. Ele
possui total autoridade sobre o projeto, podendo requisitar recursos de dentro ou de fora da organização (Prado,
2000).

, cita as vantagens e desvantagens da estrutura projetizada:

As Vantagens:
•Flexibilidade na utilização dos recursos de requeridos no projeto;
•Integração de especialistas específicos em diferentes projetos;
•Troca de experiências e conhecimento entre os especialistas de um mesmo departamento;
•Possibilita uma rotatividade pessoal com manutenção do conhecimento tecnológico no departamento;
•Facilidade de controle do orçamento e dos custos do projeto;
•Hierarquia bem definida existindo apenas um gerente imediato;
•Facilidade de comunicação devido à verticalização da mesma;
As desvantagens:
•O cliente não é priorizado pelo departamento que gerencia o projeto;
•Orientação do departamento funcional direcionada para as suas atividades específicas;
•Inexistência do Gerente específico responsável pelo Projeto;
•Lentidão das respostas perante as necessidades dos clientes;
•Desmotivação e ou motivação reduzida dos gerentes do projeto em relação ao mesmo;
•Favoritismo nas tomadas de decisões em favor dos grupos funcionais mais fortes;
Prado (2000) acrescenta como vantagem que está forma de organização é recomendada para projetos grandes e
de longa duração, por despertar grande motivação para o cumprimento das metas. Oferece ainda uma forte
motivação para carreira do gerente do projeto, por possuir uma grande autoridade, o que lhe facilita na melhor
forma de gerenciamento do projeto.
Como desvantagem principal refere-se ao surgimento de conflitos na equipe conforme se aproxima o fim do
projeto e surgem incertezas com respeito às futuras designações de trabalho. Em empresas orientadas para
operações rotineiras, nem todos gostam de ser retirados de sua área funcional para se dedicarem a algum projeto,
tendo em vista as incertezas no momento de retorno, ou as perdas e oportunidades na área funcional, como
resultado de sua ausência temporária conforme relata Prado (2000).
Outra desvantagem deste tipo de organização de acordo com Prado (2000) reside na questão de custos, aspecto
muito visível em empresas orientadas para operações rotineiras. A criação de um setor unicamente voltado para
um ou para mais projetos implica duplicação de alguns recursos. É possível também que os recursos fiquem
presos ao projeto mesmo quando não são mais necessários e poderiam estar sendo utilizados em alguma área
funcional da empresa.
Conclusão
O que uma estrutura projetizada irá possibilitar é uma administração efetiva garantindo que os projetos de uma
organização sejam alinhados com os objetivos da mesma, proporcionando os meios pelos quais a diretoria e
outros principais stakeholders de um projeto sejam alimentados com informações relevantes e confiáveis no
momento exato.
Concluindo, não existe uma estrutura perfeita, nem a melhor estrutura para desenvolvimento de projetos, o que
existe é a necessidade da organização, a complexidade do projeto e seu nível de maturidade. Gerenciar projeto
em prol de uma empresa orientada por projetos requer o desenvolvimento de suas estruturas, mudança do
processo organizacional e principalmente apoio da diretoria (planejamento estratégico).
Por fim, espera-se que o trabalho, tenha conseguido agregar informações úteis no que diz respeito a uma estrutura
projetizada, assim como as suas vantagens e desvantagens e que essas informações possam contribuir para
melhor entendimento e contribua para o gerenciamento de projetos com sucesso.

Redes de Computadores
IPV6 -
O IPv6 tem menos campos de cabeçalho a serem preenchidos frente ao cabeçalho Ipv4.
É possível definir um endereço IPv6 a partir do endereço MAC para a parte referente ao host.
Pode haver mais de um cabeçalho de extensão.
O endereço IPv6 correspondente ao IPv4 127.0.0.1 é igual a ::1/128.

protocolo IEEE 802.11 WLAN

Distribuição.provê a entrega de quadros através de Access Points
integração (“B”) refere-se à possibilidade de conexão do sistema de distribuição a uma rede não-IEEE 802.11.
Associação (“C”) refere-se ao fato de estações se registrarem em Access Points.
Dissociação (“D”) refere-se à ação da subcamada MAC para detectar estações que saem da rede sem
dissociação formal, e disassociar estas máquinas da rede.
Privacidade (“E”) refere-se ao sigilo dos dados transmitidos.

meios físicos de transmissão

Os meios físicos guiados mais utilizados são cabos metálicos e fibras ópticas.
Diferem entre si, com relação à bandwidth e taxa de transferência de dados, dentre outros fatores.
apacitância é uma grandeza elétrica, portanto é um parâmetro pertinente a cabos metálicos.
Ruído térmico é uma distorção aleatória que pode e deve ser tratada.
fibras ópticas não sofrerem perturbações elétricas. Indutância é um parâmetro elétrico.
REDES CAMADAS
Os algoritmos usados na camada k afetam apenas a implementação daquela camada, sem impactar as camadas adjacentes.
Os protocolos e as interfaces entre as camadas superiores e inferiores permanecem os mesmos, o que significa que uma
mudança na camada k não afetará a funcionalidade dessas camadas.

Os algoritmos usados na camada k afetam apenas a implementação daquela camada, sem impactar as camadas adjacentes.
Os protocolos e as interfaces entre as camadas superiores e inferiores permanecem os mesmos, o que significa que uma
mudança na camada k não afetará a funcionalidade dessas camadas.

Mudanças nos serviços fornecidos por uma camada podem sim afetar as camadas superiores. Por exemplo, se a camada k
fornecer um serviço de maior qualidade ou de maior capacidade, as camadas superiores podem tirar proveito dessas
melhorias. Da mesma forma, se a camada k reduzir a capacidade do serviço, as camadas superiores podem precisar ajustar
sua funcionalidade para acomodar a nova limitação.

Mudanças nos serviços fornecidos por uma camada podem sim afetar as camadas superiores. Por exemplo, se a camada k
fornecer um serviço de maior qualidade ou de maior capacidade, as camadas superiores podem tirar proveito dessas
melhorias. Da mesma forma, se a camada k reduzir a capacidade do serviço, as camadas superiores podem precisar ajustar
sua funcionalidade para acomodar a nova limitação.

Analise de dados
 áreas de foco o alinhamento entre a Governança de dados
Políticas, Normas e Estratégia.
Qualidade de dados.
Privacidade, Compliance e Security.
Alinhamento entre a Governança de TI e projetos.

Os algoritmos de agrupamento podem ser divididos nas seguintes categorias:

Métodos Hierárquicos;

Métodos Particionais;

Métodos Baseados em Densidade;

Métodos Baseados em Grade;

Métodos Baseados em Modelos;

Métodos Baseados em Redes Neurais;

Métodos Baseados em Lógica Fuzzy;

Métodos Baseados em Kernel;

Métodos Baseados em Grafos;

Métodos Baseados em Computação Evolucionária.

Segurança da Informação
o protocolo padrão para o gerenciamento de chaves pelo IPSec é o: IKE
Antes que se possa utilizar o IPSEC, é necessário que eles estabeleçam associações de segurança (SA) entre si,
ou seja, uma SA para cada direção da comunicação.
Para o estabelecimento da AS (Associação de Segurança), o IPSEC utiliza o protocolo Internet Key Exchange
(IKE), que é baseado no algoritmo de troca de chaves Diffie-Hellman. O IKE utiliza o protocolo da camada de
transporte UDP, e tem a porta 500 como padrão.

Vale lembrar que o uso do IKE é recomendado, e não obrigatório. Ou seja, pode-se usar outros algoritmos de
troca de chaves.
Linux
( I ) O recurso ">" (maior que) redireciona a saída de um comando para um arquivo ou para um dispositivo. No caso do
redirecionamento para arquivos, se já houver conteúdo, ele substitui todo o conteúdo do arquivo pelo o que foi
redirecionado.

( II ) O recurso ">>" (maior que duplo) é similar ao ">", a diferença é que ao invés de sobrescrever um arquivo ele adiciona o
conteúdo ao final do arquivo, mantendo o conteúdo que já existe no arquivo.

( III ) O recurso "|" (pipe) é usado para redirecionar a saída de um comando para outro comando, por exemplo: "ls
/home/user | grep teste" (a saída do comando "ls" foi redirecionada como entrada para o comando "grep").
O comando umask (abreviado de user mask (máscara de usuário) é um comando e uma função em ambientes POSIX que determinam
as permissões padrão para novos arquivos e diretórios criados. Ele é diferente do chmod.

Vamos as permissões:

1.0 – ler, escrever e executar

2.1 – ler e escrever
3.2 – ler e executar
4.3 – somente ler
5.4 – escrever e executar
6.5 – somente escrever
7.6 – somente executar
8.7 – sem permissões

Dessa forma,
1.O dono tem permissão de ler, gravar e executar. Assim, é o valor 0.
2.O grupo tem permissão de ler e executar. Assim, é o valor 2.
3.Os outros usuários terão permissão de execução somente. Assim, é o valor 6.

Portanto, o valor do umask é 026, ou seja, umask 026.

O formato de cada linha segue o seguinte padrão:

(minuto) (hora) (dia do mês) (mês) (dia da semana) (usuário) (comando/script)

Então, vamos entender a questão:

Vai ser as 23h, todos os dias, localizada em /usr/meusscripts/meubackup

Com isso, vai ser

(minuto) (hora) (dia do mês) (mês) (dia da semana) (usuário) (comando/script)

0 23 * * * root /usr/meusscripts/meubackup
Quando utiliza o * (asterisco) quer dizer todos os dias. Assim, será todos os dias do mês, todos os meses, todos os dias da semana e o
usuário é o root.

Business Intelligence (Análise de dados) 

 Drill up, que consiste em aumentar o nível de granularidade dos dados, passando de um nível mais detalhado para um nível
mais agregado, permitindo uma visão mais ampla dos dados.
Drill down (diminuir o nível de granularidade),

Roll down (mudar a dimensão que está sendo analisada para uma de nível inferior),
Drill across (analisar dados de outras dimensões) e
Roll through (avançar para o próximo período de tempo em uma dimensão).

Banco de dados
Durante o processo de recuperação de falhas de transação, a operação UNDO é responsável por reverter as alterações feitas
pelas transações incompletas que foram afetadas pela falha, enquanto a operação REDO é responsável por reaplicar as
alterações feitas pelas transações concluídas que foram perdidas devido à falha.

Para garantir o comportamento correto durante a recuperação, as operações UNDO e REDO devem ser idempotentes. Isso
significa que se essas operações forem aplicadas várias vezes, o resultado final será o mesmo que se elas fossem aplicadas
apenas uma vez.

Gradiente descendente é um dos algoritmos de maior sucesso em problemas de Machine Learning. O método consiste em
encontrar, de forma iterativa, os valores dos parâmetros que minimizam determinada função de interesse.

A. CORRETA - O Gradiente Descendente é um algoritmo que busca minimizar uma função, e se essa função tiver uma única
mínima global, o procedimento de Gradiente Descendente a encontrará.

. CORRETA - Usar consultas parametrizadas impede que a consulta seja alterada porque os valores dos parâmetros são
combinados com a declaração compilada e não concatenados diretamente na sequência de caracteres que compõem a
consulta SQL.

II. CORRETA - Para proteção de dados é importante não armazenar senhas, strings de conexão ou outras informações
confidenciais em texto claro/legível ou em qualquer forma criptograficamente insegura no lado cliente. As strings de conexão
devem estar em um arquivo de configuração separado, armazenado em um sistema confiável e as informações devem ser
criptografadas.

IV. CORRETA - A auditoria das contas criadas é interessante para a desativação das contas que não sejam mais necessárias
para os requisitos de negócio, assim diminuindo o risco associado a essas contas.

Servidores WEB
A OWASP (2012) recomenda a prática de prevenir a divulgação da estrutura de diretórios impedindo que robôs de busca
façam indexação de arquivos sensíveis, através da configuração do arquivo "robots.txt", não "security.txt".

O arquivo "security.txt" não existe e não é utilizado para essa finalidade.

Governancia de t.i
A etapa do ciclo da Governança de TI que tem, dentre outros componentes, Gestão da Demanda, Necessidades de aplicações
e Sourcing é a etapa de Alinhamento Estratégico e Compliance.
O Alinhamento Estratégico e Compliance são a primeira fase do ciclo de vida da Governança de TI. O Alinhamento
Estratégico é uma prática que garante que os processos de negócio e de tecnologia da informação trabalhem
conjuntamente. Em outras palavras, determina o alinhamento da organização e da TI em relação às necessidades do negócio.

O Compliance envolve a conformidade com leis, regulamentações e padrões aplicáveis. É importante para garantir que a
empresa esteja cumprindo todas as normas e regulamentações relevantes em relação ao uso de tecnologia da informação.