Prova final de Engenharia de Requisitos AMPLI

Prévia do material em texto

Prova final: Engenharia de Requisitos
Acertos: 8 de 10
Nota: 48 pontos de 60 pontos 
Questão 1
Respondida
A engenharia de software é a disciplina responsável pelo processo de desenvolvimento de aplicações, aplicando uma abordagem de teorias, métodos e ferramentas para projetar e construir novos sistemas.
 
O engenheiro de software irá, por exemplo, estudar e aplicar técnicas para auxiliar no processo de elicitação de requisitos, além de aplicar boas práticas de programação no software que será construído, garantindo boa manutenibilidade e longevidade ao produto.
 
A engenharia de requisitos, por sua vez, se apresenta como um ramo da engenharia de software voltado para garantir que a metodologia adequada para cada fase da elicitação de requisitos seja feita de forma adequada e sistemática.
Assinale a alternativa que apresenta as fases da elicitação de requisitos, na ordem correta de acontecimentos.
· Gerenciamento de requisitos, levantamento de requisitos, validação, especificação e estudo de viabilidade.
· Estudo de viabilidade, especificação, levantamento de requisitos, validação e gerenciamento de requisitos.
· Especificação, estudo de viabilidade, validação, levantamento de requisitos e gerenciamento de requisitos.
· Estudo de viabilidade, levantamento de requisitos, especificação, validação e gerenciamento de requisitos.
· Estudo de viabilidade, especificação, gerenciamento de requisitos, levantamento de requisitos e validação.
Sua resposta
Estudo de viabilidade, levantamento de requisitos, especificação, validação e gerenciamento de requisitos.
A engenharia de requisitos é o ramo da engenharia de software responsável por todo o processo de elicitação de requisitos, compreendendo desde as fases iniciais de entendimento das necessidades do cliente e esboço inicial do conjunto de funcionalidades até a fase de validação dos requisitos funcionais e não funcionais que serão implementados pela aplicação.   As etapas do processo de elicitação de requisitos, na ordem que acontecem, são: Estudo de viabilidade – Momento a partir do qual se analisa a viabilidade técnica das funcionalidades necessárias para a aplicação, conforme a linguagem de programação e recursos técnicos que serão utilizados; Levantamento de requisitos – Fase na qual os requisitos serão mapeados sem muito detalhamento, ainda de forma macro; Especificação de requisitos – Momento do refinamento dos requisitos levantados, com detalhes técnicos sobre as regras de negócio envolvidas e especificações técnicas para a codificação; Validação dos requisitos – Fase na qual o refinamento dos requisitos será validado junto ao cliente; Gerenciamento de requisitos – Momento que os requisitos serão atualizados, quando necessário, mantendo a coerência entre o que está implementado na aplicação com a documentação disponível.
Questão 2
Respondida
Em metodologias tradicionais, como a cascata, cada fase do processo de desenvolvimento só inicia quando a fase anterior finaliza. Com a finalização de uma fase, artefatos são gerados e utilizados pela fase subsequente, dando continuidade ao projeto até sua finalização.
 
O sucesso ou fracasso de um projeto de software irá depender, dentre outros fatores, da forma como os requisitos foram especificados e detalhados, refletindo as necessidades do cliente. Caso um requisito seja especificado de forma confusa, ambígua ou não condizente com a real necessidade do usuário, sua devida implementação será feita de forma equivocada, ocasionando retrabalhos e/ou desuso da aplicação, a longo prazo.
 
Requisitos representam todas as ações que precisam ser providas pelo sistema a seus usuários (atores), de forma que podem ser classificados em funcionais (quando representam ações) e não funcionais (quando representam características de suporte aos requisitos funcionais).
 
Muitas vezes, os requisitos funcionais podem ser classificados em categorias, para definir suas devidas prioridades no sistema. Como exemplo, podemos categorizar requisitos em obrigatórios ou desejáveis, indispensáveis ou importantes, dentre outras escalas de classificação.
 
