Você está na página 1de 9

Aula 1: Engenharia de Requisitos

Engenharia de requisitos: elicitação, análise, especificação e validação de requisitos de software.


As fases posteriores da construção de um software serão baseadas nos requisitos definidos nesta fase.
Analista de negócio: coleta, especifica, valida e implementa sistemas, de acordo com as necessidades.
Os stakeholders devem fornecer todas as informações relevantes para a implementação do sistema.
Os requisitos são compostos por necessidades de várias pessoas e de diferentes níveis organizacionais.
4 fases: elicitação, documentação, validação/negociação e gerenciamento de requisitos.
O engenheiro de requisitos deve ser o elo ou interlocutor entre os negócios e a tecnologia.
Raciocínio analítico, empatia, comunicação, moderação, resolução de problemas, autoconfiança e persuasão.
Requisitos funcionais descrevem o que deve ser feito: permitir cadastro de veículos.
Requisitos não funcionais (de qualidade) estão relacionados ao ambiente no qual o software deve permanecer.
 O sistema deve ter disponibilidade de uso 24 horas por dia.
Modelo Cascata: uma fase não se inicia antes que outra tenha sido concluída, aprovada e documentada.
Modelo incremental: Atividades intercaladas e a fase de requisitos é permanente no desenvolvimento do software.
Processos ágeis: Aceita mudança de requisitos, mesmo do fim do desenvolvimento. Mais próximo aos stakeholders.
Documentação de requisitos incompleto pode tornar o processo de desenvolvimento difícil e custoso.

Aula 2: Planejamento e Monitoramento da Análise de Requisitos

Análise das partes interessadas depende da identificação da necessidade de negócio.


 A identificação das partes interessadas é tarefa fundamental da engenharia de requisitos.
 Por meio de brainstorming, entrevistas, modelagem organizacional e de processos, workshops de requisitos etc.
 A lista de requisitos das partes interessadas deve ser periodicamente atualizada e quando necessário, revisada.
 Lista deve conter os papéis, nome e cargo das partes interessadas, categoria, localização, descrição da influência etc.
A complexidade das partes interessadas: número e variedade de usuários / número de processos de negócio.
 A atitude e a influência com as partes interessadas deve auxiliar na viabilidade dos relacionamentos.
Gerenciamento das partes interessadas exige habilidades de comunicação contínua. Cada um tem sua visão dos benefícios.
Matriz nível de influência Vs. Nível de interesse e Diagrama Cebola
Planejamento da comunicação da análise de negócios: o que, como, para quem e quando as comunicações devem ocorrer.
Comunicação: tipos de requisitos, geografia, cultura, tipo de projeto, frequência e formalidade nas comunicações.
Planejamento do gerenciamento de requisitos: para aprovar requisitos e para gerenciar as mudanças no escopo.
Gerenciamento do desempenho da análise de negócios: para escolha das métricas que irão nortear o trabalho executado.

Aula 3: Análise Corporativa

Identificar uma necessidade, um problema ou uma oportunidade de negócio. Definir uma solução para isso.
Justificar o investimento que será feito. Avaliar a capacidade organizacional.
Determinar o escopo da solução e documentar os requisitos necessários para que a solução seja aplicada.
O analista de negócios deve definir o problema, questionar as suposições e restrições e garantir a solução correta.
Para iniciar a análise corporativa: metas e objetivos, técnicas para achar os problemas e as partes interessadas.
 Os objetivos devem ser SMART (específicos, mensuráveis, alcançáveis, relevantes e com prazo viável para conclusão).
 Técnicas para identificação de problemas: benchmarking, brainstorming, análise de regra de negócio, RCA etc.
Partes interessadas: especialista em implementação, patrocinador, especialista no domínio, usuários finais, clientes etc.
Para avaliar novas capacidades é necessário avaliar primeiro, as capacidades atuais da organização.
Entradas: necessidade de negócio, arquitetura corporativa e avaliação do desempenho da solução.
Técnicas: análise de documentos e SWOT (análise de forças e fraquezas / oportunidades e ameaças).
A definição da solução deve possibilitar que as partes interessadas compreendam quais novas capacidades serão entregues.
A solução identificada precisa trazer maior valor agregado à organização, ser eficaz e factível de ser implementada.
A declaração do problema deve conter a descrição do problema, pontos afetados, impactos e os benefícios.
Aula 4: Gerenciamento e comunicação de requisitos

Permite gerenciar e expressar os requisitos para as partes interessadas.


Gerenciar o escopo e os requisitos da solução e a rastreabilidade dos requisitos.
 Referencias textuais e hyperlinks, matriz de rastreabilidade e grafos de rastreabilidade.
Documentos de rastreabilidade trazem agilidade nos cenários de poucos requisitos.
Manter requisitos para a reutilização.
Requisitos recorrentes: são utilizados com frequência e devem ser armazenados em um repositório.
 Obrigações contratuais, padrões de qualidade, regras ou processo de negócio, acordos de nível de serviço etc.
Preparar o pacote de requisitos: para comunicação efetiva dos requisitos e atendimento dos requisitos.

Aula 5: Análise de requisitos

