Desafio IFCe

Prova: 11/03/2012 - Fortaleza-CE

Prova	Nº Questões	Peso	Acerto mínimo (questões)	Pontos Ponderados
1. Língua Portuguesa	20	1	12	20
2 Conhecimento Específicos	40	2	24	80
Total de pontos				100

LÍNGUA PORTUGUESA ( PARA OS CARGOS DE NÍVEL D e E )

Textualidade: interpretação; recursos estilísticos (ou figuras de linguagem); coesão e coerência; norma padrão e variantes linguísticas. Ortografia: uso dos acentos gráficos; grafia de palavras com s ou z, ss ou ç, j ou g, x ou ch; uso do sinal indicativo de crase. Morfologia: classes gramaticais e processos de flexão das palavras. Sintaxe: de regência verbal e nominal; de concordância verbal e nominal; de colocação; uso dos sinais de pontuação. Semântica: sinonímia, antonímia, homonímia, paronímia; polissemia (denotação e conotação). Normas técnicas de redação oficial.

CÓDIGO/CARGO: 21

Hardware: Aterramento Elétrico; Estabilizador, No-Break e Modulo Isolador Estabilizado; Gabinetes AT e ATX; Fontes de Alimentação: AT,ATX,ATX12V e ATX24P; 

Placa Mãe: Socket 370, 462,478, 775, 754,939 ,940 e AM2; Instalação Placa de Vídeo PCI, AGP e PCI Express; Instalação Placa de Modem; Instalação Placa de Áudio; Instalação Placa de Rede 10/100/1000 Mb/s; Instalação de Impressoras Laser, Jato de tinta e Matricial; Instalação de Scanner; Instalação de Monitores CRT e LCD; Padrões de Interfaces(USB,PCMCIA,1394,SD) Instalação de Placa de captura de TV; Instalação e configuração de HD PATA e SATA; Instalação de unidades Óticas; Instalação de unidades de disquetes; Instalação e configuração de sistema operacional padrão Windows e Linux; Instalação e configuração de utilitários de produção e de segurança. 

Redes de Computadores e Comunicação de Dados: Tecnologias de redes locais ethernet/fast ethernet/gigabit ethernet; Cabeamento: par trançado sem blindagem - categoria 5E e 6; cabeamento estruturado (norma EIA/TIA568); Fibras ópticas: fundamentos, padrões 1000BaseSX e 1000BaseLX; Fundamento de Redes sem fio (wireless); Elementos de interconexão de redes de computadores (hubs, switches, roteadores); Conceitos de VLAN e Trunk VLAN; Topologias de redes; Modelo OSI da ISO; Fundamentos de sistemas operacionais; Configuração Básica de TCP/IP para Sistemas Operacionais (Windows 98, 2000, 2003, XP e Vista e Linux); Acesso remoto a computadores; Conceitos de segurança de redes e filtros de aplicações; Aplicativos e dispositivos para armazenamento de dados e realização de cópia de segurança (backup).

Programa para o Concurso da UFERSA

1.1 - LEGISLAÇÃO:

Administrativo: 1. Lei nº. 8.112/90. 2. Ato Administrativo: conceito,
elementos/requisitos, atributos, Convalidação, Discricionariedade e Vinculação. 3.
Poderes da Administração. 4.Licitação: Princípios, Modalidades, Dispensa e
Inexigibilidade. Processo Administrativo, Lei nº. 9.784/99. Constitucional: 5. Os
poderes do Estado e as respectivas funções. 6. Hierarquia das normas. 7. Princípios
fundamentais da CF/88. 8. Direitos e garantias fundamentais. 9. Ordem social: base e
objetivos da ordem social; seguridade social; educação, cultura e desporto; ciência e
tecnologia; comunicação social; meio ambiente; família, criança, adolescente e idoso
10. Organização político-administrativa do Estado. 11. Administração Pública na CF/88.
12. Orçamento Público: Conceitos e Princípios Orçamentários.

1.2 - INFORMÁTICA:

1. Conceitos básicos de computação. 2. Componentes de hardware e software de
computadores. 3. Operação, configuração de sistema operacionais Windows e Linux. 4.
Uso de editores de texto (Word e Writer). 5. Uso de planilhas eletrônica (Excel e Calc).
6. Uso de Internet (navegação web, correio eletrônico). 7. Noções de segurança
(proteção de informação, vírus e assemelhados). 8. Alternativas de software livre para
sistemas operacionais, editores de texto, planilhas e navegadores.

SUGESTÃO BIBLIOGRÁFICA:

Microsoft. Microsoft Office Word 2003 Básico. Bookman. 2007
Microsoft. Microsoft Windows 2000 Professional - Passo a Passo. Makron Books. 2000.
Microsoft. Microsoft Office Powerpoint 2003. Bookman. 2008.
Microsoft. Microsoft Excel 2003 - Básico. Bookman. 2007.
Braga, William. Informática Elementar 2ed: Windows Xp, Word 2003 e Excel 2003. Alta
Books. 2007.
Stanek, William R. Windows XP Professional. Bookman. 2006.
Morimoto, Carlos Eduardo. Linux - Entendendo o Sistema - Guia Prático. Sulina. 2005.
Rocha, Tarcízio da. Word X Writer - Migrando Totalmente. Ciência Moderna. 2007.
Rocha, Tarcízio da. Excel X Calc - Migrando Totalmente. Ciência Moderna. 2007.
Braga, William. Informática Elementar Open Office 2.0. Alta Books. 2007.
Manzano, Andre Luiz. Estudo Dirigido de Microsoft Office Excel 2003. Erica. 2003.
Manzano, Jose Augusto N. G.; Manzano, Andre Luiz N.g..  Estudo Dirigido - Microsoft
Office Excel 2003 Avançado. Erica. 2004.
Negrini, Fabiano; Borges, Louiseana. Excel 2003 - Avançado.Visual Books. 2006.
Negrini, Fabiano; Savichi, Louiseana Borges.  Programando com Excel 2003.  Visual
Books.  2005.
Manzano, Andre Luiz.  Estudo Dirigido - Microsoft Office Word 2003 Avançado. Erica.
2004.
Campos, Iberê M. Migrando de Windows para Linux. Brasport. 2004.
Rocha, Tarcízio da.  Openoffice.org 2.0  - Writer  - Completo e Definitivo.  Ciência
Moderna. 2006.
Rocha, Tarcízio da.  Openoffice.org 2.0  - Calc Completo e Definitivo  - Série Free  -
Volume. 3. Ciência Moderna. 2006.

Rocha, Tarcízio da.  Openoffice.org 2.0  - Draw Completo e Definitivo  - Série Free  -
Volume 5. Ciência Moderna. 2006.
Rocha, Tarcízio da. Openoffice.org 2.0 - Base - Conhecendo e Aplicando - Série Free -
Vol. 2. Ciência Moderna. 2006.
Microsoft. Ajuda online do Windows e Office

Específicas

1. Conceitos básicos de software e hardware: definição, tipos, funções e características. 

2. Algoritmos. 

3. Estruturas de dados: representação e manipulação de matrizes, listas, pilhas, 

filas e árvores. 

4. Banco de Dados: conceitos, modelos, projeto conceitual, lógico e físico, 

linguagens de consulta, banco de dados distribuídos e sistemas gerenciadores de banco de 

dados. 

5. Engenharia de software: conceitos, tipos de sistemas, modelos de ciclo de vida, 

métodos e técnicas de desenvolvimento de software estruturado e orientado a objetos: 

planejamento, análise, projeto, gestão de configuração, testes, qualidade de software, 

manutenção de software, desenvolvimento baseado em componentes, ferramentas Case e 

gestão de projetos. 

6. Redes de Computadores: conceitos básicos, tipos de redes, protocolos  de comunicação. 

7. Sistemas operacionais: Windows, Unix e Linux. 8. Linguagens de Programação: Java, C++, PHP, Pascal e Delphi. 

9. REDAÇÃO sobre assunto específico da área  de atuação.

SUGESTÃO BIBLIOGRÁFICA

· PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: McGraw-Hill, 2006. ·
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo:Prentice Hall, 2004.
· SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison-Wesley, 2003. ·
TANENBAUM, A. S. Organização Estruturada de Computadores. 4. ed. Rio de Janeiro: LTC,
2001. · DATE, C. J. Introdução a Sistemas de Bancos de Dados. 6. ed. Rio de janeiro: Campus,
2004. · SILBERSCHATZ, A. ; KORTH, H. ; SUDARSHAN, S. Sistema de Banco de Dados. 3.ed. São
Paulo: Makron. · POMPILHO, S. Análise Essencial: Guia Prático de Análise de Sistemas. Rio de
Janeiro: Infobook, 1995. · BLAHA, M. ; RUMBAUGH, J. Modelagem e Projetos Baseados em
Objetos com Uml 2. Rio de Janeiro: Campus, 2006. · JACOBSON, I. ; , BOOCH, G. ; RUMBAUGH,
J. UML: Guia do Usuário. Rio de Janeiro: Campus, 2006. · VAREJÃO, F. M. Linguagens de
Programação: Conceitos e Técnicas. Rio de Janeiro: Campus, 2004. · GOTTFRIED, B. S.
Programando em C. Rio de Janeiro: MacGraw-Hill, 1993. · SCHILDT, H. C completo e total. 3.
ed. São Paulo: MakronBooks,1997. · GOTTFRIED, B. S. Programação em Pascal. Rio de Janeiro:
McGraw-Hill, 1985. · WIRTH, N. Algoritmos e Estruturas de Dados. Rio de Janeiro:LTC, 1999.
· ZIVIANI, N. Projeto de Algoritmos com Implementações em Pascal e C. 2. ed. São Paulo:
Pioneira, 2004.

