-
No CMMI 1.3, a gestão de requisitos fica no nível 2 da Gestão de Projetos.
SG 1 Gerenciar requisitos
SP 1.1 Obter entendimento dos requisitos
SP 1.2 Obter comprometimento com os requisitos
SP 1.3 Gerenciar mudanças de requisitos
SP 1.4 Manter rastreabilidade bidirecional dos requisitos
SP 1.5 Identificar inconsistências entre trabalho de projeto e requisitos
-
Não entendi! Errei porque considerei a segunda parte incorreta: "são estabelecidas as funcionalidades do software."
Como assim? O propósito da REQM é: gerenciar requisitos dos produtos do projeto e componentes do produto e garantir que o alinhamento entre os requisitos e os planos do projeto e produtos de trabalho. (tradução minha)
Já no nível 3 tem o Desenvolvimento de Requisitos que a meu ver é quando as funcionalidades do software são estabelecidas:
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Transform Stakeholder Needs into Customer Requirements
Alguém?
-
solicitem o comentario do professor
-
No nível 2 do CMMI temos a área de processo Gestão de Configuração, que possui uma meta específica Acompanhar e Controlar Mudanças, e também a área de processo Gestão de Requisitos, que "mantém os requisitos. Ela descreve atividades para obter e controlar mudanças de requisitos e assegurar que outros planos e dados relevantes se mantenham atualizados.". Não sei se isso é suficiente para a primeira parte da questão estar certo.
Em relação às funcionalidades do software, vendo o CMMI isso me pareceu ser mais uma questão do nível 3. Na área de processo Desenvolvimento de Requisitos há a meta específica Analisar e Validar Requisitos, com a prática específica Estabelecer uma Definição da Funcionalidade Requerida. E na área de processo Solução Técnica há a meta específica Desenvolver Design, com a prática específica Desenvolver o Design do Produto ou dos Componentes de Produto, que fala "O design preliminar estabelece as principais funcionalidades e características do produto e sua arquitetura. [...] O design detalhado define completamente a estrutura e a funcionalidade dos componentes do produto.".
-
Bom é uma questão ai um pouco complicada mais vou esclarecer o meu entendimento
eu errei essa questão pois eu marquei errado e com isso eu fui atras de uma explicação.
No nível 2 de na categoria engenharia temos o processo de Gestão de Requisitos e não vou detalha-lo aqui vou apenas colocar umas frases chaves "controlar as mudanças" "identificar as inconsistências dos requisitos" "rastreabilidade"
dentro deste processo temos somente uma meta específica
Gerenciar Requisitos beleza?
O foco pessoal dessa meta é saber o que o cliente quer e capturar as necessidades de negócio dele em algum documento formal, algum documento de requisitos, algum conjunto de necessidades, depois que você fez isso, independente da técnica que você utilizou (aqui não importa isso por que lembre-se é uma gestão básica aqui no nível 2, as tecnicas serão utilizadas no nível 3) , você tem que gerenciar esses requisitos ao longo do ciclo de vida do projeto.
então pessoal para você fazer esse controle de mudanças, essa rastreabilidade, é preciso que antes você estabeleça as funcionalidades do software, pensando assim a questão está correta.
-
Eu estou com a Kamila, realmente, Gerenciamento de Requisitos é nível 2 (projeto) e o Desenvolvimento dos Requisitos (engenharia), é nível 3. Para mim, em termos de engenharia de software, primeiro devemos desenvolver requisitos e depois gerenciá-los. Eles são definidos no desenvolvimento. Desse pondo de vista. a questão estaria errada.
Acontece que o Bruno Dias aplicou um raciocínio lógico. Se eu estou gerenciado requisitos, eu preciso tê-los definido antes. Acontece que a lógica não costuma imperar em questão de concurso, mas sim o que está escrito.
Errei porque pensei nos nomes descritos no modelo. Esse é um daqueles casos que não tem para onde correr. Se o examinador quisesse dar a questão como errada, daria e justificaria.
-
bem... entendi da seguinte forma..A questão cita 2 áreas de processo do nível 2 do CMMI, sim.
1. definidos os requisitos para evitar a falta de controle nas mudanças: apesar de parecer que estamos falando de requisito, na verdade entendo isso como uma área de processo de "Gerencia ou Gestão da Configuração" em que ferramentas de controle de mudanças são aplicados. Ou seja, [SUPORTE, Nivel 2].
2. são estabelecidas funcionalidades do software: Aqui sim, estamos falando da area de processo de "gestão de requisitos". Ou seja, [Gestão de Projetos, Nível 2].
-
Questão CERTA !
Havia um processo na categoria de engenharia "Gestão de Requisitos" na versão CMMI 1.2 e hoje na versão CMMI 1.3 ele mudou de categoria e passou a ser da gestão de projeto. Nesse processo existe uma meta específica Gerenciar Requisitos em que o foco aqui é saber o que o cliente quer e capturar as necessidades dele, ou seja, as necessidades de negócio em algum documento formal mapeando as funcionalidades identificadas em algum documento de requisitos tipo CASOS DE USO. Isso tudo é independente da técnica utilizada para fazer essa elicitação porque aqui no nível 2 estamos em uma gestão básica e não padronizada, as técnicas só serão de definidas no nível 3 no desenvolvimento de requisitos seguindo um padrão. Para um bom entendedor e para quem já estudou Análise de Requisitos do capítulo do Sommervile. sabe das fases da analise de requisitos e sabe também que as FUNCIONALIDADES IDENTIFICADAS NESSA FASE serão registradas em um documento formal para que, depois de aceitas e validadas pelo cliente, esses requisitos serão gerenciados suas mudanças "GESTÃO DE REQUISITOS" para que a partir disso possamos passar para as fases de engenharia de software usadas no nível 3 CMMI.
Então... questão corretíssima !!
-
Processos do nivel 2 que validam a questão :
ReqM Gestão de requisitos
Pmc monitoramento e controle de projeto
Cm gestão de configuração
-
2 - Repetível
Gestão de Requisitos
Planejamento de Projeto de Software
Acompanhamento e Supervisão de Projeto de Software
Gestão de Subcontratação de Software
Garantia da Qualidade de Software
Gestão de Configuração de Software