Modelagem de requisitos: especificação de requisitos deve apresentar os requisitos de forma sistemática.


Documentação deve combinar linguagem natural com modelos conceituais.
O tipo de informação e os receptores que definem qual o tipo de documentação a ser utilizada.
Linguagem natural: formato de prosa livre e conta com a versatilidade da língua, mas pode gerar ambiguidades.
Modelos conceituais: definem um problema, definem as fronteiras de negócio e reduzem a ambiguidade.
 Diagramas de caso de uso, de classes, de atividades e de estados, para representar requisitos.
Escrever um bom conjunto de requisitos: expressar um requisito de cada vez, escrever em voz ativa, parágrafos curtos etc.
Técnicas: análise de regras de negócio, dicionário de dados e glossário, decomposição funcional, histórias de usuários etc.
Restrições são determinadas como limitações às possíveis soluções. O analista de negócios deve documentá-las.
As preocupações das partes interessadas devem ser usadas como entrada das restrições técnicas e de negócio.
Verificação de requisitos: para garantir que os modelos de requisitos atendam ao padrão necessário de qualidade.
Validação de requisitos: consiste em garantir que todos os requisitos entreguem valor para o negócio.
 A fase V&V de requisitos evita a proliferação de um erro.
Requisito de alta qualidade: coesão, completude, consistência, viabilidade, testabilidade, adaptação, não ambiguidade etc.
Critérios para validar requisitos: identificar suposições, determinar o valor para o negócio, analisar benefícios etc.

Aula 6: Avaliação e validação da solução (BABOK)

O analista de negócios deve avaliar as soluções propostas, para determinar se elas atendem às partes interessadas.
É necessário determinar se a solução entrega valor de negócio suficiente, para justificar sua implementação.
Suposições e restrições devem ser levadas em consideração.
Caso nenhuma solução (possível) entregue valor suficiente, então, uma recomendação de abandono deve ser dada.
Os requisitos de transição são relevantes durante o período de transição ou de uma migração entre soluções.
 Descrevem capacidades que devem desenvolvidas para que a transição entre as soluções seja bem-sucedida.
Validação da solução: para garantir o atendimento das necessidades de negócio e as resoluções dos defeitos.
 Investigar saídas defeituosas e avaliar defeitos e incidentes.
Avaliação do desempenho da solução: verificar o valor entregue, por meio das soluções em funcionamento.
 Compreender o valor entregue pela solução e validar as métricas da solução.
Tarefas pós-implementação: verificar se todos estão usando a solução e se a solução está trazendo os resultados esperados.
O analista de negócio deve identificar as possíveis modificações feitas pelos usuários finais e validar as métricas da solução.
Aula 1: Introdução aos processos de software
Sistema: coleção de componentes organizados para atender a uma função ou conjunto de funções.
Software: composto por instruções, estrutura de dados e documentos.
Produto de software: conjunto completo de softwares, procedimentos e documentação associada, para liberação ao cliente.
Produto de trabalho de software: conceito mais amplo, pois engloba os produtos de software e os resultados de projeto.
Processo de software: sequência de estados de um sistema que se transforma. Conjunto de etapas com um propósito.
 Conjunto de atividades, transformações, métodos e práticas aplicadas ao desenvolvimento e manutenção de Sw.
 Qualquer processo conta com pessoas, ferramentas e procedimentos.
A norma ISO/IEC 12207: estabelece uma estrutura comum para processos de ciclo de vida de sistemas e software.
Processos contextuais de sistema: fornecem subsídios para lidar com um produto de software ou sistema.
 Processos contratuais, organizacionais capacitadores de projeto, de projeto e técnicos.
Processos específicos são utilizados na implementação de um produto ou serviço, como elemento de um sistema maior.
 Processos de implementação de software, de apoio ao software e de reuso de software.
Modelos de processos de Sw: representação abstrata de um processo. Cascata, desenvolvimento iterativo, V, espiral e ágil.
Cada organização deve avaliar suas práticas, necessidades e características, para a aplicação das práticas da norma 12207.
A qualidade de software advém, sobretudo, da qualidade do processo de software.
A gerência de processo de software inclui definição e execução do processo, coleta de dados, análise e controle do processo.
Para a melhoria do processo de Sw: tratamento analítico (identificar onde as melhorias são necessárias) e benchmarking.
Um processo definido necessita ainda mais fortemente de pessoas preparadas para implementá-lo.
A qualidade do local de trabalho deve ser usada como instrumento para a qualidade do processo de desenvolvimento.
Estratégias diferentes para a melhoria de processo. Top-down Vs. Bottom-up.
 Top-down: tem como base a comparação entre o processo da organização, com um processo padrão reconhecido.
 Bottom-up: realiza mudanças a partir de um conjunto de metas, características de produto e experiências locais.
Medições e métricas devem ser utilizadas no tratamento objetivo da melhoria do processo de software.

Aula 2: Engenharia de Requisitos


