Sei sulla pagina 1di 82
Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

AULA 00: Engenharia de Software

SUMÁRIO

PÁGINA

Apresentação

1

Proposta de Trabalho

2

Cronograma

3

Mural do Aluno

4

Exercícios

5

Considerações Finais

64

Lista de Exercícios

65

Gabarito

82

Antes de mais nada, peço que você preste bastante atenção na nossa PROPOSTA DE TRABALHO e nas CONSIDERAÇÕES FINAIS, para que você tenha a exata noção do nosso objetivo, ao realizar este curso em exercícios. Tenho certeza que você irá se debruçar sobre o conteúdo, mas não deixe de observar estes itens, em especial.

APRESENTAÇÃO

Olá a todos! E sejam bem-vindos ao projeto Questões Comentadas de TI para Agente Fiscal de Rendas da Secretaria de Fazenda do Estado de São Paulo (ICMS-SP/2013) Especialidade Tecnologia da Informação.

Permitam-me primeiro que eu me apresente.

Eu sou Victor Dalton Teles Jesus Barbosa. Minha experiência em concursos começou aos 15 anos, quando consegui ingressar na Escola Preparatória de Cadetes do Exército, em 1999. Cursei a Academia Militar das Agulhas Negras, me tornando Bacharel em Ciências Militares, 1º Colocado em Comunicações, da turma de 2003.

Em 2005, prestei novamente concurso para o Instituto Militar de Engenharia, aprovando em 3º lugar. No final de 2009, me formei em Engenharia da Computação, sendo o 2º lugar da turma no Curso de Graduação. Decidi então mudar de ares.

Em 2010, prestei concursos para Analista do Banco Central (Área 1 Tecnologia da Informação) e para Analista de Planejamento e Orçamento (Especialização em TI). Respectivamente, as bancas examinadoras foram a Cesgranrio e ESAF.

Prof. Victor Dalton

www.estrategiaconcursos.com.br

1 de 82

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Felizmente, fui aprovado nesses certames, e hoje, após uma passagem pelo Ministério do Planejamento, optei por trabalhar no Banco Central do Brasil. Ainda, recentemente, passei para o cargo de Analista Legislativo da Câmara dos Deputados, cuja banca examinadora foi o CESPE, e estarei migrando para esta Casa nos próximos dias.

Com esta feliz experiência em concursos públicos, tive a honra de ser convidado para o Estratégia Concursos. Elaborei o simulado de Auditoria de TI para o concurso da CGU, e, uma vez aprovado, fui “intimado” a participar de forma mais efetiva. Conheço a equipe do Estratégia, sei da competência e da capacidade desse pessoal, e estou me esforçando para manter o gabarito dos cursos aqui ministrados. Já ministrei cursos para os concursos da Receita Federal e para o ICMS-PR, cujo feedback dos alunos tem me impulsionado a continuar cada vez mais a ministrar aulas.

PROPOSTA DE TRABALHO

A nossa proposta de trabalho é apresentar questões de TI comentadas, com total orientação para o concurso de Agente Fiscal de Rendas (ICMS- SP/2013). Nosso objetivo, ao término desse curso, é cobrir toda a matéria de Tecnologia da Informação do edital do certame.

Pois bem, e como alcançaremos este objetivo?

Semanalmente, traremos uma apostila, contendo em torno de 40 exercícios comentados abrangendo todo o edital, com ênfase na FCC. Contudo, também traremos exercícios de outras bancas, como ESAF, CESPE, FGV, UEL e Cesgranrio, cujo conteúdo seja relevante, e também elaborarei algumas questões, com o objetivo de chamar a atenção do futuro auditor para alguns tópicos importantes, bem como despertar formas diferentes de enxergar determinado assunto. Tudo isso, claro, com o objetivo de melhor capacitá-lo para a prova. Atualmente, o curso já contém 314 questões, e certamente ultrapassará 400 questões comentadas. Que tal?

Ainda, agregarei a este curso outro diferencial: irei divulgar diversas fontes online e livros para que você possa reforçar seus estudos. A Tecnologia da Informação, com certeza, é a matéria cuja bibliografia “ideal” para concursos públicos não é consolidada, e, inclusive, motivo de divergências entre estudiosos do assunto. Por isso, desde o início do curso, postarei no Mural do Aluno diversos links cujo conteúdo eu considere relevante, além de várias indicações de livros e comentários sobre os mesmos (pois os tenho comigo). A web possui muito lixo eletrônico, e até mesmo os mais íntimos do ramo correm o risco de estudarem por fontes inadequadas. Usarei minha experiência e meu conhecimento para direcioná-lo pelo caminho certo. De certa forma, estas indicações funcionarão como uma consultoria.

Vamos lá?

Prof. Victor Dalton

CRONOGRAMA Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor

CRONOGRAMA

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Nosso cronograma trará os exercícios na seguinte sequência:

Aula 00 (29/10/2012) Engenharia de Software: Ciclo de vida do software. Processos de Desenvolvimento de Software. Gerência de Requisitos de Software: Conceitos de Requisitos. Requisitos Funcionais e Não-Funcionais. Gerência de Configuração e Mudança. Conceitos de Gerência de Configuração e Mudança de Software. Solicitações de Mudança.Testes e Avaliação de Qualidade de Software: Conceitos. Documentos de Teste.

Aula 01 (01/11/2012) Gestão e Governança de TI: Planejamento Estratégico. Alinhamento entre estratégias de tecnologia da informação e de negócio:

conceitos e técnicas. Gerência de Projetos: Conceitos Básicos. Processos do PMBOK. Planejamento e controle de métricas de projeto. Planejamento e avaliação de iterações. CMMI (versão 1.2): conceitos e formas de representação. Disciplinas e Processos.

Aula 02 (09/11/2012)Gerência de serviços de TI: Fundamentos da ITIL (versão 3). Fundamentos de CobiT (versão 4.1). Service desk. Conhecimentos sobre norma ISO/IEC 20000. MPS/Br. Análise por Pontos de Função. Processo unificado(RUP): disciplinas, fases, papéis e atividades.

Aula 03 (13/11/2012) Vírus de computador: tipos de vírus, danos causados por vírus, antivírus, cavalo de tróia, Spoofing, Phishing e negação de serviço. Criptografia, assinatura digital e autenticação: conceitos básicos de criptografia, sistemas criptográficos simétricos e assimétricos, PKI (infraestrutura de chaves públicas), assinatura e certificação digital, protocolos criptográficos, características do RSA, DES, 3DES, e AES, das funções hash, e do MD5 e SHA-1. Conhecimentos sobre norma ISO 27001.

Aula 04 (16/11/2012) Redes: Conceito de rede. Tipos e meios de transmissão. Topologias de redes de computadores. Arquitetura de rede. Elementos de interconexão de redes de computadores (hubs, bridges, switches, roteadores, gateways). Noções de Sniffing. Arquitetura e protocolos de redes de comunicação: modelo de referência OSI e arquitetura TCP/IP. Acesso remoto e Rede Wireless. Noções de administração de redes. Noções de mobilidade.

Aula 05 (20/11/2012) Bancos de dados: Conceitos Básicos. Conceitos de desenvolvimento em bancos de dados SQL Server e Oracle. Modelagem de Dados Relacional. Business Intelligence: Modelagem de Dados Multidimensional.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Conceitos de Datawarehouse, e ETL. Modelagem e otimização de bases de dados multidimensionais. Conceitos de Data Mining.

Aula 06 (24/11/2012) Programação de Sistemas: Fundamentos de lógica de programação, estrutura de dados e arquivos. Paradigmas de programação:

programação estruturada, programação orientada a objetos. Linguagem de programação Java: conceitos básicos e aplicações. Arquitetura de Software:

Conceitos Básicos, Arquitetura em Camadas. Arquitetura Orientada a Serviços (SOA). Portais Corporativos e Colaborativos. Web Services.

Aula 07 (02/02/2013) Gestão de Processos de Negócio: Modelagem de processos. Técnicas de análise de processo. Conceitos de Arquitetura Corporativa (TOGAF). BPM (Business Process Management) e gerenciamento eletrônico de documentos. Planejamento estratégico de TI (PETI). Análise SWOT. BSC Balanced Scorecard. Responsabilidade e papéis de TI. Processos de definição, implantação e gestão de políticas organizacionais. Gestão de riscos.

Aula 08 (16/02/2013) Sistemas Operacionais: Conceitos de administração de servidores em plataforma Windows. Conceitos de administração de servidores em plataforma Linux. Conceitos de virtualização. Active Directory. Auditoria de TI: controles internos, procedimentos de controles internos gerais e aplicados à TI. Vulnerabilidade e conformidade. Backup e recuperação de dados.

MURAL DO ALUNO

Observação: O conteúdo presente neste trecho, a partir das próximas aulas, somente estará presente no Mural do Aluno, e não nas apostilas.

Engenharia de Software é um dos ramos da TI cuja bibliografia talvez seja a mais consolidada. Dois são os autores referência, tanto para aprender Engenharia de Software quanto para concursos: Pressman e Sommerville.

Se eu fosse indicar apenas um livro, indicaria Pressman, Engenharia de Software: Uma Abordagem Profissional, atualmente em sua sétima edição, no Brasil. Pressman é mais adotado para a parte de Modelos de Processo, Qualidade de Software e Teste de Software.

Já na parte de Engenharia de Requisitos e Métricas de Software, vejo um meio a meio entre Pressman e Sommerville, Engenharia de Software. Inclusive, várias bancas adotam ambas as propostas dos autores, cobrando-as simultaneamente em prova. Portanto, quem puder se dar ao luxo de ter os dois livros, vale a pena adquirir ambos.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

No livro do Pressman, é interessante ler toda a Parte 1, capítulos 5 e 6 da Parte 2, capítulos 14, 15, 16, 17 e 23 da Parte 3. Existem outros capítulos interessantes, que complementam outras matérias de TI. Serão citados em outras aulas.

Quem tem o Sommerville deveria ler os capítulos 4, 6, 7, 11, 13, 14, 17,

18,

matérias.

19,

22, 23, 27 e 29. Outros capítulos também complementam

outras

Temos abaixo, um link “quebra-galho” para ES:

Testes de software também pode ser visto aqui:

Para o estudo da UML, eu recomendo o livro Princípios de Análise e Projeto

de Sistemas com UML, do Eduardo Bezerra. É um livro bastante completo e fácil

de entender. Capítulos 1, 2, 4, (praticamente o livro todo).

11 são interessantes

5,

7,

8,

9,

10

e

Ainda, achei um trabalho da PUC muito interessante sobre Scrum:

Lembro, ainda, que o Mural do Aluno pode ser constantemente atualizado, com novas dicas e informações, à medida que novas boas fontes apareçam.

EXERCÍCIOS

1ª Questão) (ESAF Analista de Finanças e Controle Desenvolvimento de Sistemas da Informação - 2008) A Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os aspectos da

produção de software, desde os estágios iniciais de especificação do sistema até

a manutenção do mesmo. A Engenharia de Software adota métodos de

engenharia de software que a) são um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software.

b) são uma representação simplificada de um processo de software, apresentada a partir de uma perspectiva específica.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

c) são abordagens estruturadas para o desenvolvimento de software, que

incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos. d) se ocupam da teoria e dos fundamentos de desenvolvimento de software.

e) se ocupam de todos os aspectos relacionados ao desenvolvimento de

sistemas com base em computadores, incluindo hardware, software e engenharia de processos.

Nada como começar pela definição!

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. Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software adota métodos de engenharia de software que são abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos.

Nossa resposta certa é a letra c).

Desenvolvimento de Sistemas da Informação - 2012) A escolha de um

modelo é fortemente dependente das características do projeto. Os principais modelos de ciclo de vida podem ser agrupados em três categorias principais:

Questão)

