Matéria TRT13

ANALISTA JUDICIÁRIO – ÁREA APOIO ESPECIALIZADO –ESPECIALIDADE TECNOLOGIA DA INFORMAÇÃO

1. Engenharia de Software:Conceitos gerais e disciplinas de engenharia de software. Ciclo de vida de software. Análise e projeto orientado a objetos com UML. Análise de requisitos funcionais e não-funcionais. Modelagem orientada a objetos. Padrões de projeto (Design Patterns). Modelagem de dados. Modelo relacional. Processos dedesenvolvimento de software. Processo iterativo e incremental. Noções de processos e práticas ágeis de desenvolvimento de software. 2.Desenvolvimento de Software: Fundamentos: estruturas de dados e de controle de fluxo; funções e pr ocedimentos; conceitos de linguagens estruturadas; conceitos de linguagens orientadas a objetos; Arquitetura de Aplicações: conceitos de Web Services; conceitos sobre desenvolvimento Web e cliente/servidor. Linguagens e ambientes de programação: aspectos gerais das linguagens Python e Java; Controle de Versão com o Git; Testes: conceitos: verificação e validação, tipos de teste (unidade, integração, sistema /funcional, aceitação, carga, desempenho, vulnerabilidade, usabilidade); Scrum: noções de modelagem de processos com UML e BPMN. 3. Banco de Dados: características de um SGBD; modelagem lógica e física de bancos de dados; normalização e modelo rela cional; diagramas de entidade relacionamento; linguagem SQL e PL/SQL: manipulação e definição de dados, criação e manutenção de functions, procedures e packages,cláusulas, operadores lógicos, operadores relacionais, funções de agregação; triggers; Java Stored Procedures; controle de proteção, integridade, concorrência e bloqueio de transações; monitoramento, análise de desempenho e tuning de banco de dados; segurança em banco de dados; administração de bancos de dados Oracle 11g: instalação e manutenção, performance tuning, controle de acesso, implementação e execução de backup e restore RMAN, importação e exportação de bases de dados, ASM e ASMLib, arquiteturas Single Instance e Real Application Clusters, Data Guard, gestão de datafiles, gestão de tablespaces, redo logs, archive logs, dicionário de dados, parâmetros de inicialização, scheduler jobs; administração de PostgreSQL 9.0: instalação e manutenção, backup e restore; replicação;conhecimentos básicos de MySQL 5 e 6; noções de Data Warehouse e Data Mining. 4. Fundamentos de sistemas operacionais Linux e Windows: conceitos, funções, características, componentes e classificação; sistemas de arquivos: facilidades esperadas, diretórios e direitos de acesso, compartilhamento e segurança, integridade; interoperação de sistemas operacionais; Shell script Linux; RAID: tipos, características e aplicações; sistemas de arquivos NTFS, EXT3, e EXT4: características, metadados e organização física. 5. Redes de computadores: tipos e meios de transmissão e de cabeamento; técnicas de circuitos, pacotes e células; tecnologias de redes locais e de longa distância (LAN, MAN e WAN); características dos principais protocolos de comunicação; topologias; elementos de interconexão de redes de computadores (gateways, hubs, repetidores, bridges, switches e roteadores; modelo de referência OSI; redes Locais Virtuais (VLAN); características dos protocolos de controle de looping em Ethernet EAPS, Spanning Tree – IEEE 802.1d e Rapid SpanningTree – IEEE 802.1w; arquitetura TCP/IP: protocolos, segmentação e endereçamento, serviço DNS e entidades de registros. Conceitos do Multi Protocol Label Switching (MPLS). Conceitos dos protocolos de roteamento OSPF e BGP, conceitos de Autonomous System (AS) Conceitos de roteamentoIP na Internet; conceitos do protocolo IPv6; arquitetura cliente/servidor; redes sem fio (Wireless) ; gerenciamento de redes de computadores: conceitos, protocolo SNMP, agentes e gerentes, MIBs, gerenciamento de dispositivos de rede, se rvidores e aplicações. Administração e gerência de redes de computadores; tipos de serviço e QoS. 6. Serviços de rede: princípios e protocolos dos serviços: e-mail, DNS, DHCP, Web (servidores Apache e JBoss) e Proxy; sistemas operacionais Windows: princípios, conceitos e operação básica; modelos de domínio em Rede Windows Server 2008 R2 e posteriores; serviços de Diretório Active Directory e OpenLDAP; sistema operacional Linux: princípios, conceitos e operação básica; gerenciamento de usuários; configuração, administração e logs de serviços: proxy, correio eletrônico, HTTP, HTTPS, Samba, NTP, Iptables, ssh; tecnologias de virtualização de plataformas: emuladores, máquinas virtuais, paravirtualização, VMWare.7. Segurança da Informação: normas NBR ISO/IEC: nº 27001:2006, nº 27002:2005, nº 27003, nº 27004, nº 27005 e nº 15999; Noções sobre política de backup: sistemas de cópia de segurança: tipos e meios de armazenamento; vírus de computador e outros malwares (cavalos de troia, adware, spyware, backdoors, keyloggers, worms, bots, botnets,rootkits); ataques e proteções relativos a hardware, software, sistemas operacionais, aplicações, bancos de dados, redes, pessoas e ambiente físico; cartilha de segurança para internet do CERT.BR; gerência de riscos; classificação e controle dos ativos de informação; controles de acesso físico e lógico; plano de continuidade de negócio (plano de contingência e de recuperação de desastres); segurança de redes: Firewall, Sistemas de Prevenção de Intrusão (IPS), antivírus, NAT, VPN, monitoramento e análise de tráfego; uso de sniffers; traffic shaping; tráfego de dados de serviços e programas usados na Internet; segurança de redes sem fio: EAP, WEP, WPA, WPA2; ataques e ameaças da Internet e de redes sem fio; criptografia; conceitos básicos de criptografia; sistemas criptográficos simétricos e de chave pública; ICPBrasil, certificação e assinatura digital; características dos principais protocolos.8. Governança de TI. Cobit 4.1:aspectos gerais, estrutura, conceitos, finalidade; Fundamentos da ITIL v.3 v3 atualizada em 2011: aspectos gerais, estrutura, conceitos, finalidade; noções de planejamento estratégico, Balanced Scorecard e PDTIC.9. Contratação de Soluções de TI: Resolução CNJ 182/2013.10. Gerenciamento de Projetos de TI – PMBOK quarta edição: conceitos de gerenciamento de projetos, ciclo de vida de projeto, conceitos básicos e estrutura.11. Inglês Técnico.

Design Patterns

Também chamados de Padrões de Projeto, surgiram com a motivação de ajudar a solucionar problemas que ocorrem frequentemente, e, se usados com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software, uma vez que já foram testadas, utilizadas e aprimoradas a partir da experiência e conhecimento de outros programadores.

São soluções de templates abstratos de alto nível. São "blueprints" para soluções e não uma solução por si própria.

O conjunto dos mais conhecidos design patterns estão catalogados no livro "Design Patterns: Elements of Reusable Object-Oriented Software", mais conhecido como "A bíblia dos Design Patterns". Foi escrito por Erich Hamma, Richard Helm, Ralph Johnson e John Vlissdes, conhecidos como Gang of Four (GoF).

Eles coletaram 23 Design Patterns e os organizaram em 3 grupos:

Creational Patterns ou Padrões de Criação

Tratam da construção do objeto e o de referência.

Structural Patterns ou Padrões Estruturais

Tratam da relação entre objetos e como eles interagem entre si para formarem grandes objetos complexos.

Behavioral Patterns ou Padrões Comportamentais

Tratam da comunicação entre os objetos, especialmente em termos de responsabilidade e de algoritmos.

Utilidade

Seu valor reside no fato que eles foram soluções utilizadas e testadas, o que proporciona confiança em sua eficácia.

Design Patterns focam na reutilização de soluções. Ao quebrar problemas em partes menores, é possível encontrar Design Patterns para resolvê-los.

Princípios comuns de design

Keep It Simple Stupid (KISS)

Mantenha o código simples, mas não seja simplista. Evite a complexidade desnecessária.

Don't repeat yourself (DRY)

Evite a repetição de qualquer parte do sistema abstraindo as coisas que são comuns entre si e colocá-las em um lugar único.

Tell, don't ask

Está estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades para as suas classes corretas. Afirma que você deve dizer aos objetos quais ações você quer que eles realizem, ao invés de fazer perguntas sobre o estado do objeto e então tomar uma decisão por si próprio em cima da ação que você quer realizar.

You ain't gonna need it (YAGNI)

Refere-se a necessidade de adicionar somente as funcionalidades que são necessárias para a aplicação deixar de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa. O Test Driven Development, ou desenvolvimento orientado a testes, adere ao YAGNI. TDD se baseia na escrita de testes que comprovam a funcionalidade do sistema e então escrevem somente o código para obter êxito no teste.

Separation Of Concerns (SoC)

É o processo de dissecação de uma parte de software em distintas características que encapsulam um único comportamento e dados que podem ser utilizados por outras classes. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilização de código, manutenção e testabilidade.

Fonte: http://www.princiweb.com.br/blog/programacao/design-patterns/o-que-sao-design-patterns.html

Padrões de Projeto

Um padrão é uma regra de três partes que expressa a relação entre um contexto (1), um problema (2) e uma solução (3).

Domain Driven Design

Significa projeto Orientado a Domínio. Pode ser visto como a volta da orientação a objetos. Quando se fala em Orientação a Objetos, pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da orientação a objetos também tem coisas como:

Alinhamento do código com o negócio

O contato dos desenvolvedores com os especialistas do domínio é algo essencial.

Favorecer a reutilização

Os blocos de construção, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares.

Acoplamento mínimo

Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos.

Independência da tecnologia

Domain Driven Design não foca em tecnologia, mas em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia utilizada não seja importante, mas esta não é uma preocupação de DDD.

Modelo em funcionamento

Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua*. Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Isso significa que, se durante uma conversa com um cliente do sistema de cobrança, por exemplo, ele disser: "Temos que emitir a fatura para o cliente antes da data limite", vamos ter no nosso código alguma coisa do tipo:

• Uma classe para a entidade Cliente;
• Uma classe para a entidade Fatura;
• Algum serviço que tenha um método emitir;
• Algum atributo com o nome de data limite.

Utilizando a Longuagem Ubíqua, criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design - MDD). A ideia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo.