Domínio do problema: tem relação com o domínio no qual o sistema será utilizado. Inicia-se com um vago objetivo.
Domínio da solução: refere-se ao conhecimento utilizado pelos engenheiros, para resolver determinado problema.
A transição de um domínio para outro, trata-se de uma questão de comunicação, entre 2 profissionais de áreas diferentes.
Análise de negócios: conjunto de atividades e técnicas utilizadas para servir de ligação entre as partes interessadas.
 Surgiu da necessidade de obtenção de sistemas que atendessem as reais necessidades das empresas.
 Por meio da compreensão do contexto, essa prática habilita mudanças em uma organização ou empresa.
Para definição de um processo de análise de negócios (BABOK): elicitação e colaboração, análise estratégica e de requisitos.
Engenharia de requisitos: para identificação e tratamento dos requisitos. Gerenciamento e comunicação de requisitos.
 Surgiu da preocupação com os requisitos, para se chegar ao código.
Planejamento das atividades de requisitos -> análise de negócios -> levantamento -> análise -> V&V -> especificação de Sw.
Trata de identificar quais são as pessoas envolvidas com o projeto em estudo e mapear as atividades a serem desenvolvidas.
Ao final, a validação de requisitos é realizada para identificar se os requisitos especificados foram implementados no Sw.
 A matriz RACI (responsável, acusável, consultado e informado): para identificação do papel e o tipo de participação.
Processos de apoio: Gerenciamento de requisitos e comunicação de requisitos.
Um cuida do registro e da rastreabilidade dos requisitos. O outro é um processo muito importante em projetos grandes.
Compreensão do negócio: tem por objetivo atender as necessidades do negócio, para o levantamento de requisitos.
 É importante saber como a organização funciona, quais são seus objetivos e quais serão os benefícios com o novo Sw.
 Descrição geral e estrutura da organização e entendimento dos objetivos, metas e fatores críticos de sucesso.
Levantamento de requisitos: para se obter o conjunto de requisitos do software a ser desenvolvido.
Técnicas: análise de documentos, avaliação de outros softwares, entrevistas, grupo focal, brainstorming, observação etc.
 Cada requisito deve ser identificado de forma única, ter sua origem definida e deve ser rastreável.
Critérios: atomicidade, unicidade, viabilidade, clareza, precisão, verificabilidade e abstração.
Análise de requisitos: lida com o grande número de informações descobertas na fase de levantamento de requisitos.
Os requisitos devem ser organizados, classificados, agrupados e priorizados (Moscow: must, should, could, won’t).
CRUD (create, read, update, delete): técnica muito utilizada para os elementos persistentes.
Classificação em relação à qualidade dos requisitos (ISO/IEC 25000): funcionalidade, confiabilidade, usabilidade, eficiência.
Verificação e validação de requisitos: identificar possíveis erros e verificar se os requisitos estão atendendo à finalidade.
Especificação de software: entrada para a equipe de desenvolvimento realizar sua atividade de projeto de software.
Aula 3: Processo unificado (UP) / RUP
UP: nome genérico que abarca um conjunto de modelos de processo. Orientado a objetos e crescentemente utilizado.
 Iterativo, incremental e orientado a casos de uso. Visa tratar riscos o mais cedo possível e reconhece riscos.
 Compreende atividades combinadas em workflows. Cada workflow descreve como uma atividade alimenta a outra.
 As disciplinas são organizadas em iterações. Cada iteração identifica algum aspecto do sistema a ser considerado.
 As iterações são organizadas em fases que se repetem. As fases são agrupadas em ciclos. Os ciclos geram liberações.
Planejar um pouco, especificar, projetar e implementar um pouco. Integrar, testar e rodar. Obter feedback a cada iteração.
 O modelo de casos estabelece as funcionalidades do sistema e orienta todas as atividades do processo.
Fases: concepção, elaboração, construção e transição. Nove workflows ou disciplinas.
Engenharia de Sw: modelagem de negócios, requisitos, análise e design, testes e implementação.
RUP: Refinamento do UP, pela IBM. Usa uma série de ferramentas ao longo da estrutura de processo.
 Define como realizar as atividades necessárias para rodar um projeto de software, dando condições de adaptações.

Aula 4: Análise e projeto orientados a objeto


Método de modelagem que garante a integridade conceitual nas mais diferentes fases. Qualidade.
A modelagem OO busca facilitar a comunicação entre desenvolvedor e usuário, utilizando símbolos, conceitos e ferramentas.
Conceitos fundamentais: associação, ator, classe, classificador, componente, comportamento, herança, interface e objeto.
 A modelagem OO constitui um processo sistemático e semanticamente cuidadoso de abstração da realidade.
UML: Representa sistemas de forma padronizada. Linguagem de modelagem visual. Relação clara/natural com o mundo real.
 Usada para especificar, visualizar, construir e documentar artefatos de um sistema de software.