I'm back

O Renegado está de volta.

Dessa vez a missão é UFERSA.

Esse concurso é na casa do Renegado.

Passar nesse concurso para o Renegado é como defender sua pátria dos invasores estrangeiros.

BNDES

PROFISSIONAL BÁSICO DE ANÁLISE DE SISTEMAS
ANÁLISE DE SISTEMAS - DESENVOLVIMENTO


Salário de 8,3 mil.

O Renegado vai fazer esse concurso porém sabe que é um sonho...


LÍNGUA PORTUGUESA
I ‐ Ortografia oficial. II ‐ Acentuação gráfica. III ‐ Crase. IV ‐ Flexão nominal e verbal. V ‐ Emprego das classes de palavras. VI ‐ Emprego de tempo e modo verbais. VII ‐ Vozes do verbo. VIII ‐ Concordância nominal e verbal. IX ‐ Regência nominal e verbal. X ‐ Análise sintática: coordenação e subordinação. XI ‐ Pontuação. XII ‐ Interpretação de texto.

LÍNGUA ESTRANGEIRA - INGLÊS/ESPANHOL
I ‐ Conhecimentos básicos. II ‐ Interpretação de textos. III ‐ Vocabulário. IV ‐ Aspectos gramaticais.


I - CONCEITOS DE SISTEMAS DE COMPUTAÇÃO: 
1. Organização de computadores: Tipos e representações de dados numéricos;
Aritmética binária; Álgebra booleana; Codificação de caracteres; Componentes da UCP; Conceito de interrupção; Modos de endereçamento.

2. Arquitetura de processadores: RISC e CISC; Linguagem de montagem; Ligação (Linking); Modos de operação do hardware; Conceitos de processamento paralelo e distribuído.

3. Sistemas Operacionais (SO): Gerenciamento do processador – Conceito e estados de processo;
Chamadas ao SO; I/O bound, CPU bound; Comunicação entre processos; Threads; Escalonamento; Primitivas de sincronização; Deadlocks.

4. Gerenciamento de memória: Áreas de memória de um processo; Algoritmos de alocação de memória; Fragmentação; Paginação; Segmentação; Memória Virtual; Substituição de páginas.

5. Gerenciamento de E/S: Estrutura de E/S (polling, interrupções, acesso direto à
memória); Comunicação com dispositivos; Estrutura do disco; Escalonamento de disco; Contenção; Sistemas de arquivo – Conceito de arquivo e diretório; Métodos de acesso; Alocação de arquivos (contínua, encadeada, indexada, por extensão); Proteção de arquivo; Cache
de disco.

 6. Redes: Arquitetura OSI da ISO; TCP/IP; HTTP e HTTPS.

II - ENGENHARIA DE SOFTWARE: 

1. Conceitos: Gerência e desenvolvimento de Requisitos. Solução Técnica. Integração do Produto; Verificação (Teste de Software e Revisão por Pares). Validação. Gerência de Projetos; Aquisição ou Gerência de Acordo com Fornecedores. Adaptação do Processo para Gerência do Projeto ou Gerência
Integrada do Projeto. Gerência de Riscos. Gerência de Configuração. Garantia da Qualidade ou Gerência da Qualidade do Processo e do Produto. Medição e Análise. Análise de Decisão e Resolução. Modelos de ciclo de vida. Manutenção. Análise de Pontos de Função.
Integração Contínua.

2. Análise e projeto de sistemas: Análise e projeto estruturado de sistemas; Análise e projeto orientado a objetos com notação UML; Acoplamento e coesão.

3. Processos de Software: Scrum; Kanban; eXtremme Programming (XP); Processo de
desenvolvimento de software unificado - Unified Process; MPS.BR (Melhoria de Processo do Software Brasileiro); CMMI (Capability Maturity Model Integration) para desenvolvimento versão 1.2.

 III - BANCO DE DADOS:   

1. Conceitos: Padrão ANSI para arquitetura de SGBD.
Modelo relacional de dados. Álgebra relacional. Cálculo relacional, Formas normais, Transação, Commit em duas fases, Serialização;
Bloqueios (granularidade, exclusivos, compartilhados e de intenção); Método otimista de controle de concorrência.

2. Modelo de Dados: Entidades; Atributos; Relacionamentos-Cardinalidade; Generalização e especialização de entidades; Mapeamento para modelo relacional.

3. ANSI SQL/92: Níveis de Isolamento de transações; Tipos de dados; Criação de domínios; Criação de tabelas; Manipulação de dados (insert, update, delete); Clausula select; Funções de agregação; Junções - produto cartesiano, interna, externa (esquerda, direita, ambos); Referência a tabelas; Operações em tabelas (union, except, intersect); Expressões condicionais (operadores, IS, BETWEEN, LIKE, IN, MATCH, ALL, ANY, EXISTS, UNIQUE); Subqueries; Visões (atualização de dados); Restrições (de domínio, chave candidata, chave estrangeira, definidas para tabela, assertivas); Ações na restrição de chave estrangeira; avaliação postergada de restrições.