(ESAF

Analista de Finanças

e

Controle

a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.

c) sequenciais, incrementais e evolutivos.

d) sequenciais, ágeis e cascata.

e) cascata, ágeis e evolutivos.

Modelos de processos de software! O começo da Engenharia de Software. Estas classificações variam muito entre autores. Entretanto, esta é a mais recente cobrada em concursos, e muito próxima da adotada por sua fonte recomendada para estudos. Vejamos:

Modelos sequenciais: são os modelos “à moda antiga”, como o modelo em cascata e o modelo em V. Nestes modelos, uma fase só começa após o término da outra. É um modelo meio ultrapassado de desenvolver software.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 Modelo em Cascata Modelo em V Modelos

Modelo em Cascata

Prof Victor Dalton – Aula 00 Modelo em Cascata Modelo em V Modelos incrementais : onde

Modelo em V

Modelos incrementais: onde se enquadram o próprio modelo incremental e o RAD (Rapid Application Development). Partem do princípio que a cada ciclo uma versão operacional do sistema será produzida e entregue ao cliente para uso ou avaliação detalhada.

e entregue ao cliente para uso ou avaliação detalhada. Prof. Victor Dalton Modelo Incremental

Prof. Victor Dalton

Modelo Incremental

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 RAD Modelos evolutivos – É uma forma

RAD

Modelos evolutivos É uma forma de desenvolvimento na qual o software é desenvolvido em ciclos, e a cada ciclo novas funcionalidades são incrementadas ao sistema. Enquadram-se aqui o modelo espiral e a prototipação.

Enquadram-se aqui o modelo espiral e a prototipação . Modelo em espiral Prof. Victor Dalton Prototipação

Modelo em espiral

o modelo espiral e a prototipação . Modelo em espiral Prof. Victor Dalton Prototipação

Prof. Victor Dalton

Prototipação

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Observe que “interessante”: na definição de modelos incrementais falamos em ciclo, e na definição de modelos evolutivos falamos em incrementar funcionalidades. E aí? Bem, Pressmann diferencia o incremental do evolutivo afirmando que o incremental seria “o modelo sequencial aplicado de maneira iterativa”, enquanto o evolutivo é voltado para “acomodar um produto que evolui com o tempo”. Pode ser que isso não lhe diga muita coisa, mas a grande verdade é que você está aqui para acertar questões na prova, e não pra tirar um diploma de Doutor em Engenharia de Software. Não é verdade? E o Pressmann é um autor de renome, não sendo incomum suas definições aparecerem Ipsis Literis em questões de concursos. Na hora da prova, dance conforme a música. Você vai me ouvir falar isso mais de uma vez nessa apostila.

Resposta certa, alternativa c).

3ª Questão) (ESAF Analista de Planejamento e Orçamento Tecnologia da Informação - 2010) As atividades do modelo espiral de Engenharia de Software são:

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e

Avaliação feita pelo cliente. b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.

d) Planejamento,

Eliminação

dos

Riscos,

Análise

de

Contingência

e

Avaliação feita pelo cliente. e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

Se você prestou bem atenção na figura do modelo em espiral, na página anterior, vai ficar em dúvida para responder esta questão. Já falei antes e falo novamente, existe o que os autores consagrados pregam e existe o que a sua banca quer ouvir, que pode vir desses autores OU não. Entretanto, um senso comum entre os autores sobre o modelo espiral é o reconhecimento explícito do risco, e a entrega para o cliente validar, aceitar, verificar etc. E, pessoal, não é brincadeira: se você sair pesquisando no Google, vai achar umas 10 espirais diferentes, sem exagero! A própria espiral do Pressmann (reconhecidamente, o grande autor em Engenharia de Software), que é dividida em Planejamento,

Modelagem,

a

responder esta questão. “Ah, Victor e por que você não nos passa a espiral padrão, aquela que as bancas sempre cobram?” Porque se eu ou alguém lhe prometer essa espiral estará mentindo pra você. Logo, meu objetivo é lhe preparar da melhor forma para o que pode vir pela frente.

Construção,

Emprego

e

Comunicação,

não

lhe

habilitaria

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Pesquisando na internet, achei um autor que afirma que o modelo em espiral possui as seguintes etapas: Comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e liberação, e avaliação com o cliente. Foi o conceito mais próximo da alternativa correta da ESAF, a letra b). Se fôssemos por eliminação, ficaríamos entre a b) e a e), pelo menos. Já falei em “dançar conforme a música”? Pois é, acho que vou ser muito repetitivo nesta apostila

4ª Questão) (FCC Ministério Público do Estado do Rio Grande do

Norte Analista de Tecnologia da Informação Especialidade Engenharia

de

desenvolvimento de software em espiral, cada loop na espiral representa

- 2010) No modelo de

Software/Desenvolvimento

de

Sistemas

a) a necessidade de retornar ao início da fase em que se encontra.

b) um processo de reengenharia.

c) uma disciplina de software.

d) uma fase do processo de software.

e) uma atividade paralela.

Segundo Pressman, “o primeiro circuito em volta da espiral pode resultar no desenvolvimento de uma especificação de produto; passagens subsequentes em torno da espiral podem ser usadas para desenvolver um protótipo, e, então, progressivamente, versões cada vez mais sofisticadas do software.

Desse modo, percebemos que a única alternativa aplicável é a letra d). Veremos, ao longo do curso, que a FCC gosta muito de questões de raciocínio, alternadas com questões de simples definição de conceitos.

5ª Questão) (FCC Ministério Público do Estado do Rio Grande do

Especialidade

Engenharia de Software/Desenvolvimento de Sistemas - 2010) O modelo em espiral difere principalmente dos outros modelos de processo de software por

Norte

-

Analista

de

Tecnologia

da

Informação

a) não contemplar o protótipo.

b) reconhecer explicitamente o risco.

c) não ter fases.

d) possuir uma fase única evolucionária.

e) não contemplar o projeto do produto.

Esta questão é didática por mostrar exatamente o ponto comum entre os autores, ao tratarem do modelo em espiral. Lembra que eu expliquei isso questões atrás?

Resposta certa, alternativa b).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

6ª Questão) (FCC Companhia do Metropolitano de São Paulo - Analista Desenvolvimento Gestão Júnior Ciências da Computação - 2012) O processo de desenvolvimento em cascata é um exemplo de processo

dirigido a planos, pois, em princípio, é necessário planejar e programar todas as atividades do processo antes de começar a trabalhar nelas. São exemplos de estágios desse modelo:

a) Integração de Produto, Definição de Processo Organizacional e

Gerenciamento de Riscos. b) Análise e Definição de Requisitos, Implementação de Teste Unitário e Integração e Teste de Sistema.

c) Inicial, Gerenciado e Em Otimização.

d) Engenharia de Requisitos, Ciclo de Vida de Projetos e Gestão de Incidentes.

e) Acompanhamento e Controle de Projeto, Medição e Análise e

Desenvolvimento de Requisitos.

Detalhando o modelo em cascata:

Análise e Definição de Requisitos Os serviços, restrições e objetivos do sistema são definidos por meio de consulta aos usuários do sistema. Eles são, portanto, definidos detalhadamente e servem como uma especificação de sistema. Projeto de sistema e software O processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele estabelece uma arquitetura geral do sistema. O projeto de software envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações. Implementação e teste de unidade Durante esse estágio, o projeto de software é realizado como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação. Integração e testes de sistema As unidades individuais de programa ou os programas são integrados e testados como um sistema completo para garantir que os requisitos de software foram atendidos. Após os testes, o sistema de software é liberado para o cliente. Operação e manutenção Geralmente (embora não necessariamente) esta é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em operação. A manutenção envolve a correção de erros não detectados nos estágios anteriores ao ciclo de vida, no aprimoramento da implementação das unidades de sistema e na ampliação dos serviços de sistema À medida que novos requisitos são identificados.

O segredo para acertar a questão é conhecer bem os nomes das etapas, para não ser ludibriado pelas alternativas. Pela explicação da etapa, que consta do enunciado, não cabe marcar outra alternativa que não seja a letra b).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

P.S.:Apenas para desencargo de consciência, Pressman, na última edição de seu livro, “renomeou” as etapas do modelo em cascata. Nunca vi cobrança dessa nova nomenclatura em provas, mas segue, de brinde, pra você.

nomenclatura em provas, mas segue, de brinde, pra você. 7ª Questão) (FCC – Companhia do Metropolitano

7ª Questão) (FCC Companhia do Metropolitano de São Paulo - Analista Desenvolvimento Gestão Júnior Ciências da Computação - 2012) A engenharia de software baseada em reuso é uma estratégia da engenharia em que o processo de desenvolvimento é orientado para o reuso de

softwares existentes. Dentre os benefícios do reuso de software, é INCORRETO afirmar:

a) Preencher uma biblioteca de componentes reusáveis e garantir que

desenvolvedores de software possam utilizar essa biblioteca são ações não onerosas, pois processos de desenvolvimento não precisam ser adaptados para

utilizar essa biblioteca.

b) Devido ao custo do software existente já ser conhecido, o risco de

processo é reduzido.

c) Especialistas em aplicações podem desenvolver softwares reusáveis que encapsulem seu conhecimento, tornando seu uso mais eficaz.

d) Muitas vezes os custos gerais de desenvolvimento não são tão

importantes quanto entregar um sistema ao mercado o mais rápido possível. O reuso de um software pode acelerar a produção do sistema.

e) Alguns padrões, como os de interface de usuário, podem ser

implementados como um conjunto de componentes reusáveis. O uso de interfaces de usuário-padrão melhora a confiança, pois os usuários cometem menos erros quando são apresentados a interfaces familiares.

Reuso de software faz parte da Engenharia de Software baseada em componentes. Não é muito explorada na bibliografia, e as definições contidas entre as alternativas b) e e) são bom subsídio teórico. A alternativa a) é facilmente detectada como falsa, uma vez que montar uma biblioteca de componentes reusáveis para utilização por parte de desenvolvedores certamente é uma tarefa onerosa.

8ª Questão) (ESAF Agência Nacional de Águas Analista de Sistemas 2009) Analise as seguintes afirmações sobre requisitos de sistemas de software:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

I. Requisitos funcionais declaram as funções que o sistema deve fornecer, seu comportamento, e ainda, o que o sistema não deve fazer. II. Requisitos de domínio são, exclusivamente, funcionais, pois exibem as características do domínio de aplicação do sistema. III. Requisitos não-funcionais compreendem restrições sobre serviços ou funções do sistema.

Assinale a opção correta.

a) Apenas as afirmações I e II são verdadeiras.

b) Apenas as afirmações I e III são verdadeiras.

c) Apenas as afirmações II e III são verdadeiras.

d) As afirmações I, II e III são verdadeiras.

e) Nenhuma das afirmações é verdadeira.

O conceito de requisito, na Engenharia de Software refere-se à definição de uma característica, atributo, habilidade ou qualidade que um sistema deve necessariamente prover para ser útil a seus usuários. Creio que, a esta altura do campeonato, isso não seja mais novidade para você. Contudo, os requisitos podem ser classificados de diversas formas. A saber:

Requisito funcional: Define uma função de um sistema de software ou seu componente. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outras funcionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar. Em suma, dizem o que o sistema deve fazer, mas também pode ser uma declaração explícita do que o sistema não deve fazer. Ex: “o usuário deve ser capaz de pesquisar todos os livros da biblioteca”, “o usuário não pode cautelar dois exemplares do mesmo livro”. Requisito não-funcional: É o requisito relacionado ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou não. Ex: “o sistema deve suportar o uso simultâneo por cem usuários, sem apresentar lentidão ou perda de performance”. Requisito de domínio: É um requisito proveniente do domínio da aplicação do sistema e que reflete as características e as restrições desse domínio. Pode acabar produzindo requisitos funcionais ou não funcionais. Ex: “esse aplicativo deverá ser executado tanto em IPhone quanto em celulares Android”. É um requisito de domínio que demandará uma série de requisitos funcionais e não funcionais em cada plataforma a ser desenvolvido o sistema. Requisito de usuário: O requisito de usuário de um sistema deve descrever os requisitos funcionais e não funcionais de modo que ele seja compreensível

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

