Aula 00

Questes Comentadas de TI para o Banco Central do Brasil Exerccios comentados Prof Victor Dalton Aula 00
AULA 00: Engenharia de Software

SUMRIO Apresentao Proposta de Trabalho Cronograma Mural do Aluno Exerccios Consideraes Finais Lista de Exerccios Gabarito PGINA 1 2 3 5 7 72 73 93
Antes de mais nada, peo que voc preste bastante ateno na nossa PROPOSTA DE TRABALHO e nas CONSIDERAES FINAIS, para que voc tenha a exata noo do nosso objetivo, ao realizar este curso em exerccios. Tenho certeza que voc ir se debruar sobre o contedo, mas no deixe de observar estes itens, em especial.
APRESENTAO
Ol a todos! E sejam bem-vindos ao projeto Questes Comentadas de TI para Analista do Banco Central do Brasil (BCB), especialidade Tecnologia da Informao (rea 1). Permitam-me primeiro que eu me apresente. Eu sou Victor Dalton Teles Jesus Barbosa. Minha experincia em concursos comeou aos 15 anos, quando consegui ingressar na Escola Preparatria de Cadetes do Exrcito, em 1999. Cursei a Academia Militar das Agulhas Negras, me tornando Bacharel em Cincias Militares, 1 Colocado em Comunicaes, da turma de 2003. Em 2005, prestei novamente concurso para o Instituto Militar de Engenharia, aprovando em 3 lugar. No final de 2009, me formei em Engenharia da Computao, sendo o 2 lugar da turma no Curso de Graduao. Decidi ento mudar de ares. Em 2010, prestei concursos para Analista do Banco Central (rea 1 Tecnologia da Informao) e Analista de Planejamento e Oramento (Especializao em TI).
Prof. Victor Dalton
www.estrategiaconcursos.com.br
1 de 93
Felizmente, fui aprovado nesses certames, e hoje, aps uma passagem pelo Ministrio do Planejamento, optei por trabalhar no Banco Central do Brasil.
Com esta feliz experincia em concursos pblicos, tive a honra de ser convidado para o Estratgia Concursos. Elaborei o simulado de Auditoria de TI para o concurso da CGU, e, uma vez aprovado, fui intimado a participar de forma mais efetiva. Conheo a equipe do Estratgia, sei da competncia e da capacidade desse pessoal, e estou me esforando para manter o gabarito dos cursos aqui ministrados. J ministrei cursos para os concursos da Receita Federal, ICMS-PR e ICMS-SP, cujo feedback dos alunos tem me impulsionado a continuar cada vez mais a ministrar aulas. Ainda, alguns de vocs j devem saber que recentemente fui aprovado para o cargo de Analista Legislativo da Cmara dos Deputados, aplicado pela banca CESPE. Mudarei de rgo em 2013, mas antes darei o meu melhor para ajudar a trazer voc aqui para o Banco Central. E olha, pode parecer at estranho um marketing de algum que est saindo, mas eu sei que eu no sou o nico a dizer isso: O BCB (agora que vocs esto estudando pra c, saibam que a sigla Bacen morreu, BCB de Banco Central do Brasil) um dos melhores lugares do Executivo Federal para se trabalhar, e me atrevo a dizer que o melhor lugar do pas pra se trabalhar com Tecnologia da Informao, dentro do funcionalismo pblico. Ao longo das aulas eu darei dicas aqui do DEINF, falando um pouco do trabalho do Banco. Aqui as coisas funcionam. Nosso maior problema, adivinhem? Falta de pessoal.
PROPOSTA DE TRABALHO A nossa proposta de trabalho apresentar questes de TI comentadas, com total orientao para o concurso de Analista do Banco Central rea 1. Nosso objetivo, ao trmino desse curso, cobrir toda a matria de Tecnologia da Informao do futuro edital do certame. Pois bem, e como alcanaremos este objetivo? Semanalmente, traremos uma apostila, contendo em torno de 60 exerccios comentados abrangendo uma parcela do provvel edital, trazendo exerccios das principais bancas com especialidade em TI, como ESAF, FCC, CESPE, FGV, Cesgranrio e outras cujo contedo seja relevante. Tambm elaborarei algumas questes, com o objetivo de chamar a ateno do futuro analista do DEINF para alguns tpicos importantes, bem como despertar formas diferentes de enxergar determinado assunto. Tudo isso, claro, com o objetivo de melhor capacit-lo para a prova. Destaco, ainda que meus comentrios trazem considervel embasamento terico, e a maioria das anlises trazem contedo
Prof. Victor Dalton
2 de 93
que vo alm de responder a alternativa certa. Voc pode conferir isto nesta aula demonstrativa.
Das trs ltimas aulas, cujo contedo est em aberto, duas serviro para complementar o edital, depois de sua publicao , e a ltima ser um listo apenas com questes de concursos da banca selecionada para o certame. No total, teremos mais de 600 questes comentadas! Que tal? Ainda, agregarei a este curso outro diferencial: irei divulgar diversas fontes online e livros para que voc possa reforar seus estudos. A Tecnologia da Informao, com certeza, a matria cuja bibliografia ideal para concursos pblicos no consolidada, e, inclusive, motivo de divergncias entre estudiosos do assunto. Por isso, desde o incio do curso, postarei no Mural do Aluno diversos links cujo contedo eu considere relevante, alm de vrias indicaes de livros e comentrios sobre os mesmos (pois os tenho comigo). A web possui muito lixo eletrnico, e at mesmo os mais ntimos do ramo correm o risco de estudarem por fontes inadequadas. Usarei minha experincia e meu conhecimento para direcion-lo pelo caminho certo. De certa forma, estas indicaes funcionaro como uma consultoria. Vamos l? CRONOGRAMA
Nosso cronograma provvel trar os exerccios na seguinte sequncia: Aula 00 (11/12/2012) Engenharia de Software: Conceitos gerais. Ciclo de vida de software. Disciplinas: Requisitos, Anlise, Projeto,Testes e Implementao. Anlise de requisitos funcionais e no-funcionais. Modelagem orientada a objeto. Padres de projetos. Processos de desenvolvimento de software. Processo iterativo e incremental. Qualidade de software: ISO9126, Norma ISO 12207, mtricas. Scrum e Extreme Programming (XP). Teste de software: Conceitos: verificao e validao, tipos de teste (Unidade, Integrao, Sistema/Funcional, Aceitao, Carga, Desempenho, Vulnerabilidade, Usabilidade). Indicadores/mtricas de qualidade dos produtos de software. Aula 01 (21/12/2012) Gesto e Governana de TI: Planejamento Estratgico. Alinhamento entre estratgias de tecnologia da informao e de negcio: conceitos e tcnicas. Gerncia de Projetos: Conceitos Bsicos. Processos do PMBOK. Planejamento e controle de mtricas de projeto. Ferramentas e Tcnicas. Project Office - Escritrio de Projetos. CMMI (verso 1.2): conceitos e formas de representao. Disciplinas e Processos.
Prof. Victor Dalton
3 de 93
Aula 02 (04/01/2013)Gerncia de servios de TI: Fundamentos da ITIL (verso 3). Fundamentos de CobiT (verso 4.1). Service desk. Conhecimentos sobre norma ISO/IEC 20000. MPS/Br. Medio e Estimativas de Software em Pontos de Funo (IFPUB/CPM e NESMA). Papis e prticas do Unified Process.
Aula 03 (11/01/2013) Melhores prticas em polticas de segurana. Norma ISO 27002, blindagem de servidores, gesto de vulnerabilidades. Proteo de estaes de trabalho: Antivrus, firewall pessoal, identificao de cdigos maliciosos (vrus, worms, adware, trojan, spyware) e outras tcnicas como phishing e spam. Algoritmos e protocolos de criptografia: RSA, DES, 3DES, SHA1, AES. Certificao Digital. Infraestrutura de Chaves Pblicas, ICP-Brasil. Ataques em redes e aplicaes corporativas: DDOS, DOS, spoofing, port scan, session hijacking, buffer overflow, SQL Injection, cross-site scripting. Aula 04 (17/01/2013) Tipos e topologias de redes: Redes geograficamente distribudas, redes locais, topologias ponto a ponto e multiponto. Topologias Ethernet: camadas e subcamadas, controles, deteco e correo de erros, protocolos, CSMA/CD. Fast Ethernet. Gigabit ethernet. Comutao (switching). bridges, switches, roteadores, gateways. VLAN (IEEE 802.1Q) Camadas de rede e de transporte: Comutao de pacotes. Protocolos de roteamento: menor caminho; flooding; distance vector; EIGRP, OSPF, BGP, RIP, DVMRP, PIM, VRRP. O protocolo IP: endereamento IP,DHCP. Estabelecimento e liberao de conexo. Controle de fluxo; UDP. Camada de aplicao: DNS, e-mail, HTTP. Qualidade de Servio (QoS). MPLS: Arquitetura. Operao. Redes privadas virtuais (VPN) baseadas em MPLS. Topologias full-meshed e hub-and-spoke. Redes de longa distncia (WAN). VoIP e telefonia IP: conceitos, requisitos para a convergncia de voz e dados. Redes sem fio: Padro IEEE 802.11 Wireless LAN. Gerncia de Rede: conceitos, fundamentos, protocolos, implantao e Protocolo SNMP. Proteo de rede: Firewalls e regras de isolamento e proteo de redes, sistemas de preveno de intruso (IPS), VPN IPSec, autenticao de rede 802.1x. Anlise de protocolos. TCP/IP, HTTP, SMTP, DNS, DHCP, FTP, HTTPS, LDAP, ICAP.
Aula 05 (23/01/2013) Banco de Dados: Fundamentos; organizao de arquivos e mtodos de acesso. Sistemas gerenciadores de banco de dados. Linguagens de definio e manipulao de dados. Controle de proteo, integridade e concorrncia. Banco de dados relacionais distribudos. Projeto de bancos de dados. Backup, recuperao, administrao/configurao, tunning e deteco de problemas em banco de dados. DB2 IBM: fundamentos, administrao e configurao, performance e deteco de problemas. Microsoft SQL Server: fundamentos, administrao e configurao, performance e deteco de problemas. Data Warehouse, OLAP, Data Mining, BI - Business Inteligence. Modelagem Multidimensional. EIS - Enterprise Information System.
Prof. Victor Dalton
4 de 93
Aula 06 (31/01/2013) Fundamentos: lgica de programao; Operadores e expresses, Estruturas de controle, seleo, repetio e desvio. Estruturas de dados; mtodos de ordenao, pesquisa e hashing, estrutura de arquivos; paradigmas de programao; programao orientada a objetos. Programao Java. Anlise e Projeto Orientado a objetos com UML. Arquitetura de software: arquitetura 3 camadas, modelo MVC. Solues de Integrao: Service-Oriented Architecture (SOA) e Web services. Portais Corporativos e Colaborativos: Conceitos bsicos: colaborao, personalizao, gesto do conhecimento, gesto de contedo, taxonomia, single sign-on, integrao de sistemas, funcionalidades de web 2.0, Governana. Noes bsicas dos padres JSR 168 e JSR 286 - Java Specification Request, Portlet Specification. WSRP - Web Services for Remote Portlets. Noes de sistemas de busca e indexao de contedo, noes de anlise das estatsticas de site. Aula 07 (a definir) Ajustes ao edital. Aula 08 (a definir) Ajustes ao edital. Aula 09 (a definir) Listo apenas com questes da banca selecionada para o concurso.
Estas trs ltimas aulas dependem do lanamento do edital, naturalmente, para que o contedo porventura no coberto nas aulas anteriores seja inserido.
MURAL DO ALUNO Observao: O contedo presente neste trecho, a partir das prximas aulas, somente estar presente no Mural do Aluno, e no nas apostilas.
Engenharia de Software um dos ramos da TI cuja bibliografia talvez seja a mais consolidada. Dois so os autores referncia, tanto para aprender Engenharia de Software quanto para concursos: Pressman e Sommerville. Se eu fosse indicar apenas um livro, indicaria Pressman, Engenharia de Software: Uma Abordagem Profissional, atualmente em sua stima edio, no Brasil. Pressman mais adotado para a parte de Modelos de Processo, Qualidade de Software e Teste de Software. J na parte de Engenharia de Requisitos e Mtricas de Software, vejo um meio a meio entre Pressman e Sommerville, Engenharia de Software.
Prof. Victor Dalton
5 de 93
Inclusive, vrias bancas adotam ambas as propostas dos autores, cobrando-as simultaneamente em prova. Portanto, quem puder se dar ao luxo de ter os dois livros, vale a pena adquirir ambos. No livro do Pressman, interessante ler toda a Parte 1, captulos 5 e 6 da Parte 2, captulos 14, 15, 16, 17 e 23 da Parte 3. Existem outros captulos interessantes, que complementam outras matrias de TI. Sero citados em outras aulas. Quem tem o Sommerville deveria ler os captulos 4, 6, 7, 11, 13, 14, 17, 18, 19, 22, 23, 27 e 29. Outros captulos tambm complementam outras matrias. Temos abaixo, um link quebra-galho para ES: http://conhecimentovaleouro.blogspot.com.br/2011/08/engenharia-desoftware-de-roger-s.html Testes de software tambm pode ser visto aqui: http://tcclatex.googlecode.com/svn/trunk/infra/material/10/ES_Rodolfo_VI I_Teste.pdf http://pt.wikipedia.org/wiki/Teste_de_software Para o estudo da UML, eu recomendo o livro Princpios de Anlise e Projeto de Sistemas com UML, do Eduardo Bezerra. um livro bastante completo e fcil de entender. Captulos 1, 2, 4, 5, 7, 8, 9, 10 e 11 so interessantes (praticamente o livro todo). Ainda, achei um trabalho da PUC muito interessante sobre Scrum: ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_07_varaschim.pdf Tambm achei um site interessante sobre entidades UML: http://infocat.ucpel.tche.br/disc/mc/04.pdf Lembro, ainda, que o Mural do Aluno pode ser constantemente atualizado, com novas dicas e informaes, medida que novas boas fontes apaream.
Prof. Victor Dalton
6 de 93
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. 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.
Prof. Victor Dalton
7 de 93
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.
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.
Prof. Victor Dalton
8 de 93
Modelo Incremental
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
Prof. Victor Dalton
9 de 93
Prototipao
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
Prof. Victor Dalton
10 de 93
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, Emprego 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. Logo, meu objetivo lhe preparar da melhor forma para o que pode vir pela frente. 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) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) No modelo de desenvolvimento de software em espiral, cada loop na espiral representa a) a necessidade de retornar ao incio da fase em que se encontra. b) um processo de reengenharia. c) uma disciplina de software. d) uma fase do processo de software. e) uma atividade paralela. Segundo Pressman, o primeiro circuito em volta da espiral pode resultar no desenvolvimento de uma especificao de produto; passagens subsequentes em torno da espiral podem ser usadas para desenvolver um prottipo, e, ento, progressivamente, verses cada vez mais sofisticadas do software. Desse modo, percebemos que a nica alternativa aplicvel a letra d). Veremos, ao longo do curso, que a FCC gosta muito de questes de raciocnio, alternadas com questes de simples definio de conceitos.
5 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte - Analista de Tecnologia da Informao Especialidade
Prof. Victor Dalton
11 de 93
Engenharia de Software/Desenvolvimento de Sistemas - 2010) O modelo em espiral difere principalmente dos outros modelos de processo de software por a) no contemplar o prottipo. b) reconhecer explicitamente o risco. c) no ter fases. d) possuir uma fase nica evolucionria. e) no contemplar o projeto do produto.
Esta questo didtica por mostrar exatamente o ponto comum entre os autores, ao tratarem do modelo em espiral. Lembra que eu expliquei isso questes atrs? Resposta certa, alternativa b).
6 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) O processo de desenvolvimento em cascata um exemplo de processo dirigido a planos, pois, em princpio, necessrio planejar e programar todas as atividades do processo antes de comear a trabalhar nelas. So exemplos de estgios desse modelo: a) Integrao de Produto, Definio de Processo Organizacional e Gerenciamento de Riscos. b) Anlise e Definio de Requisitos, Implementao de Teste Unitrio e Integrao e Teste de Sistema. c) Inicial, Gerenciado e Em Otimizao. d) Engenharia de Requisitos, Ciclo de Vida de Projetos e Gesto de Incidentes. e) Acompanhamento e Controle de Projeto, Medio e Anlise e Desenvolvimento de Requisitos. 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 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.
Prof. Victor Dalton
12 de 93
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 b). P.S.:Apenas para desencargo de conscincia, Pressman, na ltima edio de seu livro, renomeou as etapas do modelo em cascata. Nunca vi cobrana dessa nova nomenclatura em provas, mas segue, de brinde, pra voc.
7 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) A engenharia de software baseada em reuso uma estratgia da engenharia em que o processo de desenvolvimento orientado para o reuso de softwares existentes. Dentre os benefcios do reuso de software, INCORRETO afirmar: a) Preencher uma biblioteca de componentes reusveis e garantir que desenvolvedores de software possam utilizar essa biblioteca so aes no onerosas, pois processos de desenvolvimento no precisam ser adaptados para utilizar essa biblioteca. b) Devido ao custo do software existente j ser conhecido, o risco de processo reduzido. c) Especialistas em aplicaes podem desenvolver softwares reusveis que encapsulem seu conhecimento, tornando seu uso mais eficaz. d) Muitas vezes os custos gerais de desenvolvimento no so to importantes quanto entregar um sistema ao mercado o mais rpido possvel. O reuso de um software pode acelerar a produo do sistema.
Prof. Victor Dalton
13 de 93
e) Alguns padres, como os de interface de usurio, podem ser implementados como um conjunto de componentes reusveis. O uso de interfaces de usurio-padro melhora a confiana, pois os usurios cometem menos erros quando so apresentados a interfaces familiares.
Reuso de software faz parte da Engenharia de Software baseada em componentes. No muito explorada na bibliografia, e as definies contidas entre as alternativas b) e e) so bom subsdio terico. A alternativa a) facilmente detectada como falsa, uma vez que montar uma biblioteca de componentes reusveis para utilizao por parte de desenvolvedores certamente uma tarefa onerosa.
8 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. 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.
Prof. Victor Dalton
14 de 93
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 aplicam-se ao sistema como um todo, e no a caractersticas ou servios individuais do sistema. 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 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 9 e 10, considere:
Prof. Victor Dalton
15 de 93
necessrio que o software calcule os salrios dos diaristas e mensalista s 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. 9 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. 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. 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.
Prof. Victor Dalton
16 de 93
10 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. De cara, a alternativa a) j parece correta. Vejamos as demais. b)apenas requisitos no funcionais; c)um requisito no-funcional e um funcional; d)um requisito funcional e outro no-funcional; e)requisitos no-funcionais. Podemos seguir em frente?
11 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;
Prof. Victor Dalton
17 de 93
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).
12 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. 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. A cobrana em provas acerca de tcnicas de elicitao de requisitos rarssima, apesar de comumente aparecer em editais de concursos. 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).
13 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) Na engenharia de software, etnografia a) uma fase do processo de software aplicada no modelo em cascata. b) uma fase do processo de software aplicada no modelo em espiral. c) uma tcnica de observao que pode ser usada para compreender os requisitos sociais e organizacionais. d) uma tcnica aplicada na engenharia de requisitos cujo objetivo definir, a priori, as classes que contm elementos grficos (BLOB).
Prof. Victor Dalton
18 de 93
e) um projeto cujo principal objetivo criar interfaces grficas, que facilitam o acesso do usurio (GUI). Exemplo tpico da FCC que exige, simplesmente, que voc conhea uma definio. Alternativa c).
14 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. 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
Prof. Victor Dalton
19 de 93
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
20 de 93
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.
Prof. Victor Dalton
21 de 93
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).
15 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: 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).
16 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 da equipe tcnica de desenvolvimento do software trabalham com o cliente e os usurios finais do sistema para descobrir mais informaes sobre o domnio da
Prof. Victor Dalton
22 de 93
aplicao, que servios o sistema deve fornecer, o desempenho exigido do sistema, as restries de hardware, entre outras informaes. 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. e) Somente as afirmativas II, III e IV esto corretas.
Aproveitaremos esta questo da UEL para destrinchar todas as etapas da Engenharia de Requisitos, segundo Pressman. A engenharia de requisitos fornece o mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade, negociando uma 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?
Prof. Victor Dalton
23 de 93
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 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.
Prof. Victor Dalton
24 de 93
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).
17 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, especificao, 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.
A funo : a) Elaborao b) Negociao c) Especificao d) Validao e) Gesto
Prof. Victor Dalton
25 de 93
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).
(CESPE Tribunal de Contas da Unio Auditor Federal de Controle Externo Tecnologia da Informao - 2010) Julgue os itens seguintes, a respeito de engenharia de requisitos. 18 Para o desenvolvimento de casos de uso, fundamental a identificao dos atores, tanto os principais quanto os secundrios, j na primeira iterao do levantamento de requisitos. 19 O checklist de validao uma forma til de averiguar se determinado requisito pode ser testado e, em caso afirmativo, se os testes podem ser especificados. 20 Por se tratar de funo essencial da engenharia de requisitos, a gesto formal de requisitos indispensvel mesmo para projetos de pequeno porte, com apenas duas ou trs dezenas de requisitos identificveis. Comentando: 18 O levantamento de requisitos uma atividade evolutiva,e nem todos os atores precisam ser identificados durante a primeira iterao. possvel identificar atores principais durante a primeira iterao, e os atores secundrios quando se fica sabendo mais a respeito do sistema. Portanto, errada; 19 Sim, estamos falando o checklist de validao da questo da FGV. E ele serva para averiguar se o requisito pode ser testado, e se os testes podem ser especificados. Correta;
Prof. Victor Dalton
26 de 93
20 - A gesto formal de requisitos iniciada somente para grandes projetos com centenas de requisitos identificveis. Para projetos pequenos, essa funo de engenharia de requisitos menos formal. Errada.
(CESPE Ministrio da Educao e Cultura Atividade Tcnica de Complexidade Gerencial Gerente de Projetos - 2011) A engenharia de software busca sistematizar a produo de software com qualidade. No que concerne ao estgio de projeto, julgue os seguintes itens. 21 Para transformar os requisitos em um sistema funcional, os projetistas devem criar um projeto conceitual, que descreva o sistema para o cliente em uma linguagem que este possa entender, para depois transform-lo em um projeto com uma abordagem tcnica para os construtores do sistema. 22 A independncia dos componentes um dos atributos que reflete a qualidade do projeto. O grau de independncia pode ser medido a partir dos conceitos de acoplamento e coeso, os quais, idealmente, devem ser alto e baixo, respectivamente. 23 O projeto de software deve identificar os possveis desvios do comportamento de um sistema. Cada exceo pode ser tratada por meio de um dos seguintes modos: tentar realizar novamente um servio que falhou, corrigir algum aspecto do servio antes de tentar realiz-lo novamente ou relatar o servio no realizado para outro componente de tratamento de erro. Vamos analisar? 21 Perfeito. Dialoga-se com o cliente em uma linguagem e com diagramao de alto nvel, e depois diagramam o projeto com uma abordagem tcnica para os construtores do sistema. Correta; 22 Tudo vai indo bem e de repente.... a pegadinha! A cara do CESPE. O acoplamento, que o grau de dependncia entre os componentes, deve ser baixo, enquanto a coeso, que a medida do quanto uma classe especfica para desempenhar um papel em um contexto, deve ser alta. Errada; 23 Sim, correto. O sistema ideal deve prever tratamentos de excees para os seus servios.
Prof. Victor Dalton
27 de 93
24 Questo) (ESAF Analista de Finanas e Controle Tecnologia da Informao 2003 - adaptada) Analise as seguintes afirmaes relativas Engenharia de Software: I. A anlise de requisitos responsvel pela especificao dos requisitos de software e hardware que sero utilizados durante o processo de desenvolvimento de um sistema. II. A anlise de requisitos define a metodologia de programao a ser utilizada no desenvolvimento do sistema. III. A especificao de requisitos fornece ao desenvolvedor e ao cliente os parmetros para avaliar a qualidade logo que o sistema for construdo. IV. A anlise de requisitos possibilita que o engenheiro de software compreenda o sistema que ir desenvolver. Esto corretos os itens: a) I e II b) II e III c) III e IV d) I e III e) II e IV Utilizo esta questo porque quero chamar a sua ateno para as etapas de Engenharia de Requisitos, segundo Sommerville! Ela tambm pode ser cobrada. Na Especificao do software, tambm chamada de Engenharia de Requisitos, ocorrem quatro etapas(segundo Sommerville): Estudo de viabilidade verifica se as necessidades dos usurios podem ser satisfeitas pelas tecnologias atuais de software/hardware; Elicitao e anlise de requisitos compreenso, por parte dos analistas, dos requisitos do sistema, por meio de discusses com os usurios potenciais e observao de sistemas existentes. Alm disso, ajuda os analistas a compreender o sistema a ser especificado; Especificao de requisitos Traduo das informaes obtidas na anlise em um documento de defina um conjunto de requisitos; Validao de requisitos verificao junto ao cliente da correo e escopo dos requisitos.
Prof. Victor Dalton
28 de 93
Engenharia de Requisitos, segundo Sommerville
Pois , danar conforme a msica. Quando uma questo aparece sobre requisitos, voc precisa identificar se a abordagem utilizada a do Pressman ou a do Sommerville, para poder responder corretamente. Os itens III e IV esto corretos, e nossa resposta certa a alternativa c).
25 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
29 de 93
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, apenas para lembrar, 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 d).
26 Questo)(FCC Tribunal de Contas do Estado do Paran Analista de Controle Informtica - 2011) Mtricas de software podem ser divididas em medidas diretas e indiretas, sob o ponto de vista de medio, e em mtricas de produtividade e de qualidade, sob o ponto de vista de aplicao. Nesse contexto, as mtricas que se concentram na sada do processo de engenharia de software e as mtricas que indicam o quanto o software atende aos requisitos definidos pelo usurio, podem ser classificadas, respectivamente, como mtricas de a) custo e de complexidade, em medidas indiretas. b) esforo e de confiabilidade, em medidas diretas. c) produtividade e de qualidade, em medidas indiretas.
Prof. Victor Dalton
30 de 93
d) qualidade e de eficincia, em medidas diretas. e) velocidade de execuo e tcnica, em medidas diretas.
A medio de software um recurso que tem como objetivo avaliar, de forma automatizada o projeto de software, para poder fazer previses gerais sobre um sistema e/ou identificar componentes anmalos. Para tal, so utilizadas as mtricas de software. As mtricas de produto dividem-se em duas classes: Mtricas estticas ajudam a avaliar a complexidade, a facilidade de compreenso e a facilidade de manuteno de um sistema de software; e Mtricas dinmicas mais relacionadas com a eficincia e a confiabilidade de um programa. Ainda, pode se enxergar a medio pela tica das medidas diretas e indiretas. Medida direta no envolve a medio de outro atributo alm do atributo considerado, como linhas de cdigo, nmero de erros, etc.; e Medida indireta alm do atributo considerado, medidas de outros atributos so levadas em considerao. So exemplos, qualidade, complexidade, eficincia, etc. Tambm podemos dividir as mtricas de software, sob o ponto de vista de aplicao, em duas categorias: mtricas de produtividade e de qualidade. As mtricas de produtividade se concentram na sada do processo de engenharia de software e mtricas de qualidade indicam o quanto o software atende aos requisitos definidos pelo usurio. Diante do exposto acima, percebe-se que a alternativa correta a letra c). P.S.:Caso deseje uma rpida e til sobre medidas de software, veja em http://pt.wikipedia.org/wiki/Mtrica_de_software. Nem tudo que est na Wikipedia lixo, e veremos mais links teis ao longo do curso.
27 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao - 2005)As mtricas de produtos de software dividem-se em classes: mtricas dinmicas coletadas por meio de medies realizadas em um programa em execuo, e mtricas estticas coletadas por meio de medies realizadas em representaes do sistema. Indique a opo que descreve corretamente uma mtrica esttica do produto de software. a) ndice de fog uma medida da complexidade de controle de um programa. b) Complexidade ciclomtica uma medida da extenso mdia das palavras e das sentenas em documentos, ponderada por complexidade.
Prof. Victor Dalton
31 de 93
c) Extenso de identificadores o nmero de mtodos includos em uma classe, relacionada com a facilidade de compreenso do programa. d) Extenso de cdigo uma medida de extenso mdia de um programa e est associada complexidade da lgica de controle do programa. e) Fan-in/Fan-out uma medida do nmero de funes ou mtodos que chamam alguma outra funo ou mtodo.
Esta questo da ESAF excelente, por nos chamar a ateno para 5 mtricas que, no raro, aparecem em provas. Todas as 5 definies de mtricas citadas realmente so de mtricas estticas, mas a questo faz um troca-troca nas descries, para confundir sua cabea. Segue gabarito abaixo: a) ndice de fog uma medida da extenso mdia das palavras e das sentenas em documentos, ponderada por complexidade. b) Complexidade ciclomtica uma medida da complexidade de controle de um programa. c) Extenso de identificadores uma medida da extenso mdia de identificadores distintos em um programa. d) Extenso de cdigo medida do tamanho de um programa. e) Correta.
28 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 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.
Prof. Victor Dalton
32 de 93
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. Esses conceitos so pea-chave da norma ISO 8126, que versa sobre qualidade de software. Em questes nesse estilo, 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. 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.
Prof. Victor Dalton
33 de 93
Manutenibilidade especficas no software.
Evidencia
a facilidade para fazer modificaes
Assimilados os conceitos? Alternativa d).
29 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. 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. 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?).
Prof. Victor Dalton
34 de 93
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. Pressman, copiado e modificado. 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).
30 Questo) (FCC TJ/RJ Analista Judicirio - Analista de Sistemas - 2012) No que se refere a testes de software, correto afirmar que a) o teste de operao a fase onde testada a ergonomia da interface de uso do software. b) o teste da caixa preta (teste funcional), baseia-se em analisar os arquivos de log do sistema procurando por mensagens de funcionamento inconsistente. c) um teste bem sucedido um teste que no encontra nenhum erro no software. d) o teste da caixa branca (teste estrutural), baseia-se em testar as estruturas do cdigo fonte, como comandos condicionais e de repetio. e) um caso de teste uma categoria de possveis resultados na execuo de testes. 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.
Prof. Victor Dalton
35 de 93
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 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
Prof. Victor Dalton
36 de 93
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 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).
Prof. Victor Dalton
37 de 93
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 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
Prof. Victor Dalton
38 de 93
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 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.
Prof. Victor Dalton
39 de 93
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? Voltando questo, nossa alternativa correta a letra d).
31 Questo) )(FCC Tribunal de Contas do Estado do Paran Analista de Controle Informtica - 2011) Segundo Sommerville, aps um sistema ser completamente integrado, possvel testar propriedades como a de desempenho do sistema. Neste contexto, considere: I. Testes de desempenho devem ser produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes geralmente so planejados para que a carga seja continuamente aumentada at que o sistema apresente desempenho fora do aceitvel. II. Os testes de desempenho devem determinar se um sistema corresponde s suas exigncias, sendo que a descoberta de defeitos ou problemas no sistema no enfoque desta etapa. III. Para determinar se o desempenho est sendo atingido, pode ser necessrio a construo de um perfil operacional, que a listagem de todo o grupo de operadores/usurios que faro uso deste sistema. Est correto o que se afirma em a) I, apenas. b) I, II, III. c) III, apenas. d) I e II, apenas. e) II e III, apenas. Apesar de testes de desempenho ser um assunto contemplado pelo Pressman, perceba que a FCC foi no Sommerville pegar a referida definio. Nesse sentido, o item I verdadeiro. Sommerville tambm cita que o teste de desempenho, como qualquer outro teste, tambm pode ser usado para descobrir problemas e defeitos no sistema. Logo, item II falso. Por fim, Sommervile versa o seguinte sobre perfis operacionais:se 90% das transaes de um sistema forem do tipo A, 5% do tipo B e o restante dos tipos C, D e E, voc dever projetar o perfil operacional de modo que a maioria dos testes seja do tipo A. Logo, percebe-se que perfil operacional um conjunto de testes, e no de usurios. Item III errado. Resposta correta, alternativa a).
Prof. Victor Dalton
40 de 93
32 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. 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).
Prof. Victor Dalton
41 de 93
(CESPE MPE/PI Analista Ministerial Informtica - 2012) Acerca de teste de software, julgue os itens seguintes.
33 Os testes de unidade so feitos por equipes especializadas em testes, de forma a se garantir que os mdulos que compem o sistema sob construo estejam funcionando de acordo com as especificaes. 34 Em teste funcional, o conjunto de valores de entrada vlidos pode ser reduzido por meio de partio em classes de equivalncia, o que torna a quantidade de dados de entrada finita. 35 A matriz de estmulos e estados uma tcnica que, uma vez aplicada em testes funcionais, estimula que uma quantidade maior de combinaes seja testada.
Analisando: 33 Errada. Os testes de unidades so realizados pelos prprios desenvolvedores, normalmente testes caixa-branca. Testes realizados por equipes especializadas normalmente so os testes de sistema. 34 - O Particionamento de classes de equivalncia similar anlise de Valor Limite. Ora, se uma entrada deve aceitar somente valores entre 0 e 100, definem-se grupos de valores para a entrada. 0 , 50, e 100 pode ser um conjunto de teste; 101 e 500 pode ser outro; e -1 e -100 pode ser outro grupo. Dessa forma, com sete nmeros possvel verificar se o intervalo definido como aceitvel funciona, no sendo necessrio testar dezenas ou centenas de entradas. Correta; 35 - A Matriz de estmulos e estados uma tcnica de teste que visa construir uma matriz com todos os estados (valores das variveis) e estmulos (parmetros). Desta forma, evitam-se esquecimentos e um maior numero de combinaes acaba sendo testado. Veja o exemplo abaixo, que descreve as regras de negcio para uma locadora, existindo vrios estados variando de acordo com as permisses para execuo das funes do sistema. Passo 1: definio das regras de negocio. Regras do negcio Funes/estados Disponvel Locado Cadastrar X Consultar X X Alterar X X
Prof. Victor Dalton
Reservado X X
42 de 93
Excluir Locar
X X X
Passo 2: execuo de teste e registro dos resultados Regras do negcio Funes/esta Disponvel Locado dos Cadastrar Ok Ok Consultar Ok Ok Alterar Ok Erro Excluir Ok Ok Locar Erro Ok Passo 3: comparao dos resultados
Reservado Ok Ok Ok Ok Ok
Comparao dos resultados obtidos (matriz de estmulos x estados) com o resultado esperado (regras de negocio). Basicamente o teste funcional deve testar se o mtodo chamado o correto e se este produz o resultado esperando. Perceba que um negcio aparentemente simples possuem 15 estados que devem ser testados. Sem a criao da matriz, seria muito mais fcil para o desenvolvedor/testador esquecer alguns desses estados, e a chance de desenvolver a funcionalidade com erro seria maior. Certa.
(CESPE Ministrio da Educao e Cultura Atividade Tcnica de Complexidade Gerencial Gerente de Projetos - 2011) Com relao a teste de software, julgue os itens a seguir. 36 Para qualquer sistema, independentemente do seu tamanho, as etapas de teste devem seguir a seguinte sequncia: testes de componente, testes de integrao e testes de sistema. 37 Quando o objetivo testar uma funcionalidade, assegurando-se que, para todo tipo de entrada, a sada observada corresponda quela esperada, pode-se alcanar esse objetivo fazendo-se uso de testes do tipo caixa-branca. 38 Uma das desvantagens de se utilizar a mesma equipe de desenvolvimento para a realizao de testes a tendncia informalidade na sua execuo, o que pode provocar a no identificao de determinados defeitos do projeto.
Prof. Victor Dalton
43 de 93
Mais testes!
36 Correta. Para testes, o ideal que sempre ocorra em granularidade crescente; 37 Errada. Testes de caixa-branca analisam o fluxo do sistema. Para testar resultados, ou seja, colocar a entrada e verificar a sada, o teste caixapreta; 38 Correta. Quando a equipe que desenvolve a equipe que testa, o conhecimento prvio do cdigo desenvolvido orienta o testador a buscar os caminhos felizes, ou a testar o tratamento de excees que eles j sabem que existem. Ainda, fazem os testes de cabea, informalizando procedimentos. Com isso, a probabilidade de passarem defeitos maior;
39 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. 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.
Prof. Victor Dalton
44 de 93
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 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.
Prof. Victor Dalton
45 de 93
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).
40 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 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
Prof. Victor Dalton
46 de 93
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).
41 Questo) (Formulao Pessoal) Sobre o Gerenciamento de Mudanas, analise as afirmativas abaixo: 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.
Prof. Victor Dalton
47 de 93
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).
42 Questo) (Formulao Pessoal) responsabilidade da Gerncia de Configurao: 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.
Prof. Victor Dalton
48 de 93
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 a). Para ajudar os estudos, veja um comparativo abaixo, extrado da ITIL, entre Gerenciamento de Configurao e Gerenciamento de Mudana. Maiores detalhes sero vistos no estudo da ITIL.
Gerenciamento de Configurao Gerenciamento de Mudana Suportar de forma eficiente e eficaz Responder s mudanas de os processos de Gerenciamento de requisitos de negcio do cliente Servio enquanto se maximiza o valor e se reduzem incidentes, interrupes e Otimizar os ativos de servios, retrabalhos configuraes de TI, habilidades e recursos Responder ao negcio e requisies de TI para mudanas que iro alinhar os servios s necessidades do negcio Definir e controlar os componentes Assegurar que as mudanas sejam de servios e infraestrutura, e feitas de uma forma controlada, e manter informaes precisas no sejam avaliadas, priorizadas, histrico sobre configurao, estado planejadas, testadas, implantadas e dos servios e infraestrutura atual e documentadas. planejada. Manter informaes sobre os Itens Criar a Requisio De Mudana, ou de Configurao (ICs) no Banco de registrar a RDM (quando a solicitao Dados do Gerenciamento de for originada em outra rea) Configurao (BDGC) Manter o BDGC atualizado, por meio Avaliar o impacto de mudanas no
Atividades
Objetivos
Metas
Prof. Victor Dalton
49 de 93
do SGC (Sistema de Gerenciamento da Configurao) Manter a Biblioteca de Mdia Definitiva (softwares licenciados, documentao, etc) Realizao de auditorias para conferncia do BDGC
sistema
Autorizar a mudana (quando dentro do seu escopo de autorizao) Coordenar mudana a implantao da
Como um mantm controle sobre os itens de configurao e outro os modifica, natural um relacionamento estreito entre eles. Mas no confunda o que cada um faz! 43 Questo) (FCC Ministrio Pblico do Estado de Sergipe Analista do Ministrio Pblico Gesto e Anlise de Projeto de Sistema 2010) Em relao anlise e ao projeto orientados a objetos, correto afirmar: a) A orientao a objetos no leva em conta a utilizao da prototipao, dada as restries desse modelo de desenvolvimento de software quanto reusabilidade. b) Uma das regras de normalizao aplicada s tabelas de objetos de dados especifica que uma instncia de um objeto pode ter diversos valores para cada atributo. c) Se a informao sobre um objeto em potencial precisar ser lembrada para que o sistema possa funcionar, esse objeto no poder ser utilizado durante a anlise. d) Representar os objetos e suas relaes o principal objetivo do Diagrama Entidade-Relacionamento (E-R). e) Um Diagrama de Fluxo de Dados (DFD) deve, alm do fluxo da informao, descrever detalhadamente a lgica procedimental do sistema. Na anlise e projeto estruturados, o processo a ser informatizado visto como um conjunto de funes com dados de entrada, processamento e dados de sada, ou seja, a nfase esta em funes que agem sobre dados. Estas funes podem ser decompostas em subfunes (decomposio funcional). As principais caractersticas so: preocupao com a modularidade e coeso; desenvolvimento em diferentes nveis de abstrao (top-down). O Diagrama de Fluxo de Dados (DFD) o principal diagrama utilizado nessa metodologia. Em um DFD, representam-se entidades externas por caixas, processos (ou tarefas) por circunferncias (tambm podem ser elipses ou elipses achatadas), o fluxo dos dados por setas e depsitos de dados por traos duplos. Veja abaixo:
Prof. Victor Dalton
50 de 93
Na anlise orientada a projetos, o processo a ser informatizado visto como um conjunto de objetos que interagem para realizar as funes, como no diagrama de classes abaixo:
As principais vantagens do modelo OO so: maior grau de abstrao; maior encapsulamento; modelos apoiados em conceitos do mundo real; reutilizao (reusabilidade).
Prof. Victor Dalton
51 de 93
A anlise e projeto orientada a objetos lana mo da diagramao UML para modelagem e anlise nas diversas etapas do projeto. Quanto questo, a resposta certa a alternativa d).
44 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas de Informao 2008) A linguagem de Modelagem Unificada (UML) emergiu como notao de diagramao de padro, de fato e de direito, para a modelagem orientada a objetos. Desta forma, a sentena que conceitua apropriadamente a UML, segundo o OMG-Object Management Group, a) um mtodo para especificar e modelar os artefatos dos sistemas. b) um processo de especificao e modelagem de sistemas orientados a objeto. c) uma linguagem para implementar os conceitos da orientao a objetos. d) uma linguagem visual para especificar, construir e documentar os artefatos dos sistemas. e) um mtodo comum para a representao da orientao a objetos. UML um assunto trivial em provas de concursos que exijam desenvolvimento de sistemas. Segundo nossa fonte recomendada, a modelagem de sistemas de software consiste na utilizao de notaes grficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se vrias perspectivas diferentes e complementares. Exigir a sentena exata que conceitua a UML, segundo o OMG foi exagero por parte da banca. Contudo, quem j trabalhou no desenvolvimento de um sistema e j precisou de um diagrama UML sabe que uma caracterstica importante dela a comunicao entre as pessoas envolvidas. Voc pode tentar descrever um caso de uso simples de um sistema e perder 20 minutos Entretanto, ao mostrar um diagrama de caso de uso ou um diagrama de sequncia, o entendimento comum quase que imediato. A UML uma ferramente poderosa de comunicao, alm da construo e documentao de artefatos de um sistema. Portanto, mesmo sem conhecer a exata sentena da OMG sobre o assunto, perceptvel que a letra d) a alternativa mais completa e livre de incorrees.
45 Questo) (ESAF Analista de Controle Externo Anlise de Sistemas 2002)Analise as seguintes afirmaes relativas UML: I. Ao uma abstrao representativa de entidades externas que interagem com um produto ou sistema;
Prof. Victor Dalton
52 de 93
II. Atributo a descrio de um espao com nome e tipo, dentro de uma classe, onde cada objeto desta classe mantm um valor deste tipo; III. Classe o descritor para um conjunto de objetos que partilham os mesmos atributos, operaes, relacionamentos e comportamento; IV. Evento a condio ou situao de vida de um objeto durante a qual ele executa uma atividade. 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
Analisando conceitos: I. Ator uma abstrao representativa de entidades externas que interagem com um produto ou sistema. Ao uma expresso que pode ser definida em termos dos atributos, das operaes ou das associaes da classe, realizada pelo objeto quando transita de um estado para outro. Errada; II. Correta; III. Correta; IV. Estado a condio ou situao de vida de um objeto durante a qual ele executa uma atividade. Evento alguma ocorrncia no ambiente do sistema para o qual este sistema deve realizar alguma ao quando da ocorrncia do evento. Errada; Portanto, a alternativa b) a correta.
46 Questo) (ESAF Agncia Nacional de guas Tecnologia da Informao e Comunicao Desenvolvimento de Sistemas - 2009) Em UML, o relacionamento utilizado para expressar herana entre classes e interfaces a a) multiplicidade. b) dependncia. c) agregao. d) associao. e) generalizao. Mais reviso de conceitos: a) Multiplicidades so os limites, superior e inferior, de associaes que um objeto pode possuir. Errada;
Prof. Victor Dalton
53 de 93
b) Dependncia uma conexo semntica entre dois elementos, um independente e outro dependente. Errada; c) Agregao e composio so variantes da associao, que o estabelecimento de um relacionamento entre objetos. Na agregao, a parte pode existir sem o todo, e na composio isso no possvel. Exemplos: jogador e time de futebol (agregao), Captulo, Seo e Pargrafo (composio). Errada; e) Generalizao/especializao so dois pontos de vista do mesmo relacionamento utilizado para expressar herana entre classes e interfaces. Correta. Nosso estudo de UML continua. Alternativa e).
47 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) Sobre Programao Orientada a Objetos e UML, considere: I. Os diagramas de classe so usados no desenvolvimento de um modelo de sistema orientado a objetos para mostrar as classes de um sistema e as associaes entre essas classes. II. A UML tem um tipo especfico de associao para denotar a generalizao. Em uma generalizao, os atributos e operaes associados com as classes de nvel alto (superclasses) tambm esto associados com as de nvel baixo (subclasses). III. A UML fornece um tipo especial de associao entre classes chamada agregao, que significa que um objeto (todo) composto de outros objetos (as partes). IV. Os modelos comportamentais descrevem o modelo esttico do domnio e qual a reao comportamental de interao entre as classes. Eles mostram o que acontece ou deve acontecer quando o sistema responde a um estmulo de seu ambiente. Est correto o que consta APENAS em a) I e II. b) I, III e IV. c) I, II e III. d) II, III e IV. e) III e IV. A definio de diagramas de classe da questo bastante adequada.
Prof. Victor Dalton
54 de 93
Exemplo de diagrama de classe UML.
Os itens II e III, conforme a explicao anterior, tambm esto corretos. Apenas o item IV incorreto. So os Diagramas Estruturais que representam modelos estticos, enquanto os Diagramas Comportamentais, por sua vez, modelam os aspectos dinmicos de um sistema. Veremos estes diagramas mais adiante. Resposta certa, alternativa c).
48 Questo) (ESAF Analista de Controle Externo Anlise de Sistemas 2002 - adaptada) Um gerente de projeto sabe que o modo para descrever os vrios aspectos de modelagem pela UML por meio da notao definida pelos seus vrios tipos de diagramas. Em um determinado projeto, ele necessita de um diagrama esttico onde a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. O diagrama UML recomendado para suprir esta necessidade deste gerente o a) diagrama de componente. b) diagrama de comunicao. c) diagrama de sequencia. d) diagrama de classe. e) diagrama de implantao. Vamos revisar estes diagramas?
Prof. Victor Dalton
55 de 93
Diagrama de Componente - Um Diagrama de Componentes mostra como os diferentes subsistemas de software formam a estrutura total de um sistema, sistema este que est construdo sobre um banco de dados centralizado que contm dados histricos de locaes, detalhes dos veculos, registros de manuteno, dados de clientes e funcionrios. muito importante que estas informaes estejam centralizadas em um banco de dados, pois os nveis de estoque podero sofrer alteraes a cada hora, e todos os participantes do processo comercial precisam ter acesso s informaes mais recentes. Manter os dados atualizados uma tarefa que requer atualizaes em tempo real por parte de todos os integrantes do processo.
Diagrama de Componente
Diagrama de Comunicao - Um Diagrama de Comunicao outro tipo de diagrama de interao. Assim como no Diagrama de Sequncia, o Diagrama de Comunicao mostra como um grupo de objetos num caso de uso interage com os demais. Cada mensagem numerada para documentar a ordem na qual ela ocorre. Observao: na UML 1.5, este diagrama chamava-se Diagrama de Colaborao, e na 2.0 passou a chamar-se Diagrama de Comunicao.
Diagrama de Comunicao
Diagrama de Sequncia - Um Diagrama de Sequncia oferece uma viso detalhada de um caso de uso. Ele mostra uma interao organizada em forma de uma sequncia, dentro de um determinado perodo de tempo, e contribui para a que se processe a documentao do fluxo de lgica dentro da aplicao. Os participantes so apresentados dentro do contexto das mensagens que se transitam entre eles. Num sistema de software abrangente, um Diagrama de Sequncia pode ser bastante detalhado, e pode incluir milhares de mensagens.
Prof. Victor Dalton
56 de 93
Diagrama de Sequncia
Diagrama de Classe O Diagrama de Classe um diagrama de estrutura esttica, que modela as classes de objetos, mostrando a estrutura geral do sistema e tambm as suas propriedades relacionais e de comportamento.
Prof. Victor Dalton
57 de 93
Diagrama de Classe
Diagrama de Implantao Modela o uso fsico do sistema, considerando computadores, dispositivos e suas interconexes.
Diagrama de Implantao
Diagrama de caso de uso(bnus) No poderamos no falar deste diagrama. Um Caso de Uso especifica uma interao entre um usurio e o sistema, no qual o usurio tem um objetivo muito claro a atingir.
Diagrama de Caso de Uso
Dentre todos esses diagramas, os Diagramas de Comunicao e de Sequncia so o que chamamos de Diagramas Dinmicos, por refletirem o comportamento do sistema. Pertencem a esse rol: Diagrama de Estado
Prof. Victor Dalton
58 de 93
Diagrama de Sequncia Diagrama de Colaborao Diagrama de Atividade
Os Diagramas Funcionais, por sua vez, so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo. So eles o Diagrama de Componentes e o Diagrama de Implantao. Os Diagramas Estticos, por fim, so os que retratam o sistema de uma forma estrutural, e que so vlidos durante todo o ciclo de vida. o caso dos Diagramas de Classes e de Objetos. Portanto, o Diagrama de Classe atende nossa questo. Resposta certa, letra d).
49 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas de Informao 2008) Diagramas de pacotes UML so usados para ilustrar a arquitetura lgica de um sistema. Assinale a opo correta a respeito da aplicao de diagramas de pacotes UML. a) No permitem agrupar classes, outros pacotes e casos de uso. b) Camadas de Interface de Usurio-UI no podem ser modeladas como pacotes. c) A dependncia (acoplamento) entre pacotes representada por uma Associao. d) Na UML, as associaes so definidas como o relacionamento semntico entre dois pacotes. e) Representam as camadas, subsistemas e pacotes (no significado Java). Esta uma segunda abordagem para perguntar sobre diagramas UML. Ou eles descrevem o diagrama e pedem para voc identific-lo ou apresentam 5 descries e pedem pra voc acertar a que tem relao com o diagrama solicitado. Diagrama de pacotes Descreve como os elementos so organizados dentro de pacotes e suas dependncias, mostrando, inclusive, pacotes importados (o import do Java) e extenses de pacotes, alm de pacotes contidos em outros. Tem por objetivo representar de uma forma clara os subsistemas englobados por um sistema de forma a determinar as partes que o compem, oferecendo uma viso geral das camadas do sistema.
Prof. Victor Dalton
59 de 93
Diagrama de Pacotes
Responder este estilo de pergunta mais difcil, e provavelmente vai exigir que voc trabalhe por eliminao. A letra a), por exemplo, absurda; Para a letra b), o prprio diagrama dado como exemplo, uma contraprova, pois mostra a view dentro de um pacote; A letra c) mistura conceitos, pois dependncia e associao so conceitos paralelos. A dependncia representada por uma seta tracejada, como as mostradas no exemplo; A letra d) tambm mistura conceitos pois so as dependncias que so definidas como o relacionamento semntico entre dois pacotes. As associaes, por sua vez, estabelecem relacionamento entre objetos. Nossa resposta correta, portanto, a letra e).
50 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) Na taxonomia dos diagramas de estrutura (S) e de comportamento (C) da UML, os diagramas de Pacote, Classe, Sequncia e Objeto so, respectivamente, de a) S, S, C e S. b) S, S, C e C. c) S, C, S e C. d) C, S, C e S. e) C, C, S e C.
Prof. Victor Dalton
60 de 93
Aps resolver as duas questes anteriores, esta fica fcil. Entretanto, para lembrar na hora da prova, voc precisar ter assimilado visualmente cada diagrama. Por isso, cada diagrama acima possui um exemplo visual. Resposta certa, alternativa a).
51 Questo) (FCC Ministrio Pblico do Estado de Sergipe Analista do Ministrio Pblico Gesto e Anlise de Projeto de Sistema 2010) Dentre as etapas para o desenvolvimento de software em que a UML pode ser aplicada, aquela em que sero modeladas somente classes que pertenam ao domnio principal do problema do software, deixando de lado classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outras, a etapa de a) anlise de requisitos. b) anlise sistmica. c) projeto. d) implementao. e) testes/implantao. Questo inteligente de FCC envolvendo UML e Engenharia de Software. Ora, para que serve um diagrama de classes, como este?
Fique vontade para pensar e analisar as alternativas, se for o caso. Mas perceba que, de imediato, este diagrama lhe fornece uma viso geral do sistema. No cabe falar em anlise de requisitos ou testes. Forando a barra,
Prof. Victor Dalton
61 de 93
poderamos falar em projeto ou implementao, mas o enunciado frisou que detalhes tcnicos esto excludos. Portanto, este diagrama serve para anlise sistmica, e a alternativa b) a correta.
52 Questo) (FCC Assemblia Legislativa do Estado de So Paulo Agente Tcnico Legislativo Tecnologia da Informao 2010) So consideradas metodologias geis de desenvolvimento de software: a) XP e UP. b) SCRUM e DSDM. c) SCRUM e RUP. d) DSDM e Cascata. e) Cascata e PRINCE2. Ao falar de metodologias geis, certamente Scrum e XP vieram sua cabea. XP, oriunda de eXtreme Programming, uma filosofia de programao que segue algumas prticas genricas, cujo conhecimento considero vlido. So elas: Jogo de Planejamento (Planning Game): O desenvolvimento feito em iteraes semanais. No incio da semana, desenvolvedores e cliente renem-se para priorizar as funcionalidades. Essa reunio recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente essencial neste processo e assim ele fica sabendo o que est acontecendo e o que vai acontecer no projeto. Como o escopo reavaliado semanalmente, o projeto regido por um contrato de escopo negocivel, que difere significativamente das formas tradicionais de contratao de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produo. Pequenas Verses (Small Releases): A liberao de pequenas verses funcionais do projeto auxilia muito no processo de aceitao por parte do cliente, que j pode testar uma parte do sistema que est comprando. As verses chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP. Metfora (Metaphor): Procura facilitar a comunicao com o cliente, entendendo a realidade dele. O conceito de rpido para um cliente de um sistema jurdico diferente para um programador experiente em controlar comunicao em sistemas em tempo real, como controle de trfego areo. preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto. Projeto Simples (Simple Design): Simplicidade um princpio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira verso apenas o usurio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, voc vai fazer o cdigo exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de
Prof. Victor Dalton
62 de 93
autenticao e restries de acesso. Um erro comum ao adotar essa prtica a confuso por parte dos programadores de cdigo simples e cdigo fcil. Nem sempre o cdigo mais fcil de ser desenvolvido levar a soluo mais simples por parte de projeto. Esse entendimento fundamental para o bom andamento do XP. Cdigo fcil deve ser identificado e substitudo por cdigo simples. Time Coeso (Whole Team): A equipe de desenvolvimento formada por pessoas engajadas e de forma multidisclipinar (no sentido de incluir pessoas com cada uma das habilidades necessrias para o projeto). Testes de Aceitao (Customer Tests): So testes construdos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema. Ritmo Sustentvel (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras so permitidas quando trouxerem produtividade para a execuo do projeto. Outra prtica que se verifica neste processo a prtica de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivao da equipe devem estar sempre em harmonia. Reunies em p (Stand-up Meeting): Reunies em p para no se perder o foco nos assuntos, produzindo reunies rpidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe. Posse Coletiva (Collective Ownership): O cdigo fonte no tem dono e ningum precisa solicitar permisso para poder modificar o mesmo. O objetivo com isto fazer a equipe conhecer todas as partes do sistema. Programao em Pares (Pair Programming): a programao em par/dupla num nico computador. Geralmente a dupla formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como apenas um computador, o novato que fica frente fazendo a codificao, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evoluo da equipe, melhorando a qualidade do cdigo fonte gerado. Padres de Codificao (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecer que todo o cdigo fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitrios (unit tests) e depois crie o cdigo para que os testes funcionem. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto seja mantida. Refatorao (Refactoring): um processo que permite a melhoria continua da programao, com o mnimo de introduo de erros e mantendo a compatibilidade com o cdigo j existente. Refabricar melhora a clareza (leitura)
Prof. Victor Dalton
63 de 93
do cdigo, divide-o em mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-fonte; Integrao Contnua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar verso atual do sistema. Isto s aumenta a possibilidade de conflitos e a possibilidade de erros no cdigo fonte. Integrar de forma contnua permite saber o status real da programao.
Entretanto, existem outras metodologias geis, como: Desenvolvimento de Software Adaptativo (ASD): O apoio filosfico do ASD concentra-se na colaborao humana e na auto-organizao. A auto-organizao aparece quando agentes individuais independentes cooperam para criar resultados emergentes. Um resultado emergente uma propriedade alm da capacidade de qualquer agente individual. Ciclo de vida: Especulao: iniciao do projeto e planejamento adaptativo. Colaborao: pessoal motivado trabalha junto de um modo que multiplica seus talentos e resultados criativos. Aprendizagem que pode ocorrer de trs modos: foco nos grupos; reviso tcnicas formais; ps-concluso.
ASD
Mtodo de Desenvolvimento de Sistemas Dinmicos: uma metodologia de desenvolvimento de software originalmente baseada em "Desenvolvimento Rpido de Aplicao" (RAD). DSDM uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usurio.
Prof. Victor Dalton
64 de 93
DSDM
Seu objetivo entregar softwares no tempo e com custo estimados atravs do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM um dos modelos de Metodologia gil de desenvolvimento de software, e seu formato propriedade da Agile Alliance. Processo Unificado gil (AUP):Verso simplificada do RUP, adaptada metodologia gil.
Portanto, nossa resposta correta a letra b).
53 Questo) (FCC INFRAERO Analista de Sistemas/Arquitetura de Software 2011) Um dos principais conceitos do Scrum para atacar a complexidade do desenvolvimento e gerenciamento de software a implantao de um controle descentralizado, capaz de lidar mais eficientemente com contextos pouco previsveis. Para tanto, o gerenciamento distribudo por meio de trs agentes independentes que so: a) Product Owner, Scrum Team e Scrum Master. b) Product Owner, Product Backlog e Planning Meeting. c) Product Owner, Sprint e Planning Meeting. d) Sprint, Scrum Master e Planning Meeting. e) Sprint, Scrum Team e Product Backlog.
O Scrum uma metodologia de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento gil de software. Scrum no um processo nem descreve o que se deve fazer em cada situao. Ele usado para trabalhos complexos nos quais difcil predizer tudo o que ir ocorrer. O Scrum um conjunto de passos que contm grupos de prticas e papis pr-definidos. Os nicos papis so:
Prof. Victor Dalton
65 de 93
1. O Proprietrio do Produto, ou Product Owner, que representa os stakeholders e o negcio; 2. o Scrum Master, que mantm os processos (normalmente no lugar de um gerente de projeto); 3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste, etc. Sprint
Um sprint a unidade bsica de desenvolvimento em Scrum. Sprints tendem a durar entre uma semana e um ms, e so um esforo dentro de uma "caixa de tempo" (ou seja, restrito a uma durao especfica) de comprimento constante. Cada sprint precedido por uma reunio de planejamento, onde as tarefas para o sprint so identificadas e um compromisso estimado para o objetivo do sprint definido e seguido por uma reunio de reviso ou de retrospectiva, onde o progresso revisto e lies para os prximos sprints so identificadas. Durante cada sprint, a equipe cria um incremento de produto potencialmente entregvel (por exemplo, software funcional e testado). O conjunto de funcionalidades que entram em um sprint vm do backlog do produto, que um conjunto de prioridades de requisitos de alto nvel do trabalho a ser feito. Quais itens do backlog entram para o sprint so determinados durante a reunio de planejamento do sprint. Durante esta reunio, o Product Owner informa a equipe dos itens no backlog do produto que ele ou ela quer concludos. A equipe ento determina quantos eles podem se comprometer a concluir durante o prximo sprint, e registram isso no backlog do sprint. Durante um sprint, ningum est autorizado a alterar o backlog do sprint, o que significa que os requisitos so congelados para esse sprint. O desenvolvimento de cada sprint deve terminar na "caixa de tempo" prevista. Se os requisitos no so completados por qualquer motivo, eles so deixados de fora e voltam para o backlog do produto. Depois que um sprint completado, a equipe demonstra como usar o software. O Scrum permite a criao de equipes auto organizadas, encorajando a cooperao de todos os membros da equipe e a comunicao verbal entre todos os membros e disciplinas da equipe no projeto. Artefatos Product Backlog Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog mantido pelo Product Owner e uma lista de requisitos que tipicamente vm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por deciso deste. Sprint backlog
Prof. Victor Dalton
66 de 93
O Sprint backlog uma lista de itens selecionados do Product backlog e contm tarefas concretas que sero realizadas durante o prximo sprint para implementar tais itens selecionados. O Sprint Backlog uma representao em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team. Planejamento de sprint Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar durante o prximo sprint. O Product Owner mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o backlog do sprint. Reunies Daily Scrum Cada dia durante o sprint, uma reunio de status do projeto ocorre. Isso chamado de "scrum dirio". Esta reunio tem diretrizes especficas: A reunio comea precisamente no horrio marcado. Todos so bem-vindos, mas apenas "poucos" podem falar. O encontro tem durao determinada (TimeBox) e dura 15 minutos. A reunio deve acontecer no mesmo local e mesma hora todos os dias Durante a reunio, cada membro da equipe responde a trs perguntas: O que voc tem feito desde ontem? O que voc est planejando fazer hoje? Voc tem algum problema impedindo voc de realizar seu objetivo? papel do Scrum Master para facilitar a resoluo desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a reunio possa durar menos de 15 minutos. Reunio de Planejamento da Sprint (Sprint Planning Meeting) No incio do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting realizado. Selecione o trabalho que est a ser feito. Prepare o Sprint Backlog que detalha o tempo que levar para fazer esse trabalho, com toda a equipe. Identificar e comunicar o quanto o trabalho susceptvel de ser feito durante o sprint atual. Dividida em duas partes: Parte 1 (Primeiras quatro horas): Team Product Owner: dilogo para priorizar o Product Backlog.
Prof. Victor Dalton
67 de 93
Parte 2 (Prximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando na Sprint Backlog.
No final de um ciclo de sprint, so realizadas duas reunies: a "Sprint Review" e do "Sprint Retrospective". Reunio de Reviso da Sprint (Sprint Review) Rever o trabalho que foi concludo e no concludo. Apresentar o trabalho realizado para os interessados (ou "a demo"). Um trabalho incompleto no pode ser demonstrado. Retrospectiva da Sprint (Sprint Retrospective) Todos os membros da equipe refletem sobre a sprint passada. Trs questes principais so feitas na retrospectiva sobre o sprint: O que deu errado? O que deu certo? O que poderia ser melhorado para o prximo sprint?
Se voc achou o Scrum um pouco utpico, eu posso garantir que no . Utilizamos ele no Banco Central pra valer, e os projetos andam! Com reunies dirias, sprints e tudo o mais! Nossa resposta correta, letra a).
54 Questo) (FCC TRT 6 Regio Analista Judicirio Tecnologia da Informao 2012) Na metodologia Scrum, NO faz parte de uma reviso do sprint (sprint review) o seguinte procedimento: a) Todo o time colabora no que deve ser feito em seguida, de modo que esta reviso contribua para reunies de planejamento subsequentes.
Prof. Victor Dalton
68 de 93
b) O proprietrio do produto identifica o que est pronto e o que ainda est por fazer. c) O time de desenvolvimento discute quais fatores positivos e negativos ocorreram durante o sprint e como os problemas foram resolvidos. d) O time de desenvolvimento apresenta o trabalho que foi desenvolvido e responde questes sobre o incremento. e) Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho. Veja que, apesar de uma carga terica relativamente forte sobre Scrum na questo anterior, a FCC foi mais fundo ainda, pedindo pra voc dizer qual das atividades acima no da Sprint Review. Por questes como essa que eu valorizo a leitura complementar. No caso, a letra e), cuja atividade da Sprint Retrospective.
(CESPE TCE/ES Auditor de Controle Externo Tecnologia da Informao - 2012) Acerca de engenharia de software, julgue os itens subsecutivos. 55 O desenvolvimento de software no RUP organiza-se em seis fases: planejamento, levantamento de requisitos, anlise, implementao, testes e implantao. 56 Em virtude de as metodologias geis gerarem excessiva documentao, a gesto do conhecimento depende diretamente dos programadores envolvidos no projeto. 57 O Product Backlog, um dos artefatos utilizados na metodologia gil denominada Scrum, constitui-se da lista priorizada de todos os requisitos do produto final. 58 As entidades (entity) em UML (Unified Modeling Language) correspondem invariavelmente a tabelas de banco de dados, sendo necessrias para cumprir as responsabilidades do produto. E mais CESPE! 55 Errada. A sequncia descrita no deixa de ser uma sequncia lgica de um processo de desenvolvimento de software. Porm, falou de RUP, falou de CECT (Concepo, Elaborao, Construo, Transio); 56 Errada, pois metodologias geis no geram excessiva documentao;
Prof. Victor Dalton
69 de 93
57 - Correta.
58 Errada. Em UML, existem entidades estruturais, comportamentais, de agupamento e de anotao. As entidades estruturais podem ser: Classes Interfaces Colaboraes Casos de Uso Componentes. As entidades comportamentais, por sua vez, so as: Interaes Mquinas de Estados Atividades Como entidades de agrupamento, temos o pacote (package), e entidade de anotao, a nota.
(CESPE Tribunal de Contas da Unio Auditor Federal de Controle Externo Tecnologia da Informao - 2010) Julgue os itens a seguir, relativos a modelos geis de processo. 59 O desenvolvimento adaptativo de software (DAS) uma tcnica para construo de sistemas e software complexos que foca na colaborao e na auto-organizao da equipe. 60 A agilidade no pode ser aplicada a todo e qualquer processo de software. 61 O processo XP (extreme programming) envolve a realizao das atividades de planejamento, de projeto, de codificao e de teste. 62 A atividade de planejamento XP inclui a criao das denominadas histrias de usurio, nas quais devem ser descritas as caractersticas e as funcionalidades requeridas para o software em desenvolvimento. 63 A atividade de projeto uma desvantagem do processo XP, pelo fato de requerer uma quantidade de produtos de trabalho considerada excessiva pela comunidade de desenvolvimento de software.
Prof. Victor Dalton
70 de 93
Para finalizar!
59 Correta. O DAS concentra-se na colaborao humana e na autoorganizao da equipe. 60 Errada. No importa o tamanho, qualquer software pode ser desenvolvido utilizando-se metodologias agis. No prprio Banco Central, softwares altamente complexos comeam a ser desenvolvidos de forma incremental, partindo de casos de uso simples e sendo expandidos a cada ciclo. 61 Correta. Embora a bibliografia enfatize que planejamento, projeto, codificao e teste sejam as quatro atividades chave do desenvolvimento de software em XP, c entre ns, qualquer processo de desenvolvimento de software passa por essas etapas (ou deveria passar). 62 Correta. Cpia da bibliografia. 63 Errada. Uma caracterstica da XP a pouca documentao produzida.
Prof. Victor Dalton
71 de 93
CONSIDERAES FINAIS
Espero que vocs tenham compreendido minha metodologia de trabalho. Vejo este conjunto de apostilas com as seguintes finalidades. 1) Serve para familiarizao com questes de concursos, para aqueles que ainda so novatos neste ambiente; 2) Serve para completar lacunas. Certamente existem reas da TI com as quais voc no familiarizado, e essa apostila permitir um rpido ganho de conhecimento sobre um assunto que seja novo, ou que voc domine muito pouco; 3) Serve tambm para autodiagnstico. Determinada aula que voc sinta muita dificuldade para responder aos exerccios, ou que voc erre muitas questes, pode ser um sinal de que necessrio adquirir ou ler as fontes recomendadas, para sanar esse ponto falho; 4) Ainda, nas proximidades da prova, a lista de exerccios servir como reviso. Certamente teremos mais de 600 questes para reviso da matria, ao trmino das aulas. Como vocs j devem ter percebido, no tenho inteno de substituir bibliografias consagradas de estudo. Honestamente, no acredito em apostilas milagrosas, no estilo aqui tem tudo que voc precisa para gabaritar determinado assunto. Mesmo porque as bancas esto sempre inventando novas questes, justamente para derrubar os concurseiros de planto, que vivem APENAS de mementos e mapas mentais. necessrio SIM ler os autores e bibliografias consagrados, para fazer aquele algo mais na sua pontuao. Tenho certeza que os concurseiros mais experientes concordam comigo. Por isso, resolvi divulgar fontes de estudo, em um verdadeiro trabalho de consultoria, e estou aberto a debat-las. Nossa principal meta a sua aprovao. E digo mais: caso voc no consiga aprovao neste certame (toc toc toc, vira essa boca para l), dificilmente voc far outro curso comigo, uma vez que as dicas debatidas serviro para que voc, tranquilamente, estude por conta prpria para outros certames. Espero rev-lo como meu aluno efetivo. Que venha o BCB 2013! Grande abrao, e fora nos estudos!
Victor Dalton
Prof. Victor Dalton
72 de 93
LISTA DE EXERCCIOS
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. 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.
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.
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.
Prof. Victor Dalton
73 de 93
d) Planejamento, Eliminao dos Riscos, Anlise de Contingncia e Avaliao feita pelo cliente. e) Planejamento, Projeto, Anlise dos Riscos e Engenharia.
4 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) No modelo de desenvolvimento de software em espiral, cada loop na espiral representa a) a necessidade de retornar ao incio da fase em que se encontra. b) um processo de reengenharia. c) uma disciplina de software. d) uma fase do processo de software. e) uma atividade paralela.
5 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte - Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) O modelo em espiral difere principalmente dos outros modelos de processo de software por a) no contemplar o prottipo. b) reconhecer explicitamente o risco. c) no ter fases. d) possuir uma fase nica evolucionria. e) no contemplar o projeto do produto.
6 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) O processo de desenvolvimento em cascata um exemplo de processo dirigido a planos, pois, em princpio, necessrio planejar e programar todas as atividades do processo antes de comear a trabalhar nelas. So exemplos de estgios desse modelo: a) Integrao de Produto, Definio de Processo Organizacional e Gerenciamento de Riscos. b) Anlise e Definio de Requisitos, Implementao de Teste Unitrio e Integrao e Teste de Sistema. c) Inicial, Gerenciado e Em Otimizao. d) Engenharia de Requisitos, Ciclo de Vida de Projetos e Gesto de Incidentes. e) Acompanhamento e Controle de Projeto, Medio e Anlise e Desenvolvimento de Requisitos.
Prof. Victor Dalton
74 de 93
7 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) A engenharia de software baseada em reuso uma estratgia da engenharia em que o processo de desenvolvimento orientado para o reuso de softwares existentes. Dentre os benefcios do reuso de software, INCORRETO afirmar: a) Preencher uma biblioteca de componentes reusveis e garantir que desenvolvedores de software possam utilizar essa biblioteca so aes no onerosas, pois processos de desenvolvimento no precisam ser adaptados para utilizar essa biblioteca. b) Devido ao custo do software existente j ser conhecido, o risco de processo reduzido. c) Especialistas em aplicaes podem desenvolver softwares reusveis que encapsulem seu conhecimento, tornando seu uso mais eficaz. d) Muitas vezes os custos gerais de desenvolvimento no so to importantes quanto entregar um sistema ao mercado o mais rpido possvel. O reuso de um software pode acelerar a produo do sistema. e) Alguns padres, como os de interface de usurio, podem ser implementados como um conjunto de componentes reusveis. O uso de interfaces de usurio-padro melhora a confiana, pois os usurios cometem menos erros quando so apresentados a interfaces familiares.
8 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. 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.
Prof. Victor Dalton
75 de 93
(FCC Agente Fiscal de Rendas Tecnologia da Informao - 2009) Para responder as questes de 9 e 10, 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. 9 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. 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.
10 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.
Prof. Victor Dalton
76 de 93
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.
11 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.
12 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. 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.
13 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia
Prof. Victor Dalton
77 de 93
de Software/Desenvolvimento de Sistemas - 2010) Na engenharia de software, etnografia a) uma fase do processo de software aplicada no modelo em cascata. b) uma fase do processo de software aplicada no modelo em espiral. c) uma tcnica de observao que pode ser usada para compreender os requisitos sociais e organizacionais. d) uma tcnica aplicada na engenharia de requisitos cujo objetivo definir, a priori, as classes que contm elementos grficos (BLOB). e) um projeto cujo principal objetivo criar interfaces grficas, que facilitam o acesso do usurio (GUI).
14 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.
15 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: a) Arquitetura do Software. b) Planejamento do Software. c) Engenharia de Requisitos. d) Estimativas do Projeto. e) Processo de desenvolvimento de Software.
Prof. Victor Dalton
78 de 93
16 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. e) Somente as afirmativas II, III e IV esto corretas.
17 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, especificao, 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
79 de 93
A funo : a) Elaborao b) Negociao c) Especificao d) Validao e) Gesto
(CESPE Tribunal de Contas da Unio Auditor Federal de Controle Externo Tecnologia da Informao - 2010) Julgue os itens seguintes, a respeito de engenharia de requisitos. 18 Para o desenvolvimento de casos de uso, fundamental a identificao dos atores, tanto os principais quanto os secundrios, j na primeira iterao do levantamento de requisitos. 19 O checklist de validao uma forma til de averiguar se determinado requisito pode ser testado e, em caso afirmativo, se os testes podem ser especificados. 20 Por se tratar de funo essencial da engenharia de requisitos, a gesto formal de requisitos indispensvel mesmo para projetos de pequeno porte, com apenas duas ou trs dezenas de requisitos identificveis.
(CESPE Ministrio da Educao e Cultura Atividade Tcnica de Complexidade Gerencial Gerente de Projetos - 2011) A engenharia de software busca sistematizar a produo de software com qualidade. No que concerne ao estgio de projeto, julgue os seguintes itens.
Prof. Victor Dalton
80 de 93
21 Para transformar os requisitos em um sistema funcional, os projetistas devem criar um projeto conceitual, que descreva o sistema para o cliente em uma linguagem que este possa entender, para depois transform-lo em um projeto com uma abordagem tcnica para os construtores do sistema.
22 A independncia dos componentes um dos atributos que reflete a qualidade do projeto. O grau de independncia pode ser medido a partir dos conceitos de acoplamento e coeso, os quais, idealmente, devem ser alto e baixo, respectivamente. 23 O projeto de software deve identificar os possveis desvios do comportamento de um sistema. Cada exceo pode ser tratada por meio de um dos seguintes modos: tentar realizar novamente um servio que falhou, corrigir algum aspecto do servio antes de tentar realiz-lo novamente ou relatar o servio no realizado para outro componente de tratamento de erro.
24 Questo) (ESAF Analista de Finanas e Controle Tecnologia da Informao 2003 - adaptada) Analise as seguintes afirmaes relativas Engenharia de Software: I. A anlise de requisitos responsvel pela especificao dos requisitos de software e hardware que sero utilizados durante o processo de desenvolvimento de um sistema. II. A anlise de requisitos define a metodologia de programao a ser utilizada no desenvolvimento do sistema. III. A especificao de requisitos fornece ao desenvolvedor e ao cliente os parmetros para avaliar a qualidade logo que o sistema for construdo. IV. A anlise de requisitos possibilita que o engenheiro de software compreenda o sistema que ir desenvolver. Esto corretos os itens: a) I e II b) II e III c) III e IV d) I e III e) II e IV
25 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.
Prof. Victor Dalton
81 de 93
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
26 Questo)(FCC Tribunal de Contas do Estado do Paran Analista de Controle Informtica - 2011) Mtricas de software podem ser divididas em medidas diretas e indiretas, sob o ponto de vista de medio, e em mtricas de produtividade e de qualidade, sob o ponto de vista de aplicao. Nesse contexto, as mtricas que se concentram na sada do processo de engenharia de software e as mtricas que indicam o quanto o software atende aos requisitos definidos pelo usurio, podem ser classificadas, respectivamente, como mtricas de a) custo e de complexidade, em medidas indiretas. b) esforo e de confiabilidade, em medidas diretas. c) produtividade e de qualidade, em medidas indiretas. d) qualidade e de eficincia, em medidas diretas. e) velocidade de execuo e tcnica, em medidas diretas.
27 Questo) (ESAF Analista de Planejamento e Oramento Tecnologia da Informao - 2005)As mtricas de produtos de software dividem-se em classes: mtricas dinmicas coletadas por meio de medies realizadas em um programa em execuo, e mtricas estticas coletadas por meio de medies realizadas em representaes do sistema. Indique a opo que descreve corretamente uma mtrica esttica do produto de software. a) ndice de fog uma medida da complexidade de controle de um programa. b) Complexidade ciclomtica uma medida da extenso mdia das palavras e das sentenas em documentos, ponderada por complexidade.
Prof. Victor Dalton
82 de 93
c) Extenso de identificadores o nmero de mtodos includos em uma classe, relacionada com a facilidade de compreenso do programa. d) Extenso de cdigo uma medida de extenso mdia de um programa e est associada complexidade da lgica de controle do programa. e) Fan-in/Fan-out uma medida do nmero de funes ou mtodos que chamam alguma outra funo ou mtodo.
28 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 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.
Prof. Victor Dalton
83 de 93
e) Confiabilidade; Funcionalidade; Usabilidade; Eficincia; Portabilidade; Manutenibilidade.
29 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. 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.
30 Questo) (FCC TJ/RJ Analista Judicirio - Analista de Sistemas - 2012) No que se refere a testes de software, correto afirmar que a) o teste de operao a fase onde testada a ergonomia da interface de uso do software. b) o teste da caixa preta (teste funcional), baseia-se em analisar os arquivos de log do sistema procurando por mensagens de funcionamento inconsistente. c) um teste bem sucedido um teste que no encontra nenhum erro no software. d) o teste da caixa branca (teste estrutural), baseia-se em testar as estruturas do cdigo fonte, como comandos condicionais e de repetio. e) um caso de teste uma categoria de possveis resultados na execuo de testes.
Prof. Victor Dalton
84 de 93
31 Questo) )(FCC Tribunal de Contas do Estado do Paran Analista de Controle Informtica - 2011) Segundo Sommerville, aps um sistema ser completamente integrado, possvel testar propriedades como a de desempenho do sistema. Neste contexto, considere: I. Testes de desempenho devem ser produzidos de forma a garantir que o sistema possa processar a sua carga prevista, sendo que tais testes geralmente so planejados para que a carga seja continuamente aumentada at que o sistema apresente desempenho fora do aceitvel. II. Os testes de desempenho devem determinar se um sistema corresponde s suas exigncias, sendo que a descoberta de defeitos ou problemas no sistema no enfoque desta etapa. III. Para determinar se o desempenho est sendo atingido, pode ser necessrio a construo de um perfil operacional, que a listagem de todo o grupo de operadores/usurios que faro uso deste sistema. Est correto o que se afirma em a) I, apenas. b) I, II, III. c) III, apenas. d) I e II, apenas. e) II e III, apenas.
32 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. 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.
Prof. Victor Dalton
85 de 93
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.
(CESPE MPE/PI Analista Ministerial Informtica - 2012) Acerca de teste de software, julgue os itens seguintes. 33 Os testes de unidade so feitos por equipes especializadas em testes, de forma a se garantir que os mdulos que compem o sistema sob construo estejam funcionando de acordo com as especificaes. 34 Em teste funcional, o conjunto de valores de entrada vlidos pode ser reduzido por meio de partio em classes de equivalncia, o que torna a quantidade de dados de entrada finita. 35 A matriz de estmulos e estados uma tcnica que, uma vez aplicada em testes funcionais, estimula que uma quantidade maior de combinaes seja testada.
(CESPE Ministrio da Educao e Cultura Atividade Tcnica de Complexidade Gerencial Gerente de Projetos - 2011) Com relao a teste de software, julgue os itens a seguir. 36 Para qualquer sistema, independentemente do seu tamanho, as etapas de teste devem seguir a seguinte sequncia: testes de componente, testes de integrao e testes de sistema. 37 Quando o objetivo testar uma funcionalidade, assegurando-se que, para todo tipo de entrada, a sada observada corresponda quela esperada, pode-se alcanar esse objetivo fazendo-se uso de testes do tipo caixa-branca. 38 Uma das desvantagens de se utilizar a mesma equipe de desenvolvimento para a realizao de testes a tendncia informalidade na sua execuo, o que pode provocar a no identificao de determinados defeitos do projeto.
39 Questo) (Formulao pessoal) Segundo Pressmann, cada um dos elementos de informao que so criados durante o desenvolvimento de um
Prof. Victor Dalton
86 de 93
produto de software, que so identificados de maneira nica e cuja evoluo passvel de rastreamento, refere-se a f) Item de software g) Componente de software h) Item de configurao i) Componente de dados j) Componente de programa
40 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 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
41 Questo) (Formulao Pessoal) Sobre o Gerenciamento de Mudanas, analise as afirmativas abaixo: 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.
Prof. Victor Dalton
87 de 93
e) Somente as afirmativas II, III e IV esto corretas.
42 Questo) (Formulao Pessoal) responsabilidade da Gerncia de Configurao: IV. Definir e controlar os componentes de servios e infraestrutura do sistema, mantendo informaes precisas sobre os estados dos servios e infraestrutura atual e planejada. V. 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. VI. 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.
43 Questo) (FCC Ministrio Pblico do Estado de Sergipe Analista do Ministrio Pblico Gesto e Anlise de Projeto de Sistema 2010) Em relao anlise e ao projeto orientados a objetos, correto afirmar: a) A orientao a objetos no leva em conta a utilizao da prototipao, dada as restries desse modelo de desenvolvimento de software quanto reusabilidade. b) Uma das regras de normalizao aplicada s tabelas de objetos de dados especifica que uma instncia de um objeto pode ter diversos valores para cada atributo. c) Se a informao sobre um objeto em potencial precisar ser lembrada para que o sistema possa funcionar, esse objeto no poder ser utilizado durante a anlise. d) Representar os objetos e suas relaes o principal objetivo do Diagrama Entidade-Relacionamento (E-R). e) Um Diagrama de Fluxo de Dados (DFD) deve, alm do fluxo da informao, descrever detalhadamente a lgica procedimental do sistema.
44 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas de Informao 2008) A linguagem de Modelagem Unificada (UML) emergiu como notao de diagramao de padro, de fato e de direito, para a modelagem orientada a objetos. Desta forma, a sentena que conceitua apropriadamente a UML, segundo o OMG-Object Management Group,
Prof. Victor Dalton
88 de 93
a) um mtodo para especificar e modelar os artefatos dos sistemas. b) um processo de especificao e modelagem de sistemas orientados a objeto. c) uma linguagem para implementar os conceitos da orientao a objetos. d) uma linguagem visual para especificar, construir e documentar os artefatos dos sistemas. e) um mtodo comum para a representao da orientao a objetos.
45 Questo) (ESAF Analista de Controle Externo Anlise de Sistemas 2002)Analise as seguintes afirmaes relativas UML: I. Ao uma abstrao representativa de entidades externas que interagem com um produto ou sistema; II. Atributo a descrio de um espao com nome e tipo, dentro de uma classe, onde cada objeto desta classe mantm um valor deste tipo; III. Classe o descritor para um conjunto de objetos que partilham os mesmos atributos, operaes, relacionamentos e comportamento; IV. Evento a condio ou situao de vida de um objeto durante a qual ele executa uma atividade. 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
46 Questo) (ESAF Agncia Nacional de guas Tecnologia da Informao e Comunicao Desenvolvimento de Sistemas - 2009) Em UML, o relacionamento utilizado para expressar herana entre classes e interfaces a a) multiplicidade. b) dependncia. c) agregao. d) associao. e) generalizao.
47 Questo) (FCC Companhia do Metropolitano de So Paulo Analista Desenvolvimento Gesto Jnior Cincias da Computao 2012) Sobre Programao Orientada a Objetos e UML, considere:
Prof. Victor Dalton
89 de 93
I. Os diagramas de classe so usados no desenvolvimento de um modelo de sistema orientado a objetos para mostrar as classes de um sistema e as associaes entre essas classes. II. A UML tem um tipo especfico de associao para denotar a generalizao. Em uma generalizao, os atributos e operaes associados com as classes de nvel alto (superclasses) tambm esto associados com as de nvel baixo (subclasses). III. A UML fornece um tipo especial de associao entre classes chamada agregao, que significa que um objeto (todo) composto de outros objetos (as partes). IV. Os modelos comportamentais descrevem o modelo esttico do domnio e qual a reao comportamental de interao entre as classes. Eles mostram o que acontece ou deve acontecer quando o sistema responde a um estmulo de seu ambiente. Est correto o que consta APENAS em a) I e II. b) I, III e IV. c) I, II e III. d) II, III e IV. e) III e IV.
48 Questo) (ESAF Analista de Controle Externo Anlise de Sistemas 2002 - adaptada) Um gerente de projeto sabe que o modo para descrever os vrios aspectos de modelagem pela UML por meio da notao definida pelos seus vrios tipos de diagramas. Em um determinado projeto, ele necessita de um diagrama esttico onde a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. O diagrama UML recomendado para suprir esta necessidade deste gerente o a) diagrama de componente. b) diagrama de comunicao. c) diagrama de sequencia. d) diagrama de classe. e) diagrama de implantao.
49 Questo) (ESAF Analista de Finanas e Controle Desenvolvimento de Sistemas de Informao 2008) Diagramas de pacotes UML so usados para ilustrar a arquitetura lgica de um sistema. Assinale a opo correta a respeito da aplicao de diagramas de pacotes UML. a) No permitem agrupar classes, outros pacotes e casos de uso. b) Camadas de Interface de Usurio-UI no podem ser modeladas como pacotes.
Prof. Victor Dalton
90 de 93
c) A dependncia (acoplamento) entre pacotes representada por uma Associao. d) Na UML, as associaes so definidas como o relacionamento semntico entre dois pacotes. e) Representam as camadas, subsistemas e pacotes (no significado Java).
50 Questo) (FCC Ministrio Pblico do Estado do Rio Grande do Norte Analista de Tecnologia da Informao Especialidade Engenharia de Software/Desenvolvimento de Sistemas - 2010) Na taxonomia dos diagramas de estrutura (S) e de comportamento (C) da UML, os diagramas de Pacote, Classe, Sequncia e Objeto so, respectivamente, de a) S, S, C e S. b) S, S, C e C. c) S, C, S e C. d) C, S, C e S. e) C, C, S e C.
51 Questo) (FCC Ministrio Pblico do Estado de Sergipe Analista do Ministrio Pblico Gesto e Anlise de Projeto de Sistema 2010) Dentre as etapas para o desenvolvimento de software em que a UML pode ser aplicada, aquela em que sero modeladas somente classes que pertenam ao domnio principal do problema do software, deixando de lado classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outras, a etapa de a) anlise de requisitos. b) anlise sistmica. c) projeto. d) implementao. e) testes/implantao.
52 Questo) (FCC Assemblia Legislativa do Estado de So Paulo Agente Tcnico Legislativo Tecnologia da Informao 2010) So consideradas metodologias geis de desenvolvimento de software: a) XP e UP. b) SCRUM e DSDM. c) SCRUM e RUP. d) DSDM e Cascata. e) Cascata e PRINCE2.
Prof. Victor Dalton
91 de 93
53 Questo) (FCC INFRAERO Analista de Sistemas/Arquitetura de Software 2011) Um dos principais conceitos do Scrum para atacar a complexidade do desenvolvimento e gerenciamento de software a implantao de um controle descentralizado, capaz de lidar mais eficientemente com contextos pouco previsveis. Para tanto, o gerenciamento distribudo por meio de trs agentes independentes que so: a) Product Owner, Scrum Team e Scrum Master. b) Product Owner, Product Backlog e Planning Meeting. c) Product Owner, Sprint e Planning Meeting. d) Sprint, Scrum Master e Planning Meeting. e) Sprint, Scrum Team e Product Backlog.
54 Questo) (FCC TRT 6 Regio Analista Judicirio Tecnologia da Informao 2012) Na metodologia Scrum, NO faz parte de uma reviso do sprint (sprint review) o seguinte procedimento: a) Todo o time colabora no que deve ser feito em seguida, de modo que esta reviso contribua para reunies de planejamento subsequentes. b) O proprietrio do produto identifica o que est pronto e o que ainda est por fazer. c) O time de desenvolvimento discute quais fatores positivos e negativos ocorreram durante o sprint e como os problemas foram resolvidos. d) O time de desenvolvimento apresenta o trabalho que foi desenvolvido e responde questes sobre o incremento. e) Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho. (CESPE TCE/ES Auditor de Controle Externo Tecnologia da Informao - 2012) Acerca de engenharia de software, julgue os itens subsecutivos. 55 O desenvolvimento de software no RUP organiza-se em seis fases: planejamento, levantamento de requisitos, anlise, implementao, testes e implantao. 56 Em virtude de as metodologias geis gerarem excessiva documentao, a gesto do conhecimento depende diretamente dos programadores envolvidos no projeto. 57 O Product Backlog, um dos artefatos utilizados na metodologia gil denominada Scrum, constitui-se da lista priorizada de todos os requisitos do produto final.
Prof. Victor Dalton
92 de 93
58 As entidades (entity) em UML (Unified Modeling Language) correspondem invariavelmente a tabelas de banco de dados, sendo necessrias para cumprir as responsabilidades do produto.
(CESPE Tribunal de Contas da Unio Auditor Federal de Controle Externo Tecnologia da Informao - 2010) Julgue os itens a seguir, relativos a modelos geis de processo. 59 O desenvolvimento adaptativo de software (DAS) uma tcnica para construo de sistemas e software complexos que foca na colaborao e na auto-organizao da equipe. 60 A agilidade no pode ser aplicada a todo e qualquer processo de software. 61 O processo XP (extreme programming) envolve a realizao das atividades de planejamento, de projeto, de codificao e de teste. 62 A atividade de planejamento XP inclui a criao das denominadas histrias de usurio, nas quais devem ser descritas as caractersticas e as funcionalidades requeridas para o software em desenvolvimento. 63 A atividade de projeto uma desvantagem do processo XP, pelo fato de requerer uma quantidade de produtos de trabalho considerada excessiva pela comunidade de desenvolvimento de software.
GABARITO 1.c 11.c 21.c 31.a 41.a 51.b 61.c 2.c 12.e 22.e 32.b 42.a 52.b 62.c 3.b 13.c 23.c 33.e 43.d 53.a 63.e 4.d 14.c 24.c 34.c 44.d 54.e 5.b 15.c 25.d 35.c 45.b 55.e 6.b 16.d 26.c 36.c 46.e 56.e 7.a 17.d 27.e 37.e 47.c 57.c 8.b 18.e 28.d 38.c 48.d 58.e 9.d 19.c 29.d 39.c 49.e 59.c 10.a 20.e 30.d 40.b 50.a 60.e
Prof. Victor Dalton
93 de 93