Num processo ágil defendido pelo MDD, a criação do modelo abstrato deve ser feita em grupo, com todas pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modellers).

O processo de maturação de um sistema utilizando MDD deve ser contínuo. O modelo servirá de guia para a criação de código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

Blocos de construção do Model Driven Design

Decidindo pela criação de um modelo utilizando MDD, precisamos, inicialmente, isolar o modelo de domínio das demais partes que compõem o sistema. Essa separação pode ser feita utilizando-se uma arquitetura em camadas, que dividirá a aplicação em quatro partes

Interface do Usuário

Responsável pela exibição de informações do sistema ao usuário e também por interpretar comandos do usuário.

Aplicação

Não possui lógica de negócio. É responsável por conectar a Interface de Usuário às camadas inferiores.

Domínio

Representa conceitos, regras e lógicas de negócio. Todo o foco de DDD está nesta camada.

Infra-estrutura

Fornece recursos técnicos que darão suporte às camadas superiores.

Após dividir o sistema em camadas, preocupamo-nos apenas com a camada de domínio. Para modelar esta parte, utilizamos alguns padrões propostos em DDD. Esses padrões são chamados de blocos de construção e serão utilizados para representar o modelo abstrato. Estes blocos podem ser:

Entidades

Classes de objetos que necessitam de uma identidade. Normalmente são elementos do domínio que possuem ciclo de vida dentro de nossa aplicação: um Cliente, por exemplo, se cadastra no sistema, faz compras, se torna inativo, é excluído, etc.

