Aula 01

Questes Comentadas de TI para o ICMS-PR Exerccios comentados Prof Victor Dalton Aula 01
AULA 01: Engenharia de Software

SUMRIO Introduo Cronograma Exerccios Consideraes Finais
INTRODUO Que bom encontr-los novamente! Isto significa que voc viu a minha aula demonstrativa e julgou a minha proposta de aula condizente com seus objetivos de estudos. Espero que ns possamos fazer com que seu esforo valha a pena! Esta primeira aula abrange Engenharia de Software, um assunto relativamente terico e, creio eu, um bom contedo inicial para a aproximao com a TI, especialmente se voc no for do ramo. Espero que voc tenha lido os referenciais tericos que indiquei. Uma aula de exerccios, por mais abrangente que ela tente ser, requer cooperao do aluno no sentido de buscar o mximo de familiarizao com o contedo a ser cobrado. Ser o nosso trabalho em equipe que levar voc a melhores resultados na prova que se aproxima! Alm disso, ainda mais quando tratamos de assuntos novos, ler mais de uma vez sempre nos ajuda a memorizar mais. Se voc tiver tempo, leia novamente os referenciais tericos aps os exerccios, pois esta tarefa auxiliar ainda mais a assimilao do contedo. Reforo essa releitura, em especial sobre Engenharia de Software, em que a UEL mostrou ser bem receptiva s ideias do nosso autor referncia em ES. Sem mais delongas, vamos comear? Mas, antes, acompanhemos o cronograma.
PGINA 1 1 2 48
CRONOGRAMA
1 aula (21 de setembro): Gerncia de Requisitos de Software: Conceitos de Requisitos. Requisitos Funcionais e no Funcionais. Engenharia de requisitos: conceitos bsicos. Tcnicas de elicitao de requisitos. Gerenciamento de requisitos. Especificao de requisitos. Tcnicas de validao de requisitos. Gerncia de configurao e
Prof. Victor Dalton
www.estrategiaconcursos.com.br
1 de 48
mudana: Conceitos de Gerncia de Configurao e Mudana de Software. Solicitaes de Mudana. Testes e Avaliao de Qualidade de Software: Conceitos. Documentos de Teste. Engenharia de Software: Ciclo de vida do software. Metodologias de desenvolvimento de software. Anlise por pontos de funo. 2 aula (05 de outubro): Gesto e Governana de TI: Planejamento Estratgico. Alinhamento entre estratgias de tecnologia da informao e de negcio: conceitos e tcnicas. Gerncia de Projetos: Conceitos. Processos do PMBOK. Planejamento e controle de mtricas de projeto. Planejamento e avaliao de iteraes. Fundamentos de CMMI (verso 1.2) e MPS-Br. Gesto de Processos de Negcio: Modelagem de processos. Tcnicas de anlise e modelagem de processo. BPM Business Process Modeling. Workflow e Gerenciamento Eletrnico de Contedo. 3 aula (12 de outubro): Programao de Sistemas: Lgica de Programao. Conceitos de Programao orientada a objetos e para web. Arquitetura de Software: Conceitos. Arquitetura Orientada a Servio (SOA). Portais corporativos e colaborativos. Web Services. Segurana da informao: Conceitos bsicos. Plano de continuidade de negcio. Noes sobre Criptografia, Assinatura Digital e Autenticao. Certificao Digital. Auditoria, vulnerabilidade e conformidade. Noes sobre norma ISO 27001 e ISO 27002. Redes: Conceito de rede. Arquitetura de Rede. Noes de administrao de redes. Conceitos de Virtualizao. 4 aula (16 de outubro): Gerncia de Servios de TI: Fundamentos da ITIL (Verso 3). Fundamentos de COBIT (Verso 5). Service desk. Conhecimentos sobre norma ISO/IEC 20000. Banco de Dados: Conceitos. Modelagem de Dados Relacional. Modelagem de Dados Multidimensional. Segurana aplicada a Bancos de Dados. Conceitos e estratgias de implantao de Data Warehouse, OLAP, Data Mining, ETL e Business Intelligence.
EXERCCIOS
1 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas da Informao - 2008) A Engenharia de Software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de especificao do sistema at a manuteno do mesmo. A Engenharia de Software adota mtodos de engenharia de software que a) so um conjunto de atividades, cuja meta o desenvolvimento ou a evoluo do software. b) so uma representao simplificada de um processo de software, apresentada a partir de uma perspectiva especfica.
Prof. Victor Dalton
2 de 48
c) so abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notaes, regras, recomendaes 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 comear pela definio! Engenharia de software uma rea da computao voltada especificao, desenvolvimento e manuteno de sistemas de software, com aplicao de tecnologias e prticas de gerncia de projetos e outras disciplinas, visando organizao, produtividade e qualidade. Os fundamentos cientficos 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. Alm disso, a engenharia de software adota mtodos de engenharia de software que so abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notaes, regras, recomendaes de projetos e diretrizes de processos. Nossa resposta certa a letra c).
2 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas da Informao - 2012) A escolha de um modelo fortemente dependente das caractersticas do projeto. Os principais modelos de ciclo de vida podem ser agrupados em trs categorias principais: 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 comeo da Engenharia de Software. Estas classificaes variam muito entre autores. Entretanto, esta a mais recente cobrada em concursos, e muito prxima da adotada por sua fonte recomendada para estudos. Vejamos: Modelos sequenciais: so os modelos moda antiga, como o modelo em cascata e o modelo em V. Nestes modelos, uma fase s comea aps o trmino da outra. um modelo meio ultrapassado de desenvolver software.
Prof. Victor Dalton
3 de 48
Modelo em Cascata
Modelo em V
Modelos incrementais: onde se enquadram o prprio modelo incremental e o RAD (Rapid Application Development). Partem do princpio que a cada ciclo uma verso operacional do sistema ser produzida e entregue ao cliente para uso ou avaliao detalhada.
Modelo Incremental
Prof. Victor Dalton
4 de 48
RAD
Modelos evolutivos uma forma de desenvolvimento na qual o software desenvolvido em ciclos, e a cada ciclo novas funcionalidades so incrementadas ao sistema. Enquadram-se aqui o modelo espiral e a prototipao.
Modelo em espiral
Prototipao
Prof. Victor Dalton
5 de 48
Observe que interessante: na definio de modelos incrementais falamos em ciclo, e na definio 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 no lhe diga muita coisa, mas a grande verdade que voc est aqui para acertar questes na prova, e no pra tirar um diploma de Doutor em Engenharia de Software. No verdade? E o Pressmann um autor de renome, no sendo incomum suas definies aparecerem Ipsis Literis em questes de concursos. Na hora da prova, dance conforme a msica. Voc vai me ouvir falar isso mais de uma vez nessa apostila. Resposta certa, alternativa c).
3 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao - 2010) As atividades do modelo espiral de Engenharia de Software so: a) Planejamento, Anlise dos Componentes, Anlise de Hierarquia e Avaliao feita pelo cliente. b) Planejamento, Anlise dos Riscos, Engenharia e Avaliao feita pelo cliente. c) Projeto, Anlise dos Benefcios, Engenharia e Avaliao feita pelo gestor. d) Planejamento, Eliminao dos Riscos, Anlise de Contingncia e Avaliao feita pelo cliente. e) Planejamento, Projeto, Anlise dos Riscos e Engenharia. Se voc prestou bem ateno na figura do modelo em espiral, na pgina anterior, vai ficar em dvida para responder esta questo. 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 no. Entretanto, um senso comum entre os autores sobre o modelo espiral o reconhecimento explcito do risco, e a entrega para o cliente validar, aceitar, verificar... etc. E, pessoal, no brincadeira: se voc sair pesquisando no Google, vai achar umas 10 espirais diferentes, sem exagero! A prpria espiral do Pressmann (reconhecidamente, o grande autor em Engenharia de Software), que dividida em Planejamento, Modelagem, Construo, Implantao e Comunicao, no lhe habilitaria a responder esta questo. Ah, Victor e por que voc no nos passa a espiral padro, aquela que as bancas sempre cobram? Porque se eu ou algum lhe prometer essa espiral estar mentindo pra voc. Ainda mais a UEL, banca com poucas provas de TI cuja questo exata sobre esse assunto no encontrei em provas anteriores. Logo, meu objetivo lhe preparar da melhor forma para o que pode vir pela frente.
Prof. Victor Dalton
6 de 48
Pesquisando na internet, achei um autor que afirma que o modelo em espiral possui as seguintes etapas: Comunicao com o cliente, planejamento, anlise de riscos, engenharia, construo e liberao, e avaliao com o cliente. Foi o conceito mais prximo da alternativa correta da ESAF, a letra b). Se fssemos por eliminao, ficaramos entre a b) e a e), pelo menos. J falei em danar conforme a msica? Pois , acho que vou ser muito repetitivo nesta apostila...
4 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas de Informao 2008) No modelo de desenvolvimento em espiral, cada ciclo da espiral representa uma fase do processo de software. Nesse modelo, a atividade que obrigatoriamente estar presente em todos os ciclos : a) Planejamento de desenvolvimento. b) Anlise de requisitos. c) Teste de unidade. d) Anlise, Projeto, Implementao e Teste. e) Anlise de riscos. Senso comum entre os autores! Voc no pode errar! Letra e).
5 Questo) (ESAF Analista de Controle Externo Anlise de Sistemas 2002) O paradigma do ciclo de vida clssico da engenharia de software requer uma abordagem sistemtica, sequencial ao desenvolvimento do software, que se inicia no nvel do sistema e avana ao longo da anlise, projeto, codificao, teste e manuteno. A etapa deste ciclo, que se apresenta como um processo de mltiplos passos e se concentra em quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterizao da interface, a atividade de a) codificao. b) anlise de requisitos de software. c) anlise de sistemas. d) engenharia de sistemas. e) projeto. Detalhando o modelo em cascata: Anlise e Definio de Requisitos Os servios, restries e objetivos do sistema so definidos por meio de consulta aos usurios do sistema. Eles so, portanto, definidos detalhadamente e servem como uma especificao 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
Prof. Victor Dalton
7 de 48
arquitetura geral do sistema. O projeto de software envolve a identificao e a descrio das abstraes fundamentais do sistema de software e suas relaes. Implementao e teste de unidade Durante esse estgio, o projeto de software realizado como um conjunto de programas ou unidades de programa. O teste unitrio envolve a verificao de que cada unidade atende sua especificao. Integrao e testes de sistema As unidades individuais de programa ou os programas so integrados e testados como um sistema completo para garantir que os requisitos de software foram atendidos. Aps os testes, o sistema de software liberado para o cliente. Operao e manuteno Geralmente (embora no necessariamente) esta a fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A manuteno envolve a correo de erros no detectados nos estgios anteriores ao ciclo de vida, no aprimoramento da implementao das unidades de sistema e na ampliao dos servios de sistema medida que novos requisitos so identificados. O segredo para acertar a questo conhecer bem os nomes das etapas, para no ser ludibriado pelas alternativas. Pela explicao da etapa, que consta do enunciado, no cabe marcar outra alternativa que no seja a letra e).
6 Questo) (UEL POSCOMP 2010) Sobre o Ciclo de Desenvolvimento de Software, correto afirmar: I. O desenvolvimento em cascata tem como base a ideia de desenvolver uma implementao inicial, mostrar e discutir tal implementao com o usurio e fazer seu aprimoramento por meio de verses subsequentes, at que um sistema adequado tenha sido desenvolvido. II. no modelo de processo de desenvolvimento em espiral, cada loop na espiral representa uma fase do processo de software. Este modelo exige a considerao direta dos riscos tcnicos em todos os estgios do projeto e, se aplicado adequadamente, deve reduzir os riscos antes que eles se tornem problemticos. III. O Rapid Application Development (Desenvolvimento Rpido de Aplicao) um modelo de processo se software incremental que enfatiza um ciclo de desenvolvimento rpido. Este modelo uma adaptao de modelo cascata, no qual o desenvolvimento rpido conseguido com o uso de uma abordagem de construo baseada em componentes. IV. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. Em um processo de desenvolvimento incremental, os clientes identificam (esboam) as funes a serem fornecidas pelo sistema e
Prof. Victor Dalton
8 de 48
a importncia das mesmas. Em seguida, definida uma srie de estgios de entrega, com cada estgio fornecendo um subconjunto das funcionalidades do sistema. Assinale a alternativa correta. a) Somente as afirmativas I e II esto corretas. b) Somente as afirmativas I e III esto corretas. c) Somente as afirmativas III e IV esto corretas. d) Somente as afirmativas I, II e IV esto corretas. e) Somente as afirmativas II, III e IV esto corretas.
Questo da UEL sobre o assunto! Coisa rara, viu? Mas analisemos com o conhecimento j transmitido: I. Errado! Analisamos o modelo em cascata na questo anterior, e, no incio da apostila, afirmei que este modelo estava ultrapassado. No modelo em cascata, o cliente pede o software, levantam-se os requisitos e, depois de um bom tempo, o cliente recebe o programa pronto; II. Eu afirmei que o reconhecimento do risco senso comum entre os autores, quando falamos do modelo espiral! Certa; III. Observando a figura do RAD, na 2 questo, percebe-se facilmente que ele uma adaptao do modelo em cascata, com o uso de uma abordagem baseada em componentes. Diga-se de passagem, este item uma cpia do Pressmann. Certa; IV. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. Se eu conhecesse o Pressmann pessoalmente, poderia imagin-lo falando essa frase. Certa. Dessa forma, nossa alternativa correta a letra e).
7 Questo) (ESAF Agncia Nacional de guas Analista de Sistemas 2009) Analise as seguintes afirmaes sobre requisitos de sistemas de software: I. Requisitos funcionais declaram as funes que o sistema deve fornecer, seu comportamento, e ainda, o que o sistema no deve fazer. II. Requisitos de domnio so, exclusivamente, funcionais, pois exibem as caractersticas do domnio de aplicao do sistema. III. Requisitos no-funcionais compreendem restries sobre servios ou funes do sistema. Assinale a opo correta. a) Apenas as afirmaes I e II so verdadeiras.
Prof. Victor Dalton
9 de 48
b) Apenas as afirmaes I e III so verdadeiras. c) Apenas as afirmaes II e III so verdadeiras. d) As afirmaes I, II e III so verdadeiras. e) Nenhuma das afirmaes verdadeira.
O conceito de requisito, na Engenharia de Software refere-se definio de uma caracterstica, atributo, habilidade ou qualidade que um sistema deve necessariamente prover para ser til a seus usurios. Creio que, a esta altura do campeonato, isso no seja mais novidade para voc. Contudo, os requisitos podem ser classificados de diversas formas. A saber: Requisito funcional: Define uma funo de um sistema de software ou seu componente. Uma funo descrita como um conjunto de entradas, seu comportamento e as sadas. Os requisitos funcionais podem ser clculos, detalhes tcnicos, manipulao de dados e de processamento e outras funcionalidades especficas que definem o que um sistema, idealmente, ser capaz de realizar. Em suma, dizem o que o sistema deve fazer, mas tambm pode ser uma declarao explcita do que o sistema no deve fazer. Ex: o usurio deve ser capaz de pesquisar todos os livros da biblioteca, o usurio no pode cautelar dois exemplares do mesmo livro. Requisito no-funcional: o requisito relacionado ao uso da aplicao em termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos no-funcionais podem constituir restries aos requisitos funcionais e no preciso o cliente dizer sobre eles, pois eles so caractersticas mnimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou no. Ex: o sistema deve suportar o uso simultneo por cem usurios, sem apresentar lentido ou perda de performance. Requisito de domnio: um requisito proveniente do domnio da aplicao do sistema e que reflete as caractersticas e as restries desse domnio. Pode acabar produzindo requisitos funcionais ou no funcionais. Ex: esse aplicativo dever ser executado tanto em IPhone quanto em celulares Android. um requisito de domnio que demandar uma srie de requisitos funcionais e no funcionais em cada plataforma a ser desenvolvido o sistema. Requisito de usurio: O requisito de usurio de um sistema deve descrever os requisitos funcionais e no funcionais de modo que ele seja compreensvel pelos usurios do sistema que no possuem conhecimento tcnico detalhado. Eles devem especificar apenas o comportamento externo do sistema e evitar, sempre que possvel, descrever caractersticas de projeto do sistema. Os exemplos de requisitos funcionais que eu passei so bons exemplos de requisitos de usurio. Requisito de sistema: uma verso expandida do requisito de usurio, usado pelos engenheiros de software como ponto de partida para o projeto do sistema. Podem ser escritas em linguagem natural e/ou linguagens de notao de projetos e notaes grficas. Por exemplo: Uma chamada a um arquivo
Prof. Victor Dalton
10 de 48
externo no dever repassar parmetros a esse arquivo. O tratamento das variveis dever se local. Especificao de interface (ou de projeto): uma especificao tcnica 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 explanao, voltemos aos itens da questo: I. Correta; II.Errada, pois os requisitos de domnio podem ser tambm no-funcionais; III.Correta. Um requisito no-funcional pode afetar um requisito funcional. Ex:Um sistema que opere em uma mquina que no permita a insero de pendrives pode restringir o salvamento de arquivos neste tipo de mdia, permitindo apenas o envio de dados pela internet; Logo, nossa resposta certa a letra b).
(FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009) Para responder as questes de 8 e 9, considere: necessrio que o software calcule os salrios dos diaristas e mensalistas e emita relatrios mensais sumariados por tipo de salrio. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usurios autorizados. De qualquer forma, o tempo de resposta das consultas no deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente em razo dos adiantamentos e vales que recebem. fundamental que o software seja operacionalizado usando cdigo aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final no pode ultrapassar o prazo de oito meses a contar da data de incio do projeto. A frase acima, expressa por um funcionrio do cliente, aborda alguns requisitos de software especificados para um sistema de gesto de pessoal. 8 Questo) No texto, so requisitos no-funcionais: a) no pode ultrapassar o prazo de oito meses e necessrio que o software calcule os salrios dos diaristas e mensalistas. b) os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente e em razo dos adiantamentos e vales que recebem.
Prof. Victor Dalton
11 de 48
c) fundamental que o software seja operacionalizado usando cdigo aberto e os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente. d) tempo de resposta das consultas no deve superar os quinze segundos e entrega do produto final no pode ultrapassar o prazo de oito meses. e) pois inviabilizaria todo o investimento nesse sistema e em razo dos adiantamentos e vales que recebem. Pois bem, aps trabalharmos bastante os conceitos dos diversos tipos de requisitos, nada como usarmos um pouco do raciocnio para responder esta questo da famosa prova da FCC, cujo edital muito similar ao da prova de vocs. No se preocupem, brincaremos bastante com esta prova.
Definimos requisitos no-funcionais como requisitos relacionados ao uso da aplicao em termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade, manutenibilidade e tecnologias envolvidas. Vejamos os itens: a) b) c) d) e) fala em clculo de salrios. Errada; fala em emisso de relatrios. Errada; idem b). Errada; tempo de resposta de consultas e prazo para entrega. Certa! item nonsense. Errada.
Mesmo que voc no estivesse confiante em marcar a alternativa d), seria possvel trabalhar por eliminao. 9 Questo) No texto, so requisitos funcionais: a) calcule os salrios dos diaristas e mensalistas e os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, 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 usurios autorizados. c) fundamental que o software seja operacionalizado usando cdigo aberto e emita relatrios mensais sumariados por tipo de salrio. d) emita relatrios mensais sumariados por tipo de salrio e Necessito, ainda, forte gerenciamento de risco, prazo e custo. e) a base de dados deve estar protegida e com acesso restrito aos usurios autorizados e entrega do produto final no pode ultrapassar o prazo de oito meses. Aqui eu j quero voc mais confiante! De cara, a alternativa a) j parece correta. Vejamos as demais. b)apenas requisitos no funcionais; c)um requisito no-funcional e um funcional;
Prof. Victor Dalton
12 de 48
d)um requisito funcional e outro no-funcional; e)requisitos no-funcionais. Podemos seguir em frente?
10 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao 2008) Os requisitos de um sistema so descries dos servios fornecidos pelo sistema e as suas restries operacionais. Indique a opo que corretamente se relaciona com a anlise ou gerenciamento de requisitos. a) Requisitos de sistema so declaraes do usurio que definem, detalhadamente, as funes, os servios e as restries operacionais do sistema. b) As representaes de dados usadas nas interfaces de sistemas so exemplos de requisitos funcionais. c) A exigncia de que o sistema deva fornecer telas apropriadas para o usurio ler os documentos no repositrio de documentos um exemplo de requisito funcional. d) A exigncia de que o sistema no deva revelar quaisquer informaes pessoais sobre os usurios do sistema ao pessoal de vendas que o utiliza, com exceo do nome e cargo, um exemplo de requisito funcional. e) Avaliar se os requisitos associados ao desempenho, ao comportamento e s caractersticas operacionais do sistema foram explicitamente declaradas uma tarefa de especificao de requisitos. Vamos analisar as alternativas com o conhecimento j adquirido? a) Descreve o que so requisitos de usurio. Errada; b) Especificaes de interface. Errada; c) Correta; d) Requisito no-funcional, pois est relacionado segurana da aplicao. Errada; e) Tarefa da validao de requisitos, mas este contedo ser visto mais adiante. Errada; Espero que voc j esteja dominando este tpico. Alternativa c).
11 Questo) (Formulao pessoal) uma tcnica de elicitao de Requisitos: a) Entrevista com stakeholder, por meio de formulrios predefinidos (entrevista fechada) ou no (entrevista aberta). Por meio dela procura-se saber o que o interessado espera ou deseja no sistema. b) Descrio de cenrios, na qual comea-se com um esboo da interao e, durante a elicitao, adicionam-se detalhes para uma descrio completa dessa interao.
Prof. Victor Dalton
13 de 48
c) Elaborao de casos de uso, que so cenrios descritos em um diagrama UML, visual, tambm discutidos com os interessados. d) Etnografia, que uma tcnica na qual o analista insere-se no ambiente de trabalho como um observador, procurando levantar os requisitos do sistema. e) Todas as alternativas esto corretas.
Este tpico consta em seu edital, embora a cobrana em provas seja rarssima. Elicitar requisitos nada mais do que descobrir, elucidar os requisitos. Todas as tcnicas acima so tcnicas de elicitao de requisitos. Perceba que nada mais so do que formas prticas de procurar saber dos interessados o que eles esperam do sistema que esto solicitando. Utilize a questo como subsdio de contedo. Alternativa e).
12 Questo) (FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009) Quanto aos requisitos de software, considere: I. importante que se estabeleam prticas para encontrar, documentar, organizar e rastrear os requisitos variveis de um sistema. II. Etnografia (observao e anlise dos fluxos de trabalho) e sesses de JAD so prticas que podem ser aplicadas na elicitao. III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema existente, de anlise do domnio 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 ento, acredito que sua nica dvida na questo a respeito de JAD. Vamos l: O JAD (Joint Application Design) uma tcnica de levantamento interativo, criada por dois profissionais da IBM do Canad na dcada de 1970 onde, em uma ou mais sesses, so reunidos todos os interessados no assunto para tomar as decises sobre o mesmo. A tcnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de soluo de problemas baseado em consenso.
Prof. Victor Dalton
14 de 48
A dinmica do JAD: So feitas reunies participativas, chamadas de sesses, envolvendo representantes de todas as reas relacionadas com os assuntos em discusso. As regras da sesso:
Todos os participantes so iguais. Nas sesses JAD, a estrutura hierrquica e de poder so deixadas do lado de fora. Todas as posies tem o mesmo peso e sero avaliadas pelo grupo sem levar em conta qual a origem da mesma. Apenas uma pessoa fala de cada vez. Assim todos tero chance de expressar a sua opinio e de ouvir as opinies do restante do grupo. Todas as opinies so vlidas. preciso no ter uma posio prconcebida sobre as opinies dadas. Hora para comear, interromper e terminar. necessrio definir uma agenda para as sesses e cumpri-la risca. Celular desligado. Durante a sesso no devem acontecer interrupes externas. Recursos visuais. Utilizar intensivamente recursos visuais para tornar o projeto do sistema mais palpvel e permitir que ele seja entendido pelos diversos participantes. Uma fotografia mais explicativa e rica em detalhes do que 1000 palavras para a descrio de um fato. Os papis na sesso:
Sponsor (Patrocinador). o executivo responsvel pelo projeto, o dono do sistema. Ele precisa ter autonomia para tomar decises, definir estratgias e direcionar o trabalho. Facilitador. o responsvel por conduzir a sesso. Ele no precisa ser um especialista no assunto que est sendo tratado. Ele dever estar focado em organizar a dinmica, dando a palavra a cada participante, obtendo o consenso sobre os assuntos tratados, organizando o registro das decises e intermediando os conflitos. Escriba. a pessoa responsvel por registrar todas as discusses e decises em um local que todos possam visualizar, como um quadro ou flip-chart. Documentador. o responsvel por registrar todas as decises em um documento formal, como uma ata de reunio ou uma especificao de requisitos, que ser assinado por todos ao final das sesses. Especialistas. So as pessoas que tem conhecimento do assunto que est sendo discutido e que podem efetivamente contribuir para a discusso e na tomada de decises. Observadores. So pessoas que esto na sesso apenas para conhecer mais do assunto que est sendo tratado ou para assimilar a tcnica da reunio. Os observadores no podem se manifestar durante a sesso.
Prof. Victor Dalton
15 de 48
Os fatores de sucesso:
A sesso precisa ter presente as pessoas que tem poder de deciso sobre o assunto tratado, pois, no adianta tomar decises durante a reunio que podero ser contestadas quando todos voltarem para o escritrio. As decises precisam ser tomadas por consenso, pois, todos os participantes da sesso precisam sair de l comprometidos com as definies registradas. As sesses devem ocorrer fora do ambiente de trabalho dos participantes para evitar interrupes e prevenir que os participantes se vejam tentados a tratar de assuntos ligados a sua rotina diria. No deixar que os participantes imponham suas opinies em funo do seu nvel hierrquico, para evitar que pessoas de nvel hierrquico mais baixo fiquem constrangidas em debater ou discordar. Definir claramente qual ser o produto gerado no final das sesses. Os benefcios esperados em relao aos mtodos tradicionais:
Maior produtividade. Estudos relatam aumentos de 20 a 60% na produtividade, em relao aos mtodos tradicionais. Maior qualidade. Usurios e analistas de sistemas costumam citar projeto de softwares de alta qualidade como sendo o maior benefcio do mtodo. Trabalho em equipe. Promove o esprito de cooperao, entendimento e trabalho em equipe. Custos mais baixos. O projeto de alta qualidade, obtido atravs do JAD, possibilita uma grande economia de tempo e dinheiro mesmo aps a entrega do sistema.
Bem, apesar de parecer mais com uma reunio do AA (no que eu j tenha ido em uma, rs), voc pde notar que o JAD tambm uma tcnica de Elicitao de requisitos. Assim sendo, todos os itens esto corretos e nossa alternativa certa a letra c).
13 Questo) (UEL Secretaria do Estado da Administrao e da Previdncia 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 caractersticas antes da Implementao. seu papel realizar a interao entre o que deve ser feito e como deve ser feito. Esta afirmao refere-se a:
Prof. Victor Dalton
16 de 48
a) Arquitetura do Software. b) Planejamento do Software. 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 vo trabalhar para resolver. Ela inclui o conjunto de tarefas que levam a um entendimento de qual ser o impacto do software sobre o negcio, do que o cliente quer e de como os usurios finais vo interagir com o software. Seu objetivo fornecer a todas as partes um entendimento escrito do problema. Resposta certa, letra c).
14 Questo) (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 estgio de levantamento e anlise dos requisitos, os membros equipe tcnica de desenvolvimento do software trabalham com o cliente e usurios finais do sistema para descobrir mais informaes sobre o domnio aplicao, que servios o sistema deve fornecer, o desempenho exigido sistema, as restries de hardware, entre outras informaes. da os da do
III. Na medida em que a informao de vrios pontos de vista coletada, os requisitos emergentes so consistentes. IV. A validao de requisitos se ocupa de mostrar que estes realmente definem o sistema que o cliente deseja. Ela importante porque a ocorrncia 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 esto corretas. b) Somente as afirmativas I e III esto corretas. c) Somente as afirmativas III e IV esto corretas. d) Somente as afirmativas I, II e IV esto corretas.
Prof. Victor Dalton
17 de 48
e) Somente as afirmativas II, III e IV esto corretas.
Aproveitaremos esta questo da UEL para destrinchar todas as etapas da Engenharia de Requisitos. A engenharia de requisitos fornece o mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade, negociando uma condio razovel, especificando a soluo de modo no ambguo, validando a especificao e gerindo os requisitos medida que eles so transformados em um sistema operacional (no 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 execuo de sete funes distintas: concepo, levantamento, elaborao, negociao, especificao, validao e gesto. Concepo - Concepo inicial do software. O objetivo desta etapa entender o problema, quais os envolvidos, a natureza da soluo e iniciar o processo de comunicao entre clientes e colaboradores. Levantamento e anlise - Perguntar aos envolvidos no projeto: Qual o objetivo do produto?; Como o produto se enquadra nas necessidades do negcio?; Como o produto ser utilizado? O que o produto deve oferecer? Entretanto, podem existir diversos problemas nesse ponto do projeto: Problemas de escopo: No se identifica corretamente os limites do que o Software deve ou no fazer, muitas vezes requisitos tcnicos desnecessrios confundem o entendimento da soluo esperada; Problemas de entendimento: O cliente no tem domnio suficiente do problema, no conhece o potencial de uma soluo computacional, omite informaes bvias, entre outros; Problemas de volatilidade: Os requisitos mudam ao longo do tempo. Por experincia prpria, posso afirmar o quanto difcil levantar requisitos, principalmente quanto a problemas de entendimento. Sempre que partimos para a prxima etapa, a elaborao, uma das coisas mais comuns o cliente afirmar que aquele cenrio elaborado no condiz com o que ele mesmo descreveu e
Prof. Victor Dalton
18 de 48
documentou na reunio anterior. As etapas de elaborao e levantamento formam um loop parte, at que se consiga avanar no projeto. Elaborao - Refinamento das informaes obtidas na etapa anterior com a incluso de modelagens de cenrios de interao do usurio com o sistema e modelagem das classes envolvidas tanto como a relao entre elas. Negociao - frequente que aps a etapa de elaborao muitos requisitos no estejam de acordo com a disponibilidade de recursos disponveis ou ainda sejam conflitantes entre si. Nesse ponto os requisitos so avaliados junto ao cliente e podem ser excludos, combinados ou ainda serem acrescentados novos requisitos. Especificao - A especificao a apresentao formal dos dados obtidos at o momento podendo incluir grficos, textos em linguagem natural, modelagem de cenrios ou um prottipo. O principal que a especificao possa guiar o desenvolvimento futuro indicando os limites do software com as suas possibilidades e limitaes. Validao - Nesse ponto, todos os envolvidos (clientes, colaboradores e usurios) avaliam os requisitos em busca de erros de interpretao, ambiguidade e omisses. Pode ser usado um modelo de questes checklist para validar os requisitos. Gesto - A gesto de requisitos o processo que visa identificar, controlar e rastrear requisitos e modificaes 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 dependncias. Para projetos menores esse processo pode ser feito de forma mais informal.
Voc ainda se lembra da questo? Ento volte aos itens dela e tente responder sem a minha explicao abaixo. I. uma afirmativa bem genrica e verdadeira. Todas as atividades da Engenharia de Software devem ser adaptadas organizao que a realiza; II. Correta. A descoberta, elicitao ou levantamento dos requisitos (isso mesmo, 10 questo) a etapa em que ocorre essa obteno de informaes sobre o domnio da aplicao; III. No necessariamente. Inclusive, o mais comum, medida que se coletam diferentes pontos de vista, encontrarmos requisitos conflitantes. E por isso que a fase de negociao indispensvel; IV. Correta. Aps a negociao e a especificao, a validao uma espcie de reunio final em que todos avalizam os requisitos definidos. Aps isto, temos apenas a gesto, que rastreia a evoluo dos requisitos ao longo do tempo. Entendidas estas sete etapas? Certamente este assunto ser cobrado em sua prova. Alternativa d).
Prof. Victor Dalton
19 de 48
15 Questo) (ESAF Analista de Finanas e Controle Tecnologia da Informao 2012 - adaptada) Assinale a opo correta. a) Gesto de requisitos preocupa-se com a documentao, atualizao e controle de stakeholders envolvidos na fase de identificao da demanda. b) Engenharia de requisitos compreende: identificar, analisar, especificar e definir as necessidades de negcio que um aplicativo deve prover para soluo do problema levantado. c) Engenharia de requisitos compreende: planejar, especificar e desenvolver as necessidades de negcio que um aplicativo deve prover para minimizao dos problemas levantados. d) Engenharia de requisitos compreende: identificar, analisar, programar e testar os programas das necessidades de soluo de problemas que um negcio deve prover para satisfazer usurios. e) Gesto de requisitos preocupa-se com a documentao, direcionamento, controle de definio e acesso aos requisitos levantados na fase de planejamento de escopo. Agora que voc compreende os conceitos de Engenharia de Requisitos pode responder bem uma questo que mistura e confunde conceitos. As alternativas a) e e) afirmam coisas sem sentido; voc j sabe que, aps a consolidao dos requisitos, a gesto de requisitos atua no sentido de rastrear e acompanhar os requisitos ao longo do tempo. Quanto s questes que definem engenharia de requisitos, no difcil encontrar verbos absurdos atribudos nas alternativas c) e d), como desenvolver as necessidades do negcio e programar e testar os programas. Voc j domina esse conceito. Logo, a alternativa correta a letra b).
16 Questo) (FGV Senado Federal - Analista Sistemas 2012) O processo de Engenharia de Requisitos realizado por meio da execuo de sete funes distintas: concepo, levantamento, elaborao, negociao, especi validao e gesto. Nesse contexto, observe a lista abaixo, que representa um conjunto de questes a serem utilizadas como checklist dentro de uma dessas funes.
Prof. Victor Dalton
20 de 48
A funo : a) Elaborao b) Negociao c) Especificao d) Validao e) Gesto Opa! Voc j sabe qual a etapa que rene clientes, colaboradores e usurios para avaliar os requisitos acordados, inclusive por meio de um checklist, no sabe? a validao. Ainda, se lhe restar alguma dvida, confirme que o checklist apresentado procura erros de interpretao, ambiguidade e omisses. At mesmo pelo contedo das perguntas mostradas, razovel que estejamos em uma etapa posterior concepo, levantamento e elaborao dos requisitos. Tambm no so perguntas referentes a uma eventual negociao. Na especificao no cabe checklist, pois esta um detalhamento formal dos requisitos ps-negociao, auxiliada por prottipos e diagramas. E, por fim, no cabe ser gesto de requisitos, pois tambm no cabe checklist na gesto. Nesta etapa, os requisitos j esto claros, sendo apenas rastreados em caso de modificao ou evoluo ao longo do tempo. Nossa resposta correta, alternativa d).
17 Questo) (Formulao pessoal) uma tcnica de Validao de Requisitos: a) Revises de requisitos, na qual os requisitos so analisados sistematicamente por uma equipe de revisores. b) Prototipao, na qual um modelo executvel do sistema apresentado para usurios finais e clientes.
Prof. Victor Dalton
21 de 48
c) Gerao de casos de teste, no qual cdigo de testes produzido para analisar se os requisitos so testveis, e se passam nos testes. d) As alternativas a, b e c esto corretas. e) Nenhuma alternativa est correta.
Quero chamar a sua ateno para esse tpico, uma vez que tcnicas de validao de requisitos est em seu edital, apesar de no ser comum sua cobrana em provas. Alm disso, nossa fonte recomendada no contm este contedo com essas exatas palavras. As alternativas a,b e c so as trs tcnicas de validao de requisitos segundo Sommerville, em seu Livro Engenharia de Software. a outra referncia forte no ramo de ES. Portanto, utilize esta questo como fonte de estudo. Alternativa d).
18 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao - 2005) Analise as seguintes afirmaes 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 ento este ter alcanado um ndice de qualidade de 100%. III. O controle de qualidade utiliza inspees para provar a existncia de qualidade dentro de um produto final do projeto. IV. Um ambiente de desenvolvimento de software, no processo de evoluo da qualidade dos seus produtos e servios, deve substituir o processo de Controle da Qualidade pelo processo de Garantia da Qualidade. Indique a opo que contenha todas as afirmaes 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 questo conceitual apenas para desencargo de conscincia. O gerenciamento da qualidade de software pode ser estruturado em trs grandes atividades:
Prof. Victor Dalton
22 de 48
Garantia de qualidade estabelecimento de um framework de procedimentos organizacionais e padres que conduzem a um software de alta qualidade; Planejamento de qualidade seleo de procedimentos e padres apropriados deste framework, adaptados para um projeto de software especfico; e Controle de qualidade Definio e aprovao de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentos e os padres 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 padres de processo, que definem os processos que devem ser seguidos durante o desenvolvimento do software (como documentos obrigatrios que devam ser gerados, estabelecimento de reunies peridicas), e o estabelecimento de padres de produto(exigncia de determinada nomenclatura a ser adotada no cdigo, padronizao de comentrios no cdigo, padronizao do formato da documentao, etc.). Feita esta introduo, vejamos as alternativas: I. Est razoavelmente certa. Garantir que o projeto foi concludo sem desvios tambm 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 no faz parte do edital, mas, apenas para lembrar, este o diagrama da lei do 80/20. Por exemplo, 20% dos defeitos do software so responsveis por 80% das reclamaes. Ele um diagrama que ajuda a estabelecer prioridades, logo, no garante nada; III.Certssimo. Controle -> inspees! IV. Esta substituio no existe, as trs tarefas so necessrias. Logo, ficamos com a alternativa c).
19 Questo) (UEL Analista de Informtica Jnior Desenvolvimento de Sistemas - 2009) A norma ISO 9126 (Caractersticas de Qualidade de Software define 6 caractersticas (requisitos) de qualidade desejveis para um produto de software. Considere os itens a seguir: I. Evidencia o conjunto de funes que atendem s necessidades explcitas e implcitas para a finalidade a que se destina o produto e suas propriedades especficas
Prof. Victor Dalton
23 de 48
II. Evidencia o desempenho do produto, verificado ao longo do tempo e em condies estabelecidas. III. Evidencia a facilidade de uso do produto, bem como o julgamento individual desse uso, por um conjunto de usurios estabelecido ou subentendido. IV. Evidencia a compatibilidade entre os recursos e os tempos envolvidos, assim como o nvel de desempenho requerido para o produto, sob condies estabelecidas. V. Evidencia a possibilidade de se utilizar o produto em diversas plataformas, com pequeno esforo para adaptao. VI. Evidencia a facilidade para fazer modificaes especficas no software. Assinale a alternativa que apresenta a sequncia correta em relao aos itens colocados anteriormente.
a) Funcionalidade; Eficincia; Usabilidade; Confiabilidade; Portabilidade; Manutenibilidade. b) Funcionalidade; Confiabilidade; Portabilidade; Eficincia; Usabilidade; Manutenibilidade. c) Confiabilidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade; Funcionalidade. d) Funcionalidade; Confiabilidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade. e) Confiabilidade; Funcionalidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade. Voc no leu a ISO 9126 e est se sentindo inseguro frente questo? Nada disso. Ela vai servir para medir o seu grau de intimidade com o vocabulrio tcnico da TI. Se voc conseguir associar os itens s caractersticas de forma correta, parabns, voc j est ficando ntimo da TI! Tente resolver a questo antes de ver a minha explicao abaixo, tudo bem? Alguns itens podem amarrar a alternativa correta com maior facilidade. Evidenciar se um conjunto de funes 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, graas 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 questo. Por fim, modificar o software, seja para correes ou evoluo est diretamente relacionado manutenibilidade do mesmo.
Prof. Victor Dalton
24 de 48
Logo, a dvida reside apenas entre as alternativas a) e d), em que as definies de confiabilidade e eficincia talvez no estejam to explcitas em suas descries. Ento vejamos abaixo as seis caractersticas descritas corretamente: Funcionalidade - Evidencia o conjunto de funes que atendem s necessidades explcitas e implcitas para a finalidade a que se destina o produto e suas propriedades especficas. Confiabilidade - Evidencia o desempenho do produto, verificado ao longo do tempo e em condies estabelecidas. Usabilidade - Evidencia a facilidade de uso do produto, bem como o julgamento individual desse uso, por um conjunto de usurios estabelecido ou subentendido. Eficincia - Evidencia a compatibilidade entre os recursos e os tempos envolvidos, assim como o nvel de desempenho requerido para o produto, sob condies estabelecidas. Portabilidade - Evidencia a possibilidade de se utilizar o produto em diversas plataformas, com pequeno esforo para adaptao. Manutenibilidade - Evidencia a facilidade para fazer modificaes especficas no software. Assimilados os conceitos? Alternativa d).
20 Questo) (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 tcnica utilizada para se projetar casos de teste no qual o programa ou sistema considerado uma caixa preta e, para test-lo, so fornecidas entradas e avaliadas as sadas geradas para verificar se esto em conformidade com os objetivos especificados. II. A tcnica estrutural estabelece os requisitos de teste com base em uma dada implementao, requerendo a execuo de partes ou de componentes elementares do programa. III. Teste um conjunto de atividades que no pode ser planejado antecipadamente, porm deve ser realizado sistematicamente. IV. Um mdulo driver chama o mdulo que est sendo testado, devendo conter apenas as inicializaes das variveis globais e dos parmetros que sero utilizados para a chamada do mdulo testado. Assinale a alternativa correta. a) Somente as afirmativas I e III esto corretas. b) Somente as afirmativas III e IV esto corretas.
Prof. Victor Dalton
25 de 48
c) Somente as afirmativas I e II esto corretas. d) Somente as afirmativas I, II e IV esto corretas. e) Somente as afirmativas II, III e IV esto corretas.
Vamos conversar um pouco sobre teste de software. Teste de software uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construdo. Pode ser planejado antecipadamente e conduzido sistematicamente. Ainda, podem ser testes de baixo nvel, no qual so verificados se pequenos segmentos de cdigo-fonte foram corretamente implementados, bem como testes de alto nvel, que validam as principais funes do sistema com base nos requisitos do cliente. O teste de software um elemento de um aspecto mais amplo, que frequentemente referido como Verificao e Validao (V&V). Verificao se refere ao conjunto de atividades que garante que o software implementa corretamente uma funo especfica (estamos construindo o produto corretamente?), enquanto a Validao se certifica que o software construdo corresponde aos requisitos do cliente (estamos construindo o produto certo?). A partir de agora, vamos utilizar as alternativas e as questes seguintes para mergulharmos naquilo que for mais importante dentro deste assunto. I. Teste funcional um outro nome o teste caixa preta. Sua descrio combina com aquilo que, intuitivamente, vem sua cabea: um este que se preocupa apenas em saber se o programa funciona. Aplica-se uma entrada e verifica-se se a sada a esperada. Falaremos mais dele adiante. Certa; II. A tcnica estrutural um outro nome para o teste caixa branca. Nele, alm do resultado, preocupa-se com o caminho percorrido ao longo do programa, e com quais partes foram executadas. Tambm ser discutido mais adiante. Correta; III. Pgina 289 da nossa fonte, copiada e modificada. Retire o no da frase, troque porm por e e ela fica correta. Errada; IV. Os testes, quando realizados de forma automatizada, so coordenados por esse mdulo chamado de mdulo driver; sua tarefa exatamente a descrita no item. Uma vez inicializadas as variveis globais e chamados os parmetros do mdulo que ser testado, ser possvel verificar se o mdulo est funcionando corretamente, ou seja, se a sada do mdulo a esperada, com base nos parmetros utilizados. Certa; Portanto, nossa alternativa correta a letra d).
Prof. Victor Dalton
26 de 48
21 Questo) (UEL Analista de Informtica Jnior Desenvolvimento de Sistemas - 2009) O mtodo de teste, que tem por finalidade determinar se os requisitos dos usurios foram total ou parcialmente satisfeitos pelo produto, preocupando-se tambm em verificar como ocorre o processamento, ou seja, preocupando-se com o caminho percorrido pelo dado de entrada, conhecido como: a) Caixa preta. b) Teste de domnio. c) Caixa branca. d) Teste de Stress. e) Teste de Atividade. Na questo anterior j frisamos a definio de testes. Agora, veremos algumas das tcnicas de testes mais comuns e as fases em que eles podem ser empregados. Tcnicas de teste Caixa-Branca - Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixa-branca avalia o comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados. Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnologia que determinarem a construo do componente de software, cabendo portanto avaliao de mais aspectos que os citados anteriormente. O testador tem acesso ao cdigo fonte da aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e componentes. Este tipo de teste desenvolvido analisando o cdigo fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variaes relevantes originadas por estruturas de condies so testadas. Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para desenvolvimento de classes de teste para testar classes ou mtodos desenvolvidos em Java. Tambm se enquadram nessa tcnica testes manuais ou testes efetuados com apoio de ferramentas para verificao de aderncia a boas prticas de codificao reconhecidas pelo mercado de software. A aderncia a padres e boas prticas visa principalmente a diminuio da possibilidade de erros de codificao e a busca de utilizao de comandos que gerem o melhor desempenho de execuo possvel. Apesar de muitos desenvolvedores alegarem que no h ganhos perceptveis com essa tcnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhes de vezes em intervalos de tempo pequenos. na realidade de produo que a soma dos aparentes pequenos tempos de execuo e consumo de memria de cada programa poder levar o software a deixar de atender aos objetivos esperados. A tcnica de teste
Prof. Victor Dalton
27 de 48
de caixa-branca recomendada para as fases de teste de unidade e teste de integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o cdigo fonte produzido. Caixa-Preta - Tambm chamada de teste funcional, orientado a dado ou orientado a entrada e sada, a tcnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Como detalhes de implementao no so considerados, os casos de teste so todos derivados da especificao. Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas as entradas possveis seriam testadas, mas na ampla maioria dos casos isso impossvel. Outro problema que a especificao pode estar ambgua em relao ao sistema produzido, e como resultado as entradas especificadas podem no ser as mesmas aceitas para o teste. Uma abordagem 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 possveis que so 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 possveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificao do sistema, podese encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propsito do sistema, mas casos possveis incluem inteiros pares, inteiros mpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro. Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de integrao, teste de sistema e teste de aceitao. A aplicao de tcnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situaes de teste). A aplicao combinada de outra tcnica tcnica de particionamento de equivalncia (ou uso de classes de equivalncia) permite avaliar se a quantidade de casos de teste produzida coerente. A partir das classes de equivalncia identificadas, o testador construir casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um nmero mnimo de casos de teste permita a maior cobertura de teste possvel. Uma abordagem no desenvolvimento do teste de caixa-preta o teste baseado na especificao, de forma que as funcionalidades so testadas de acordo com os requisitos. Apesar de necessrio, esse tipo de teste insuficiente para identificar certos riscos num projeto de software. Regresso - Essa uma tcnica de teste aplicvel a uma nova verso de software ou necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou
Prof. Victor Dalton
28 de 48
ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas de teste de acordo com o impacto de alteraes provocado pela nova verso ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, recomendada a utilizao de ferramentas de automao de teste, de forma que, sobre a nova verso ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.
Tcnicas nofuncionais - Outras tcnicas de teste existem para testar aspectos no-funcionais do software, como por exemplo, a adequao a restries de negcio, adequao a normas, ou restries tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que verificam a produo pelo sistema de respostas adequadas de suas operaes, de acordo com uma especificao, as tcnicas no funcionais verificam atributos de um componente ou sistema que no se relacionam com a funcionalidade (por exemplo, confiabilidade, eficincia, usabilidade, manutenibilidade e portabilidade). 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 especificaes de tempo de processamento exigidas, o que determina a escalabilidade do software. O teste de usabilidade necessrio para verificar se a interface de usurio fcil de se aprender e utilizar. Entre verificaes cabveis esto a relao da interface com conhecimento do usurio, 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 recuperao usado para verificar a robustez do software em retornar a um estado estvel de execuo aps estar em um estado de falha. Teste de Domnio - Pode ser aplicado em um campo, uma assinatura, um I/O, ou qualquer tipo de local que receba valores externos ao sistema. Todo domnio deve realizar consistncias de dados validos e invlidos. Um domnio s permite dados com a formatao igual ao que ser armazenado. Ex.: Campo DDD dever permitir nmeros de at quatro casas no negativas ou a base de dados deve impedir a entrada de valores invlidos. Uma tcnica de teste comumente empregada em testes de domnio a Anlise do Valor Limite na qual so testados valores nas fronteiras de um domnio. Por exemplo: se determinado campo s permite o preenchimento com nmeros de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101.
Fases (Tipos de Teste) Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais diferente da implementao. Essa prtica pode resultar na fase de
Prof. Victor Dalton
29 de 48
teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prtica comear o teste no mesmo momento que o projeto, num processo contnuo at o fim do projeto. Em contrapartida, algumas prticas emergentes como a programao extrema e o desenvolvimento gil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade so escritos primeiro ( TDD ), por engenheiros de software. Antes da implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando incrementalmente em pores maiores dos casos de teste. Os testes so mantidos junto com o resto do cdigo fonte do software, e geralmente tambm integra o processo de construo do software.
Teste de unidade - Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema). O universo alvo desse tipo de teste so as subrotinas ou mesmo pequenos trechos de cdigo. Assim, o objetivo o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo. Teste de integrao - Na fase de teste de integrao, o objetivo encontrar falhas provenientes da integrao interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas so de transmisso de dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um mtodo do componente B; porm, B pode retornar um valor Y, gerando uma falha. No faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integrao entre sistemas). Essas interfaces so testadas na fase de teste de sistema, apesar de, a critrio do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construdo. Teste de sistema - Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em busca de falhas em relao aos objetivos originais. Os testes so executados em condies similares de ambiente, interfaces sistmicas e massas de dados quelas que um usurio utilizar no seu dia-a-dia de manipulao do sistema. De acordo com a poltica de uma organizao, podem ser utilizadas condies reais de ambiente, interfaces sistmicas e massas de dados. Teste de aceitao - Geralmente, os testes de aceitao so realizados por um grupo restrito de usurios finais do sistema, que simulam operaes 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 no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou no o sistema. Validao de um software pelo comprador, pelo usurio ou por terceira parte, com o uso de dados ou cenrios especificados ou reais. Pode
Prof. Victor Dalton
30 de 48
incluir testes funcionais, de configurao, de recuperao de falhas, de segurana e de desempenho.
Teste de operao - 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 aplicvel somente a sistemas de informao prprios de uma organizao, cujo acesso pode ser feito interna ou externamente a essa organizao. Nessa fase de teste devem ser feitas simulaes para garantir que a entrada em produo do sistema ser bem sucedida. Envolve testes de instalao, simulaes com cpia de segurana dos bancos de dados, etc.. Em alguns casos um sistema entrar em produo para substituir outro e necessrio garantir que o novo sistema continuar garantindo o suporte ao negcio. Destaco que as tcnicas de testes e as fases so pontos de vista distintos para se observar um determinado teste. Por exemplo, uma inspeo detalhada na execuo de um cdigo especfico pode ser um teste caixa-branca e um teste de unidade. Assim como um teste de Stress, no ambiente final do sistema, tambm pode ser um teste de operao. Compreendido? Voltemos questo, nossa alternativa correta a letra c).
22 Questo) (UEL Secretaria do Estado da Administrao e da Previdncia Analista de Sistemas - 2009) Sobre teste de software, considere as afirmativas a seguir: I. A Atividade de teste de software um elemento crtico da garantia de qualidade de software e representa a ltima reviso de especificao, projeto e codificao. O objetivo principal do projeto de casos de teste originar um conjunto de testes que tenha a maior probabilidade de detectar erros no software. II. O teste de caixa preta usa a estrutura de controle do projeto procedimental para derivar casos de teste. O engenheiro de software pode derivar os casos de teste que: garantem que todos os caminhos independentes dentro de um mdulo tenham sido exercitados pelo menos uma vez; exercitem todas as decises lgicas para valores falsos ou verdadeiros; executem todos os laos em suas fronteiras e dentro de seus limites operacionais; e exercitem as estruturas de dados internas para garantir a sua validade. III. Os mtodos de caixa branca concentram-se nos requisitos funcionais do software. O teste de caixa preta procura descobrir erros nas seguintes categorias: funes incorretas ou ausentes; erros de interface; erros nas
Prof. Victor Dalton
31 de 48
estruturas de dados ou no acesso a bancos de dados externos; erros de desempenho e erros de inicializao e trmino. IV. O teste de caminho bsico uma tcnica de caixa branca e possibilita que o projetista do caso de teste derive uma medida da complexidade lgica de um projeto procedimental e use essa medida como guia para definir um conjunto bsico de caminhos de execuo. Assinale a alternativa correta. a) Somente as afirmativas I e III esto corretas. b) Somente as afirmativas I e IV esto corretas. c) Somente as afirmativas II e IV esto corretas. d) Somente as afirmativas I, II e III esto corretas. e) Somente as afirmativas II, III e IV esto corretas.
Depois de uma dose terica na questo anterior, podemos analisar diretamente os itens desta. I. Este item est correto. Interessante deixar essa ideia bem frisada: o objetivo dos testes fazer o programa falhar! Fazer o programa funcionar o objetivo de quem desenvolve. O testador um sabotador, no bom sentido, que busca sempre fazer com que o programa falhe. por isso que os testes sempre procuram ser os mais maldosos possvel; II.Descrio do teste caixa-branca, ou , mais especificamente, do teste de caminho, que uma variao do teste caixa branca.. Errado; III. Essa descrio plenamente do teste caixa preta, estando errada apenas a primeira frase. Errada; IV. Outra definio para o teste de caminho, desta vez correta. Desta forma, nossa alternativa correta a letra b). 23 Questo) (UEL POSCOMP 2011) Tendo em vista a complexidade envolvida no desenvolvimento de um sistema de software, importante assegurar que ele cumpra com suas especificaes e atenda s necessidades dos usurios. Sobre o desenvolvimento de software, considere as afirmativas a seguir. I. A Validao tem como objetivo responder. Estamos construindo o produto certo? J a Verificao busca responder: Estamos construindo o produto corretamente? II. Em um cadastro, encontra-se um campo de entrada solicitando o ano de nascimento, sendo vlidos valores entre 1900 e 2011. Os casos de teste para este campo, considerando a tcnica de anlise de valor limite, so: 1899,1900,1901,2010,2011,2012 e 0.
Prof. Victor Dalton
32 de 48
III. As atividades de Verificao e Validao envolvem atividades de anlise esttica e de anlise dinmica do produto em desenvolvimento, e apenas as atividades de anlise dinmica envolvem a execuo do produto. IV. Um dos objetivos dos mtodos de teste de caixa preta garantir que todos os caminhos de um programa tenham sido exercitados pelo menos uma vez, podendo-se aplicar a tcnica do teste do caminha bsico para este fim. Assinale a alternativa correta. a) Somente as afirmativas I e II esto corretas. b) Somente as afirmativas I e III esto corretas. c) Somente as afirmativas III e IV esto corretas. d) Somente as afirmativas I, II e IV esto corretas. e) Somente as afirmativas II, III e IV esto corretas. Uma questo mais abrangente sobre testes, cujo conhecimento voc j possui para responder. Revisando: I. Certa. Esta diferena dentre Verificao e Validao estendida a todos os ramos da TI, ento assimile-a bem; II. Na anlise 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. Anlise esttica envolve apenas a anlise de cdigos e modelos, enquanto a dinmica compreende a anlise do programa em execuo; IV. Teste de caminho! Errada. Portanto, a alternativa correta a letra b). 24 Questo) (Formulao pessoal) Segundo Pressmann, cada um dos elementos de informao que so criados durante o desenvolvimento de um produto de software, que so identificados de maneira nica e cuja evoluo passvel de rastreamento, refere-se a a) Item de software b) Componente de software c) Item de configurao d) Componente de dados e) Componente de programa Vamos falar um pouco sobre Gerncia de Configurao. Gerncia de Configurao Durante seu ciclo de vida, o software passa por uma srie de modificaes, desde sua concepo implantao.
Prof. Victor Dalton
33 de 48
Sob este aspecto, a Gerncia de Configurao de Software (CGS) vem a definir critrios que permitam realizar tais modificaes mantendo-se a consistncia e a integridade do software com as especificaes. Ela permite minimizar os problemas decorrentes ao processo de desenvolvimento, atravs de um controle sistemtico sobre as modificaes. No objetivo da GCS evitar modificaes, mas permitir que elas ocorram sempre que possvel, 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, constitudas por objetivos bem definidos e documentados. Neste contexto, GCS atua como um suporte sobre o qual as fases do desenvolvimento so conduzidas e os produtos controlados. Aplicar um plano de gerncia de configurao consiste em estabelecer normas, ferramentas e templates que permitam gerenciar de maneira satisfatria os itens de configurao de um sistema. Entende-se como item de configurao Cada um dos elementos de informao que so criados durante o desenvolvimento de um produto de software, ou que para este desenvolvimento sejam necessrios, que so identificados de maneira nica e cuja evoluo passvel de rastreamento (Pressman). Itens de configurao podem ser: Servidores Estaes de trabalho dos usurios Banco de dados Plano de negcio Acordos com clientes Softwares Manuais de instruo Outros, desde que sejam itens correlatos ao software entregue Se o item de configurao for composto exclusivamente de software, ele ento caracterizado como Item de Configurao de Software (ICSW). Qualquer IC constitui uma unidade funcional que possui um ciclo de desenvolvimento e acompanhamento de GCS prprios. Qualquer sistema em desenvolvimento deve ser particionado em itens de configurao, 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 no particionveis, que so desenvolvidos segundo um ciclo de vida propriamente definido. A configurao de um sistema de software passa a ser definida pela configurao do conjunto dos ICSW que o constitui. importante salientar que a diviso de um sistema ou produto de software em ICs, bem como a definio do ciclo de vida de cada IC, so decises de projeto e no de GCS. Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configurao deve ser estabelecido. Tal conjunto representa um
Prof. Victor Dalton
34 de 48
estgio do desenvolvimento, o qual passvel de modificaes apenas mediante um mecanismo formal de alteraes. A este conjunto dado o nome de Baselines, ou Configuraes Base do sistema. Em princpio, 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 configuraes base pode, ento, ser resumido nos seguintes pontos: Caracterizao 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. Definio do conjunto de baselines. Para cada baseline planejada, deve-se estabelecer quais sero os ICs que a iro compor e quais as condies 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 modificao de uma configurao-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; O estabelecimento de cada baseline somente realizado aps ser aprovada por procedimentos de consistncia interna, verificao e validao; Desta forma possvel ter um controle sistemtico sobre todos os itens de configurao abordados em cada fase do ciclo de vida do software, assim como possvel avaliar mais facilmente o seu grau de evoluo.
O Gerenciamento de Configurao e o Gerenciamento de Mudanas pode ser visto com mais detalhes no ITIL. Entretanto, por ter sido citado em Engenharia de Software, tambm estamos vendo-o aqui. Resposta certa, letra c).
25 Questo) (Formulao Pessoal) Procedimentos de gerenciamento de mudana dizem respeito anlise de custo e benefcio das mudanas propostas, aprovao das mudanas viveis e rastreabilidade de quais componentes do
Prof. Victor Dalton
35 de 48
sistema foram alterados. O processo de gerenciamento de mudana deve surtir efeito quando o software ou a documentao associada so colocados em baseline pela equipe de gerenciamento de configuraes. O primeiro estgio para a solicitao de uma mudana para o sistema a) Modificar o item de configurao envolvido e notificar equipe de gerenciamento de mudana b) Preencher uma Requisio de Mudana, ou Formulrio de Solicitao de Mudana, e encaminhar ao Comit de Controle de Mudanas c) Modificar o item de configurao envolvido e preencher o formulrio para envio ao Comit de Controle de Mudanas d) Notificar o Gerenciamento de Problema que deseja fazer uma mudana no sistema e) Aguardar uma falha no sistema para preencher uma Requisio de Mudana
A ITIL define que o Gerenciamento de Mudanas e o Gerenciamento de Configurao so processos distintos. Entretanto, reconhece-se que, principalmente em pequenas organizaes, estes processos podem ser executados pelas mesmas pessoas. No confunda pessoas com papis, nem papis com processos; uma pessoa pode exercer vrios papeis (como Gerente de Mudana e Gerente de Configurao). Entretanto, os processos continuam sendo distintos. Mudanas so um fato da vida para sistemas de software. Nesse contexto, o Gerenciamento de Mudana tem por objetivo assegurar que as mudanas sejam feitas de uma forma controlada, e sejam avaliadas, priorizadas, planejadas, testadas, implantadas e documentadas. O primeiro estgio no processo de gerenciamento de mudanas completar um formulrio de solicitao de mudana (destaco que este formulrio ser um item de configurao!), que descreva a mudana necessria para o sistema. Ao longo do processo, este formulrio registrar as recomendaes para a mudana, os custos estimados e as datas de quando ela foi solicitada, aprovada, implementada e validada, bem como seu nvel de prioridade. O Comit de Controle de Mudanas um grupo importante que toma as decises de mudana. Apesar do nome pomposo, em pequenos e mdios projetos, o CCM pode ser apenas o gerente de projeto e um ou dois engenheiros. Em condies ideais, o CCM uma equipe exclusiva, e que conta com representantes do negcio. Naturalmente, caber ao CCM analisar quais so as mudanas dentro de seu nvel de autorizao, e quais mudanas exigem cincia ou autorizao de outros stakeholders. Logo, nossa resposta certa a letra b).
26 Questo) (Formulao Pessoal) Mudanas, analise as afirmativas abaixo:

Prof. Victor Dalton
Sobre o Gerenciamento de
36 de 48
I. As mudanas em um sistema podem ser levantadas proativamente, para resolver erros ou adaptar-se a circunstncias de mudana, ou reativamente, para gerar benefcios ao negcio, como reduzir custos e melhorar os servios. II. Gerenciar mudanas no fazer mudanas que no ofeream risco: fazer mudanas de forma que os riscos sejam mapeados e gerenciados. III. Mudanas de alto custo e mudanas de risco so mudanas tpicas cuja autoridade de mudana a gerncia de TI. IV. Mudanas urgentes sempre devem passar pela autoridade do negcio. Assinale a alternativa correta. a) Somente a afirmativa II est correta. b) Somente as afirmativas II e III esto corretas. c) Somente as afirmativas II e IV esto corretas. d) Somente as afirmativas I, II e IV esto corretas. e) Somente as afirmativas II, III e IV esto corretas. Vamos utilizar estas afirmativas para captar mais algumas ideias acerca do Gerenciamento de Mudana: I. Proativamente e reativamente esto trocadas na afirmativa. Errada; II. Correta; III. Naturalmente, para cada nvel de importncia da mudana existem autoridades que podem autorizar a mudana ou no. Mudanas de alto custo e mudanas de risco so mudanas que exigem que o Comit Executivo de Negcio autorize, enquanto mudanas de menor relevncia podem ficar a cargo do prprio CCM. Destaco que a presidncia do CCM, apesar de poder conter representantes de negcio, sempre do Gerente de Mudana, que algum da TI. Errada; IV. Mudanas urgentes no devem ser confundidas com mudanas 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. No preciso uma autoridade de negcio para toda mudana urgente. Errada; P.S.: Destaco ainda que existe o Comit de Controle de Mudanas Emergencial, ou Comit Consultivo de Mudanas Emergencial (CCME), que uma verso reduzida do CCM, que pode ser reunido quando da necessidade de uma mudana urgente. Voltando s alternativas, nossa resposta certa a letra a).
27 Questo) (Formulao Pessoal) responsabilidade da Gerncia de Configurao:
Prof. Victor Dalton
37 de 48
I. Definir e controlar os componentes de servios e infraestrutura do sistema, mantendo informaes precisas sobre os estados dos servios e infraestrutura atual e planejada. II. Manter um banco de dados de configurao (Configuration Management Data Base) com todas as informaes relevantes sobre as configuraes do sistema e os itens de configurao. III. Avaliar o impacto de uma mudana no sistema. a) Somente as afirmativas I e II esto corretas. b) Somente as afirmativas I e III esto corretas. c) Somente as afirmativas II e III esto corretas. d) Todas as afirmativas esto corretas. e) Apenas a afirmativa II est correta.
Quero chamar a sua ateno para uma pegadinha que as bancas gostam de armar para seus candidatos, que confundir as atribuies da Gerncia de Configurao e a Gerncia de Mudana. Os itens I e II so de responsabilidade da Gerncia de Configurao. O item III, entretanto, responsabilidade do Gerenciamento de Mudana! Apesar do estreito relacionamento entre esses processos ( natural que a equipe de mudana consulte a equipe de configurao para avaliar os itens de configurao que sero afetados), no ser a Gerncia de Configurao que avaliar o impacto de uma mudana, seno o prprio Gerenciamento de Mudana. Porm, no ato da implantao da mudana, a Gerncia de Configurao rastrear os itens modificados, para manter o banco de dados de configurao atualizado. Estamos entendidos? Alternativa c).
28 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao 2005 - adaptada) A Anlise de Pontos de Funo quantifica a funcionalidade do sistema sob o ponto de vista do usurio e a) oferece uma medida da quantidade de linhas de cdigo do software ou sistema solicitado. b) por isso, uma contagem de pontos de funo deve ser realizada utilizando uma terminologia exclusiva para o usurio, o que significa dizer que os requisitos devem estar definidos em uma linguagem que represente de forma nica o entendimento dos stakeholders do projeto. c) utiliza os requisitos no-funcionais como a base para o clculo dos pontos de funo no ajustados e alguns requisitos funcionais so integrantes
Prof. Victor Dalton
38 de 48
das Caractersticas Gerais de Sistema utilizadas na fase de determinao do fator de ajuste utilizado no clculo do nmero de pontos de funo ajustados. d) mede o tamanho funcional do software. Este tamanho, em conjunto com outras variveis, pode ser usado para estimar esforo, prazo e custo, no sendo a APF a responsvel direta por estes parmetros. e) fornece um valor que especifica a quantidade de funes e procedimentos e, em alguns casos como o desenvolvimento orientado a objetos, mtodos e classes que sero implementados no cdigo do software ou sistema solicitado. A partir deste ponto, temos as mesmas questes de APF que voc viu em sua aula demonstrativa. Se voc j estiver confiante no assunto, pule para as questes 32 e 33 da aula, onde eu apresento questes bnus sobre o assunto. Vale a pena v-las!
Anlise de Pontos de Funo uma tcnica de medio das funcionalidades fornecidas por um software do ponto de vista do usurio. Por buscar independncia da tecnologia utilizada para a construo do software, a APF independe da linguagem de programao utilizada. Portanto, o processo de medio, ou a contagem dos pontos de funo, baseada em uma avaliao padronizada dos requisitos lgicos do uaurio. Ressalta-se que pontos de funo no medem diretamente esforo, produtividade ou custo. exclusivamente uma medida de tamanho funcional do software. Este tamanho, em conjunto com outras variveis, que poder ser usado para derivar produtividade, estimar esforo e custo. Portanto, nossa resposta correta a letra d). Acho importante este entendimento. A APF no calcula esforo, produtividade e custos, mas o valor dos pontos de funo calculados so utilizados pela desenvolvedora do software em questo para estimar estas variveis, com base na sua equipe disponvel, tecnologias, etc.
29 Questo) (ESAF Ministrio do Planejamento Analista de Sistemas 2006) Na utilizao das tcnicas de Anlise de Pontos de Funo para mtricas de software, as funes do tipo dados so classificadas em a) ALI (Arquivo Lgico Interno) e AIE (Arquivo de Interface Externa). A principal inteno do ALI armazenar dados mantidos atravs de uma ou mais transaes da aplicao sendo contada, como, por exemplo, tabelas de banco de dados atualizadas pela aplicao. b) EE (Entrada Externa) e AIE (Arquivo de Interface Externa). A principal inteno do EE armazenar dados mantidos atravs de uma ou mais transaes da aplicao sendo contada, como, por exemplo, tabelas de banco de dados atualizadas pela aplicao.
Prof. Victor Dalton
39 de 48
c) EE (Entrada Externa), SE (Sada Externa) e CE (Consulta Externa). A principal inteno do CE armazenar dados mantidos atravs de uma ou mais transaes da aplicao sendo contada, como, por exemplo, tabelas de banco de dados consultadas pela aplicao. d) ALI (Arquivo Lgico Interno), AIE (Arquivo de Interface Externa), EE (Entrada Externa), SE (Sada Externa) e CE (Consulta Externa). A principal inteno de todas essas funes armazenar dados mantidos atravs de uma ou mais transaes da aplicao sendo contada, como, por exemplo, manuteno, pela aplicao, de tabelas de banco. e) AIE (Arquivo de Interface Externa), SE (Sada Externa) e CE (Consulta Externa). A principal inteno de todas essas funes apresentar informaes aos usurios por meio de simples recuperao de dados. Vejamos estes conceitos: Arquivo lgico interno (ALI) grupo de dados ou informao de controle logicamente relacionados, reconhecido pelo usurio, mantido dentro da fronteira de aplicao. um grupo de dados lgico, podendo ser tanto um arquivo como uma parte de um banco de dados maior. Exemplos: cadastros, dados de segurana, dados de auditoria e dados que sofrem manuteno da aplicao, mesmo que sejam acessados por outra. Tambm so ALIs os dados de mensagens de auxlio e mensagens de erros. Ateno: ndices alternativos para recuperao de informao e dados temporrios no so ALI! Arquivo de interface externa (AIE) tambm um arquivo lgico, s que est fora da fronteira da aplicao, sendo, portanto, um ALI de um outro aplicativo. No sofrem manuteno pela aplicao. Exemplos: dados de referncia, mensagens de auxlio, mensagens de erro. Sada externa (SE) processo lgico do negcio que gera dados para um usurio ou para outro aplicativo externo ao software. s vezes fcil confundir com as consultas externas, ento importante ressaltar que para ser considerado SE, deve haver clculo. Exemplos: telas e relatrios, como os que mostram uma nota fiscal, calculando o subtotal por item e o total geral da compra. Repare tambm que os dados que so formatados e processados para uso por outra aplicao tambm so sadas externas. Entrada externa (EE) so os dados que entram no sistema e so usados para incluir, alterar ou excluir dados nos arquivos lgicos internos (ALI). Cada adio, alterao ou remoo contada como uma entrada externa. Tambm o cada formato de tela de entrada de dados. Importante: dados utilizados pela aplicao, mas que no atualizam dados nos ALIs no so entradas externas. Isto parece simples, mas s vezes confunde telas de logon e de menu, por exemplo, no so EE, a no ser que alimentem logs de segurana. Consulta externa (CE) um par pergunta-resposta, cuja pergunta vem de um usurio ou de outro aplicativo. Os dados so recuperados para atender solicitao e ento so enviados para fora. Uma consulta definida como uma entrada que resulta na gerao de alguma resposta imediata. So consultas
Prof. Victor Dalton
40 de 48
externas as consultas simples, realizadas no banco de dados, sem modific-lo, e mostradas na tela. As telas de ajuda so exemplos. Diferencia-se da Sada Externa por no envolver lgica em seu processamento.
ALI e AIE so agrupados como sendo funes de dados, enquanto EE, SE e CE so funes do tipo transao. A cobrana em torno destes cinco elementos comum. Nossa resposta correta, alternativa a).
30 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas da Informao - 2012) Cada Arquivo Lgico Interno e cada Arquivo de Interface Externa devem ser classificados com relao sua complexidade funcional com base em: a) Nmero de Tipos de Dados, Nmero de Tipos de Registros. b) Nmero de Tipos de Arquivos, Nmero de Tipos de Registros. c) Nmero de Tipos de Dados, Nmero de Tipos de Consultas. d) Nmero de Tipos de Campos, Nmero de Tipos de Arquivos. e) Nmero de Tipos de Tabelas, Nmero de Tipos de Campos. O clculo da complexidade funcional uma etapa necessria para a determinao do nmero de pontos de funo. Mais algumas tabelinhas para a compreenso do clculo da complexidade:
Prof. Victor Dalton
41 de 48
Nas funes do tipo dados, o n de itens de dados e o n de arquivos referenciados determina o nvel de complexidade, enquanto nas funes do tipo transao o n de itens de dados e o n de arquivos referenciados so os itens utilizados. Posteriormente, estes pontos so computados em uma tabela, como a que segue:
Prof. Victor Dalton
42 de 48
Os valores obtidos nesta tabela, na sequncia, sero utilizados nas frmulas mostradas na prxima questo.
Quanto a esta questo, estamos entendidos? A bibliografia fala em nmero de Itens de Dados, mas a ESAF teimou em nmero de Tipos de Dados, e no aceitou recurso. Fazer o qu? Adivinha? Danar conforme a msica... alternativa a).
31 Questo) (ESAF Comisso de Valores Mobilirios Analista de Sistemas 2010) O clculo dos pontos de funo de um projeto de desenvolvimento consiste dos componentes de funcionalidade: a) reusabilidade de aplicao; reusabilidade de converso; fator de ajuste da aplicao. b) funcionalidade de aplicao; funcionalidade de compresso; fator de ponderao da aplicao. c) reusabilidade de aplicao; funcionalidade de programao; fator de ajuste da aplicao. d) funcionalidade de aplicao; funcionalidade de converso; fator de ajuste da aplicao. e) funcionalidade de programao; funcionalidade de converso; funcionalidade de manuteno. A APF, via de regra, possuir metodologias de clculo distintas para duas situaes: ou desenvolvimento de um software novo, ou melhoria de um software (manuteno e/ou evoluo). Utilizando as frmulas do IFPUG, que so as mais simples, temos que: Frmula do Projeto de Desenvolvimento: DFP = (UFP + CFP)x VAF Em que DFP o nmero total dos pontos de funo de um projeto de desenvolvimento, UFP o nmero de pontos de funo da aplicao, no ajustados, CFP o nmero de pontos de pontos de funo no ajustados das funes de converso, e VAF o valor do fator de ajuste. Frmula do Projeto de Melhoria: EFP = [(ADD + CHGA + CFP)x VAFA] + (DEL x VAFB)] Em que EFP o nmero total dos pontos de funo de um projeto de melhoria,
Prof. Victor Dalton
43 de 48
ADD o nmero de pontos de funo da aplicao, no ajustados, das funes includas no projeto de melhoria, CHGA o nmero de pontos de funo da aplicao, no ajustados, das funes modificadas no projeto de melhoria, CFP o nmero de pontos de pontos de funo no ajustados das funes de converso, VAFA o valor do fator de ajuste depois da aplicao do projeto de melhoria, DEL o o nmero de pontos de funo da aplicao, no ajustados, das funes excludas no projeto de melhoria, e VAFB o valor do fator de ajuste antes da aplicao do projeto de melhoria. As frmulas fazem bastante sentido, voc percebe o bom senso no estabelecimento dos critrios. Pontos de funo, para quem faz concursos de TI com frequncia, merecem um estudo aprofundado pelo menos uma vez, para depois ser apenas revisado antes de um concurso. Gosto do livro do Adriano Vazquez, Anlise de Pontos de Funo. Ai ai ai, quem me dera ganhar um extra pelo merchan! Voltando questo, e depois de entender as frmulas, d pra eliminar todas as alternativas e ficar com a letra d). Continuemos na prxima pgina!
Prof. Victor Dalton
44 de 48
(FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009) Para responder as questes 32 e 33, considere os dados de referncia para os clculos de pontos de funo.
33 Questo) Durante o levantamento de requisitos de um sistema, foram apuradas as seguintes informaes, base para o clculo de pontos de funo: Complexidade de: Entrada: 2 complexas, 4 mdias e 5 simples. Sada: 10 mdias e 3 simples. Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 mdios. Sem nenhuma influncia, o resultado apurado foi a) 133 b) 138 c) 140 d) 149 e) 161
Prof. Victor Dalton
45 de 48
Uma bela oportunidade de colocar em prtica o conhecimento adquirido nas questes tericas anteriores, no? Neste primeiro momento, no h muitas exigncias. Voc apenas precisa pegar os valores correspondentes s complexidades nas tabelas e multiplicar pelo nmero de ocorrncias. Entrada (EE) = 2x6 + 4x4 +5x3 = 43 Sada (SE) = 10x5 + 3x4 = 62 Arquivo mantido dentro da fronteira do sistema(ALI): 1x15 + 2x10 = 35 Total, 140 pontos de funo, correspondendo letra c).
33 Questo) Mantida a pontuao bruta obtida na questo de nmero 32 e considerando que as influncias por caractersticas gerais do sistema foram estimadas como: Forte em performance; Significante em entrada de dados online e em processamento distribudo; Demais caractersticas sem influncia. O resultado final mais aproximado, aps o ajuste, foi a) 98,0 b) 107,8 c) 110,6 d) 109,2 e) 116,0 Para fazer o clculo do Fator de Ajuste (o VAF das frmulas), voc vai precisar aplicar a frmula VAF = (NI*0,01) + 0,65, mostrada no material que eu te indiquei sobre APF (voc leu?) Caso no tenha lido, ou no se lembre, farei um rpido resumo. Consideram-se 14 itens para o fator de ajuste, fornecidos para voc nos dados da questo. Para cada um destes fatores, existe um nvel de influncia de 0 a 5, tambm fornecidos na questo para voc. Ento, faz-se necessrio somar todos os nveis de influncia dos itens, multiplica-los por 0,01 e soma-los a 0,65. Mas por que isso? O VAF, como voc deve ter percebido nas frmulas de clculo da APF, pode aumentar ou diminuir significativamente o valor dos pontos de funo. Foi estipulada uma margem de 35% para cima ou para baixo, na criao da frmula. Se todas as 14 caractersticas do sistema forem fortemente influentes,
Prof. Victor Dalton
46 de 48
14*5 ser 70 e seu VAF ser de 1,35. Em contrapartida, sendo nenhum item influente, seu VAF ser de 0,65. Conseguiu captar? No um clculo complexo, e em caso de cair na prova, creio eu que todos os dados sero fornecidos a voc, assim como na questo que estamos trabalhando. Aos clculos: 1 influncia forte (5) + 2 influncias significantes (4) + demais sem influncia (0); VAF = (13*0,01) + 0,65 = 0,78. 140 x 0,78 = 109,2. Se voc trouxer o valor incorreto da questo anterior, vai errar aqui tambm. Ateno! Portanto, temos a letra d) como resposta correta.
Prof. Victor Dalton
47 de 48
CONSIDERAES FINAIS
Companheiros,
Encerramos a primeira de quatro aulas de exerccios. Espero, sinceramente, que alm de decorar o que eu estou passando atravs das questes, voc esteja rompendo o hiato entre o vocabulrio que possui e o vocabulrio de TI. Compreender essa nova terminologia facilitar o aprendizado nas prximas aulas. Este, inclusive, um dos motivos pelo qual optei por fazer um curso com um nmero moderado de exerccios e com recomendao de teoria em paralelo. Pra quem no de TI, ler apenas uma apostila seca e 100% orientada a concurso uma tarefa perigosa. Leia a teoria nas fontes recomendadas, que explica as coisas um pouco mais devagar. O risco de branco na hora da prova bem menor. Nossa segunda aula j est no forno. Mantenha a pegada, pois possvel entrar nas 100 vagas. Estude!
Victor Dalton
Prof. Victor Dalton
48 de 48

Aula 01

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Aula 01

Hochgeladen von

Copyright:

Verfügbare Formate

Questes Comentadas de TI para o ICMS-PR Exerccios comentados Prof Victor Dalton Aula 01

AULA 01: Engenharia de Software

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

e) Somente as afirmativas II, III e IV esto corretas.

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

incluir testes funcionais, de configurao, de recuperao de falhas, de segurana e de desempenho.

Prof. Victor Dalton

Prof. Victor Dalton

26 Questo) (Formulao Pessoal) Mudanas, analise as afirmativas abaixo:

27 Questo) (Formulao Pessoal) responsabilidade da Gerncia de Configurao:

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Das könnte Ihnen auch gefallen