Nenhum processo é definido. Apenas apresenta uma simbologia para representar as decisões.
Os modelos são descritos por intermédio de diagramas. Cada diagrama oferece uma visão parcial do sistema desenvolvido.
Diagramas estruturais: Estrutura estática do sistema e suas partes, nos diferentes níveis de abstração e implementação.
Diagramas comportamentais: Mostram o comportamento dinâmico dos objetos ou as mudanças através do tempo.
O projeto OO realiza a decomposição OO, utilizando a UML para descrever os modelos, logico e físico, estáticos e dinâmicos.
O modelo de requisitos utiliza diagramas de casos de uso e descreve os requisitos funcionais e não funcionais.
A modelagem de análise parte do modelo de requisitos e visa conhecer melhor o problema que se pretende resolver.
Objetivos: modelar os conceitos de forma precisa, verificar a qualidade dos requisitos e detalhar os conceitos envolvidos.
Requisitos, análise, projeto, construção e avaliação. Os conceitos são representados pelos objetos e as classes do sistema.
Relacionamentos entre as classes: agregação, composição, associação simples e generalização.
Os atributos representam as propriedades ou qualidades da classe. Os métodos representam as ações que a classe realiza.
Modelagem do projeto: todos os atributos precisam ser definidos e detalhados. Diferentes tipos e formatos de atributos.
Os métodos também são desenvolvidos e detalhados no projeto. O projeto detalha o modelo dinâmico do sistema.
Diagrama de sequência: detalhamento para os diferentes casos de uso. Diagrama de colaboração: interações em grafo.

Aula 5: Modelo V, Verificação e Validação


Contribuem para a entrega de produtos de alta qualidade.
Verificação assegura que o produto é construído corretamente. Validação assegura que o produto certo é construído.
 Atividades e práticas do V&V: análise, avaliação, revisão técnica, prototipagem, simulação, inspeção e testes.
Modelo V: Para compreender os testes de software de uma maneira abrangente. Originário da engenharia de sistemas.
Lado esquerdo: Definição dos reqs, projeto funcional do sistema, projeto técnico do sistema e especificação de componente.
 Fase de decomposição e definição das partes que compõem o sistema.
Lado direito: Teste de componente, teste de integração, teste de sistema e teste de aceitação.
 Etapa de integração e recomposição na qual o sistema é construído e são realizadas verificações, testes e validações.
Existe uma correspondência entre os lados: 4 tarefas em cada lado. Da tarefa do lado esquerdo, sai a tarefa do lado direito.
A verificação é realizada durante todo o processo de desenvolvimento, por meio de revisões, simulações e testes.
O CMMI propõe: preparar a verificação, realizar revisões por pares e verificar produtos de trabalho selecionados.
 peer review, walkthrough, revisão informal, FTR, por meio de simulações e por testes (de unidade e de integração).
Testes de regressão são realizados quando uma modificação é realizada em um projeto, determinando uma nova versão.
Atividades de validação são realizadas em várias etapas do projeto. A visão que se sobrepõe é a do usuário final (cliente).
O CMM propõe: preparar a validação, validar o produto e os componentes do produto. Os critérios saem nas primeiras fases.
 Prototipagem, testes de sistema, de aceitação, testes alfa e beta, testes de validação e revisões técnicas formais.
As atividades de V&V contribuem para que a cultura da qualidade se consolide nas organizações que as aplicam.
IV&V: Verificação e validação independentes, realizadas por uma organização de terceira parte.
Aula 6: Testes de Software
Encontrar e corrigir erros de software depois da entrega é muito mais caro, do que durante as fases de requisitos e projeto.
Objetivo das atividades de testes: encontrar erros o mais cedo possível e garantir que eles sejam corrigidos.
 Erro é alguma coisa feita no código que provoca uma saída não esperada do software. Bug.
 Falha é a manifestação do erro, quando o software é executado. Failure.
A ISO usou padronizações de atividades de testes para elaborar a série de normas 29119, voltada para testes.
 Apresentar vocabulário, definir um modelo genérico de processo, contém modelos e exemplos de documentação;
 Define as técnicas de projeto de testes, para testes dirigidos por palavra-chave.
Maturidade em testes de software: TIM, TPI e TMM (admite 5 níveis de maturidade, baseados no CMMI).
Classificação dos testes: caixa preta (considera apenas entradas e saídas) e caixa branca (considera como o Sw foi construído).
Tipos de testes: estáticos, dinâmicos, unitários, de integração, de sistema e de regressão. Funcionais e não funcionais.
Estrutura e finalidade: garantir que o produto seja estruturalmente sólido e que funcione corretamente. Pass vs. Fail.
Em aplicações maiores, as empresas fazem a contratação de terceiros, para o processo de desenvolvimento de testes.
Ferramentas de testes: para gerenciamento e controle, para testes de especificação, para diferentes tidos de testes.
Integração contínua (IC): prática do XP, garante que pequenas partes sejam adicionadas e fiquem prontas, o quanto antes.

Aula 7: Gestão da Qualidade