Objetos de Valores

Objetos que só carregam valores, mas que não possuem distinção de identidade. Bons exemplos seriam strings, números ou cores.

Agregados

Compostos de entidades ou objetos de valores que são encapsulados numa única classe. Serve para manter a integridade do modelo. Elege-se uma classe para servir de raiz do Agregado. Quando algum cliente necessitar manipular dados de uma das classes que compõem o Agregado, essa manipulação só poderá ser feita através da raiz.

Fábricas

Classes responsáveis pelo processo de criação dos Agregados ou dos Objetos de Valores. Algumas vezes, agregados são relativamente complexos e não queremos manter a lógica de criação desses agregados nas classes que o compõem. Extraímos então as regras de criação para uma classe externa: a fábrica.

Serviços

Classes que cntém lógica de negócio, mas que não pertence a nenhuma Entidade ou Objetos de valores. Não guardam estado, ou seja, toda chamada a um mesmo serviço, dada uma mesma pré-condição, deve retornar sempre o mesmo resultado.

Repositórios

Classes responsáveis por administrar o ciclo de vida dos outros objetos, normalmente Entidades, Objetos de Valor e Agregados. Centralizam operações de criação, alteração e remoção de objetos. Em linguagens como java, são comumente implementados utilizando frameworks como o Hibernate.