Aula 00

Hochgeladen von

Dokumentinformationen

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 00

Hochgeladen von

Copyright:

Verfügbare Formate

Questes Comentadas de TI para o Banco Central do Brasil Exerccios comentados Prof Victor Dalton Aula 00

AULA 00: Engenharia de Software

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

c) sequenciais, incrementais e evolutivos. d) sequenciais, geis e cascata. e) cascata, geis e evolutivos.

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

10 Questo) No texto, so requisitos funcionais:

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

A funo : a) Elaborao b) Negociao c) Especificao d) Validao e) Gesto

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Engenharia de Requisitos, segundo Sommerville

Prof. Victor Dalton

d) qualidade e de eficincia, em medidas diretas. e) velocidade de execuo e tcnica, em medidas diretas.

Prof. Victor Dalton

Prof. Victor Dalton

Manutenibilidade especficas no software.

Assimilados os conceitos? Alternativa d).

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

e) Aguardar uma falha no sistema para preencher uma Requisio de Mudana

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Exemplo de diagrama de classe UML.

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Diagrama de Caso de Uso

Diagrama de Sequncia Diagrama de Colaborao Diagrama de Atividade

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Portanto, nossa resposta correta a letra b).

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton

A funo : a) Elaborao b) Negociao c) Especificao d) Validao e) Gesto

Prof. Victor Dalton

Prof. Victor Dalton

Prof. Victor Dalton