pelos usuários do sistema que não possuem conhecimento técnico detalhado. Eles devem especificar apenas o comportamento externo do sistema e evitar, sempre que possível, descrever características de projeto do sistema. Os exemplos de requisitos funcionais que eu passei são bons exemplos de requisitos de usuário. Requisito de sistema: É uma versão expandida do requisito de usuário, usado pelos engenheiros de software como ponto de partida para o projeto do sistema. Podem ser escritas em linguagem natural e/ou linguagens de notação de projetos e notações gráficas. Por exemplo: “Uma chamada a um arquivo externo não deverá repassar parâmetros a esse arquivo. O tratamento das variáveis deverá se local.” Especificação de interface (ou de projeto):É uma especificação técnica que auxilia o sistema em desenvolvimento a operar junto a outros sistemas já existentes. Por exemplo, um sistema que eventualmente use uma impressora em ambiente Windows deverá saber como “interfacear” com uma impressora nesse sistema operacional.

Feita essa explanação, voltemos aos itens da questão:

I. Correta; II.Errada, pois os requisitos de domínio podem ser também não-funcionais; III.Correta. Um requisito não-funcional pode afetar um requisito funcional. Ex:Um sistema que opere em uma máquina que não permita a inserção de pendrives pode restringir o salvamento de arquivos neste tipo de mídia, permitindo apenas o envio de dados pela internet;

Logo, nossa resposta certa é a letra b).

(FCC Agente Fiscal de Rendas Tecnologia da Informação - 2009) Para responder as questões de 9 e 10, considere:

“É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software especificados para um sistema de gestão de pessoal.

9ª Questão) No texto, são requisitos não-funcionais:

a) não pode ultrapassar o prazo de oito meses e necessário que o software

calcule os salários dos diaristas e mensalistas.

b) os relatórios individuais dos departamentos, nos quais constam os

salários dos funcionários, devem ser emitidos quinzenalmente e em razão dos adiantamentos e vales que recebem.

c) É fundamental que o software seja operacionalizado usando código

aberto e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente.

d) tempo de resposta das consultas não deve superar os quinze segundos e

entrega do produto final não pode ultrapassar o prazo de oito meses.

e) pois inviabilizaria todo o investimento nesse sistema e em razão dos

adiantamentos e vales que recebem.

Definimos requisitos não-funcionais como “requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Vejamos os itens:

a) fala em cálculo de salários. Errada;

b) fala em emissão de relatórios. Errada;

c) idem à b). Errada;

d) tempo de resposta de consultas e prazo para entrega. Certa!

e) item nonsense. Errada.

Mesmo que você não estivesse confiante em marcar a alternativa d), seria possível trabalhar por eliminação.

10ª Questão) No texto, são requisitos funcionais:

a) calcule os salários dos diaristas e mensalistas e os relatórios individuais

dos departamentos, nos quais constam os salários dos funcionários, devem ser

emitidos quinzenalmente.

b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base

de dados deve estar protegida e com acesso restrito aos usuários autorizados.

c) é fundamental que o software seja operacionalizado usando código

aberto e emita relatórios mensais sumariados por tipo de salário.

d) emita relatórios mensais sumariados por tipo de salário e Necessito,

ainda, forte gerenciamento de risco, prazo e custo.

e) a base de dados deve estar protegida e com acesso restrito aos usuários

autorizados e entrega do produto final não pode ultrapassar o prazo de oito

meses.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

De cara, a alternativa a) já parece correta. Vejamos as demais. b)apenas requisitos não funcionais; c)um requisito não-funcional e um funcional; d)um requisito funcional e outro não-funcional; e)requisitos não-funcionais.

Podemos seguir em frente?

11ª Questão) (ESAF Analista de Planejamento e Orçamento Tecnologia da Informação 2008) Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Indique a opção que corretamente se relaciona com a análise ou gerenciamento de requisitos. a) Requisitos de sistema são declarações do usuário que definem,

detalhadamente, as funções, os serviços e as restrições operacionais do sistema.

b) As representações de dados usadas nas interfaces de sistemas são

exemplos de requisitos funcionais.

c) A exigência de que o sistema deva fornecer telas apropriadas para o

usuário ler os documentos no repositório de documentos é um exemplo de requisito funcional.

d) A exigência de que o sistema não deva revelar quaisquer informações

pessoais sobre os usuários do sistema ao pessoal de vendas que o utiliza, com exceção do nome e cargo, é um exemplo de requisito funcional.

e) Avaliar se os requisitos associados ao desempenho, ao comportamento e

às características operacionais do sistema foram explicitamente declaradas é

uma tarefa de especificação de requisitos.

Vamos analisar as alternativas com o conhecimento já adquirido?

a) Descreve o que são requisitos de usuário. Errada;

b) Especificações de interface. Errada;

c) Correta;

d) Requisito não-funcional, pois está relacionado à segurança da aplicação. Errada;

e) Tarefa da validação de requisitos, mas este conteúdo será visto mais adiante. Errada;

Espero que você já esteja dominando este tópico. Alternativa c).

12ª Questão) (Formulação pessoal) É uma técnica de elicitação de Requisitos:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

a) Entrevista com stakeholder, por meio de formulários predefinidos

(entrevista fechada) ou não (entrevista aberta). Por meio dela procura-se saber

o que o interessado espera ou deseja no sistema.

b) Descrição de cenários, na qual começa-se com um esboço da interação

e, durante a elicitação, adicionam-se detalhes para uma descrição completa dessa interação.

c) Elaboração de casos de uso, que são cenários descritos em um diagrama

UML, visual, também discutidos com os interessados.

d) Etnografia, que é uma técnica na qual o analista insere-se no ambiente

de trabalho como um observador, procurando levantar os requisitos do sistema.

e) Todas as alternativas estão corretas.

A cobrança em provas acerca de técnicas de elicitação de requisitos é raríssima, apesar de comumente aparecer em editais de concursos. Elicitar requisitos nada mais é do que descobrir, elucidar os requisitos. Todas as técnicas acima são técnicas de elicitação de requisitos. Perceba que nada mais são do que formas práticas de procurar saber dos interessados o que eles esperam do sistema que estão solicitando.

Utilize a questão como subsídio de conteúdo. Alternativa e).

13ª Questão) (FCC Ministério Público do Estado do Rio Grande do Norte Analista de Tecnologia da Informação Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) Na engenharia de software, etnografia é

a) uma fase do processo de software aplicada no modelo em cascata.

b) uma fase do processo de software aplicada no modelo em espiral.

c) uma técnica de observação que pode ser usada para compreender os

requisitos sociais e organizacionais.

d) uma técnica aplicada na engenharia de requisitos cujo objetivo é definir,

a priori, as classes que contém elementos gráficos (BLOB).

e) um projeto cujo principal objetivo é criar interfaces gráficas, que

facilitam o acesso do usuário (GUI).

Exemplo típico da FCC que exige, simplesmente, que você conheça uma definição. Alternativa c).

14ª Questão) (FCC Agente Fiscal de Rendas Tecnologia da Informação - 2009) Quanto aos requisitos de software, considere:

I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser aplicadas na elicitação.

III. Elicitar significa descobrir os requisitos de um sistema por meio de

entrevistas, de documentos do sistema existente, de análise do domínio do problema ou de estudos do mercado.

Está correto o que se afirma em

a) I, apenas.

b) I e II, apenas.

c) I, II e III.

d) II e III, apenas.

e) III, apenas.

Utilizando os conhecimentos adquiridos até então, acredito que sua única dúvida na questão a respeito de JAD. Vamos lá:

O JAD (Joint Application Design) é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de solução de problemas baseado em consenso.

A dinâmica do JAD: São feitas reuniões participativas, chamadas de sessões, envolvendo representantes de todas as áreas relacionadas com os assuntos em discussão.

As regras da sessão:

Todos os participantes são iguais. Nas sessões JAD, a estrutura hierárquica e de poder são deixadas do lado de fora. Todas as posições tem o mesmo peso e serão avaliadas pelo grupo sem levar em conta qual é a origem da mesma.

Apenas uma pessoa fala de cada vez. Assim todos terão chance de expressar a sua opinião e de ouvir as opiniões do restante do grupo.

Todas as opiniões são válidas. É preciso não ter uma posição pré- concebida sobre as opiniões dadas.

Hora para começar, interromper e terminar. É necessário definir uma agenda para as sessões e cumpri-la à risca.

Celular desligado. Durante a sessão não devem acontecer interrupções externas.

Recursos visuais. Utilizar intensivamente recursos visuais para tornar o projeto do sistema mais palpável e permitir que ele seja entendido pelos

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

diversos participantes. Uma fotografia é mais explicativa e rica em detalhes do que 1000 palavras para a descrição de um fato.

Os papéis na sessão:

Sponsor (Patrocinador). É o executivo responsável pelo projeto, o dono do sistema. Ele precisa ter autonomia para tomar decisões, definir estratégias e direcionar o trabalho.

Facilitador. É o responsável por conduzir a sessão. Ele não precisa ser um especialista no assunto que está sendo tratado. Ele deverá estar focado em organizar a dinâmica, dando a palavra a cada participante, obtendo o consenso sobre os assuntos tratados, organizando o registro das decisões e intermediando os conflitos.

Escriba. É a pessoa responsável por registrar todas as discussões e decisões em um local que todos possam visualizar, como um quadro ou flip-chart.

Documentador. É o responsável por registrar todas as decisões em um documento formal, como uma ata de reunião ou uma especificação de requisitos, que será assinado por todos ao final das sessões.

Especialistas. São as pessoas que tem conhecimento do assunto que está sendo discutido e que podem efetivamente contribuir para a discussão e na tomada de decisões.

Observadores. São pessoas que estão na sessão apenas para conhecer mais do assunto que está sendo tratado ou para assimilar a técnica da reunião. Os observadores não podem se manifestar durante a sessão.

Os observadores não podem se manifestar durante a sessão. Os fatores de sucesso: Prof. Victor Dalton

Os fatores de sucesso:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

A

sessão precisa ter presente as pessoas que tem poder de decisão sobre

assunto tratado, pois, não adianta tomar decisões durante a reunião que poderão ser contestadas quando todos voltarem para o escritório.

o

As decisões precisam ser tomadas por consenso, pois, todos os participantes da sessão precisam sair de lá comprometidos com as definições registradas.

As sessões devem ocorrer fora do ambiente de trabalho dos participantes

para evitar interrupções e prevenir que os participantes se vejam tentados

a

tratar de assuntos ligados a sua rotina diária.

Não deixar que os participantes imponham suas opiniões em função do seu nível hierárquico, para evitar que pessoas de nível hierárquico mais baixo fiquem constrangidas em debater ou discordar.

Definir claramente qual será o produto gerado no final das sessões.

Os benefícios esperados em relação aos métodos tradicionais:

Maior produtividade. Estudos relatam aumentos de 20 a 60% na produtividade, em relação aos métodos tradicionais.

Maior qualidade. Usuários e analistas de sistemas costumam citar “projeto de softwares de alta qualidade” como sendo o maior benefício do método.

Trabalho em equipe. Promove o espírito de cooperação, entendimento e trabalho em equipe.

Custos mais baixos. O projeto de alta qualidade, obtido através do JAD, possibilita uma grande economia de tempo e dinheiro mesmo após a entrega do sistema.

Bem, apesar de parecer mais com uma reunião do AA (não que eu já tenha ido em uma, rs), você pôde notar que o JAD também é uma técnica de Elicitação de requisitos.