Para executar e controlar atividades da qualidade. É um tema mais abrangente do que consequência de um bom processo.
As empresas mais estruturadas possuem uma equipe da qualidade. Os custos com qualidade devem estar equilibrados.
Diagrama da trilogia de Juran: controle da qualidade, planejamento da qualidade e melhoria da qualidade.
A partir dos anos 20: qualidade surgiu por meio de inspeções, depois controle estatístico e controle da qualidade total.
A gestão da qualidade total é uma atividade mais recente, devido ao mercado complexo e alta competição.
TQM: estabelece um sistema de melhoria contínua, com base na busca de satisfação do cliente e análise do mercado.
Qualidade de Sw: reqs funcionais e de desempenho explicitamente declarados e padrões de desenvolvimento documentados.
No ponto de vistas das pessoas: defeito 0, com grande núm. de funções, código elegante, alto desempenho, baixo custo etc.
A empresa de hoje, para destacar-se, precisa mover-se na direção da prevenção de defeitos e não na detecção e remoção.
Alta qualidade em software e melhoria: gerência de processo e gerência do produto. Estas visões são complementares.
Planejamento da qualidade: as atividades da qualidade precisam ser inseridas com as atividades do projeto, como um todo.
Controle da qualidade: é realizado a partir dos dados históricos de projetos anteriores.
Melhoria da qualidade: tem por objetivo reduzir defeitos, definir ações e visa mudar a empresa de patamar.
Garantia da qualidade: visa fiscalizar se as atividades da qualidade estão sendo realizadas adequadamente.
SQA: verificação, validação e garantia da qualidade de software.
PPQA (process and product quality assurance): avaliar objetivamente processos e produtos de trabalho. Fornecer visibilidade.

Aula 8: Melhoria contínua do processo


É importante a realização de medições, para se saber objetivamente qual foi a profundidade da melhoria.
Trilogia de Juran: comparação entre o que é esperado que seja feito e o que realmente é feito. Divergência = Necessidades.
Medições do processo: permitem identificar as atividades relacionadas à construção do Sw. Ex.: Núm. De horas trabalhadas.
Medições de produto: referentes ao produto que está sendo construído. Ex.: Núm. de erros na fase de testes.
GQM (goal question metrics): identifica as metas e realiza perguntas que são respondidas com as medições a serem feitas.
PSM (practical Sw & Sys. measurement): oferece as informações quantitativas, requeridas para a tomada de decisões (TD).
Processo de medição: envolve a necessidade das pessoas se disciplinarem para registrar os dados e usar as medições p/ TD.
Modelos de referência: CMMI, MPS.BR e norma NBR ISO 29110.
O CMMI considera que a organização evolui no tempo e elabora suas atividades com mais maturidade e com mais qualidade.
CMMI-DEV: possui 5 níveis, numerados de 2 a 5. O 1 corresponde a fase inicial de todas as empresas.
 2: foco na gerência de projeto, 3: processo definido, 4: processo gerenciado quantitativamente e 5: melhoria contínua.
Modelo muito robusto e apropriado para o desenvolvimento de aplicações de Sw que requerem alta qualidade.
MPS.BR: nasceu como uma alternativa ao CMMI. Conta com 7 níveis, nomeados de G até A. Tem equivalência com CMMI.
 G: parcialmente gerenciado e F: gerenciado (2)
 E: parcialmente definido, D: largamente definido e C: definido (3)
 B: gerenciado quantitativamente (4) e A: em otimização (5)
ISO 29110: para atender organizações com até 25 pessoas envolvidas com o desenvolvimento de software. 22 produtos.
 Gerência de projetos: devem ser cumpridos os objetivos do projeto, na qualidade, tempo e custo esperados.
 Implementação de software: tem como objetivo garantir que os requisitos especificados são atendidos.
Aula 1: Introdução à ciência de dados
Explora as inovações relacionadas a manipular, analisar e visualizar uma enorme quantidade de dados.
Transformação de dados em informação visa auxiliar no processo de tomada de decisão.
Sistemas OLTP: tratam o negócio e dão suporte diariamente a ele.
 Sem registros dos fatos históricos. Para operação da organização.
Sistemas de BI: Todos os sistemas gerenciais de uma organização. Analisam o negócio. Interpretam o que ocorreu. P/ TD.
 Se refere ao processo de coleta, organização, análise, compartilhamento e monitoramento de informações.
 Descreve as habilidades para acessar dados, explorar informações (geralmente de um DW) e melhorar o processo de TD.
DW: armazém de dados, base de dados orientada por assunto, integrado, não volátil de histórico, criado para suportar TD.
 Os dados coletados podem ter diversas fontes e são extraídos periodicamente por meio de ferramentas ETL.
 ETL, uma nova organização de dados, OLAP para acesso à base DW e um HW específico, com processamento paralelo.
DD: para auditórias e fiscalizações. Responde perguntas que o usuário ainda não conhece. Valoriza o potencial dos dados.
 Conhecimento, autonomia (GUI fácil), descoberta de tendências e resultado (self-service BI).
A parceria entre os especialistas de TI (sistemas) e de negócios é essencial.

Aula 2: Big Data


Surge com o desafio de transformar, de forma rápida, um grande volume de dados em informações úteis para às TDs.
Vs nativos: va-ve-vo. Variedade, Velocidade e Volume. | Vs adquiridos: va-ve-vo. Valor, Veracidade e Volatilidade.
 Volume indica o tamanho das bases de dados. / Variedade: os dados são armazenados nas mais diferentes formas.
 Velocidade é a capacidade de analisar grandes volumes de dados.
 Volátil/Variável: tipos de dados que sofrem alterações. / Veracidade: refere-se à autenticidade ou reputação dos dados.
 Valor: dados que sejam fontes de valor agregado.