Existem diferentes origens de requisitos, visando atender aos mais variados tipos de necessidades das partes interessadas no projeto.
Com base em seus conhecimentos sobre as origens dos requisitos de uma aplicação, é correto afirmar que os requisitos externos são
· requisitos que restringem o comportamento da aplicação.
· requisitos originados de políticas empresariais ou do cliente.
· requisitos originados da relação entre o sistema e outros sistemas da Organização.
· requisitos relacionados com a maturidade do sistema que está sendo migrado de plataforma e/ou linguagem de programação.
· requisitos relacionados com pesquisas feitas em sistemas do mesmo domínio, que tenham o mesmo propósito.
Sua resposta
requisitos originados da relação entre o sistema e outros sistemas da Organização.
Requisitos visam englobar todas as ações e funcionalidades que devem ser providas pelo sistema ou aplicação, de modo que deve ser especificada em conjunto com o cliente, em rodadas de entrevistas.   Em projetos grandes, podem existir diversos tipos de partes interessadas, cada um com seus objetivos e expectativas em relação ao produto, que pode se refletir em requisitos com prioridades diferentes.   Considerando as origens dos tipos de requisitos de uma aplicação, podemos mencionar:   Requisitos do produto – Compreendem as necessidades dos usuários com o produto que está sendo desenvolvido; Requisitos organizacionais – São os requisitos originados das políticas Empresariais ou do cliente, como a definição da linguagem de programação na qual o produto será desenvolvido; Requisitos externos – Todos os requisitos que são provenientes de fontes externas à aplicação, como a interoperabilidade dela com outras aplicações da Organização e/ou fora dela, Leis, dentre outros fatores.   A partir dessa classificação, é possível explorar mais situações que auxiliem aos envolvidos na análise de requisitos da aplicação a encontrarem situações anteriormente não previstas e que são importantes para o andamento do projeto. Ferramentas como tempestade de ideias e a matriz de priorização podem ser utilizadas, também, para que os requisitos levantados possam ser priorizados.
Questão 3
Respondida
Planejar é uma tarefa fundamental em qualquer fase de qualquer projeto. Saber o que será implementado, a forma como será construído e seguir um cronograma são exemplos de planejamento em diferentes fases.
 
Com testes não é diferente. É preciso ter documentado quais funcionalidades serão entregues em cada pacote da aplicação, de modo a planejar os testes destas funcionalidades.
 
O Plano de testes entra, então, como um importante artefato para reunir as principais informações sobre os testes que precisarão ser realizados em uma aplicação, detalhando a forma como estes testes deverão ser realizados, permitindo, assim, a replicação dos testes até mesmo por pessoas que não conhecem as funcionalidades da aplicação que será testada em seus melindres.
 
Os membros da equipe de desenvolvimento só poderão executar os testes em uma funcionalidade apenas no caso desta não ter sido codificada pelo desenvolvedor que irá executar os testes. Isso é importante para evitar os “vícios de testes”, tendo em vista que o desenvolvedor que implementou o requisito tende a utilizar sempre as mesmas entradas, evitando os fluxos alternativos. Desenvolvedores que não tiveram um contato inicial com o requisito a ser testado, por outro lado, irão executar os testes com entradas diferentes, muitas vezes seguindo etapas diferentes para a funcionalidade, o que poderá ser mais eficaz na detecção de erros e nos ajustes necessários.
 