4. Apoio à Decisão: Modelo dimensional; Drill Down; Esquemas estrela e floco de neve; Métricas aditivas, não aditivas e semi-aditivas; Dimensões não estáveis; Agregação de fatos; Uso de fatos agregados; Procedimentos de extração, transformação e carga.


 IV - PROGRAMAÇÃO E ARQUITETURA: 

1. Lógica: Lógica Proposicional; Lógica de Predicados.

2. Algoritmos e estrutura de dados: Complexidade de algoritmo; Listas e Pilhas; Vetores e matrizes; Estruturas em árvores; Árvores balanceadas; Métodos de ordenação; Pesquisa e hashing.

3. Programação estruturada: Tipos de dados (vinculação; verificação de tipos; tipificação forte); Estruturas de controle (comandos de decisão e repetição); Modularização; Sub-rotinas e funções; Passagem de parâmetros por referência e valor; Escopo de Variáveis.

 4. Programação orientada a objetos: conceitos de orientação por objetos; classes e objetos; herança e polimorfismo; encapsulamento.

5. Práticas de arquitetura de software: Inversão de controle; Programação por contrato; Injeção de dependências; Refatoração (princípios, aplicações e indícios de código mal estruturado).

6. Padrões de arquitetura de software: Padrões de projeto (Design Patterns); Padrões de Arquitetura de
Aplicações Corporativas (Patterns of Enterprise Applications Architecture); Padrões e antipadrões de projeto Java EE.

7. Linguagem Java: tipos e estrutura de dados; variáveis; enumerações; operações e expressões; instruções de controle; orientação a objetos; interfaces e classes abstratas; pacotes; exceções; coleções; tipos genéricos; anotações; sincronismo e multi-threading.

8. Desenvolvimento Java EE: Conceito de servidor de aplicação; Containers web e EJB; Java Server Faces (JSF), Facelets, Filtros e Servlet; Enterprise JavaBeans 3
(EJB); Java Persistent Architecture (JPA); Java Messaging System (JMS); Web Services SOAP e REST; Portlets (JSR 168 e JSR 286).

9. Arquitetura de TI: Benefícios estratégicos; Arquitetura atual e futura, análise de gap e roadmap; Tipos de arquitetura - Negócio, informação, sistemas, integração e tecnologia; Frameworks de arquitetura – Conceitos; Noções de computação distribuída (clusters, balanceamento de carga e tolerância a falhas); Arquitetura Orientada a Serviços (SOA - Service Oriented Architecture); Gerenciamento de Processos de Negócio (BPM - Business Process Managment); Portais corporativos (conceitos básicos: colaboração, personalização, gestão do conhecimento, gestão de conteúdo, taxonomia, integração de sistemas, web 2.0, Governança, Portlets); Barramento corporativo de serviços (ESB - Enterprise Service Bus).

10. Testes: Conceitos (verificação e validação); Tipos de Testes (Unidade, Integração, Funcional, Aceitação,Carga, Desempenho, Vulnerabilidade, Usabilidade).

11. Conceitos de Segurança: autenticação, autorização e auditoria; controle de acesso
baseado em papéis (Role Based Access Control - RBAC); controle de falhas em aplicações (OWASP - Open Web Application Security Project).

V - GESTÃO DE TI: 

1. Gerenciamento de Projetos baseado no PMBOK: Conceitos; Planejamento, Acompanhamento e Controle; Gerência de Escopo, Estrutura de decomposição de trabalho (WBS); Gerência de Prazo; Gerência de Custos; Gerência de Qualidade; Gerência de Recursos Humanos; Gerência de Comunicação; Gerência de Risco; Gerência de Aquisições; Gerência de Integração.

2. Governança e COBIT 4.0 (Control Objectives for Information and related Technology): Conceito, importância e responsabilidades sobre a
governança de TI; COBIT como framework de governança de TI; Principais características: foco em negócio, orientação a processos,
controle através de objetivos e direcionamento para medições; Áreas de Foco da Governança de TI; Domínios de processos do COBIT;
Modelo de maturidade para o COBIT.

3. Fundamentos da ITIL (Information Technology Infrastructure Library): Definição de Serviço, Métricas
(CSF, KPI), Modelo RACI, Service Desk, Gerências de: Demandas; Portfólio, Catálogo e Níveis de Serviço; Capacidade; Disponibilidade; Continuidade; Segurança; Mudanças; Configuração; Liberação; Validação; Conhecimento; Eventos; Incidentes; Requisição; Problemas; Acesso e Melhoria Contínua.

Análise e Levantamento de Requisitos

Primeiro que eu detesto essa palavra: "Requisitos".
Requisitos me faz lembrar de toda aquela baboseira sobre Engenharia de Software que eu tive que engolir na graduação.
É por isso que eu só desenvolvo programas para mim mesmo, pois eu sei os meus tais requisitos.