Assim sendo, todos os itens estão corretos e nossa alternativa certa é a letra c).

15ª Questão) (UEL Secretaria do Estado da Administração e da Previdência Analista de Sistemas - 2009) Um dos seus principais objetivos é melhorar a modelagem de sistemas e a capacidade de analisá-los, possibilitando maior entendimento de suas características antes da Implementação. É seu papel realizar a interação entre “o que” deve ser feito e “como” deve ser feito. Esta afirmação refere-se a:

a) Arquitetura do Software. b) Planejamento do Software.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

c) Engenharia de Requisitos.

d) Estimativas do Projeto.

e) Processo de desenvolvimento de Software.

A Engenharia de Requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui o conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. Seu objetivo é fornecer a todas as partes um entendimento escrito do problema.

Resposta certa, letra c).

16ª Questão) (UEL POSCOMP 2010) A Engenharia de Requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos do sistema. Sobre a Engenharia de Requisitos, considere as afirmativas a seguir.

I. A Engenharia de Requisitos, como todas as outras atividades de Engenharia de Software, precisa ser adaptada às necessidades do processo, do projeto, do produto e do pessoal que está fazendo o trabalho.

II. No estágio de levantamento e análise dos requisitos, os membros da equipe técnica de desenvolvimento do software trabalham com o cliente e os usuários finais do sistema para descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve fornecer, o desempenho exigido do sistema, as restrições de hardware, entre outras informações.

III. Na medida em que a informação de vários pontos de vista é coletada, os requisitos emergentes são consistentes.

IV. A validação de requisitos se ocupa de mostrar que estes realmente definem o sistema que o cliente deseja. Ela é importante porque a ocorrência de erros em um documento de requisitos pode levar a grandes custos relacionados ao retrabalho.

Assinale a alternativa correta.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas III e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton
Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Aproveitaremos esta questão da UEL para destrinchar todas as etapas da Engenharia de Requisitos, segundo Pressman.

A engenharia de requisitos fornece o mecanismo apropriado para entender

o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade, negociando uma condição razoável, especificando a solução de modo não

ambíguo, validando a especificação e gerindo os requisitos à medida que eles são transformados em um sistema operacional (não confundir com Windows ou Linux sistema operacional, neste contexto, significa um sistema pronto para operar). O processo de engenharia de requisitos é realizado por meio da execução de sete funções distintas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. Concepção - Concepção inicial do software. O objetivo desta etapa é entender o problema, quais os envolvidos, a natureza da solução e iniciar o processo de comunicação entre clientes e colaboradores. Levantamento e análise - Perguntar aos envolvidos no projeto:

Qual o objetivo do produto?;

Como o produto se enquadra nas necessidades do negócio?;

Como o produto será utilizado?

O que o produto deve oferecer?

Entretanto, podem existir diversos problemas nesse ponto do projeto:

Problemas de escopo: Não se identifica corretamente os

limites do que o Software deve ou não fazer, muitas vezes requisitos técnicos desnecessários confundem o entendimento da solução esperada;

Problemas de entendimento: O cliente não tem domínio

suficiente do problema, não conhece o potencial de uma solução computacional, omite informações óbvias, entre outros;

Problemas de volatilidade: Os requisitos mudam ao longo

do tempo. Por experiência própria, posso afirmar o quanto é difícil levantar requisitos,

principalmente quanto a problemas de entendimento. Sempre que partimos para

a próxima etapa, a elaboração, uma das coisas mais comuns é o cliente afirmar que aquele cenário elaborado não condiz com o que ele mesmo descreveu e documentou na reunião anterior. As etapas de elaboração e levantamento formam um loop à parte, até que se consiga avançar no projeto.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Elaboração - Refinamento das informações obtidas na etapa anterior com a inclusão de modelagens de cenários de interação do usuário com o sistema e modelagem das classes envolvidas tanto como a relação entre elas. Negociação - É frequente que após a etapa de elaboração muitos requisitos não estejam de acordo com a disponibilidade de recursos disponíveis ou ainda sejam conflitantes entre si. Nesse ponto os requisitos são avaliados junto ao cliente e podem ser excluídos, combinados ou ainda serem acrescentados novos requisitos. Especificação - A especificação é a apresentação formal dos dados obtidos até o momento podendo incluir gráficos, textos em linguagem natural, modelagem de cenários ou um protótipo. O principal é que a especificação possa guiar o desenvolvimento futuro indicando os limites do software com as suas possibilidades e limitações. Validação - Nesse ponto, todos os envolvidos (clientes, colaboradores e usuários) avaliam os requisitos em busca de erros de interpretação, ambiguidade e omissões. Pode ser usado um modelo de questões checklist para validar os requisitos. Gestão - A gestão de requisitos é o processo que visa identificar, controlar e rastrear requisitos e modificações nos requisitos ao longo de um projeto. Em projetos de grande porte com centenas de requisitos é essencial um modelo formal, muitas vezes baseado em tabelas que cruzam estes requisitos com os aspectos do sistema como interface e dependências. Para projetos menores esse processo pode ser feito de forma mais informal.

Você ainda se

lembra da questão? Então volte aos itens dela e tente

responder sem a minha explicação abaixo.

I.É uma afirmativa bem genérica e verdadeira. Todas as atividades da

Engenharia de Software devem ser adaptadas à organização que a realiza;

II. Correta. A descoberta, elicitação ou levantamento dos requisitos (isso

mesmo, 10ª questão) é a etapa em que ocorre essa obtenção de informações sobre o domínio da aplicação; III. Não necessariamente. Inclusive, o mais comum, à medida que se coletam diferentes pontos de vista, é encontrarmos requisitos conflitantes. E é

por isso que a fase de negociação é indispensável;

IV. Correta. Após a negociação e a especificação, a validação é uma espécie

de “reunião final” em que todos avalizam os requisitos definidos. Após isto,

temos apenas a gestão, que rastreia a evolução dos requisitos ao longo do tempo.

Entendidas estas sete etapas? Certamente este assunto será cobrado em sua prova. Alternativa d).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

17ª Questão) (FGV Senado Federal - Analista Sistemas 2012) O processo de Engenharia de Requisitos é realizado por meio da execução de sete funções distintas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. Nesse contexto, observe a lista abaixo, que representa um conjunto de questões a serem utilizadas como checklist dentro de uma dessas funções.

utilizadas como checklist dentro de uma dessas funções. A função é: a) Elaboração b) Negociação c)

A função é:

a) Elaboração

b) Negociação

c) Especificação

d) Validação

e) Gestão

clientes, colaboradores e

usuários para avaliar os requisitos acordados, inclusive por meio de um checklist, não sabe? É a validação. Ainda, se lhe restar alguma dúvida, confirme que o checklist apresentado procura erros de interpretação, ambiguidade e omissões. Até mesmo pelo conteúdo das perguntas mostradas, é razoável que estejamos em uma etapa posterior à concepção, levantamento e elaboração dos requisitos. Também não são perguntas referentes a uma eventual negociação. Na especificação não cabe checklist, pois esta é um detalhamento formal dos requisitos pós-negociação, auxiliada por protótipos e diagramas. E, por fim, não cabe ser gestão de requisitos, pois também não cabe checklist na gestão. Nesta etapa, os requisitos já estão claros, sendo apenas rastreados em caso de modificação ou evolução ao longo do tempo.

Opa! Você

já sabe

qual

a

etapa

que

reúne

Nossa resposta correta, alternativa d).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton
Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

18ª Questão) (ESAF Analista de Finanças e Controle Tecnologia da Informação 2003 - adaptada) Analise as seguintes afirmações relativas à Engenharia de Software:

I. A análise de requisitos é responsável pela especificação dos requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema. II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema. III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for construído. IV. A análise de requisitos possibilita que o engenheiro de software compreenda o sistema que irá desenvolver.

Estão corretos os itens:

a) I e II

b) II e III

c) III e IV

d) I e III

e) II e IV

Utilizo esta questão porque quero chamar a sua atenção para as etapas de Engenharia de Requisitos, segundo Sommerville! Ela também pode ser cobrada.

de

Requisitos, ocorrem quatro etapas(segundo Sommerville):

Estudo de viabilidade verifica se as necessidades dos usuários podem ser satisfeitas pelas tecnologias atuais de software/hardware; Elicitação e análise de requisitos compreensão, por parte dos analistas, dos requisitos do sistema, por meio de discussões com os usuários potenciais e observação de sistemas existentes. Além disso, ajuda os analistas a compreender o sistema a ser especificado; Especificação de requisitos Tradução das informações obtidas na análise em um documento de defina um conjunto de requisitos;

Validação de requisitos verificação junto ao cliente da correção e escopo dos requisitos.

Na

Especificação

do

software,

também

chamada

de

Engenharia

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 Engenharia de Requisitos, segundo Sommerville Pois é,

Engenharia de Requisitos, segundo Sommerville

Pois é, dançar conforme a música. Quando uma questão aparece sobre requisitos, você precisa identificar se a abordagem utilizada é a do Pressman ou a do Sommerville, para poder responder corretamente. Os itens III e IV estão corretos, e nossa resposta certa é a alternativa c).

19ª Questão) (ESAF Analista de Planejamento e Orçamento Tecnologia da Informação - 2005) Analise as seguintes afirmações relacionadas a conceitos gerais de gerenciamento e controle de qualidade:

I. O gerenciamento de qualidade é o processo que permite garantir que o projeto foi completado sem desvio dos requisitos. II. O diagrama de Pareto está relacionado às regras de Pareto para a Qualidade de Software, que afirma que se forem solucionados 80% dos problemas ou desvios de um software então este terá alcançado um índice de qualidade de 100%. III. O controle de qualidade utiliza inspeções para provar a existência de qualidade dentro de um produto final do projeto. IV. Um ambiente de desenvolvimento de software, no processo de evolução da qualidade dos seus produtos e serviços, deve substituir o processo de Controle da Qualidade pelo processo de Garantia da Qualidade.

Indique a opção que contenha todas as afirmações verdadeiras.

a) I e II

b) II e III

c) III e IV

d) I e III

e) II e IV

Qualidade de software está estreitamente relacionada a testes de software (testar software faz parte da busca pela qualidade), faremos uma questão conceitual apenas para desencargo de consciência. O gerenciamento da qualidade de software pode ser estruturado em três grandes atividades:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

de

procedimentos organizacionais e padrões que conduzem a um software de alta qualidade; Planejamento de qualidade seleção de procedimentos e padrões apropriados deste framework, adaptados para um projeto de software específico; e Controle de qualidade Definição e aprovação de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentos e os padrões de qualidade de projeto. Aconselha-se que a equipe de qualidade seja diferente da equipe de desenvolvimento do software. Por fim, destaco que o gerenciamento da qualidade envolve o estabelecimento de padrões de processo, que definem os processos que devem ser seguidos durante o desenvolvimento do software (como documentos obrigatórios que devam ser gerados, estabelecimento de reuniões periódicas), e o estabelecimento de padrões de produto(exigência de determinada nomenclatura a ser adotada no código, padronização de comentários no código, padronização do formato da documentação, etc.).

Garantia

de

qualidade

estabelecimento

de

um

framework

Feita esta introdução, vejamos as alternativas:

I. Está razoavelmente certa. Garantir que o projeto foi concluído sem desvios também é um objetivo do gerenciamento de qualidade, embora a maneira como a frase está escrita possa dar a entender que é o único objetivo;

II. O diagrama de Pareto, apenas para lembrar, é o diagrama da lei do 80/20. Por exemplo, 20% dos defeitos do software são responsáveis por 80% das reclamações. Ele é um diagrama que ajuda a estabelecer prioridades, logo, não garante nada;

III.Certíssimo. Controle -> inspeções! IV. Esta substituição não existe, as três tarefas são necessárias.