Com base no contexto e em seus conhecimentos sobre o Plano de testes, analise as afirmativas a seguir:
I.   Testes de carga e acessos simultâneos podem fazer parte do plano de testes da aplicação;
II.  Cada aplicação terá os testes necessários para seus requisitos funcionais e não funcionais;
III. Apenas os requisitos funcionais serãoinseridos no plano de testes de uma aplicação.
Considerando o contexto apresentado, é correto o que se afirma em:
· I, apenas.
· I e II, apenas.
· I e III, apenas.
· I, II e III.
· III, apenas.
Sua resposta
I e II, apenas.
Alternativa correta: I e II, apenas.   O documento do Plano de testes, além de informações básicas sobre o projeto, deverá englobar todos os tipos de testes necessários para cada aplicação, como carga, stress, segurança, performance, dentre outros. Além disso, os requisitos funcionais e não funcionais da aplicação precisarão ter seus respectivos testes descritos, com o objetivo de sanar eventuais falhas na implementação.   Os testes dos requisitos da aplicação, sejam eles funcionais ou não funcionais, precisam seguir os cenários de teste para cada critério de validação da funcionalidade. Quanto mais critérios de validação forem testados de forma minuciosa, maior será a qualidade da aplicação que será entregue, e, consequentemente, maior será a satisfação dos interessados com o produto.   Aplicações que, após serem entregues ao usuário final, apresentam uma alta taxa de erros e problemas detectados, são reflexos da pouca quantidade de testes efetuados em seus requisitos ou do baixo detalhamento dos testes, no que diz respeito ao número de possibilidades nos cenários de testes criados ou à falta de experiência de quem elaborou o documento, muitas vezes sem a supervisão de outro analista mais experiente da equipe.   I.   Testes de carga e acessos simultâneos podem fazer parte do plano de testes da aplicação. Correta. O plano de testes tem o objetivo de englobar todos os tipos de testes necessários para uma aplicação, como os testes de carga e de quantidade de acessos simultâneos. II.  Cada aplicação terá os testes necessários para seus requisitos funcionais e não funcionais. Correta. Os testes a serem realizados em cada aplicação serão conforme as necessidades de seus requisitos funcionais e não funcionais.   III. Apenas os requisitos funcionais serão inseridos no plano de testes de uma aplicação. Incorreta. Tantos os requisitos funcionais como os não funcionais precisam ser inseridos no plano de testes para validação.
Questão 4
Respondida
Toda funcionalidade de um sistema tem, por objetivo, ser utilizado por um ator, que deverá disparar esta ação através de algum tipo de interação com a aplicação.
 
Os diagramas UML, que visam modelar visualmente os atores e as interações entre estes e as funcionalidades do sistema, são denominados de diagramas de caso de uso. Mas não somente este tipo de diagrama serve como apresentação visual.
 
Diagramas de sequência, que visam apresentar o sequenciamento de passos, a partir do evento inicial que disparará a ação no sistema até a resposta final retornada, também utilizam a imagem dos atores, para definir quem irá utilizar a funcionalidade.
 
Na metodologia ágil, com as Histórias de usuário, também se deve definir e especificar claramente quem será a persona que irá fazer uso do requisito, detalhando como aquela ação deverá ocorrer no sistema e com qual propósito.
 
Todos esses diagramas e documentos mencionados serão apresentados às partes interessadas na aplicação, para que possam validar e/ou corrigir eventuais falhas de entendimento, adequando a funcionalidade ao real interesse do cliente, fazendo com que o sistema de fato agregue valor e tenha uma vida útil longa.
 
Com base no contexto e em seus conhecimentos sobre o conceito de ator, analise as afirmativas a seguir:
I.   Ator pode ser tanto um usuário do sistema, quanto outro sistema que possa disparar uma ação;
II.  Ator é apenas o usuário humano do sistema, não sendo considerado ator um outro sistema que faça interação com a aplicação que será construída;
III. Ator pode ser um serviço WEB, desde que este dispare uma ação no sistema que será construído.
Considerando o contexto apresentado, é correto o que se afirma em:
· I, apenas.
· I e II, apenas.
· I e III, apenas
· I, II e III.
· III, apenas.
Sua resposta
I e III, apenas
Alternativa correta: I e III, apenas.   O ator, ou persona, de uma aplicação poderá ser representado tanto por uma pessoa (usuário do sistema), quanto por outro sistema ou serviço, contanto que estes disparem alguma ação na aplicação que será construída.   Dessa forma, é importante identificar e mapear quais as funcionalidades que irão compor a aplicação e quem irá utilizar este requisito, de modo a mapear esta relação através dos diagramas de caso de uso ou de sequência, facilitando a compreensão do todo pelas partes interessadas (stakeholders) da aplicação.   Então, se uma aplicação externa irá executar alguma solicitação para uma funcionalidade da aplicação que está sendo construída, esta aplicação externa é o ator que irá disparar tal função, da mesma forma que um usuário humano faria, através da interação com uma tela e clicando em algum botão, por exemplo.   Então, no caso de serviços WEB, como são considerados aplicações externas, caso estes interajam de alguma forma com a aplicação que será implementada de modo a disparar uma ação e esperar por uma resposta desta, será sim considerado um ator para a funcionalidade que irá depender deste gatilho.   I.   Ator pode ser tanto um usuário do sistema, quanto outro sistema que possa disparar uma ação; Correto. Ator não é representado apenas por um humano, mas sim por tudo que possa estar interagindo com a aplicação, seja outra aplicação ou uma pessoa. II.  Ator é apenas o usuário humano do sistema, não sendo considerado ator um outro sistema que faça interação com a aplicação que será construída; Incorreto. Ator não é representado apenas por um humano, mas sim por tudo que possa estar interagindo com a aplicação, seja outra aplicação ou uma pessoa.   III. Ator pode ser um serviço WEB, desde que este dispare uma ação no sistema que será construído. Correto. No caso de serviços WEB, como são considerados aplicações externas, caso estes interajam de alguma forma com a aplicação que será implementada de modo a disparar uma ação e esperar por uma resposta desta, será sim considerado um ator para a funcionalidade que irá depender deste gatilho.
Questão 5
Respondida
Nas fases iniciais de um projeto, os documentos gerados não estão sendo escritos pensados em evitar problemas de ambiguidade e inconsistências. O intuito inicial será, apenas, obter os requisitos necessários para que a aplicação possa ser construída, com as regras de negócio necessárias.
 