Funções e Restrições.

Requisitos de Usuário =>  São requisitos de alto nível, abstratos. Em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições que ele deve operar.
Podem ser requisitos funcionais ou não-funcionais.
Podem ser escritos em linguagem natural, formulários ou diagramas muito simples.

Requisitos de Sistema => Descrição detalhada do que o sistema deve fazer. Pode servir de contrato entre o comprador do sistema e o desenvolvedor.
Grave isso bem: "Requisitos do sistema informam de maneira detalhada o que um sistema deve fazer, e não como ele deve ser implementado"

Um único requisito de usuário de ser desbulhado em vários requisitos do sistema.

Especificação do Projeto => É uma descrição abstrata do projeto de software.

Tipo de Requisito	Escrito para quem poder entender?
Requisitos de Usuário	Gerentes de clientes Usuário final do sistema Engenheiro do Cliente Gerente do Fornecedor Arquiteto do Sistema
Requisitos do Sistema	Usuário final do sistema Engenheiro do Cliente Arquiteto do Sistema Desenvolvedor do Software ( Note que ele considera o desenvolvedor ignorante demais para entender os requisitos direta da boca do usuário) Note que aqui também os gerentes pulam fora.
Especificação do Projeto de Software	Engenheiro do Cliente Arquiteto do Sistema Desenvolvedor do Software

Então até aqui concordamos que os requisitos de usuário, sistema e a especificação formam uma espécie de pirâmide.

 No topo tempos a especificação - um monte de diagrama UML.
No meio temos os requisitos do sistema, em mais alto nível porém mais detalhado que os requisitos do usuário, expressos por vossa majestade Engenheiro de Software. É preciso esse nível porque segundo eles os desenvolvedores são estúpidos e não conseguem entender diretamente os requisitos do usuário.
Aqui o usuário vai dizer o que quer do software, com as palavras dele.






== Agora os Requisitos Classificam-se em ==

Requisitos Funcionais => São as funções.

Requisitos Não-funcionais => São as restrições.

Requisitos de Domínio => Podem ser funcionais ( as funções ) ou não-funcionais ( as restrições ). Emergem do próprio domínio de aplicação do software. Bom, eu procurei alguns exemplos mas Enrolagem de Software é algo tão subjetivo que ninguém se arrisca a dar um exemplo diferente do que tem no livro de Somevile.

"A desaceleração do trem deve ser computada através da fórmula Dtrem=Dcontrole+Dgradiente onde ..."

O próprio Someleca fala que na prática é muito difícil se classificar um requisito como funcional ou não funcional porque um requisito não-funcional pode envolver a implementação de um requisito funcional.

Ná prática a Engenharia de Software não é Engenharia, se fosse, engenheiro de software tinha o CREA.

Requisitos Não-Funcionais

Eles estão relacionados com as propriedades emergentes dos sistemas.
Eles são as restrições sobre as funcionalidades do sistema, como desempenho, portabilidade de código, robustez, resiliência e etc.

Eles se dividem em:

Os requisitos de produto especificam as restrições impostas ao produto, como  a portabilidade, o desempenho, requisitos de espaço e a confiabilidade.

Os requisitos organizacionais derivam das restrições políticas da organização do cliente e também da organização do desenvolvedor, como por exemplo, linguagem de programação X ou utilizar SGBD Y.

Requisitos Organizacionais de Linguagem de Programação

Os requisitos externos são restrições externas ao sistema e ao seu processo de desenvolvimento, a citar, requisitos de interoperabilidade com outros sistemas legados, utilizando por exemplo JCA ( Java Conector Architecture) ou ainda (Java para Coisas Antigas). Também os requisitos legais, como por exemplo, é proibido utilizar criptografia na China.

Destino de quem usa SSL, TSL, IPSec, SSH ...  na China

Não confundir interoperabilidade com portabilidade.

Além disso, os requisitos não-funcionais podem ser de difícil verificação. Sempre que possível utilizar uma métrica quantitativa.

Abaixo, uma questão que eu errei no último concurso que teve para Engenheiro de Software. E assim, com mais duas questões que eu errei de algoritmos, coisa que eu estava bastante confiante pois já tinha participado de duas maratonas de programação, assim eu deixei escapar a chance de comprar meu honda civic. (Fiquei a 3 questões das vagas)


(Petrobras, 2011) Na Engenharia de Software, os requisitos que descrevem
o comportamento externo do sistema, estabelecendo uma
descrição detalhada das funções, dos serviços e das restrições
operacionais do referido sistema, são os requisitos
(A) funcionais
(B) externos
(C) de sistema
(D) do usuário
(E) não funcionais


O que me lascou foi esse "comportamento externo".  Porém ele fala em funções e restrições operacionais do sistema.  E note também que ele fala em comportamento externo, não em restrições externas, que seriam os requisitos externos. Comportamento externo é o sentido pelo usuário, então trata-se dos requisitos de sistema, letra C, que abarcam os requisitos funcionais (funções) e requisitos não-funcionais (restrições) de forma mais detalhadas que os requisitos de usuário.