Logo, ficamos com a alternativa d).

20ª Questão)(FCC Tribunal de Contas do Estado do Paraná - Analista de Controle Informática - 2011) Métricas de software podem ser divididas em medidas diretas e indiretas, sob o ponto de vista de medição, e em métricas de produtividade e de qualidade, sob o ponto de vista de aplicação. Nesse contexto, as métricas que se concentram na saída do processo de engenharia de software e as métricas que indicam o quanto o software atende

aos requisitos definidos pelo usuário, podem ser classificadas, respectivamente, como métricas de

a) custo e de complexidade, em medidas indiretas.

b) esforço e de confiabilidade, em medidas diretas.

c) produtividade e de qualidade, em medidas indiretas.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

d) qualidade e de eficiência, em medidas diretas.

e) velocidade de execução e técnica, em medidas diretas.

A medição de software é um recurso que tem como objetivo avaliar, de forma automatizada o projeto de software, para poder fazer previsões gerais sobre um sistema e/ou identificar componentes anômalos. Para tal, são utilizadas as métricas de software.

As métricas de produto dividem-se em duas classes:

Métricas estáticas ajudam a avaliar a complexidade, a facilidade de compreensão e a facilidade de manutenção de um sistema de software; e Métricas dinâmicas mais relacionadas com a eficiência e a confiabilidade de um programa. Ainda, pode se enxergar a medição pela ótica das medidas diretas e indiretas. Medida direta não envolve a medição de outro atributo além do atributo considerado, como linhas de código, número de erros, etc.; e Medida indireta além do atributo considerado, medidas de outros atributos são levadas em consideração. São exemplos, qualidade, complexidade, eficiência, etc.

Também podemos dividir as métricas de software, sob o ponto de vista de aplicação, em duas categorias: métricas de produtividade e de qualidade. As métricas de produtividade se concentram na saída do processo de engenharia de software e métricas de qualidade indicam o quanto o software atende aos requisitos definidos pelo usuário.

Diante do exposto acima, percebe-se que a alternativa correta é a letra c).

P.S.:Caso deseje uma rápida e útil sobre medidas de software, veja em http://pt.wikipedia.org/wiki/Métrica_de_software. Nem tudo que está na Wikipedia é lixo, e veremos mais links úteis ao longo do curso.

21ª Questão) (ESAF Analista de Planejamento e Orçamento

Tecnologia da Informação - 2005)As métricas de produtos de software dividem-se em classes: métricas dinâmicas coletadas por meio de medições realizadas em um programa em execução, e métricas estáticas coletadas por meio de medições realizadas em representações do sistema. Indique a opção que descreve corretamente uma métrica estática do produto de software.

a) Índice de fog é uma medida da complexidade de controle de um

programa.

b) Complexidade ciclomática é uma medida da extensão média das

palavras e das sentenças em documentos, ponderada por complexidade.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

c) Extensão de identificadores é o número de métodos incluídos em uma

classe, relacionada com a facilidade de compreensão do programa.

d) Extensão de código é uma medida de extensão média de um programa

e está associada à complexidade da lógica de controle do programa.

e) Fan-in/Fan-out é uma medida do número de funções ou métodos que

chamam alguma outra função ou método.

Esta questão da ESAF é excelente, por nos chamar a atenção para 5 métricas que, não raro, aparecem em provas. Todas as 5 definições de métricas citadas realmente são de métricas estáticas, mas a questão faz um troca-troca nas descrições, para confundir sua cabeça. Segue gabarito abaixo:

a) Índice de fog é uma medida da extensão média das palavras e das sentenças em documentos, ponderada por complexidade.

b) Complexidade ciclomática é uma medida da complexidade de controle

de um programa.

c) Extensão de identificadores é uma medida da extensão média de

identificadores distintos em um programa.

d) Extensão de código medida do tamanho de um programa.

e) Correta.

22ª Questão) (UEL Analista de Informática Júnior Desenvolvimento de Sistemas - 2009) A norma ISO 9126 (Características de Qualidade de Software define 6 características (requisitos) de qualidade desejáveis para um produto de software. Considere os itens a seguir:

I. Evidencia o conjunto de funções que atendem às necessidades explícitas e implícitas para a finalidade a que se destina o produto e suas propriedades específicas

II. Evidencia o desempenho do produto, verificado ao longo do tempo e em condições estabelecidas.

III. Evidencia a facilidade de uso do produto, bem como o julgamento individual desse uso, por um conjunto de usuários estabelecido ou subentendido.

IV. Evidencia a compatibilidade entre os recursos e os tempos envolvidos,

assim como o nível de desempenho requerido para o produto, sob condições estabelecidas.

V. Evidencia

a

possibilidade

de

se

utilizar

o

produto

em

diversas

plataformas, com pequeno esforço para adaptação.

VI. Evidencia a facilidade para fazer modificações específicas no software.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Assinale a alternativa que apresenta a sequência correta em relação aos itens colocados anteriormente.

a) Funcionalidade; Eficiência; Usabilidade; Confiabilidade; Portabilidade;

Manutenibilidade.

b) Funcionalidade; Confiabilidade; Portabilidade; Eficiência; Usabilidade;

Manutenibilidade. c) Confiabilidade; Usabilidade; Eficiência; Portabilidade; Manutenibilidade; Funcionalidade.

d) Funcionalidade; Confiabilidade; Usabilidade; Eficiência; Portabilidade;

Manutenibilidade.

e) Confiabilidade; Funcionalidade; Usabilidade; Eficiência; Portabilidade;

Manutenibilidade.

Esses conceitos são peça-chave da norma ISO 8126, que versa sobre qualidade de software.

Em questões nesse estilo, alguns itens podem “amarrar” a alternativa correta com maior facilidade. Evidenciar se um conjunto de funções atende à finalidade desejada está diretamente relacionado à Funcionalidade. Por sua vez, Usabilidade é a medida de facilidade de uso de um software, e existe todo um ramo da TI orientado a esse assunto, chamado Engenharia da Usabilidade. Ainda, graças ao aparecimento da “Portabilidade”, no âmbito da telefonia, você já deve estar familiarizado com a palavra, e ter notado que ela só pode se aplicar ao item V da questão. Por fim, modificar o software, seja para correções ou evolução está diretamente relacionado à manutenibilidade do mesmo.

Logo, a dúvida reside apenas entre as alternativas a) e d), em que as definições de confiabilidade e eficiência talvez não estejam tão explícitas em suas descrições. Então vejamos abaixo as seis características descritas corretamente:

Funcionalidade - Evidencia o conjunto de funções que atendem às necessidades explícitas e implícitas para a finalidade a que se destina o produto e suas propriedades específicas. Confiabilidade - Evidencia o desempenho do produto, verificado ao longo do tempo e em condições estabelecidas.

produto, bem como o

julgamento individual desse uso, por um conjunto de usuários estabelecido ou

subentendido. Eficiência - Evidencia a compatibilidade entre os recursos e os tempos envolvidos, assim como o nível de desempenho requerido para o produto, sob condições estabelecidas. Portabilidade - Evidencia a possibilidade de se utilizar o produto em diversas plataformas, com pequeno esforço para adaptação.

Usabilidade - Evidencia a facilidade de

uso do

Prof. Victor Dalton

Manutenibilidade específicas no software . - Questões Comentadas de TI para o ICMS-SP 2013- Área:

Manutenibilidade específicas no software.

-

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Evidencia

a

facilidade

para

fazer

modificações

Assimilados os conceitos? Alternativa d).

23ª Questão) (UEL Estrada de Ferro Paraná Oeste S.A Analista de Sistemas - 2008) Considere as afirmativas a seguir, sobre Teste de software:

I. Teste funcional é uma técnica utilizada para se projetar casos de teste no qual o programa ou sistema é considerado uma caixa preta e, para testá-lo, são fornecidas entradas e avaliadas as saídas geradas para verificar se estão em conformidade com os objetivos especificados.

II. A técnica estrutural estabelece os requisitos de teste com base em uma dada implementação, requerendo a execução de partes ou de componentes elementares do programa.

III.

Teste é

um conjunto de atividades

que não pode ser planejado

antecipadamente, porém deve ser realizado sistematicamente.

IV. Um módulo driver chama o módulo que está sendo testado, devendo conter apenas as inicializações das variáveis globais e dos parâmetros que serão utilizados para a chamada do módulo testado. Assinale a alternativa correta.

a) Somente as afirmativas I e III estão corretas.

b) Somente as afirmativas III e IV estão corretas.

c) Somente as afirmativas I e II estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Teste de software é uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construído. Pode ser planejado antecipadamente e conduzido sistematicamente. Ainda, podem ser testes de baixo nível, no qual são verificados se pequenos segmentos de código-fonte foram corretamente implementados, bem como testes de alto nível, que validam as principais funções do sistema com base nos requisitos do cliente. O teste de software é um elemento de um aspecto mais amplo, que é frequentemente referido como Verificação e Validação (V&V). Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica (estamos construindo o produto corretamente?), enquanto a Validação se certifica que o software construído corresponde aos requisitos do cliente (estamos construindo o produto certo?).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

A partir de agora, vamos utilizar as alternativas e as questões seguintes para mergulharmos naquilo que for mais importante dentro deste assunto.

I. Teste funcional é um outro nome o teste “caixa preta”. Sua descrição

combina com aquilo que, intuitivamente, vem à sua cabeça: é um este que se preocupa apenas em saber se o programa funciona. Aplica-se uma entrada e verifica-se se a saída é a esperada. Falaremos mais dele adiante. Certa;

II. A técnica estrutural é um outro nome para o teste “caixa branca”. Nele, além do resultado, preocupa-se com o caminho percorrido ao longo do programa, e com quais partes foram executadas. Também será discutido mais adiante. Correta;

III. Pressman, copiado e modificado. Retire o “não” da frase, troque “porém” por “e” e ela fica correta. Errada;

IV. Os testes, quando realizados de forma automatizada, são coordenados

por esse módulo chamado de módulo driver; sua tarefa é exatamente a descrita no item. Uma vez inicializadas as variáveis globais e chamados os parâmetros do módulo que será testado, será possível verificar se o módulo está funcionando corretamente, ou seja, se a saída do módulo é a esperada, com base nos parâmetros utilizados. Certa;

Portanto, nossa alternativa correta é a letra d).

24ª Questão) (FCC TJ/RJ Analista Judiciário - Analista de Sistemas - 2012) No que se refere a testes de software, é correto afirmar que

a) o teste de operação é a fase onde é testada a ergonomia da interface de

uso do software.

b) o teste da caixa preta (teste funcional), baseia-se em analisar os

arquivos de log do sistema procurando por mensagens de funcionamento

inconsistente.

c) um teste bem sucedido é um teste que não encontra nenhum erro no

software.

d) o teste da caixa branca (teste estrutural), baseia-se em testar as

estruturas do código fonte, como comandos condicionais e de repetição.

e) um caso de teste é uma categoria de possíveis resultados na execução

de testes.

Na questão anterior já frisamos a definição de testes. Agora, veremos algumas das técnicas de testes mais comuns e as fases em que eles podem ser empregados.

Prof. Victor Dalton

Técnicas de teste Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação

Técnicas de teste

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Caixa-Branca - Também chamada de teste estrutural ou orientado à lógica,

a técnica de caixa-branca avalia o comportamento interno do componente de

software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Os aspectos avaliados nesta técnica de teste dependerão da complexidade

e da tecnologia que determinarem a construção do componente de software,

cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas. Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou

testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor desempenho de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produzido.

Caixa-Preta - Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação. Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos casos isso é impossível. Outro problema é que a especificação pode estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, pode- se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro. Essa técnica é aplicável a todas as fases de teste teste unitário, teste de integração, teste de sistema e teste de aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica técnica de particionamento de equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível. Uma abordagem no desenvolvimento do teste de caixa-preta é o teste baseado na especificação, de forma que as funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente para identificar certos riscos num projeto de software.