Módulos

Abstrações que têm por objetivos agrupar classes por um determinado conceito de domínio. Em java, seriam os packages.



* Linguagem comum, com termos bem definidos, que fazem parte do domínio do negócio e que são usados por todas as pessoas que fazem parte do processo de desenvolvimento de software.

Fonte: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/

Emergent Design

É um conceito criado por David Cavallo para descrever um framework teórico para a implementação de mudanças sistêmicas em ambientes de desenvolvimento e educação. Ele examina como a escolha da metodologia de design contribui para o sucesso ou a falha de reformas educacionais em estudos na Tailândia.

O Emergent Design é um tópico consistente no desenvolvimento ágil de software, como resultado do foco da metodologia em desenvolver pequenas peças de código com valor para o negócio. Com o Emergent Design, uma empresa de desenvolvimento começa entregando funcionalidade e deixa o design emergir. O Desenvolvimento vai pegar um pedaço de uma funcionalidade A e implementá-lo utilizando as melhores práticas e uma cobertura de testes apropriada e em seguida entregar a funcionalidade B. Assim que B for concluído, ou enquanto estiver sendo desenvolvido, a organização irá olhar o que A e B possuem em comum e refatorar esta parte comum, permitindo o design emergir. Esse processo continua à medida que a organização continuamente entrega as funcionalidades. No fim do ciclo de liberações das entregas, o desenvolvimento fica com a menor parcela do design necessária. O resultado final é uma base de códigos menor, que naturalmente possui menos espaço para erros e baixo custo de manutenção.

Disciplinas de Engenharia de Software

Requisitos

É um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Deve ser precedido por estudos de viabilidade. Posteriormente ao levantamento, deve ser realizada a gestão dos requisitos. É composto por quatro atividades de alto nível:

Identificação dos Requisitos

Tem como atividades envolvidas:

• Compreensão do domínio;
• Identificação das partes interessadas;
• Captura;
• Identificação e análise de problemas. 

Tem como dificuldades:

• Desconhecimento do requisito pelo cliente, ou dificuldade no repasse deste;
• Requisitos que não são realistas;
• Transmissão do mesmo requisito de formas diferentes por pessoas diferentes.

Técnicas de levantamento de requisitos

Entrevistas e questionários, que está condicionada aos seguintes fatores:

• Influência do entrevistador nas respostas do cliente;
• Relação pessoal entre os intervenientes da entrevista;
• predisposição do entrevistado;
• Capacidade para seguir umplano para a entrevista.

Workshops de requisitos

Técnica usada através de uma reunião estruturada  , da qual devem fazer parte um grupo de analistas e um grupo representando um cliente, para então obter um conjunto de requisitos bem definidos. Deve existir um membro neutro cujo papel será conduzir o workshop e promover a discussão entre os vários intervenientes. Outra técnica que pode ser bem utilizada é a do brainstorming.

Cenários (Séries de Eventos Hipotéticos)

 Forma de levar as pessoas a imaginar o comportamento de sistemas, através de exemplos práticos descritivos do comportamento de um sistema. Assim, seus usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Os cenários devem incluir os seguintes elementos:

• Estado do sistema no início do cenário;
• Sequência de eventos esperada no cenário;
• Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como eles serão tratados;
• Outras atividades que podem ser executadas ao mesmo tempo que as deste cenário;
• Estado do sistema depois de o cenário terminar.

Prototipagem

Trata-se de uma versão inicial do sistema, baseada em requisitos ainda poucos definidos, que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são facilmente identificáveis. 


Estudo etnográfico

