Fala, galera.<\/p>\n
<\/p>\n
Achei a prova mais pesada do que eu esperava. Por conta da \u00faltima prova (em que sobraram vagas), eu achei que essa viria mais leve, mas n\u00e3o foi t\u00e3o assim (principalmente a discursiva). Est\u00e3o dizendo por a\u00ed que talvez sobrem vagas de novo… vamos aos coment\u00e1rios (mais tarde tem webin\u00e1rio ao vivo).<\/p>\n
<\/p>\n
76<\/strong>. (Dificuldade: F\u00e1cil)\u00a0<\/strong>Metodologias de desenvolvimento \u00e1gil enfocam atividades de projeto e implementa\u00e7\u00e3o, desconsiderando as atividades de elicita\u00e7\u00e3o de requisitos e a produ\u00e7\u00e3o de documenta\u00e7\u00e3o.<\/strong><\/p>\n Errado. \u00c9 absurdo pensar que se desconsidera atividades de elicita\u00e7\u00e3o de requisitos – n\u00e3o h\u00e1 o que se discutir nesse ponto. Al\u00e9m disso, o Manifesto \u00c1gil afirma que, mesmo havendo valor na documenta\u00e7\u00e3o extensa de software, valoriza-se mais o software em funcionamento. Em outras palavras, \u00e9 errado afirmar que se desconsidera a produ\u00e7\u00e3o de documenta\u00e7\u00e3o, tendo em vista que h\u00e1 uma codifica\u00e7\u00e3o n\u00e3o formal. N\u00f3s ressaltamos isso\u00a0em aula:<\/p>\n “O manifesto enfatiza que os itens \u00e0 direita (Documenta\u00e7\u00e3o Abrangente) t\u00eam seu valor, entretanto os itens \u00e0 esquerda (Software em funcionamento) s\u00e3o mais valorizados!\u00a0Por que valorizar mais software em funcionamento do que documenta\u00e7\u00e3o abrangente?<\/em>\u00a0Porque apresentar software funcionando aos clientes em uma reuni\u00e3o\u00a0\u00e9 mais \u00fatil e desejado do que apresentar documentos<\/strong>“.<\/p>\n <\/p>\n 77.\u00a0(Dificuldade: F\u00e1cil)\u00a0No ciclo de vida do software, o congelamento dos requisitos do software garante que este, quando em desenvolvimento, atenda \u00e0 expectativa do usu\u00e1rio, desde que tudo que tenha sido requisitado seja implementado.<\/strong><\/p>\n Errado. Requisitos n\u00e3o s\u00e3o est\u00e1ticos, s\u00e3o din\u00e2micos e precisam ser refinados constantemente. O processo de defini\u00e7\u00e3o de requisitos gera um feedback que acaba modificando os pr\u00f3prios requisitos. Dessa forma, \u00e9 evidente que o congelamento de requisitos n\u00e3o garante o atendimento \u00e0 expectativa do usu\u00e1rio. Em geral, usu\u00e1rios n\u00e3o sabem o que querem; aqueles que sabem, mudam de opini\u00e3o durante o processo de desenvolvimento de software. Logo, mesmo que tudo que foi requisitado tenha sido implementado, pode n\u00e3o atender \u00e0s expectativas do usu\u00e1rio, tendo em vista que, logo ap\u00f3s o congelamento dos requisitos, o usu\u00e1rio pode muito bem querer modific\u00e1-lo.<\/p>\n <\/p>\n 78.\u00a0(Dificuldade: F\u00e1cil)\u00a0<\/strong>A aplica\u00e7\u00e3o da an\u00e1lise de pontos de fun\u00e7\u00e3o determina o custo do software a ser desenvolvido, independentemente dos \u00edndices de produtividade de cada empresa.<\/strong><\/p>\n Errado. A APF permite determinar indiretamente o custo do software a ser desenvolvido, no entanto \u00e9 necess\u00e1rio saber hist\u00f3ricos de \u00edndices de produtividade de cada empresa. Conforme eu disse em aula:<\/p>\n <\/p>\n 79.\u00a0(Dificuldade: Dif\u00edcil)\u00a0A m\u00e9trica conhecida como resposta para uma classe relaciona o n\u00edvel de complexidade de uma determinada classe com a quantidade de intera\u00e7\u00f5es que ela faz com objetos de outras classes.<\/strong><\/p>\n Errado. A banca foi muito, mas muito profunda nesse item! Eu confesso que nunca havia ouvido falar nessa m\u00e9trica. Trata-se de uma m\u00e9trica orientada a objetos, criada em 1994, chamada Response for a Class (Resposta para uma Classe) e mede a complexidade de uma classe por meio da quantidade de m\u00e9todos diferentes que potencialmente podem ser executados em resposta a uma mensagem recebida por um objeto dessa classe. Dessa forma, n\u00e3o se trata da quantidade de intera\u00e7\u00f5es que ela faz com objetos \u2013 \u00e9 mais espec\u00edfico: \u00e9 a quantidade de m\u00e9todos que podem ser executados em uma classe, em resposta a uma solicita\u00e7\u00e3o (invoca\u00e7\u00e3o de um m\u00e9todo). Quanto maior, mais dif\u00edcil ser\u00e1 de manter e testar a classe. Logo, se o objeto de uma Classe X recebe uma mensagem e ele pode potencialmente executar cinco m\u00e9todos dentro dessa classe, ent\u00e3o RFC = 5.<\/p>\n <\/p>\n 80.\u00a0(Dificuldade:\u00a0M\u00e9dia)\u00a0<\/strong>A aplica\u00e7\u00e3o de m\u00e9tricas est\u00e1ticas de produto \u00e9 comumente usada para se avaliar a complexidade de um software.<\/strong><\/p>\n Correto. As m\u00e9tricas din\u00e2micas s\u00e3o aquelas coletadas durante a execu\u00e7\u00e3o de um programa; as m\u00e9tricas est\u00e1ticas s\u00e3o aquelas coletadas de representa\u00e7\u00f5es do sistema como projeto, programa ou documenta\u00e7\u00e3o. De fato, \u00e9 comum utilizar m\u00e9tricas est\u00e1ticas para avaliar a complexidade e manuten\u00e7\u00e3o de um software, por meio – por exemplo – de um Modelo de Design.<\/p>\n “Professor, como uma organiza\u00e7\u00e3o consegue saber qual deve ser a produtividade esperada para um projeto que ainda ir\u00e1 se iniciar?\u00a0Bem, isso pode ocorrer de duas maneiras: ela pode manter um reposit\u00f3rio privado com dados sobre seus projetos anteriores ou ela pode utilizar um reposit\u00f3rio p\u00fablico com dados de diversos projetos para realizar essas estimativas<\/strong>“.<\/em><\/p>\n <\/p>\n 84.\u00a0(Dificuldade:\u00a0F\u00e1cil)\u00a0<\/strong>Uma forma de valida\u00e7\u00e3o dos requisitos \u00e9 a gera\u00e7\u00e3o de casos de teste para os requisitos documentados.<\/strong><\/p>\n Correto. Foram explicitadas tr\u00eas t\u00e9cnicas de valida\u00e7\u00e3o de requisitos: Revis\u00e3o de Requisitos, Prototipa\u00e7\u00e3o e Gera\u00e7\u00e3o de Casos de Teste. Para este \u00faltimo, foi dito em aula:<\/p>\n “Enfim, uma s\u00e9rie de t\u00e9cnicas de valida\u00e7\u00e3o de requisitos pode ser usada em conjunto ou individualmente, entre elas:\u00a0Gera\u00e7\u00e3o de Casos de Teste<\/strong>\u00a0– os requisitos devem ser test\u00e1veis. Se os testes dos requisitos forem criados como parte do processo de valida\u00e7\u00e3o, eles frequentemente revelar\u00e3o problemas de requisitos. Se um teste for dif\u00edcil ou imposs\u00edvel de ser projetado, significa geralmente que os requisitos ser\u00e3o dif\u00edceis de serem implementados e devem ser reconsiderados para implementa\u00e7\u00e3o”.<\/em><\/p>\n <\/p>\n 85. (Dificuldade: F\u00e1cil)\u00a0<\/strong>A defini\u00e7\u00e3o de um prot\u00f3tipo para a valida\u00e7\u00e3o dos requisitos pode tornar o processo de requisitos mais barato e mais simplificado, j\u00e1 que ele vai corresponder \u00e0 real forma de uso do sistema a ser constru\u00eddo.<\/strong><\/p>\n Errado. Observem que a quest\u00e3o afirma que ‘pode tornar o processo mais barato e simplificado’. Quando o item afirma que ‘pode’, ele abre margem para muitas interpreta\u00e7\u00f5es – facilitando nossa vida. E, sim, ele pode tornar o processo mais barato e simplificado. No entanto, o prot\u00f3tipo n\u00e3o necessariamente vai corresponder \u00e0 real forma de uso do sistema a ser constru\u00eddo. Na verdade, o prot\u00f3tipo, em geral, \u00e9 utilizado para validar requisitos de alto n\u00edvel, logo ele n\u00e3o vai contemplar diversas funcionalidades que estar\u00e3o no sistema real. Pressman afirma:<\/p>\n “Yet, prototyping can be problematic for the following reasons: 1. Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven\u2019t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high levels of quality can be maintained, stakeholders cry foul and demand that \u201ca few fixes\u201d be applied to make the prototype a working product. Too often, software development management relents”.<\/em><\/p>\n <\/p>\n 86.\u00a0(Dificuldade: F\u00e1cil)\u00a0Os requisitos n\u00e3o funcionais a serem especificados estabelecer\u00e3o restri\u00e7\u00f5es que devem ser seguidas por todo o sistema da referida empresa, podendo at\u00e9 mesmo levar \u00e0 necessidade de defini\u00e7\u00e3o de requisitos funcionais.<\/strong><\/p>\n Correto. Observem novamente que a quest\u00e3o afirma ‘podendo at\u00e9 levar’, logo ela abre margem para muitas interpreta\u00e7\u00f5es – facilitando nossa vida. E, sim, a defini\u00e7\u00e3o de requisitos n\u00e3o-funcionais pode levar a defini\u00e7\u00e3o de requisitos funcionais.<\/p>\n <\/p>\n 87. (Dificuldade: F\u00e1cil)\u00a0<\/strong>Para a elicita\u00e7\u00e3o dos requisitos, \u00e9 indicada \u00e0 empresa a realiza\u00e7\u00e3o de um workshop de requisitos, em que seja determinado um facilitador, mesmo que sem grande experi\u00eancia com os processos de gerenciamento de requisitos.<\/strong><\/p>\n Correto. Bem, alguns podem argumentar que n\u00e3o \u00e9 t\u00e9cnica mais indicada. No entanto, a quest\u00e3o n\u00e3o afirma isso, ela apenas afirma que \u00e9 indicada \u2013 e, de fato, ela \u00e9 indicada para elicita\u00e7\u00e3o de requisitos. Al\u00e9m disso, conforme eu disse em aula, o facilitador deve ser neutro e respons\u00e1vel por atividades de log\u00edstica, organiza\u00e7\u00e3o, etc. Muitas vezes, ele n\u00e3o precisa ser sequer um cara da \u00e1rea de tecnologia, pode ser um cara da \u00e1rea de gest\u00e3o de pessoas, por exemplo.\u00a0Seu papel \u00e9 facilitar o workshop, mas \u2013 similar ao Scrum Master no contexto de Gest\u00e3o de Projetos de Desenvolvimento de Software \u2013 n\u00e3o precisa ter nenhuma experi\u00eancia espec\u00edfica no gerenciamento de requisitos. A quest\u00e3o poderia at\u00e9 ser pass\u00edvel de recurso se falasse ‘sem experi\u00eancia alguma’, mas como ela disse apenas ‘sem GRANDE\u00a0experi\u00eancia’, eu a avalio como correta. O facilitador deve ter experi\u00eancia em facilitar Conforme vimos em aula:<\/p>\n “Reuni\u00e3o estruturada e intensiva entre analistas e usu\u00e1rios com o intuito de obter um conjunto de requisitos bem definidos.\u00a0Possui um facilitador neutro respons\u00e1vel pelas atividades de log\u00edstica e promo\u00e7\u00e3o de momentos de descontra\u00e7\u00e3o<\/strong>, como forma de dinamizar o trabalho em equipe. Permite utilizar t\u00e9cnicas como brainstorming ou interpreta\u00e7\u00e3o de pap\u00e9is”.<\/em><\/p>\n <\/p>\n 88.\u00a0(Dificuldade: M\u00e9dio)\u00a0As mudan\u00e7as de requisitos em processos \u00e1geis de desenvolvimento n\u00e3o seguem um processo formal de gerenciamento de requisitos<\/strong><\/p>\n Correto. De fato, as mudan\u00e7as de requisitos em processos \u00e1geis de desenvolvimento seguem um processo mais informal de gerenciamento. N\u00e3o h\u00e1, por exemplo, documenta\u00e7\u00e3o extensa ou matrizes de rastreabilidade. Metodologias \u00e1geis n\u00e3o podem se dar ao luxo de processos formais, em geral.<\/p>\n <\/p>\n 89.\u00a0(Dificuldade: F\u00e1cil)\u00a0As informa\u00e7\u00f5es de rastreabilidade de requisitos possibilitam a realiza\u00e7\u00e3o de estimativa do custo de mudan\u00e7as em requisitos<\/strong><\/p>\n Correto. Mais uma vez, a banca nos ajuda com esse ‘possibilitam’. Como a rastreabilidade permite avaliar impacto, possibilita estimar o custo de mudan\u00e7as em requisitos. Conforme foi dito em aula:<\/p>\n “\u00c9 preciso manter o acompanhamento dos requisitos individuais e manter as liga\u00e7\u00f5es entre os requisitos dependentes,\u00a0de modo que seja poss\u00edvel avaliar o impacto das mudan\u00e7as de requisitos (rastreabilidade)<\/strong>. \u00c9 necess\u00e1rio, tamb\u00e9m, estabelecer um processo formal para fazer propostas de mudan\u00e7a e lig\u00e1-las aos requisitos de sistema”.<\/em><\/p>\n <\/p>\n 90.\u00a0(Dificuldade: F\u00e1cil)\u00a0<\/strong>T\u00e3o logo exista uma vers\u00e3o do documento de requisitos, o processo de gerenciamento de requisitos dever\u00e1 ser iniciado.<\/strong><\/p>\n Correto. Essa quest\u00e3o estava quase\u00a0ipsis litteris\u00a0<\/em>em nosso material. Vejam abaixo:<\/p>\n “O processo de gerenciamento de requisitos deve se iniciar assim que uma vers\u00e3o inicial do documento de requisitos esteja dispon\u00edvel<\/strong>, mas o planejamento das mudan\u00e7as de requisitos deve ser iniciado durante o processo de elicita\u00e7\u00e3o de requisitos. A evolu\u00e7\u00e3o de requisitos, durante o processo de engenharia de requisitos e ap\u00f3s a entrada de um sistema em opera\u00e7\u00e3o, \u00e9 inevit\u00e1vel”.<\/em><\/p>\n <\/p>\n 91.\u00a0(Dificuldade: Dif\u00edcil)\u00a0Em arquiteturas orientadas a servi\u00e7o, um servi\u00e7o deve ser implementado de forma a garantir um fraco acoplamento.<\/strong><\/p>\n Correto. Para quem participou do curso, ficou f\u00e1cil. N\u00f3s dissemos que h\u00e1, entre os princ\u00edpios da Arquitetura Orientada a Servi\u00e7os, o Princ\u00edpio do Baixo\/Fraco Acoplamento (Service Loose Coupling).<\/p>\n <\/p>\n 92.\u00a0(Dificuldade: Dif\u00edcil)\u00a0Embora normalmente os sistemas desenvolvidos se baseiem em padr\u00f5es de arquitetura, cada um deles tem arquitetura totalmente espec\u00edfica, em consequ\u00eancia dos seus requisitos.<\/strong><\/p>\n Errado. De fato, eu posso usar padr\u00f5es de arquitetura, tais como uma arquitetura em camadas, uma arquitetura distribu\u00edda, uma arquitetura mainframe ou uma arquitetura orientada a servi\u00e7os. Embora cada sistema tenha uma arquitetura baseada em seus requisitos, elas n\u00e3o s\u00e3o TOTALMENTE espec\u00edficas.<\/p>\n <\/p>\n 94.\u00a0(Dificuldade: Dif\u00edcil )\u00a0As informa\u00e7\u00f5es relativas a formato de protocolo e mensagem s\u00e3o associadas \u00e0s opera\u00e7\u00f5es (elementos operation) por meio de elementos binding.<\/strong><\/p>\n Correto. N\u00f3s vimos em aula que o elemento <operation> trata da especifica\u00e7\u00e3o das assinaturas das opera\u00e7\u00f5es disponibilizadas (na se\u00e7\u00e3o abstrata) e o elemento <binding> trata dos protocolos de comunica\u00e7\u00e3o utilizados (na se\u00e7\u00e3o concreta). Os elementos <binding> associam detalhes\u00a0de formato de protocolo e mensagem \u00e0s\u00a0opera\u00e7\u00f5es.<\/p>\n <\/p>\n 95.\u00a0(Dificuldade: Dif\u00edcil)\u00a0Em uma arquitetura de portal corporativo, a camada web \u00e9 a respons\u00e1vel por prover a integra\u00e7\u00e3o com os sistemas de bancos de dados da organiza\u00e7\u00e3o.<\/strong><\/p>\n Errado. Quem participou do curso viu em nossa aula as quatro camadas. A quest\u00e3o trata da Camada de Conectores e, n\u00e3o, Web.<\/p>\n “Aplica\u00e7\u00f5es Web:<\/strong>\u00a0engloba uma grande variedade de solu\u00e7\u00f5es, dependendo de seu contexto, tais como: intranet, internet, correio eletr\u00f4nico, f\u00f3rum de discuss\u00f5es, business, groupware, workflow, CMS, etc. Conectores:\u00a0<\/strong>essa camada \u00e9 respons\u00e1vel pelo controle de acesso e integra\u00e7\u00e3o entre sistemas de informa\u00e7\u00f5es, tais como bancos de dados, sistemas legados, ERP, CRM, entre outros”.<\/em><\/p>\n <\/p>\n \u00c9 isso, espero que voc\u00eas tenham gostado! Grande abra\u00e7o e at\u00e9 a pr\u00f3xima…<\/p>\n","protected":false},"excerpt":{"rendered":" Fala, galera. Achei a prova mais pesada do que eu esperava. Por conta da \u00faltima prova (em que sobraram vagas), eu achei que essa viria mais leve, mas n\u00e3o foi t\u00e3o assim (principalmente a discursiva). Est\u00e3o dizendo por a\u00ed que talvez sobrem vagas de novo… vamos aos coment\u00e1rios (mais tarde tem webin\u00e1rio ao vivo). […]<\/p>\n","protected":false},"author":131,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"post_tipo":"article","footnotes":""},"categories":[],"tags":[743],"tax_estado":[],"class_list":["post-26640","post","type-post","status-publish","format-standard","hentry","tag-ati-mpog"],"acf":[],"yoast_head":"\n