Regressão - Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.

Técnicas nãofuncionais - Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente ou sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Uma delas é o uso conjunto de teste de desempenho e teste de carga (testes de Stress), que verifica se o software consegue processar grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes. Já o teste de confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados e processados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável de execução após estar em um estado de falha.

Teste de Domínio - Pode ser aplicado em um campo, uma assinatura, um I/O, ou qualquer tipo de local que receba valores externos ao sistema. Todo domínio deve realizar consistências de dados validos e inválidos. Um domínio só permite dados com a formatação igual ao que será armazenado. Ex.: Campo DDD deverá permitir números de até quatro casas não negativas ou a base de dados deve impedir a entrada de valores inválidos. Uma técnica de teste comumente empregada em testes de domínio é a Análise do Valor Limite na qual são testados valores nas fronteiras de um domínio. Por exemplo: se determinado campo só permite o preenchimento com números de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101.

Fases (Tipos de Teste)

Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto. Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro ( TDD ), por engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito, passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do código fonte do software, e geralmente também integra o processo de construção do software.

Teste de unidade - Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema). O universo alvo desse

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

tipo de teste são as subrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

Teste de integração - Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.

Teste de sistema - Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições similares de ambiente, interfaces sistêmicas e massas de dados àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.

Teste de aceitação - Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de operação - Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de instalação, simulações com cópia de segurança dos

Em alguns casos um sistema entrará em produção para

bancos de dados, etc

substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Destaco que as técnicas de testes e as fases são pontos de vista distintos para se observar um determinado teste. Por exemplo, uma inspeção detalhada na execução de um código específico pode ser um teste caixa-branca e um teste de unidade. Assim como um teste de Stress, no ambiente final do sistema, também pode ser um teste de operação. Compreendido?

Voltando à questão, nossa alternativa correta é a letra d).

25ª Questão) )(FCC Tribunal de Contas do Estado do Paraná - Analista de Controle Informática - 2011) Segundo Sommerville, após um sistema ser completamente integrado, é possível testar propriedades como a de desempenho do sistema. Neste contexto, considere:

I. Testes de desempenho devem ser produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes geralmente são planejados para que a carga seja continuamente aumentada até que o sistema apresente desempenho fora do aceitável. II. Os testes de desempenho devem determinar se um sistema corresponde às suas exigências, sendo que a descoberta de defeitos ou problemas no sistema não é enfoque desta etapa. III. Para determinar se o desempenho está sendo atingido, pode ser necessário a construção de um perfil operacional, que é a listagem de todo o grupo de operadores/usuários que farão uso deste sistema. Está correto o que se afirma em

a) I, apenas.

b) I, II, III.

c) III, apenas.

d) I e II, apenas.

e) II e III, apenas.

Apesar de testes de desempenho ser um assunto contemplado pelo Pressman, perceba que a FCC foi no Sommerville pegar a referida definição. Nesse sentido, o item I é verdadeiro. Sommerville também cita que o teste de desempenho, como qualquer outro teste, também pode ser usado para descobrir problemas e defeitos no sistema. Logo, item II é falso. Por fim, Sommervile versa o seguinte sobre perfis operacionais:”se 90% das transações de um sistema forem do tipo A, 5% do tipo B e o restante dos tipos C, D e E, você deverá projetar o perfil operacional de modo que a maioria dos testes seja do tipo A. Logo, percebe-se que perfil operacional é um conjunto de testes, e não de usuários. Item III errado.

Resposta correta, alternativa a).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

26ª Questão) (UEL POSCOMP 2011) Tendo em vista a complexidade envolvida no desenvolvimento de um sistema de software, é importante assegurar que ele cumpra com suas especificações e atenda às necessidades dos usuários. Sobre o desenvolvimento de software, considere as afirmativas a seguir.

I. A Validação tem como objetivo responder. “Estamos construindo o produto certo?” Já a Verificação busca responder: “Estamos construindo o produto corretamente?”

II. Em um cadastro, encontra-se um campo de entrada solicitando o ano de nascimento, sendo válidos valores entre 1900 e 2011. Os casos de teste para este campo, considerando a técnica de análise de valor limite, são:

1899,1900,1901,2010,2011,2012 e 0.

III. As atividades de Verificação e Validação envolvem atividades de análise estática e de análise dinâmica do produto em desenvolvimento, e apenas as atividades de análise dinâmica envolvem a execução do produto.

IV. Um dos objetivos dos métodos de teste de caixa preta é garantir que todos os caminhos de um programa tenham sido exercitados pelo menos uma vez, podendo-se aplicar a técnica do teste do caminha básico para este fim. Assinale a alternativa correta.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas III e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Uma questão mais abrangente sobre testes, cujo conhecimento você já possui para responder. Revisando:

I. Certa. Esta diferença dentre Verificação e Validação é estendida a todos os ramos da TI, então assimile-a bem; II. Na análise de Valor Limite, segundo Pressmann, cabe apenas testar os valores das fronteiras e valores imediatamente acima e abaixo. Logo, seriam apenas 1899,1900,2011 e 2012. Errada; III. Correta. Análise estática envolve apenas a análise de códigos e modelos, enquanto a dinâmica compreende a análise do programa em execução; IV. Teste de caminho! Errada.

Portanto, a alternativa correta é a letra b).

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

27ª Questão) (Formulação pessoal) Segundo Pressmann, “cada um dos elementos de informação que são criados durante o desenvolvimento de um

produto de software, que são identificados de maneira única e cuja evolução é passível de rastreamento”, refere-se a

a) Item de software

b) Componente de software

c) Item de configuração

d) Componente de dados

e) Componente de programa

Vamos falar um pouco sobre Gerência de Configuração.

Gerência de Configuração Durante seu ciclo de vida, o software passa por uma série de modificações, desde sua concepção à implantação. Sob este aspecto, a Gerência de Configuração de Software (CGS) vem a definir critérios que permitam realizar tais modificações mantendo-se a

consistência e a integridade do software com as especificações. Ela permite minimizar os problemas decorrentes ao processo de desenvolvimento, através de um controle sistemático sobre as modificações. Não é objetivo da GCS evitar modificações, mas permitir que elas ocorram sempre que possível, sem que hajam falhas inerentes ao processo. Em geral a GCS é aplicada apenas quando existe um processo de desenvolvimento bem definido, com atividades agrupadas em fases, constituídas por objetivos bem definidos e documentados. Neste contexto, GCS atua como um suporte sobre o qual as fases do desenvolvimento são conduzidas e os produtos controlados. Aplicar um plano de gerência de configuração consiste em estabelecer normas, ferramentas e templates que permitam gerenciar de maneira satisfatória os itens de configuração de um sistema. Entende-se como item de configuração “Cada um dos elementos de informação que são criados durante o desenvolvimento de um produto de software, ou que para este desenvolvimento sejam necessários, que são identificados de maneira única e cuja evolução é passível de rastreamento” (Pressman). Itens de configuração podem ser:

Servidores

Estações de trabalho dos usuários

Banco de dados

Plano de negócio

Acordos com clientes

Softwares

Manuais de instrução

Outros, desde que sejam itens correlatos ao software entregue

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Se o item de configuração for composto exclusivamente de software, ele é então caracterizado como Item de Configuração de Software (ICSW). Qualquer IC constitui uma unidade funcional que possui um ciclo de desenvolvimento e acompanhamento de GCS próprios. Qualquer sistema em desenvolvimento deve ser particionado em itens de configuração, e o seu desenvolvimento é visto como o desenvolvimento de cada um dos ICs. Cada IC, por sua vez pode ser particionado em outro conjunto de ICs e assim sucessivamente, até que se resulte um conjunto de ICs não particionáveis, que são desenvolvidos segundo um ciclo de vida propriamente definido. A configuração de um sistema de software passa a ser definida pela configuração do conjunto dos ICSW que o constitui. É importante salientar que a divisão de um sistema ou produto de software em ICs, bem como a definição do ciclo de vida de cada IC, são decisões de projeto e não de GCS. Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configuração deve ser estabelecido. Tal conjunto representa um estágio do desenvolvimento, o qual é passível de modificações apenas mediante um mecanismo formal de alterações. A este conjunto é dado o nome de Baselines, ou Configurações Base do sistema. Em princípio, baselines poderiam ser estabelecidas em qualquer ponto do desenvolvimento. Entretanto, a grande vantagem do conceito está em se fazer coincidir o estabelecimento de baselines com os finais de fase do ciclo de vida do produto. O desenvolvimento com configurações base pode, então, ser resumido nos seguintes pontos:

Caracterização do ciclo de vida, identificando-se as fases pelas quais o desenvolvimento do software irá passar e, dentro delas, as atividades a serem realizadas e os produtos a serem desenvolvidos.

Definição do conjunto de baselines. Para cada baseline planejada, deve-se estabelecer quais serão os ICs que a irão compor e quais as condições impostas para seu estabelecimento;

Baselines representam marcos no processo de desenvolvimento: uma nova baseline é estabelecida no final de cada fase do ciclo de vida do software;

Durante cada fase, o desenvolvimento dos ICs a ela referentes está sob total controle de seus desenvolvedores, e realiza-se com ampla liberdade, podendo os ICs serem criados e modificados com bastante facilidade;

Durante cada fase, entretanto, a modificação de uma configuração-base anteriormente estabelecida somente pode ser feita de forma controlada, mediante um processo bem definido;

Ao ser estabelecida, cada baseline incorpora integralmente a anterior. Desta forma, em qualquer instante do desenvolvimento, a última baseline estabelecida representa o estado atual do desenvolvimento como um todo;

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

O estabelecimento de cada baseline somente é realizado após ser aprovada por procedimentos de consistência interna, verificação e validação; Desta forma é possível ter um controle sistemático sobre todos os itens de configuração abordados em cada fase do ciclo de vida do software, assim como é possível avaliar mais facilmente o seu grau de evolução.

O Gerenciamento de Configuração e o Gerenciamento de Mudanças pode

ser visto com mais detalhes no ITIL. Entretanto, por ter sido citado em Engenharia de Software, também estamos vendo-o aqui.

Resposta certa, letra c).

28ª Questão) (Formulação Pessoal) Procedimentos de gerenciamento de mudança dizem respeito à análise de custo e benefício das mudanças propostas, à aprovação das mudanças viáveis e à rastreabilidade de quais componentes do sistema foram alterados. O processo de gerenciamento de mudança deve surtir efeito quando o software ou a documentação associada são colocados em baseline pela equipe de gerenciamento de configurações.

O primeiro estágio para a solicitação de uma mudança para o sistema é

a) Modificar o item de configuração envolvido e notificar à equipe de

gerenciamento de mudança

b) Preencher uma Requisição de Mudança, ou Formulário de Solicitação de

Mudança, e encaminhar ao Comitê de Controle de Mudanças

c) Modificar o item de configuração envolvido e preencher o formulário para

envio ao Comitê de Controle de Mudanças

d) Notificar o Gerenciamento de Problema que deseja fazer uma mudança

no sistema

e) Aguardar uma falha no sistema para preencher uma Requisição de

Mudança

A ITIL define que o Gerenciamento de Mudanças e o Gerenciamento de

Configuração são processos distintos. Entretanto, reconhece-se que, principalmente em pequenas organizações, estes processos podem ser

executados pelas mesmas pessoas. Não confunda pessoas com papéis, nem papéis com processos; uma pessoa pode exercer vários papeis (como Gerente de Mudança e Gerente de Configuração). Entretanto, os processos continuam sendo distintos. Mudanças são um fato da vida para sistemas de software. Nesse contexto, o Gerenciamento de Mudança tem por objetivo assegurar que as mudanças sejam feitas de uma forma controlada, e sejam avaliadas, priorizadas, planejadas, testadas, implantadas e documentadas.