Com o andamento das fases do projeto, serão realizados ajustes nos requisitos inicialmente especificados, como ajustes na escrita para garantir um melhor entendimento das regras de negócio ou solucionar ambiguidades.
 
Ao passar do tempo, documentos do projeto podem se tornar obsoletos, caso suas evoluções não acompanhem as alterações efetuadas nos requisitos. Outro ponto importante de atenção, em relação aos documentos gerados, é a ocorrência de inconsistências, decorrentes da falha na atualização dos documentos necessários do projeto.
 
Repositórios de documentos podem ser utilizados para que versões dos documentos possam ser mantidas, mas, ainda assim, é necessária intervenção do analista responsável pela manutenção destes documentos para que, ao final do projeto, possam estar refletindo a realidade dos requisitos implementados.
 
Consulta a documentos desatualizados, mesmo após a finalização do projeto, podem ocasionar em entendimentos errados das regras de negócio, além de não ser possível rastrear todos os ajustes feitos nos requisitos, ao longo do projeto.
Levando em consideração o texto acima e seus conhecimentos sobre o gerenciamento dos documentos do projeto, é correto afirmar que o gerenciamento pode ser resolvido através da implementação da técnica
· TUCCA, para garantir que os casos de uso reflitam as necessidades do cliente.
· TDD, garantindo que os testes dos requisitos serão construídos anteriormente à fase de implementação deles.
· BDD, para garantir que o comportamento da aplicação irá se refletir nos requisitos implementados.
· Análise manual por especialista,garantindo que uma pessoa com conhecimento do negócio poderá atualizar da melhor forma a documentação.
· Visão baseada em perspectiva do usuário final, garantindo que o usuário final será responsável pela atualização da documentação do projeto.
Sua resposta
TDD, garantindo que os testes dos requisitos serão construídos anteriormente à fase de implementação deles.
A partir da técnica de Desenvolvimento Baseado em Comportamento (BDD), a documentação terá que ser atualizada, anteriormente ao processo de codificação da funcionalidade, para que o comportamento da aplicação reflita as alterações realizadas.   Desta forma, todos os documentos necessários para detalhar o comportamento que o sistema deve ter para uma funcionalidade deverá ser descrito, de forma detalhada, nos documentos gerados. Caso alguma inconsistência seja resultante da alteração nas regras de negócio geradas, este problema não se refletirá na documentação, já que a revisão será uma ação constante e feita de forma a englobar todos os artefatos gerados.   Mesmo com a utilização de um repositório de documentos, similar aos repositórios de código fonte da aplicação, não existe uma garantia que os documentos armazenados nestes repositórios estarão atualizados, conforme a fase atual da aplicação, já que será necessária uma intervenção manual em cada documento armazenado, realizando as devidas alterações.   Com a técnica BDD, além de estar elaborando os testes de forma antecipada, como acontece com a técnica TDD, o processo de elaboração da documentação também será otimizado, de modo que os ajustes nas regras de negócio precisam ser feitos, em primeiro lugar, na documentação para que possam ser implementados pela equipe responsável.
Questão 6
Sem resposta
O processo de levantamento de requisitos precisa ser feito com muito cuidado e atenção, a fim de evitar retrabalhos e insatisfação por parte do cliente. Um dos motivos pelo qual a equipe que será responsável pelo projeto precisará se atentar é garantir que as funcionalidades acordadas para a aplicação estejam completas e sem inconsistências.
 