Tratamento dos dados: Descoberta de dados, integração dos dados e exploração dos dados (análise, visualização e TD).
Qualidade de dados: a qualidade do resultado do processo de análise depende da qualidade dos dados armazenados.
Aspectos importantes: integridade, validade, granularidade, tempestividade, precisão, consistência e flexibilidade.
Imperfeições nos dados podem ser aceitas, desde que o nível de ruído seja pequeno, em relação ao volume.

Aula 3: Arquitetura Big data


Exige uma arquitetura mais barata que a arquitetura tradicional. Processamento distribuído e paralelo em HW simples.
Com a redundância, pode contornar o problema de pouca confiabilidade do HW. As escritas em posições aleatórios são raras.
O tipo mais comum de processamento é em lote. A maioria dos acessos é para leitura sequencial. MBBF < 1 dia.
GoogleFS e HDFS são arquiteturas adequadas para o processamento massivo e distribuído de dados.
GoogleFS: arquivos divididos em pedaços. Pedaços são distribuídos entre vários nós do cluster de armazenamento.
 Os dados são armazenados com redundância, o servidor mestre possui uma ou várias redundâncias
 O mestre distribui atividades em diversos servidores secundários, que processam os arquivos previamente fracionados.
 O mapeamento entre as aplicações e os servidores fica armazenado no mestre. Existem vários servidores secundários.
 A aplicação acessa os servidores intermediários de maneira direta. Servidor espelho assume as funções do mestre.
 Todos os metadados do sistema de arquivos ficam armazenados no servidor mestre ou em suas réplicas.
 Acesso aos dados é feito diretamente do cliente, p/ o servidor secundário. Evitando-se que o mestre se torne um gargalo.
HDFS: Haddop distribuído utiliza blocos de 128MB. Cada bloco é um chunk. Master/Worker: NameNode e DataNode.
 NameNode funciona como um guia que armazena a localização de cada bloco de informação. Tem os metadados.
 O cliente faz o acesso aos nós de dados, por meio do NameNode.
 Para ler ou armazenar um arquivo, aplicações cliente comunicam-se com o NameNode (para saber dos acesso e escritas).
 Após determinação, todo o fluxo de dados ocorre entre o cliente e o DataNode. NameNode não atua como gargalo.
MapReduce: uma abstração que abrange várias tarefas de análise e que são facilmente paralelizáveis.
 Map e Reduce são duas operações comuns em programas funcionais, originários de dialetos Lisp.
 A lista é a estrutura de dados fundamental. Armazenamento e processamento escaláveis.
 Proveem modelos de programação simplificados para armazenar e processar grandes conjuntos de dados.
 O sistema MapReduce pode ter conhecimento de qual servidor secundário contém cada arquivos.
 E com isso, a função Map pode ser executada no mesmo servidor.
 A função Map recebe um par, composto de chave e valor. E retorna uma lista de pares ordenados.
 A operação Reduce recebe um par e retorna um valor.
 Os valores retornados por Map, de mesma chave são agrupados então, em uma lista.
 A função Map pode ser facilmente executada em paralelo.
Aula 4: Ingestão de dados
É a ponta de um iceberg. Um dos elementos mais críticos de um processo de Big Data. Parte trabalhosa e invisível.
Os tipos de dados se referem ao critério de Variedade. Estruturados, não estruturados e semiestruturados.
Estruturados: são organizados segundo um padrão rígido e predefinido, respeitando critérios como campos e domínio.
Não estruturados: nenhum esquema é especificado. Contém apenas conteúdo da informação e uma forma de apresentá-lo.
Semiestruturados: são dados heterogêneos e sem uma estrutura regular. Ex.: As referências bibliográficas.
A coleta de dados é semelhante ao processo ETL e composta por 3 camadas:
 De dados operacionais: variedade
 De concentração: data lake que fica no back room. É o canteiro de obras, onde a coleta de dados é construída.
 De carga: após a manipulação dos dados é necessário carregá-los para a respectiva base.
Processo de extração: é o primeiro passo no sentido de cavar o iceberg e dar nova vida aos dados que ali estavam enterrados.
Processo de manipulação ou transformação dos dados: fase do ajuste do dado.
 Pode envolver o desmembramento ou composição de dados.
 Consiste em várias operações feitas sobre os dados extraídos, para torná-los adequados para as análises;
 Eliminação de dados redundantes e/ou inconsistentes. Recuperação de dados ausentes. Transformação de dados.
Processo de carga: acrescenta novas informações à base de dados existente, sem perder nenhuma das informações.
 Os dados são carregados em lote e em paralelo, depois são indexados.
 Podem acontecer alguns erros. O limite aceitável de erros é de 1% do total da coleta de dados. >1%; etapa rejeitada.
Integração dos dados: requer o envolvimento efetivo dos usuários finais, a fim de obter uma definição precisa.
 Requer compreensão profunda dos sistemas-fonte, modelagem dos dados, adoção de padrões;
 Um sistema de transformação que manipule os dados vindos de diversas fontes.
 Bottom-up: feita de forma desconectada. Utilizada para a criação de pequenas bases isoladas de análise.