O primeiro estágio no processo de gerenciamento de mudanças é completar

um formulário de solicitação de mudança (destaco que este formulário será um

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

item de configuração!), que descreva a mudança necessária para o sistema. Ao longo do processo, este formulário registrará as recomendações para a mudança, os custos estimados e as datas de quando ela foi solicitada, aprovada, implementada e validada, bem como seu nível de prioridade. O Comitê de Controle de Mudanças é um grupo importante que toma as decisões de mudança. Apesar do nome “pomposo”, em pequenos e médios projetos, o CCM pode ser apenas o gerente de projeto e um ou dois engenheiros. Em condições ideais, o CCM é uma equipe exclusiva, e que conta com representantes do negócio. Naturalmente, caberá ao CCM analisar quais são as mudanças dentro de seu nível de autorização, e quais mudanças exigem ciência ou autorização de outros stakeholders.

Logo, nossa resposta certa é a letra b).

29ª Questão) (Formulação Pessoal) Sobre o Gerenciamento de Mudanças, analise as afirmativas abaixo:

I. As mudanças em um sistema podem ser levantadas proativamente, para

resolver erros ou adaptar-se a circunstâncias de mudança, ou reativamente,

para gerar benefícios ao negócio, como reduzir custos e melhorar os serviços.

II. Gerenciar mudanças não é fazer mudanças que não ofereçam risco: é

fazer mudanças de forma que os riscos sejam mapeados e gerenciados.

III. Mudanças de alto custo e mudanças de risco são mudanças típicas cuja autoridade de mudança é a gerência de TI.

IV. Mudanças urgentes sempre devem passar pela autoridade do negócio.

Assinale a alternativa correta.

a) Somente a afirmativa II está correta.

b) Somente as afirmativas II e III estão corretas.

c) Somente as afirmativas II e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Vamos utilizar estas afirmativas para captar mais algumas ideias acerca do Gerenciamento de Mudança:

I. Proativamente e reativamente estão trocadas na afirmativa. Errada;

II. Correta;

III. Naturalmente, para cada nível de importância da mudança existem autoridades que podem autorizar a mudança ou não. Mudanças de alto custo e mudanças de risco são mudanças que exigem que o Comitê Executivo de Negócio autorize, enquanto mudanças de menor relevância podem ficar a cargo do próprio CCM. Destaco que a “presidência” do CCM, apesar de poder conter representantes de negócio, é sempre do Gerente de Mudança, que é alguém da

TI. Errada;

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

IV. Mudanças urgentes não devem ser confundidas com mudanças importantes. Mudar o sistema de pagamento de um site pode ser importante sem ser urgente, assim como trocar um servidor que deu defeito pode ser urgente sem ser importante. Não é preciso uma autoridade de negócio para toda mudança urgente. Errada;

P.S.: Destaco ainda que existe o Comitê de Controle de Mudanças Emergencial, ou Comitê Consultivo de Mudanças Emergencial (CCME), que é uma versão reduzida do CCM, que pode ser reunido quando da necessidade de uma mudança urgente.

Voltando às alternativas, nossa resposta certa é a letra a).

30ª Questão) (Formulação Pessoal) É responsabilidade da Gerência de Configuração:

I. Definir e controlar os componentes de serviços e infraestrutura do sistema, mantendo informações precisas sobre os estados dos serviços e infraestrutura atual e planejada. II. Manter um banco de dados de configuração (Configuration Management Data Base) com todas as informações relevantes sobre as configurações do sistema e os itens de configuração. III. Avaliar o impacto de uma mudança no sistema.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas II e III estão corretas.

d) Todas as afirmativas estão corretas.

e) Apenas a afirmativa II está correta.

estão corretas. e) Apenas a afirmativa II está correta. Quero chamar a sua atenção para uma

Quero chamar a sua atenção para uma pegadinha que as bancas gostam de armar para seus candidatos, que é confundir as atribuições da Gerência de Configuração e a Gerência de Mudança. Os itens I e II são de responsabilidade da Gerência de Configuração. O item III, entretanto, é responsabilidade do Gerenciamento de Mudança! Apesar do estreito relacionamento entre esses processos (é natural que a equipe de mudança consulte a equipe de configuração para avaliar os itens de configuração que serão afetados), não será a Gerência de Configuração que avaliará o impacto de uma mudança, senão o próprio Gerenciamento de Mudança. Porém, no ato da implantação da mudança, a Gerência de Configuração rastreará os itens modificados, para manter o banco de dados de configuração atualizado.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Estamos entendidos? Alternativa a).

Para ajudar os estudos, veja um comparativo abaixo, extraído da ITIL, entre Gerenciamento de Configuração e Gerenciamento de Mudança. Maiores detalhes serão vistos no estudo da ITIL.

 

Gerenciamento de Configuração

Gerenciamento de Mudança

 
 

Suportar de forma eficiente e eficaz os processos de Gerenciamento de Serviço

Responder às mudanças

de

requisitos de negócio do cliente enquanto se maximiza o valor e se reduzem incidentes, interrupções e

Metas

Otimizar os ativos de serviços, configurações de TI, habilidades e recursos

retrabalhos

Responder ao negócio e requisições de TI para mudanças que irão alinhar os serviços às necessidades do negócio

Objetivos

Definir e controlar os componentes de serviços e infraestrutura, e manter informações precisas no histórico sobre configuração, estado dos serviços e infraestrutura atual e planejada.

Assegurar que as mudanças sejam feitas de uma forma controlada, e sejam avaliadas, priorizadas, planejadas, testadas, implantadas e documentadas.

 

Manter informações sobre os Itens de Configuração (ICs) no Banco de Dados do Gerenciamento de Configuração (BDGC)

Criar a Requisição De Mudança, ou registrar a RDM (quando a solicitação for originada em outra área)

Atividades

Manter o BDGC atualizado, por meio do SGC (Sistema de Gerenciamento da Configuração)

Avaliar o impacto de mudanças no sistema

Manter

a

Biblioteca

de

Mídia

Autorizar a mudança (quando dentro do seu escopo de autorização)

Definitiva

(softwares

licenciados,

 

documentação, etc)

 

Realização de auditorias para conferência do BDGC

Coordenar

a

implantação

da

mudança

Como um mantém controle sobre os itens de configuração e outro os modifica, é natural um relacionamento estreito entre eles. Mas não confunda o que cada um faz!

31ª Questão) (FCC Ministério Público do Estado de Sergipe Analista do Ministério Público Gestão e Análise de Projeto de Sistema

Prof. Victor Dalton

www.estrategiaconcursos.com.br

44 de 82

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

2010) Em relação à análise e ao projeto orientados a objetos, é correto afirmar:

a) A orientação a objetos não leva em conta a utilização da prototipação,

dada as restrições desse modelo de desenvolvimento de software quanto à reusabilidade.

b) Uma das regras de normalização aplicada às tabelas de objetos de dados

especifica que uma instância de um objeto pode ter diversos valores para cada atributo.

c) Se a informação sobre um objeto em potencial precisar ser lembrada

para que o sistema possa funcionar, esse objeto não poderá ser utilizado

durante a análise.

d) Representar os objetos e suas relações é o principal objetivo do

Diagrama Entidade-Relacionamento (E-R).

e) Um Diagrama de Fluxo de Dados (DFD) deve, além do fluxo da

informação, descrever detalhadamente a lógica procedimental do sistema.

Na análise e projeto estruturados, o processo a ser informatizado é visto como um conjunto de funções com dados de entrada, processamento e dados de saída, ou seja, a ênfase esta em funções que agem sobre dados. Estas funções podem ser decompostas em subfunções (decomposição funcional). As principais características são:

◊ preocupação com a modularidade e coesão;

◊ desenvolvimento em diferentes níveis de abstração (top-down).

O Diagrama de Fluxo de Dados (DFD) é o principal diagrama utilizado nessa metodologia.

Em um DFD, representam-se entidades externas por caixas, processos (ou tarefas) por circunferências (também podem ser elipses ou elipses achatadas), o fluxo dos dados por setas e depósitos de dados por traços duplos. Veja abaixo:

setas e depósitos de dados por traços duplos. Veja abaixo: Prof. Victor Dalton www.estrategiaconcursos.com.br 45 de

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00 Na análise orientada a projetos, o processo a ser informatizado é visto como um conjunto de objetos que interagem para realizar as funções, como no diagrama de classes abaixo:

realizar as funções, como no diagrama de classes abaixo: As principais vantagens do modelo OO são:

As principais vantagens do modelo OO são:

◊ maior grau de abstração;

◊ maior encapsulamento;

◊ modelos apoiados em conceitos do mundo real;

◊ reutilização (reusabilidade).

A análise e projeto orientada a objetos lança mão da diagramação UML para modelagem e análise nas diversas etapas do projeto.

Quanto à questão, a resposta certa é a alternativa d).

32ª Questão) (ESAF Analista de Finanças e Controle Desenvolvimento de Sistemas de Informação 2008) A linguagem de Modelagem Unificada (UML) emergiu como notação de diagramação de padrão, de fato e de direito, para a modelagem orientada a objetos. Desta forma, a sentença que conceitua apropriadamente a UML, segundo o OMG-Object Management Group, é a) um método para especificar e modelar os artefatos dos sistemas. b) um processo de especificação e modelagem de sistemas orientados a objeto.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

c) uma linguagem para implementar os conceitos da orientação a objetos.

d) uma linguagem visual para especificar, construir e documentar os artefatos dos sistemas.

e) um método comum para a representação da orientação a objetos.

UML é um assunto trivial em provas de concursos que exijam desenvolvimento de sistemas. Segundo nossa fonte recomendada, a modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se várias perspectivas diferentes e complementares. Exigir a sentença exata que conceitua a UML, segundo o OMG foi exagero por parte da banca. Contudo, quem já trabalhou no desenvolvimento de um sistema e já precisou de um diagrama UML sabe que uma característica importante dela é a comunicação entre as pessoas envolvidas. Você pode tentar descrever um caso de uso simples de um sistema e perder 20 minutos Entretanto, ao mostrar um diagrama de caso de uso ou um diagrama de sequência, o entendimento comum é quase que imediato. A UML é uma ferramente poderosa de comunicação, além da construção e documentação de artefatos de um sistema.

Portanto, mesmo sem conhecer a exata sentença da OMG sobre o assunto, é perceptível que a letra d) é a alternativa mais completa e livre de incorreções.

33ª Questão) (ESAF Analista de Controle Externo Análise de Sistemas 2002)Analise as seguintes afirmações relativas à UML:

I. Ação é uma abstração representativa de entidades externas que interagem com um produto ou sistema;

II. Atributo é a descrição de um espaço com nome e tipo, dentro de uma

classe, onde cada objeto desta classe mantém um valor deste tipo; III. Classe é o descritor para um conjunto de objetos que partilham os mesmos atributos, operações, relacionamentos e comportamento; IV. Evento é a condição ou situação de vida de um objeto durante a qual ele executa uma atividade.

Indique a opção que contenha todas as afirmações verdadeiras.

a) I e II

b) II e III

c) III e IV

d) I e III

e) II e IV

Analisando conceitos:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

I. Ator é uma abstração representativa de entidades externas que

interagem com um produto ou sistema. Ação é uma expressão que pode ser

definida em termos dos atributos, das operações ou das associações da classe, realizada pelo objeto quando transita de um estado para outro. Errada;

II. Correta;

III. Correta;

IV. Estado é a condição ou situação de vida de um objeto durante a

qual ele executa uma atividade. Evento é alguma ocorrência no ambiente do sistema para o qual este sistema deve realizar alguma ação quando da ocorrência do evento. Errada;

Portanto, a alternativa b) é a correta.