Levantamento de Requisitos

Eita, vou até pegar um café que o texto é longo.


Algumas partes que escrevi abaixo foi retirado no trabalho de FABIANA MICHELE FERNANDES PIVOTO FARIA, podendo ser encontrada aqui [1]


Outras foram escritas com base em minhas anotações e mindmaps que perdi as referências.

Amostragem

• Determinar os dados a serem coletados
• Determinar a população a ser amostrada
• Escolher o tipo da amostra
• Decidir o tamanho da amostra

Observação

• Levantar informações que passam despercebidas em outras técnicas
• Ver não apenas o que é documentado e especificado
• O relacionamento do tomador de decisão e os demais membros da organização
• Confirmar ou negar informações obtidas em entrevistas e questionários

A técnica em que o levantador de requisitos se insere no ambiente de trabalho para coletar requisitos é chamado de etnografia, é como um antropólogo ir morar em uma aldeia indígena para aprender o costume dos índios.

Etnografia para o sommerville:
Utilizada para compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de trabalho onde o sistema será usado. Observa o trabalho do dia a dia e anota as tarefas reais nas quais os participantes estão envolvidos. O valor da etnografia está na ajuda que presta aos analistas para descobrir requisitos implícitos de sistemas que refletem os processos reais, e não os formais.
Ela é eficaz para descobrir dois tipos de requisitos:
1. derivados da maneira como as pessoas realmente trabalham
2. derivados da cooperação e do conhecimento das atividades de outras pessoas.

Entrevista

Quanto ao tipo de pergunta

• Perguntas Abertas ( Subjetivas )
• Perguntas Capciosas
• Tendem a fazer o entrevistado responder de uma forma específica
• São tendenciosas
• Duas questões em uma Ex: O que você faz nessa situação, e como?
• Perguntas Fechadas (Objetivas) 
• Que nem questões de concurso. 

Agora que formulamos as perguntas, vamos fazer a entrevista.

Lembre-se, as questões objetivas são mais arrochadas que as subjetivas. As objetivas são as estreitas, as subjetivas são largas. Isso é útil para decorar sobre a geometria de como são estruturadas as entrevistas.

• Quanto a estrutura da entrevista.
• Estrutura Pirâmide 
• Começa com questões detalhadas (Objetivas / finas)
• Termina com questões mais gerais (Subjetivas / largas )
• Estrutura Funil
• Começa com questões mais gerais (Subjetivas / largas )
• Termina com questões mais detalhadas (Objetivas / finas)
• Estrutura de Diamante 
• Funil + Pirâmide
• Específicas -> Gerais -> Específicas
• Geralmente a melhor forma
• Tende a ser mais longa
• Não-Estruturada
• Não há uma sequência de como as questões serão abordadas
• Porém as questões são definidas a-priori (Isso é questão de concurso, já errei uma no QC assim. Não tem como vc ir para um entrevista sem saber o que perguntar!)

Prototipação

Pode utilizada para descoberta ou validação de requisitos
Pode ser

• Evolucionária
• Exploratória

Prototipação em papel não têm a necessidade de linguagem de programação. Essa é a melhor de todas, a gente faz cada programa revolucionário no papel... Eu mesmo tenho uma suite todinha que fiz enquanto lanchava um dia desses.

Análise de Protocolo
Cenário

Sessões JAD

Criada pela IBM
Workshop estruturado

5 FASES

1. Definição do projeto
2. Pesquisa
3. Preparação para a sessão
4. A Sessão
5. Documento Final

PD
QFD
CRC

IFQ (Implantação da Função de Qualidade)

• Também conhecido como ou QFD (Quality Function Deployment)
• Traduzir Necessidades dos clientes para requisitos técnicos de software
• Três tipos de requisitos
• Requisitos Normais
• Requisitos Funcionais
• Requisitos Esperados
• Requisitos Implícitos
• Importantes, porém não mencionados na coleta
• Requisitos Excitantes
• Vão além da expectativa dos usuário

Atividades do Processo

obtenção; classificação e organização; priorização e negociação; documentação.

Validação de Requisitos

Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

Prova: CESGRANRIO - 2006 - Petrobrás - Analista de Sistemas Pleno - Especialidade - Engenharia de Software

Disciplina: Engenharia de Software | Assuntos: Análise de Requisitos;  Engenharia de Requisitos; 

Analise as afirmativas abaixo a respeito de técnicas de levantamento de requisitos:

I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

Estão corretas apenas as afirmativas:

•  a) I e II.

•  b) III e IV.

•  c) I, II e III.

•  d) I, II e IV.

•  e) II, III e IV.

I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente. 

ERRADO.  As questões devem ser definidas anteriormente, porém a forma com a qual essas questões serão estruturadas é que não é definida.