E uma análise de componente social das atividades desempenhadas numa organização. Quando uma pessoa está muito habituada a uma tarefa, ela pode sentir dificuldade em detalhar o passo-a-passo de suas tarefas para o analista. Ele então fará uma observação do trabalho desta pessoa, buscando compreender os requisitos envolvidos.

Análise e negociação 23/10/2013

Atividades Envolvidas

• Classificação: agrupamento dos requisitos em "módulos";
• Resolução de confitos;
• Priorização;
• Confirmação: confirmar junto à parte interessada a completude dos requisitos, sua consistência e validade. 

Dificuldade

• Fatores externos (políticos);
• Ambiente (econômico e/ou organizacional)

Análise e negociação 

Nesta fase se dá a produção propriamente dita do Documento de Especificação de Requisitos. Entre eles:

• Requisitos Funcionais;
• Requisitos não-funcionais.

A documentação poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir três tipos de especificação:

Especificação de requisitos do usuário ou utilizador

 Destinam-se aos vários níveis hierárquicos da organização na qual o sistema será implantado. São desenvolvidos utilizando apenas linguagem natura e simples diagramas. Assim, surgem algumas dificuldades como:

• Ambiguidade;
• Confusão;
• Agrupamento de requisitos.

Especificação de requisitos do sistema

 Têm caráter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para além da linguagem natura, de linguagens estruturadas e notações gráficas. 

Especificação de design da aplicação

Consiste num documento usado pela equipe de desenvolvimento de sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de se situar quando começar a codificar.  

Projeto

É a parte que se encarrega de transformar os resultados da Análise de Requisitos em um documento ou um conjunto de documentos capazes de serem interpretados diretamente pelo programador. Para atingir este objetivo, o projetista deve mapear as estruturas e funcionalidades identificadas na análise de requerimentos dentro do contexto e das restrições da arquitetura, de forma a tornar possível a construção do software. Ao longo do tempo e nos diversos processos de software existentes, várias ferramentas foram idealizadas para facilitar e atingir ese objetivo:

• Design por contrato;
• Model Driven Architecture e Model Driven Design;
• Design Patterns;
• Refatoração;
• Outras.

Construção

Teste

É a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.


Manutenção

Gerência de Configuração 24/10/2013

Também conhecida como Gestão de Configuração de Software, é responsável por fornecer o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações.

Para Roger Pressman é o conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.

Resumindo, tem como objetivo responder as seguintes perguntas:

• O que mudou e quando?
• Por que mudou?
• Quem fez a mudança?
• Podemos reproduzir esta mudança?

Configuração de Software

É o estado em que um sistema se encontra em determinado momento. Trata apenas dos elementos que se encontram em formato eletrônico e fazem parte dessa configuração. Varia com o tempo e arquivos existentes são alterados ou removidos.

Linha base 

Também chamada de baseline, é um conceito de GCS que nos ajuda a controlar as mudanças, sem impedir seriamente as mudanças justificáveis. Segundo Pressman, definimos uma linha-base como um marco de referência no desenvolvimento de um software, que é caracterizado pela entrega de um ou mais itens de configuração.

Gerência de Mudanças

É uma parte geralmente negligenciada pela GC. Como ela não traz resultados imediatos para desenvolvedores e engenheiros de software envolvidos, estes acabam por não perceber sua importância. Porém, ela é importante pois permite se saber o motivo de uma configuração ter sido mudada para outra.

Gerência de Engenharia 

Qualidade de Software 

Objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça as expectativas do cliente, dentro daquilo que foi acordado inicialmente.

Segundo a norma ISO 9000, a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.

Modelos de Qualidade

• CMMI
• MPS.BR
• ISO 9126
• ISO 15504
• ISO 12207

Conceitos Básicos sobre Engenharia de Software

É uma área da computação voltada à especificação, desenvolvimento e manutenção de sistemas de software, com aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade.

Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software.

Áreas de Conhecimento (GGQM-TC-PR)

• Requisitos;
• Projeto;
• Construção;
• Teste;
• Manutenção;
• Gerência de Configuração;
• Gerência de Engenharia;
• Processos de Engenharia;
• Ferramentas e Métodos de Engenharia de Software;
• Qualidade de Software.