Completude de um requisito se refere à especificação de todas as regras de negócio necessárias para a implementação deste, de modo que a equipe de desenvolvimento não tenha dúvidas quanto as regras acordadas. Consistência, por sua vez, representa a inexistência de conflitos entre regras de negócio, seja no pré-requisito para a funcionalidade ou na dependência entre diferentes requisitos.
Considerando o contexto apresentado, é um fator que pode acarretar inconsistência nos requisitos
· a ausência de regras de negócio para validação.
· a inexistência de um plano de testes para o requisito.
· o escopo da aplicação.
· os conflitos de interesse entre diferentes partes interessadas.
· regras que podem ter duplo entendimento.
Sua resposta
os conflitos de interesse entre diferentes partes interessadas.
Para que um requisito possa ser considerado pronto para o processo de codificação, é preciso que ele esteja completo, ou seja, com todas as suas regras de negócio especificadas e devidamente documentadas, de forma que a equipe de desenvolvimento não tenha dúvidas, e consistente, ou seja, suas premissas (ou pré-requisitos) não podem estar em conflito com outros requisitos existentes na aplicação.   Nas fases iniciais do projeto, quando ainda o objetivo é elencar todas as funcionalidades necessárias para a aplicação, sem muita preocupação em manter a consistência, é comum que, em projetos com muitas partes interessadas, haja conflitos de interesse que ocasionem requisitos conflitantes, ditos inconsistentes. Neste caso, será necessário chegar a um consenso com as partes interessadas, de modo a dirimir estas inconsistências.   A inconsistência está relacionada com as premissas e relação com os demais requisitos do sistema, de modo que um requisito ou premissa não poderá conflitar com outro requisito existente (não podem ser contraditórios).
Questão 7
Sem resposta
É notável a evolução nas metodologias de desenvolvimento de sistemas desde que a metodologia tradicional cascata surgiu. O grande objetivo era otimizar o processo de entregas e feedback do cliente, adequando o produto às reais necessidades dos interessados ao longo do projeto, evitando, assim, um problema típico da metodologia cascata: a inadequação do produto às expectativas, tendo em vista o longo tempo de duração do projeto.
 
A metodologia em espiral (ou incremental) foi a precursora das metodologias mais interativas com o cliente, como as ágeis. Com fases que podem ser revistas, ajustadas e reexecutadas, conforme as necessidades do cliente, o produto poderá ir se ajustando ao longo do processo, garantindo uma melhor adequação do esperado como entrega final ao que foi proposto nas fases iniciais do projeto.
 
O framework SCRUM, por exemplo, representa um exemplo de metodologia que evoluiu com base na metodologia incremental, no qual o escopo do projeto não é totalmente definido logo nas primeiras fases da elicitação de requisitos, podendo acrescentar novas funcionalidades ao longo do projeto, desde que devidamente ajustados com o cliente.
 