As questões podem ser abertas (subjetivas) ou fechadas (objetivas) e podem ser estruturadas em várias estruturas (Pirâmide, Funil e Diamante), ou em nenhuma estrutura como cita a questão.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

Sim, isso mesmo. (Requisitos Excitantes - Que excedem a expectativa do cliente )

III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

Correto também. Quando o universo da população é muito grande pode-se utilizar uma parcela dessa população para se representar o todo.

IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

Observar o comportamento e o ambiente do indivíduo que toma decisões pode ser
uma forma bastante eficaz de levantar informações que, tipicamente, passam
desapercebidas usando outras técnicas.

Note que as pessoas tem um conhecimento tácito, algo inerente a elas que não pode ser facilmente formalizado em um documento.

Teste de Unidade e Integração

Bom, tomando umas cervas aqui e pensando na vida, em como faz um ano que estudo para concursos e até agora só dedo nas ventas, resolvi dar uma estudadinha em teste de software.

Vou falar basicamente de testes de unidade, módulo e integração.

O Plano de Testes.

• Escopo dos testes
• Abordagem de testes
• Os recursos para a realização dos testes
• Cronograma das atividades a serem realizadas

Os casos de teste são as especificações das entradas para o teste e da saída esperada.

Teste de Unidade, unário ou de modo.

O objetivo desse teste é testar componentes individuais do software.
Usualmente é de responsabilidade do desenvolvedor. A exceção é para software crítico, pois nesse caso não dá para confiar em uma só pessoa.
Geralmente esses testes são derivados da experiência do desenvolvedor e também do conhecimento da estrutura de implementação do programa.

Esse teste garante que todas as declarações sejam executadas pelo menos uma vez.

Já o teste de caminho é ainda mais arrochado. Ele deve garantir que todos os caminhos individuais de um programa sejam executados pelo menos uma vez, com todos os seus ifs e elses. Alias, isso é particularmente impossível quando existem loops. Não tem como testar infinitas iterações em loops. Então a n-passagens por um loop contam como uma condicional.

Teste de Integração

Enquanto o teste de unidade é de responsabilidade do desenvolvedor, o teste de integração é de responsabilidade de uma equipe independente.  Esses testes são baseados na especificação do sistema, isto é, o objetivo do teste de integração é testar o desenho do sistema, enquanto o teste de unidades tem como objetivo testar o código do sistema.

Se esse teste de integração for de cima para baixo -  (TOP-DOWN) - usa-se stubs, se form de baixo para cima - BOTTOM UP - usa-se drivers.

Teste de Integração BOTTOM-UP

Nesse tipo de teste os componentes baixo-nível são desenvolvidos primeiro.

Teste de Integração TOP-DOWN

Nesse tipo de teste, os componentes alto-nível são desenvolvidos e testados primeiro, e criam-se os stubs que simulam os componentes em baixo nível, isto é, esses stubs têm a mesma interface que os componentes em baixo-nível a serem desenvolvidos, porém uma funcionalidade bem limitada.

Validação da Arquitetura	Os testes top-down oferecem maior probabilidade de descobrir erros na arquitetura do sistema e no projeto de alto-nível. Assim, erros estruturais podem ser corrigidos logo no começo, sem muito prejuízo. Já no Bottom-up, o projeto em alto-nível não é validade até os estágios finais ( quando estão sendo construídos os componentes em alto-nível, até então simulados por drivers)
Demonstração do Sistema	No desenvolvimento top-down o aspecto geral do projeto está mais visível.
Implementação de Teste	Implementações top-down são mais difíceis de testar porque os componentes em alto-nível são mais complexos, então todo esse comportamento tem que ser simulado. As vezes fica tão complicado fazer os stubs quando desenvolver os próprios componentes inferiores.
Observação de Teste	Isso é um problema para os dois, já que tanto em um quanto em outro, é possível que os componentes que estão sendo desenvolvidos não gerem saída, de forma que essa saída tem que ser implementada para que se possa testar o componente.

A espiral abaixo mostra uma visão geral do processo de teste.

Em um teste de defeitos, nós temos sucesso quando encontramos um defeito.

A coisa mais manjada sobre teste é você saber que um teste pode revelar a presença de defeitos, mas nunca a sua ausência.

Isso contrasta com o Teste de Validação cujo objetivo é demonstrar que um sistema atende às suas especificações.

Segundo Sommervile: "Testes exaustivos são impossíveis" , de fato, estudando Teoria da Computação esses dias, vi que o problema da parada não é Turing-Decidível, então não há nunca como saber se um software vai parar ou entrar em loop infinito.

Testar antigas capacidades é mais importante que testar capacidades antigas.

Testar situações tipicas é mais importante que testar situações nas fronteiras ( referindo-se a situações incomuns)

Teste de Caixa-preta é uma técnica de teste que não deriva da implementação, apenas da especificação do sistema. Isto é,  note que implementação é diferente de especificação.