o Vantagens: foco em um determinado contexto. Implementação rápida e retorno rápido.
o Desvantagens: cria repositórios independentes. Perpetua a visão de contextos incompatíveis.
 Top-down: para análises em nível global. Uma única equipe tem que identificar todas as necessidades de informações.
o Vantagens: totalmente integrado, visão como um todo, repositório de metadados centralizados etc.
o Desvantagens: Implementação muito longa. Alta taxa de risco. Dificuldade em se conhecer todos os sist. legados.
Interoperabilidade dos dados: Para a viabilização da cooperação entre organizações e o sucesso da troca de informações.
 É a capacidade dos sistemas operarem em conjunto, trocando informações e compartilhando funções.
 De forma mais ampla é a habilidade de pessoas, organizações, e sistemas interagirem e se interconectarem;
 Para a troca e o uso da informação, de forma eficiente e efetiva. Dividida em 3 categorias de acordos;
 Acordo técnico (formato dos dados), de conteúdo (dados e metadados) e organizacional (regras básicas de acesso).

Aula 5: Modelagem de dados


Tem como objetivo o entendimento e a representação do mundo. Modelo multidimensional, NoSQL e UML estendida.
Modelo multidimensional: seu conceito tem origem nos vetores n-dimensionais ou matrizes
 Corresponde ao produto cartesiano de n variáveis. Foco é o cruzamento de variáveis.
 Modelo conceitual: retrata a forma como o ambiente informacional se manifesta para os usuários via OLAP.
 Modelo físico: retrata a realização ou fiscalização do modelo dimensional, no contexto do DB hospedeiro.
 A tabela no centro do diagrama (de 5 arestas) é a tabela fato. As demais são dimensão;
 Em geral, deseja-se estudar os valores que os fatos assumem, para cada combinação possível das dimensões;
 1 único registro do atributo da dimensão, para 0 ou mais registros da tabela de fatos;
 Na implementação física, os conjuntos de fatos dão origem a uma tabela de fatos.
 As métricas são as fórmulas matemáticas, que atuam sobre os fatos;
 De forma a permitir a agregação de muitos registros, em um único registro. Métricas básicas e derivadas.
 O modelo multidimensional aceita que uma mesma variável seja modelada como dimensional e como fato.
NoSQL: Not Only Structured Query Language. Armazenamento distribuído de dados, sem exigir uma estrutura.
 Favorece o uso das leituras. Não possuem joins entre seus dados;
 Não segue o padrão ACID (atomicidade, consistência, isolamento e durabilidade). 4 tipos:
 Orientado a documentos (modela os dados na forma de documentos). Orientado a chave-valor.
 Orientado a colunas (modela os dados como um mapa multidimensional). Grafos (armazena os dados com ligações).
UML estendida: para incorporar propriedades ontológicas, devido às limitações relacionadas à modelagem de Big Data.
 OntoUML: permite expressar mais sobre o domínio. Obriga a explicitação de uma grande quantidade de conhecimentos;
 Que fica escondida atrás de relações materiais. kind, subkind, role e phase. Relações formais e materiais.
Aula 6: Analítico (analytics) para Big Data
Por meio do cruzamento dos dados coletados é possível gerar diversos tipos de relatórios, para ajudar no processo de TD.
O analítico utiliza duas grandes áreas: a estatística e o DM. O DM utiliza os resultados, para estipular ações proativas.
Analítico descritivo: descrever os padrões e tendências revelados pelos dados. DW. O que aconteceu?
 Oferece uma possível interpretação para os resultados obtidos. Foco em buscar uma análise de uma situação imediata.
 Interpolação linear: Para construir um novo conjunto de dados, a partir de um conjunto já conhecido. Previsão de valores
 Distribuição de frequência: Permite a identificação de tendências. Medidas de posição e de dispersão;
 Moda: valor ou atributo que ocorre com maior frequência. Amodal, Bimodal, Unimodal e Multimodal.
 Mediana: Medida de posição que representa o valor que divide a distribuição em 2 conjuntos com o mesmo num. de E.
 Variância: É uma medida de dispersão que considera todos os dados em torno da média aritmética.
 Covariância: Mede a relação linear entre duas variáveis. Seus valores não são padronizados.
 Desvio Padrão: Indica o grau de variação de um conjunto de elementos.
 Coeficiente de correlação: Mede o grau de associação linear entre duas variáveis. De -1 a 1.
Analítico preditivo: visa prever o que acontecerá no futuro. DD. O que acontecerá? Realizado por meio de uma amostra.
 Busca analisar dados armazenados ao longo de um tempo, para mapear ou prever um resultado ou comportamento.
 Amostragem: escolha de qualquer subconjunto não vazio, de uma população. Seleção de forma aleatória.
 Amostragem probabilística e não probabilística (não aplicada em Big Data).
 Em geral, quanto maior a amostragem, maior será a precisão do resultado.
 Amostragem probabilísticas: aleatória simples, sistemática e estratificação.
Analítico prescritivo: Como podemos fazer acontecer? DM.

Aula 7: Mineração de dados