A grande vantagem das metodologias ágeis sobre as tradicionais é a existência de entregas constantes de partes do produto que podem ser utilizadas já em ambiente de produção, sem a necessidade de aguardar todo o projeto ser finalizado.
Com base em seus conhecimentos sobre as metodologias de desenvolvimento, assinale a alternativa que apresenta uma característica da metodologia incremental.
· Cliente tem a possibilidade de fornecer feedbacks constantes sobre as entregas parciais para realização de ajustes.
· Não é possível realizar alterações no conjunto de funcionalidades após a fase de implementação ter sido iniciada.
· As entregas parciais são descartadas a cada nova entrega, de modo que são disponibilizadas apenas para que o cliente valide o comportamento da aplicação.
· O escopo da aplicação não pode ser alterado após a fase de elicitação de requisitos.
· Cliente irá esperar um longo tempo até que o produto seja entregue e possa ser utilizado em produção.
Sua resposta
Cliente tem a possibilidade de fornecer feedbacks constantes sobre as entregas parciais para realização de ajustes.
A metodologia incremental (ou espiral) representa uma evolução da metodologia em cascata, na qual cada fase só se inicia com a finalização da fase anterior. Com o processo em espiral, uma mesma etapa pode acontecer diversas vezes, sempre buscando a melhoria contínua e o processo de validação do que está sendo construído.   As metodologias ágeis, por sua vez, têm o objetivo de aproximar o cliente do processo de codificação da aplicação, sempre mantendo-o informado sobre todas as fases, esclarecendo eventuais dúvidas sobre os requisitos levantados e validando as entregas parciais (também conhecidas como incrementos), que podem ser utilizadas já em produção pelos interessados.   O conjunto de funcionalidades da aplicação, que na metodologia em cascata precisaria estar totalmente fechado e sem a possibilidade de alteração, na metodologia ágil poderá ser alterado a qualquer momento do andamento do projeto, podendo incluir, excluir ou modificar os requisitos já especificados, conforme a necessidade dinâmica do cliente.   Quando novos pacotes são entregues, por serem incrementos de uma aplicação que está sendo construída, estes irão compor, como peças de um quebra cabeças, as entregas já feitas, agregando ao produto parcial o que já está pronto e validado pelo stakeholder.
Questão 8
Sem resposta
A fase de elicitação de requisitos é de suma importância para o sucesso do projeto, garantindo que o produto a ser construído atenderá de forma efetiva às necessidades dos clientes. Esta fase do projeto será composta pelas subfases de entrevistas com o cliente, refinamento dos requisitos e validação, compondo o documento de especificação de requisitos.
 
Para que o processo de levantamento de funcionalidades possa acontecer com mais efetividade, técnicas podem ser aplicadas pelo analista de requisitos.O objetivo, com estas técnicas, é conseguir identificar regras de negócio ocultas e de difícil percepção apenas com entrevistas.
 
A fase de validação dos requisitos irá finalizar o processo de elicitação, estabelecendo um acordo com o cliente acerca do conjunto de funcionalidades que será contemplada pela aplicação.
 
 
De acordo com as informações apresentadas na tabela a seguir, faça a associação das técnicas para levantamento de requisitos, apresentadas na Coluna A com suas respectivas descrições, apresentadas na Coluna B.
 
	Coluna A
	Coluna B
	I.              Levantamento orientado a ponto de vista
	1-    Voltada para criação de uma única visão do comportamento da aplicação para todos os interessados.
	II.            JAD
	2-    Se baseia na observação do ambiente no qual a aplicação estará inserida para levantar seus requisitos de negócio.
	III.           Etnografia
	3-    Se baseia na visão dos diferentes interessados no produto para definir quais as funcionalidades da aplicação.
Assinale a alternativa que apresenta a associação CORRETA entre as colunas:
· I-1, II-2, III-3.
· I-1, II-3, III-2.
· I-3, II-1, III-2.
· I-2, II-1, III-3.
· I-3, II-2, III-1.
Sua resposta
I-3, II-1, III-2.
Alternativa correta: I-3, II-1, III-2.   As técnicas para levantamento de requisitos podem ser aplicadas de forma individual ou em conjunto com outras técnicas, conforme as necessidades do produto e a facilitação que cada técnica pode prover para o projeto específico.   Técnicas como entrevistas e workshops podem ser utilizadas, por exemplo, durante as primeiras reuniões de entendimento do negócio e das necessidades dos stakeholders, de modo que, ao longo do processo de refinamento dos requisitos, outras técnicas podem ser aplicadas, com a finalidade de auxiliar na identificação de regras de negócio ocultas.   A técnica de levantamento orientado a ponto de vista tem o objetivo de identificar as funcionalidades de uma aplicação a partir dos diferentes pontos de vista de cada interessado no projeto.   A técnica JAD tem o objetivo de criar uma visão única do produto para o entendimento de todos os interessados, de modo que eles possam interagir em uma dinâmica em grupo, a fim de realizar os ajustes necessários para que todos os interesses possam ser atendidos da melhor forma.   A técnica de etnografia é baseada na observação, pelo analista de requisitos, do contexto no qual a aplicação será inserida, identificando as regras de negócio que geralmente são de difícil explicação pelo cliente.
Questão 9
Sem resposta
O gerenciamento do projeto de software deve ter eficiência através do uso da matriz de rastreabilidade de requisitos. O gestor de TI da Mitsubishi Co. sabe que depois que adotou a matriz de rastreabilidade (RTM) percebeu muitas vantagens por ampliar as chances de sucesso na implementação do software. Diante do contexto, analise a influência da matriz de rastreabilidade de requisitos no gerenciamento de projeto de software:
 