34ª Questão) (ESAF Agência Nacional de Águas Tecnologia da Informação e Comunicação Desenvolvimento de Sistemas - 2009) Em UML, o relacionamento utilizado para expressar herança entre classes e interfaces é a

a) multiplicidade.

b) dependência.

c) agregação.

d) associação.

e) generalização.

Mais revisão de conceitos:

a)

Multiplicidades são os limites, superior e inferior, de associações que um objeto pode possuir. Errada;

b)

Dependência é uma conexão semântica entre dois elementos, um independente e outro dependente. Errada;

c)

Agregação e composição são variantes da associação, que é o estabelecimento de um relacionamento entre objetos. Na agregação, a parte pode existir sem o todo, e na composição isso não é possível. Exemplos: jogador e time de futebol (agregação), Capítulo, Seção e Parágrafo (composição). Errada;

e)

Generalização/especialização são dois pontos de vista do mesmo

relacionamento

interfaces. Correta.

utilizado

para

expressar

herança

entre

classes

e

Nosso estudo de UML continua. Alternativa e).

35ª Questão) (FCC Companhia do Metropolitano de São Paulo - Analista Desenvolvimento Gestão Júnior Ciências da Computação - 2012) Sobre Programação Orientada a Objetos e UML, considere:

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

I. Os diagramas de classe são usados no desenvolvimento de um modelo

de sistema orientado a objetos para mostrar as classes de um sistema e as associações entre essas classes. II. A UML tem um tipo específico de associação para denotar a generalização. Em uma generalização, os atributos e operações associados com as classes de nível alto (superclasses) também estão associados com as de nível baixo (subclasses). III. A UML fornece um tipo especial de associação entre classes chamada agregação, que significa que um objeto (todo) é composto de outros objetos (as partes). IV. Os modelos comportamentais descrevem o modelo estático do domínio e qual a reação comportamental de interação entre as classes. Eles mostram o que acontece ou deve acontecer quando o sistema responde a um estímulo de seu ambiente. Está correto o que consta APENAS em

a) I e II.

b) I, III e IV.

c) I, II e III.

d) II, III e IV.

e) III e IV.

A definição de diagramas de classe da questão é bastante adequada.

de diagramas de classe da questão é bastante adequada. Exemplo de diagrama de classe UML. Os

Exemplo de diagrama de classe UML.

Os itens II e III, conforme a explicação anterior, também estão corretos.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

que

representam modelos estáticos, enquanto os Diagramas Comportamentais, por sua vez, modelam os aspectos dinâmicos de um sistema. Veremos estes diagramas mais adiante.

Apenas

o

item

IV

é

incorreto.

São

os

Diagramas

Estruturais

Resposta certa, alternativa c).

36ª Questão) (ESAF Analista de Controle Externo Análise de Sistemas 2002 - adaptada) Um gerente de projeto sabe que o modo para

descrever os vários aspectos de modelagem pela UML é por meio da notação definida pelos seus vários tipos de diagramas. Em um determinado projeto, ele necessita de um diagrama estático onde a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. O diagrama UML recomendado para suprir esta necessidade deste gerente é o

a) diagrama de componente.

b) diagrama de comunicação.

c) diagrama de sequencia.

d) diagrama de classe.

e) diagrama de implantação.

Vamos revisar estes diagramas?

Diagrama de Componente - Um Diagrama de Componentes mostra como os diferentes subsistemas de software formam a estrutura total de um sistema, sistema este que está construído sobre um banco de dados centralizado que contém dados históricos de locações, detalhes dos veículos, registros de manutenção, dados de clientes e funcionários. É muito importante que estas informações estejam centralizadas em um banco de dados, pois os níveis de estoque poderão sofrer alterações a cada hora, e todos os participantes do processo comercial precisam ter acesso às informações mais recentes. Manter os dados atualizados é uma tarefa que requer atualizações em tempo real por parte de todos os integrantes do processo.

em tempo real por parte de todos os integrantes do processo. Prof. Victor Dalton Diagrama de

Prof. Victor Dalton

Diagrama de Componente

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Diagrama de Comunicação - Um Diagrama de Comunicação é outro tipo de diagrama de interação. Assim como no Diagrama de Sequência, o Diagrama de Comunicação mostra como um grupo de objetos num caso de uso interage com os demais. Cada mensagem é numerada para documentar a ordem na qual ela ocorre. Observação: na UML 1.5, este diagrama chamava-se Diagrama de Colaboração, e na 2.0 passou a chamar-se Diagrama de Comunicação.

e na 2.0 passou a chamar-se Diagrama de Comunicação. Diagrama de Comunicação Diagrama de Sequência -

Diagrama de Comunicação

Diagrama de Sequência - Um Diagrama de Sequência oferece uma visão detalhada de um caso de uso. Ele mostra uma interação organizada em forma de uma sequência, dentro de um determinado período de tempo, e contribui para a que se processe a documentação do fluxo de lógica dentro da aplicação. Os participantes são apresentados dentro do contexto das mensagens que se transitam entre eles. Num sistema de software abrangente, um Diagrama de Sequência pode ser bastante detalhado, e pode incluir milhares de mensagens.

bastante detalhado, e pode incluir milhares de mensagens. Diagrama de Sequência Diagrama de Classe – O

Diagrama de Sequência

Diagrama de Classe O Diagrama de Classe é um diagrama de estrutura estática, que modela as classes de objetos, mostrando a estrutura geral do sistema e também as suas propriedades relacionais e de comportamento.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 Diagrama de Classe Diagrama de Implantação –

Diagrama de Classe

Diagrama de Implantação Modela o uso físico do sistema, considerando computadores, dispositivos e suas interconexões.

computadores, dispositivos e suas interconexões. Diagrama de Implantação Diagrama de caso de uso(bônus )

Diagrama de Implantação

Diagrama de caso de uso(bônus) Não poderíamos não falar deste diagrama. Um Caso de Uso especifica uma interação entre um usuário e o sistema, no qual o usuário tem um objetivo muito claro a atingir.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 Diagrama de Caso de Uso Dentre todos

Diagrama de Caso de Uso

Dentre todos esses diagramas, os Diagramas de Comunicação e de Sequência são o que chamamos de Diagramas Dinâmicos, por refletirem o comportamento do sistema. Pertencem a esse rol:

Diagrama de Estado

Diagrama de Sequência

Diagrama de Colaboração

Diagrama de Atividade

Os Diagramas Funcionais, por sua vez, são diagramas que mostram o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução. São eles o Diagrama de Componentes e o Diagrama de Implantação.

Os Diagramas Estáticos, por fim, são os que retratam o sistema de uma forma estrutural, e que são válidos durante todo o ciclo de vida. É o caso dos Diagramas de Classes e de Objetos.

Portanto, o Diagrama de Classe atende à nossa questão.

Resposta certa, letra d).

37ª Questão) (ESAF Analista de Finanças e Controle Desenvolvimento de Sistemas de Informação 2008) Diagramas de pacotes UML são usados para ilustrar a arquitetura lógica de um sistema. Assinale a opção correta a respeito da aplicação de diagramas de pacotes UML. a) Não permitem agrupar classes, outros pacotes e casos de uso.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

b) Camadas de Interface de Usuário-UI não podem ser modeladas como

pacotes.

c) A dependência (acoplamento) entre pacotes é representada por uma

Associação. d) Na UML, as associações são definidas como “o relacionamento semântico entre dois pacotes”. e) Representam as camadas, subsistemas e pacotes (no significado Java).

Esta é uma segunda abordagem para perguntar sobre diagramas UML. Ou eles descrevem o diagrama e pedem para você identificá-lo ou apresentam 5 descrições e pedem pra você acertar a que tem relação com o diagrama solicitado.

Diagrama de pacotes Descreve como os elementos são organizados dentro de pacotes e suas dependências, mostrando, inclusive, pacotes importados (o “import” do Java) e extensões de pacotes, além de pacotes contidos em outros. Tem por objetivo representar de uma forma clara os subsistemas englobados por um sistema de forma a determinar as partes que o compõem, oferecendo uma visão geral das camadas do sistema.

oferecendo uma visão geral das camadas do sistema. Diagrama de Pacotes Responder este estilo de pergunta

Diagrama de Pacotes

Responder este estilo de pergunta é mais difícil, e provavelmente vai exigir que você trabalhe por eliminação.

A letra a), por exemplo, é absurda;

Para a letra b), o próprio diagrama dado como exemplo, é uma

contraprova, pois mostra a “view” dentro de um pacote;

A letra c) mistura conceitos, pois dependência e associação são conceitos

“paralelos”. A dependência é representada por uma seta tracejada, como as mostradas no exemplo;

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

A letra d) também mistura conceitos pois são as dependências que são definidas como o relacionamento semântico entre dois pacotes. As associações, por sua vez, estabelecem relacionamento entre objetos.

Nossa resposta correta, portanto, é a letra e).

38ª Questão) (FCC Ministério Público do Estado do Rio Grande do Norte Analista de Tecnologia da Informação Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) Na taxonomia dos

diagramas de estrutura (S) e de comportamento (C) da UML, os diagramas de Pacote, Classe, Sequência e Objeto são, respectivamente, de

a) S, S, C e S.

b) S, S, C e C.

c) S, C, S e C.

d) C, S, C e S.

e) C, C, S e C.

Após resolver as duas questões anteriores, esta fica fácil. Entretanto, para lembrar na hora da prova, você precisará ter assimilado visualmente cada diagrama. Por isso, cada diagrama acima possui um exemplo visual.

Resposta certa, alternativa a).

39ª Questão) (FCC Ministério Público do Estado de Sergipe Analista do Ministério Público Gestão e Análise de Projeto de Sistema 2010) Dentre as etapas para o desenvolvimento de software em que a UML pode ser aplicada, aquela em que serão modeladas somente classes que

pertençam ao domínio principal do problema do software, deixando de lado

classes técnicas que gerenciem banco de dados, concorrência e outras, é a etapa de

interface, comunicação,

a) análise de requisitos.

b) análise sistêmica.

c) projeto.

d) implementação.

e) testes/implantação.

Questão inteligente de FCC envolvendo UML e Engenharia de Software. Ora, para que serve um diagrama de classes, como este?

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Tecnologia da Informação Prof Victor Dalton – Aula 00 Fique à vontade para pensar e analisar

Fique à vontade para pensar e analisar as alternativas, se for o caso. Mas perceba que, de imediato, este diagrama lhe fornece uma visão geral do sistema. Não cabe falar em análise de requisitos ou testes. Forçando a barra, poderíamos falar em projeto ou implementação, mas o enunciado frisou que detalhes técnicos estão excluídos. Portanto, este diagrama serve para análise sistêmica, e a alternativa b) é a correta.

40ª Questão) (FCC Assembléia Legislativa do Estado de São Paulo Agente Técnico Legislativo Tecnologia da Informação 2010) São consideradas metodologias ágeis de desenvolvimento de software:

a) XP e UP.

b) SCRUM e DSDM.

c) SCRUM e RUP.

d) DSDM e Cascata.

e) Cascata e PRINCE2.

Ao falar de metodologias ágeis, certamente Scrum e XP vieram à sua cabeça. XP, oriunda de eXtreme Programming, é uma filosofia de programação que segue algumas práticas genéricas, cujo conhecimento considero válido. São elas:

Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção. Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples. Time Coeso (Whole Team): A equipe de desenvolvimento é formada por pessoas engajadas e de forma multidisclipinar (no sentido de incluir pessoas com cada uma das habilidades necessárias para o projeto). Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia. Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

Prof. Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área: Tecnologia da Informação Prof Victor Dalton

Questões Comentadas de TI para o ICMS-SP 2013- Área:

Tecnologia da Informação Prof Victor Dalton Aula 00

Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema. Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Desenvolvimento Orientado a Testes (Test Driven Development):

Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida. Refatoração (Refactoring): É um processo que permite a melhoria continua da programaçã