Para encontrar padrões presentes nas bases de dados, por meio de algumas técnicas, supervisionadas e não supervisionadas.
Classificação: identifica a qual classe um determinado objeto pertence.
 Criação do modelo de classificação, validação do modelo e operação do modelo sobre novos dados.
 Objeto: transação de cartão de crédito | Classe: fraude ou não fraude.
Associação: identifica quais atributos de um objeto estão relacionados.
 Se compra fraldas, também compra-se cerveja.
Regressão: determina um objeto, por um valor numérico (e não por meio de uma classe).
 Objeto: Registro de valores | Classe: Valor gasto por um novo consumidor.
 Linear: reta (y = ax + b) | Não linear: parábola (y = ax2 + bx +c)
Agrupamento: visa identificar e aproximar os objetos similares. Não necessita de dados categorizados.
 Não supervisionado;
 Coleção de registros similares entre si, porém diferentes dos outros registros nos demais agrupamentos.
 Particional (sem hierarquia), hierárquico e probabilístico.
 Objeto: clientes (dados pessoais / histórico de compras) | Classe: grupos de clientes. K-means.
Para a mineração de dados é importante o pré-processamento de dados e conhecimento do modelo de negócios do cliente.
 E também, contar com uma infraestrutura de computação.

Aula 8: Análise visual de dados


Possibilita ao cientista de dados ampliar sua compreensão sobre os dados.
Análise OLAP: conjunto de processos para a manipulação, visualização e análise de dados multidimensional.
 O cubo (dice) é uma estrutura que armazena os dados em formato multidimensional.
 Aplicações: são relatórios de negócio, marketing, gerenciais, BPM, budgeting e previsão, financeiros etc.
 Operadores são utilizados para modificar a posição de uma informação, alterando linhas por colunas;
 E possibilitando a criação de visões dos dados, por meio de sua reorganização, de forma que eles possam ser;
 Examinados sob diferentes perspectivas. Filtros, Ranking, Sorts, Tiling, Drills, Throught etc.
 Oferecem respostas consistentes às consultas iterativas executadas pelos usuários.
Exploratória de dados: um topo de recurso muito utilizado para a representação gráfica dos dados.
 Utiliza recursos estatísticos. Gráficos, Histogramas e Polígonos de frequência.
Arvores de decisão: técnica simples e poderosa. Contem raiz, nós (nodos) não folhas e folhas.
 Um tipo de fluxograma para representar de maneira gráfica, o processo de classificação de mineração de dados.
 Para visualizar as consequências de decisões atuais e futuras, bem como os eventos aleatórios relacionados.
Painéis de controle ou dashboards: visualização por diversos elementos gráficos, em uma única tela.
Aula 9: Plataformas de Big Data
Essenciais para o cientista de dados.
Apache Haddop: representa uma família de componentes que associada ao paradigma de nuvem, permite;
 Principalmente que as manipulações sejam trazidas para onde estão os dados, utilizando-se;
 A arquitetura HDFS e o MapReduce, com 2 implementações adicionais: Combine e Shuffle/sort
 Plataforma de software livre.
Weka: plataforma com um catálogo de algoritmos com técnicas de aprendizado de maquinas.
 Supervisionado e não supervisionado.
 Consiste em um banco de programas em Java, como os principais algoritmos de mineração de dados.
 São necessárias as massas de treinamento e as de teste.
 Formato de arquivo ARFF; relação, atributos e dados.
Tableau: permite que dados sejam analisados de forma eficiente, sem importar o formato dos dados de origem.
 Baseia-se em 3 conceitos: conectar, analisar e compartilhar.
Exemplos de aplicação: Uso de Big data em Google, Amazon e Netflix. Empresas de transporte aéreo.
 Sears, Petrobras, Serasa, Itaú e BB.
 As questões de privacidade são uma das maiores barreiras para explorar os benefícios do Big Data.
 Big Data não é Big Brother. É importante a valorização da segurança.
 Incertezas sobre retorno de investimento também representam desafios.
 Infraestrutura de TI (HW e SW) deve estar preparada para o processamento em tempo aceitável;
 Escalabilidade massiva de dados, integração de bases heterogêneas e computação destruída.

Aula 10: Novas fontes de dados para o Big Data


Dados abertos: são as informações produzidas e utilizadas livremente, reutilizadas e redistribuídas;
 Por qualquer pessoa, sem qualquer restrição.
Web semântica: é uma teia de informações construída de maneira a ser facilmente processável por máquinas,
 em uma escala global, construindo um banco global de dados ligados, os quais, de alguma forma,
 estão interligados na web.
 W3C, URI, RDF e OWL.
Dados ligados ou linked data: para interligar dados relacionados, que não estavam previamente interligados.
 Ou ainda: uma boa prática para expor, compartilhar e conectar fragmentos de dados, informação e conhecimento;
 na web semântica, por meio de URIs e RDF.
IoT: refere-se a objetos unicamente identificáveis e que sejam capazes de trocar informações por meio de rede;
 Como Internet ou alguma rede especifica.
 Depende da inovação técnica dinâmica em campos da eletrônica;
 Como os sensores sem fios, a nanotecnologia e os dispositivos embarcados.

Você também pode gostar