I. Na composição das atividades de projetos, os artefatos a serem entregues podem variar de acordo com os requisitos que sofrerão modificação, previstos na matriz de rastreabilidade de requisitos.
II. Em função da grande quantidade de itens a serem modificados, conforme consta na matriz de rastreabilidade de requisitos, atrapalha a estimativa de prazos no cronograma do gerenciamento de projetos de software.
III. Na preparação do ambiente de testes, recursos administrados pelo gestor de projeto de software, passa a ser uma tarefa bastante precisa por ter a dimensão adequada aos requisitos relacionados.
IV. Na preparação do ambiente de testes, recursos administrados pelo usuário do sistema, passa a ser uma tarefa bastante precisa por ter a dimensão adequada aos requisitos relacionados.
Assinale a alternativa correta.
· Somente I está correta.
· Somente I, II e IV estão corretas.
· Somente III e IV estão corretas.
· Somente II está correta.
· Somente I e III estão corretas.
Sua resposta
Somente I e III estão corretas.
(V) Na composição das atividades de projetos, os artefatos a serem entregues podem variar de acordo com os requisitos que sofrerão modificação, previstos na matriz de rastreabilidade de requisitos. Correta. (F) Em função da grande quantidade de itens a serem modificados, conforme consta na matriz de rastreabilidade de requisitos, atrapalha a estimativa de prazos no cronograma do gerenciamento de projetos de software. Incorreta. A quantidade não será impacto negativo na estimativa, ao contrário quanto mais completa a matriz, maior será a precisão da estimativa. (V) Na preparação do ambiente de testes, recursos administrados pelo gestor de projeto de software, passa a ser uma tarefa bastante precisa por ter a dimensão adequada aos requisitos relacionados. Correta. (F) Na preparação do ambiente de testes, recursos administrados pelo usuário do sistema, passa a ser uma tarefa bastante precisa por ter a dimensão adequada aos requisitos relacionados. Incorreta. Este ambiente é administrado pelo gestor do projeto de software.
Questão 10
Sem resposta
Num caso apresentado em Reinehr (2020, páginas 17 e 18), uma Startup sempre busca inovação, pois a sua proposta é ser diferente e avante à sua época, o que leva a depender de requisitos desafiadores que nunca foram implementados ou experimentados.
Por ocasião, verifica-se que muitos problemas de entendimento ou cumprimento de implementação de modificações de requisitos, segundo Wiegers e Beatty (2013), estão baseados em fatores diversos que podem ser motivadores para uma Startup aumentar as chances de sucesso em seus projetos. Analise as afirmativas que podem afetar na qualidade dos requisitos e do desenvolvimento de software.
I. Os clientes argumentaram que todos os requisitos eram críticos, por isso eles não estabeleceram prioridades causando falta de controle em mudanças de requisitos.
II. A falta de tempo dos clientes para se dedicarem mais trabalhando com os analistas ou os desenvolvedores nos requisitos não tem impacto na qualidade dos requisitos.
III. Os objetivos de negócio, a visão e o escopo do projeto nunca definidos claramente causam falhas na definição dos requisitos.
Assinale a alternativa com a(s) afirmativa(s) verdadeira(s).
· Somente I
· Somente I e II
· Somente II e III
· Somente III
· Somente I e III
Sua resposta
Somente III
Afirmativa II - “A falta de tempo dos clientes para se dedicarem mais trabalhando com os analistas ou os desenvolvedores nos requisitos não tem impacto na qualidade dos requisitos.” Falsa. É correto dizer que os clientes estavam muito ocupados para dedicar mais tempo trabalhando com os analistas ou os desenvolvedores nos requisitos. Por outro lado, o entendimento adequado dos requisitos é base para definir prioridades. Afirmativas I e III estão corretas de acordo com os critérios de sucesso em projetos “I. Os clientes argumentaram que todos os requisitos eram críticos, por isso eles não estabeleceram prioridades causando falta de controle em mudanças de requisitos. III. Os objetivos de negócio, a visão e o escopo do projeto nunca definidos claramente causam falhas na definição dos requisitos.”