Já o Teste em Caixa-branca é derivado da implementação, isto é, do código-fonte. O objetivo é exercitar todas as estruturas do programa.

O Teste de caminho vai além do Teste em Caixa-Branca, garantindo que todos os caminhos possíveis de um software seja exercitados pelo menos uma vez. Isso está diretamente ligado a complexidade ciclomática de um software, que é todos os possíveis caminhos que um software pode percorrer por sua estrutura de implementação.

A fórmula que nos dá essa complexidade é nada por C = P +  1 onde P é o número de nós preditivos, isto é, que podem causar desvios condicionais como if, for ...

CMM

O CMM envolve a aplicação dos princípios de qualidade total.
É uma metodologa de diagnóstico e avaliação da maturidade.

Estrutura do CMM

• Níveis de Maturidade
• Áreas-chave do processo
• Objetivos
• Características Comuns
• Práticas-base

Níveis de Maturidade

São 5 níveis de maturidade.

Como meu broder muito bem mencionou. Para fazer o concurso, é bom

IR DE GOL

Inicial => Poucos processos definidos, não se consegue fazer previsões e os imprevistos são comuns. O desenvolvimento do software é confuso. Pegam-se os requisitos e sem passar pelo menos uma manteguinha vai logo para a codificação. Documentação é desprezada. Dependência de heróis e bombeiros. A palavra mais usada aqui é ad hoc.

Não dispõe de nenhum processo.

--

Repetível => Aqui já começa a preocupação com a gerência do projeto. Começa a prática se fazer reuniões semanais, de acompanhamento do cronograma. Aqui os gerentes já conseguem identificar os problemas. Porém os processos só funcionam se mudanças não ocorrem.

Note a figura. Os marcos do processo e o seu status já são visíveis. Aqui técnicas de gerenciamento de projetos são estabelecidas para mapear custos, prazos e funcionalidades.

Os requisitos do cliente e os produtos de trabalho são controlados.

As práticas básicas de gerenciamento de projetos estão estabelecidas.

Esses controles possibilitam a visibilidade do projeto em momentos  definidos (como se pode ver na figura, os marcos); Então esse processo é visto como uma sucessão de caixas-pretas. Quando termina cada caixinha preta dessa é que a organização vê o progresso do software, que nem a empresa onde eu trabalhava. O que seria cada caixa preta dessa:

Criação da Arte => Montagem do Layout => Programação => Colocação do Conteúdo => Publicação.

Porém em cada etapa dessas a empresa não tinha a menor noção de como estava o andamento do projeto.

A gerência reage a problemas quando eles ocorrem. 

• Gestão de Requisitos  ( RM )
• Planejamento do Projeto ( SPP )
• Supervisão e Acompanhamento de Projeto de Software ( SPTO )
• Gestão de Subcontratação de Software ( SSM )
• Garantia da Qualidade de Software (  SQA )
• Gestão de Configuração de Software (SCM)

Definido => Os processos permitem adaptação e mudança. Mesmo se a coisa tiver preta os gerentes ainda têm o controle do processo ( Lembre-se, isso é o mundo mágico da godelagem de ti, é absurdo, eu sei, mas decore essa tranqueira só para passar no concurso, depois esqueça pq isso n serve pra nada). Essa gestão é feita baseada na experiência da equipe. Aqui o processo já começa a ser bem documentado. Atividades planejadas, estáveis e repetitivas.  As funções e responsabilidades no processo são bem entendidas. A produção do produto de software é visível através do processo de software.

Processos previstos apenas qualitativamente.

• Foco no Processo da Organização (OPF)
• Definição do processo da organização ( OPD )
• Programa de Treinamento ( TP )
• Gestão Integrada de Software ( ISM )
• Engenharia de Produto de Software ( SPE )
• Coordenação entre Grupos (IC)
• Revisões Técnicas Formais (PR)

Gerenciado => Aqui a gestão de processos já tem tratamento quantitativo. A produtividade e qualidade são medidas em todos os produtos e processos.

A principal diferença com o nível anterior é que aqui o desempenho dos processos já pode ser medido quantitativamente, tais como técnicas estatísticas. Aqui o desempenho do processo já pode ser previsto.

Previsto quantitativamente e qualitativamente.

• Gestão quantitativa dos processos (QPM )
• Gestão da qualidade de software (SQM)

Otimizado => Gerentes agem de forma pró-ativa. A eficiência é usada para análise de  novas tecnologias.

Avaliação constante da equipe para tornar o trabalho mais produtivo.

• Prevenção de Defeitos (DP)
• Gerência de Mudança Tecnológica (TCM)
• Gerência de Mudanças de Processos (PCM)

A TCM foi parar na DP da Polícia Cívil de Mossoró.

Áreas-chave do processo

São 18 áreas-chave

Objetivos

São 52 objetivos

Características Comuns

• Compromisso para realizar
• Capacidade para realizar
• Atividades realizadas
• Medições e Análise
• Verificar a Implementação

Práticas Base

Sâo 316 práticas