Avaliação com base no PMBOK 6

• Achado I – Os projetos são iniciados sem a elicitação dos requisitos do projeto e da solução. Proposição de melhoria: A especificação de todos os requisitos do projeto deve ser obtida no

• início do projeto. Logo após, deve ser realizado o planejamento detalhado de todas as entregas necessárias antes do início do desenvolvimento.

• Achado II – Os cronogramas são falhos e devem ser revistos sempre que mudam os requisitos. Proposição de melhoria: Não é necessário elaborar cronogramas ou quaisquer controles de entrega, pois, em ciclos iterativos, não há como mensurar prazos de entrega.

Avaliação com base no Scrum 2020

• Achado III – As perguntas “Por que a sprint é valiosa?” e “O que pode ser feito nessa sprint?” são respondidas como tópicos na sprint planning e, com base nelas, é definido o trabalho entregue na sprint. Proposição de melhoria: Incluir na sprint planning a pergunta “Como o trabalho escolhido será realizado?”, com vistas a compor a sprint backlog.

• Achado IV – A meta do produto não é desenvolvida a contento e a equipe não é comunicada claramente sobre os itens do product backlog pelo product owner. Proposição de melhoria: Criar um comitê gestor de tecnologia da informação e comunicação (TIC) especificamente incumbido de garantir que a meta do produto e que o product backlog sejam desenvolvidos e compreendidos pelo scrum team, uma vez que product owner não é responsável pelo gerenciamento do product backlog.

• Achado V – Não há evento que permita avaliar o que deu certo durante a sprint. Da mesma forma, não há discussão sobre como os problemas foram resolvidos ou não. Proposição de melhoria: Estabelecer a execução da sprint review como o evento que conclua a sprint, com vistas a inspecionar o seu resultado. Avaliação com base na XP

• Achado VI – Não há evento que permita avaliar se as alterações realizadas por cada membro da equipe deixam o código consistente — ou seja, não são realizados testes para verificar se há algum problema a ser corrigido imediatamente a cada envio do código pelo programador. Proposição de melhoria: Não é necessário promover esse tipo de teste, pois, no desenvolvimento ágil, ao final de cada sprint, o resultado é considerado parte de um incremento, ou seja, “pronto”.

Avaliação com base no COBIT 2019

• Achado VII – Não há avaliação em relação à governança de TI sobre o método de desenvolvimento de software da organização. Proposição de melhoria: É indiferente para a governança de TI se a organização utiliza o modelo Cascata, o DevOps ou o desenvolvimento ágil, pois isso está relacionado ao nível operacional da TI.

• Achado VIII – A cascata de objetivos está sendo utilizada em paralelo com a gestão ágil de projeto nos projetos considerados estratégicos. Proposição de melhoria: Implementar áreas de focos relacionadas aos problemas a serem resolvidos, pois, no COBIT 2019, a cascata de objetivos foi substituída pelas áreas de foco (focus area).

Tendo como referência essa situação hipotética, redija, na condição de auditor responsável pela avaliação dos dados apresentados no relatório final de auditoria da empresa contratada, um texto dissertativo posicionando-se favorável ou contrariamente a cada proposição de melhoria dos achados mencionados.

Ao elaborar seu texto, identifique o item avaliado (achado I, achado II etc.), apresente sua avaliação acerca da respectiva proposição de melhoria e justifique sua avaliação. Nos(s) caso(s) em que eventualmente concordar com o relatório hipotético em apreço, justifique sua avaliação com base em elementos que complementem, embasem ou reforcem a adequação da proposição de melhoria apresentada. No(s) caso(s) em que eventualmente discordar do relatório hipotético em apreço, apresente o devido embasamento e sugira uma proposição de melhoria apropriada para o achado.

(45 Linhas)

(5,0 Pontos)

A prova foi realizada sem consulta a códigos e(ou) legislação.

O post Q134859 apareceu primeiro em Treine Subjetivas.

• O gestor da área de RH informou que esse sistema de informação deve permitir somente ao chefe do RH a gestão dos dados de pagamento dos colaboradores. Além disso, o sistema deve permitir que os colaboradores e o chefe do RH realizem consulta por nome do colaborador utilizando, no mínimo, 3 caracteres na pesquisa. Avaliação I: “Isso não pode ser modelado por meio de diagrama da UML, por se tratar de requisitos não funcionais.”

• O gestor da área de RH informou que cada colaborador está alocado em somente um departamento, que um departamento possui vários funcionários (no mínimo dois), que cada departamento possui um chefe e que todo chefe é colaborador. É necessário saber quem é chefe de quem. Avaliação II: “Isso pode ser modelado por meio do MER, que consiste em um diagrama da UML voltado para modelagem de banco de dados.”

• Os desenvolvedores afirmaram que, conforme norma do órgão, o sistema deve ser desenvolvido utilizando-se Java 8 e SGBD PostgreSQL 12 em múltiplas camadas, usando-se como referência o MVC (model-view-controller) em que cada camada deve ficar em uma máquina virtual distinta. Além disso, deve-se usar a arquitetura orientada a serviços em uma plataforma web com JBOSS 7. Avaliação III: “Isso não pode ser modelado por meio de diagrama da UML, por se tratar de área de arquitetura da solução que envolve itens de hardware.”

• Os desenvolvedores solicitaram que fossem realizados testes do tipo unitário ou de unidade a partir das descrições de casos de uso. Avaliação IV: “Não é possível atender a essa solicitação, pois não cabe essa recomendação para esse tipo de teste: testes do tipo unitário ou de unidade não podem ser realizados a partir das descrições de casos de uso.”

• O gerente de projeto informou que será utilizado o Guia do Scrum 2020 para condução do desenvolvimento, mas os desenvolvedores informaram que não possuem conhecimento sobre Scrum, somente sobre XP. Avaliação V: “Nesse caso, recomenda-se solicitar ajuda ao PO (product owner), responsável pela implementação do Scrum, tal como definido no referido Guia.”

• Os desenvolvedores solicitaram a manutenção do uso da integração contínua no desenvolvimento dos sistemas. Avaliação VI: “A prática integração contínua da XP não pode mais ser utilizada, por ser incompatível com o Scrum, adotado como guia para o desenvolvimento.”

Considerando essa situação hipotética, redija, na condição de auditor, um texto analisando cada uma das avaliações emitidas pelo gerente de projeto a respeito dos tópicos apresentados e posicione-se favorável ou contrariamente a cada avaliação, tendo como referência a UML 2, o Scrum 2020 e a XP. Em seu texto, identifique a avaliação analisada (I, II, III, IV, V e VI) e informe se você concorda com a avaliação, com base nesse referencial. Em caso de concordância com a avaliação, complemente-a, informando seu ponto de vista em relação às partes mencionadas na reunião. Em caso de discordância com a avaliação, aponte o(s) aspecto(s) considerado(s) equivocado(s), justificando sua resposta.

Ao abordar as avaliações I, II e III, responda se existe diagrama da UML que modele o requisito em questão e qual seria seu objetivo e, caso não haja, explique como o requisito deve ser modelado. Ao abordar a avaliação IV, discorra sobre os objetivos dos testes do tipo unitário ou de unidade. Ao abordar a avaliação V, informe se a função em questão cabe ao PO e apresente, pelo menos, duas responsabilidades do PO, de acordo com o Guia do Scrum. Ao abordar a avaliação VI, discorra sobre o objetivo da integração contínua e informe se ela pode ser utilizada no Scrum.

(30 Linhas)

(25 Pontos)

A prova foi realizada sem consulta a códigos e(ou) legislação.

O post Q134836 apareceu primeiro em Treine Subjetivas.