Foram encontradas 260 questões.
Provas
I. da Entidade estabelece que o patrimônio pertence à entidade e que não se confunde com o patrimônio dos seus sócios ou proprietários.
II. da Continuidade pressupõe que a Entidade continuará em operação no futuro e, portanto, a mensuração e a apresentação dos componentes do patrimônio não precisam levar em conta esta circunstância.
III. do Registro pelo Valor Original determina que os componentes do patrimônio devem ser inicialmente registrados pelos valores originais das transações, expressos em moeda nacional.
IV. da Competência determina que os efeitos das transações e outros eventos sejam reconhecidos nos períodos em que ocorrem os respectivos recebimentos ou pagamentos.
Está correto o que se afirma em
Provas
- Para responder às questões de números 30 a 33 utilize como base os conhecimentos disponíveis no Guia PMBoK.
Sobre as técnicas e ferramentas utilizadas para estimar os custos do projeto, considere:
I. A opinião especializada, guiada por informações históricas, fornece um discernimento valioso sobre o ambiente e informações de projetos passados similares.
II. Estimativa análoga de custos usa os valores de parâmetros, como escopo, custo, orçamento e duração ou medidas de escala como tamanho, peso e complexidade de um projeto anterior semelhante, como base para estimar o mesmo parâmetro ou medida para um projeto atual.
III. A estimativa paramétrica utiliza uma relação estatística entre dados históricos e outras variáveis para calcular uma estimativa para parâmetros da atividade, como custo, orçamento e duração.
IV. A estimativa bottom-up permite estimar cada atividade ou item de trabalho separadamente para depois reuni-las ou agregá-las em uma estimativa total de custo do projeto. É uma alternativa adequada para fazer uma estimativa dos custos do projeto na fase de Iniciação.
Está correto o que se afirma APENAS em
Provas
- Para responder às questões de números 30 a 33 utilize como base os conhecimentos disponíveis no Guia PMBoK.
Provas
O sucesso depende do foco em saber o que se quer
Em 1982, o Sr. Hiroshito I. Hossaka abriu sua primeira escola de datilografia no bairro do Bom Retiro em São Paulo e logo no primeiro mês já contabilizava uma clientela de 30 alunos matriculados. Anos depois, em 1989, o mesmo curso, já modernizado, utilizava computadores da linha IBM PC AT em 9 filiais espalhadas pelo estado de São Paulo com um total de 550 alunos. Nessa época, todo o controle de caixa e de matrículas era feito utilizando o software Lotus 1-2-3.
Com o crescimento constante do número de filiais e de alunos matriculados, o Sr. Hiroshito percebeu que o controle via planilha não era mais suficiente. Adquiriu alguns softwares de prateleira comercializados em lojas de varejo, mas todos não atendiam suas necessidades. Nessa época, a rede de escolas do Sr. Hiroshito já ministrava cursos em diversas áreas do conhecimento, como informática, enfermagem, eletrônica e contabilidade.
Em 1998, impulsionado pelo apelo das mídias especializadas em tecnologia, o Sr. Hiroshito decidiu contratar uma empresa especializada no desenvolvimento de software para criar um sistema que permitisse integrar todos os processos e resultados da empresa (como compras de materiais, matrículas, cursos, funcionários, contabilidade etc.). Por três anos, a empresa de desenvolvimento contratada manteve especialistas em contato direto com os funcionários das diversas áreas da empresa, levantando suas necessidades. Muitas das necessidades relatadas nunca foram implementadas e diversas delas, por terem sido relatadas de forma imprecisa e dando margem à ambiguidade, foram implementadas de maneira incorreta ou deficiente. Frequentemente, os preços e o prazo de entrega prometidos eram alterados. Um ano depois, a contratada havia aumentado em 40% o preço pedido para a fabricação do software e em 60% o prazo de entrega. Além desses gastos, para atender às necessidades de hardware, software e infraestrutura para executar o sistema e integrar todas as filiais, o Sr. Hiroshito já havia gasto o que equivaleria nos dias de hoje a cerca de 1,5 milhões de reais.
Três anos se passaram e o software, que parecia a galinha dos ovos de ouro, se tornou um pesadelo para o Sr. Hiroshito, que já cogitava voltar a fazer os controles por meio das velhas planilhas de cálculo. Não era homem de desistir facilmente, mas quando toda a parte já desenvolvida do sistema (do qual já tinha certa dependência) parou de funcionar por uma semana sem que a contra-tada apresentasse uma solução clara e coerente, ele rompeu o contrato. A empresa contratada foi penalizada legalmente a devolver 30% dos valores já pagos pelo software.
Por cerca de um ano, todos os controles voltaram a ser feitos por planilhas de cálculo e editores de texto, enquanto o Sr. Hiroshito contratava uma equipe de TI própria para desenvolver um novo sistema. Em 2004, a equipe de TI contava com 1 gerente de projetos, 10 analistas de sistemas, 15 programadores, 2 administradores de banco de dados e 3 especialistas em infraestrutura de redes e servidores. Apesar das perdas geradas pelo fracasso do software anterior, a rede de escolas do Sr. Hiroshito estava em franco crescimento e mais 5 novos cursos passaram a ser oferecidos. Naquele ano, após autorização do MEC, foi inaugurada a Faculdade Integrada Hiroshito. Para dar foco ao novo nicho de mercado voltado para os cursos superiores, ele vendeu a rede de escolas e ficou apenas com a faculdade recém inaugurada.
A equipe de TI recém-contratada foi incumbida de desenvolver o sistema para a faculdade. Para realizar a tarefa, foi feito um levantamento inicial dos softwares, equipamentos de informática e telecomunicações necessários. Teve início também nesse mesmo ano o desenvolvimento do software. A equipe de TI adotou o grupo de conhecimentos de engenharia de requisitos e as melhores práticas no gerenciamento e desenvolvimento de projetos.
Em junho de 2006, 60% das funcionalidades do software haviam sido desenvolvidas atendendo as expectativas do Sr. Hiroshito. O desenvolvimento do software até esse período havia superado em 32% o valor previsto inicialmente, porém, o software havia contribuído com um aumento de 75% no faturamento da empresa. Em janeiro de 2008, o software tinha 90% de suas funcionalidades desenvolvidas e 10% delas foram descartadas por extrapolarem muito o orçamento previsto. Nessa época, o Sr. Hiroshito comemorava a terceira filial da faculdade com muito otimismo.
(Pedro Henrique Leuret, inédito)
Informações adicionais:
Dentre os requisitos obtidos para a construção do software constavam:
1. O software deve permitir as funções de cadastro, consultas diversas, alteração de dados e exclusão de alunos, professores e demais colaboradores.
2. O sistema deve ser fácil de usar, fácil de encontrar o que se procura e fácil de memorizar os passos para executar as operações mais comuns.
3. O sistema deve ter seu funcionamento baseado nas tecnologias web.
4. Todas as operações disponibilizadas no sistema devem contemplar a legislação vigente.
5. O sistema deve fazer interface com o sistema da Receita Federal por meio de requisições/respostas utilizando XML.
6. Os alunos devem poder obter por meio do sistema informações sobre suas faltas e notas em cada disciplina.
7. O boletim e o histórico do aluno poderão ser consultados e visualizados pelos gestores, funcionários da secretaria e pelo próprio aluno.
8. Ao clicar em uma opção para gerar o boletim do aluno, deve ser apresentada ao solicitante uma tabela com todas as disciplinas que o aluno cursou, bem como as notas das provas e o número total de faltas em cada disciplina.
9. O sistema deve responder à solicitação de geração do boletim de um aluno em no máximo 10 segundos.
10. O sistema deve calcular a média aritmética das duas maiores dentre três notas de cada disciplina no final do semestre.
11. Quando o sistema constatar que o aluno tem mais que 25% de faltas em uma disciplina do semestre, deve ser exibida no boletim do aluno a informação "Reprovado".
12. O sistema deverá suportar a execução em qualquer plataforma de hardware e/ou sistema operacional.
13. O sistema deve enviar automaticamente para o e-mail dos gestores autorizados um relatório com o número de alunos inadimplentes por curso.
14. O sistema não deve revelar quaisquer dados pessoais dos alunos aos professores, exceto informações sobre notas e faltas no curso em que o professor leciona.
15. O sistema deve permitir que o professor inclua ou modifique as notas de seus alunos durante o semestre letivo.
16. A quantidade de memória necessária para que um terminal possa executar o sistema nas condições mínimas aceitáveis é de 1 gigabyte.
17. A taxa aceitável de falhas nas operações realizadas pelo usuário no sistema deve ser de 1 falha para cada 200 operações.
18. O sistema e sua respectiva documentação deverão ser entregues em um ano a partir da data atual.
19. O sistema não deve permitir operações que beneficiem alguns usuários em detrimento de outros.
20. A interface do usuário deve ser construída utilizando HTML5 e CSS.
21. Se a média do aluno por disciplina, calculada no final do semestre, for menor do que 7, deve ser exibido no boletim do aluno a informação "Reprovado".
− Para responder à questão utilize como base os conhecimentos disponíveis no Guia PMBoK.
Um dos processos de gerenciamento do tempo do projeto é o que permite desenvolver o cronograma do projeto. Uma das técnicas utilizadas no desenvolvimento do cronograma é a que permite mostrar o caminho crítico no diagrama de redes. A figura a seguir mostra um fragmento de um diagrama de redes.
| Número da atividade | Duração |
| Primeira data de início | Primeira data de término |
| Última data de início | Última data de término |
Considere que as datas de início e término de cada atividade referem-se à quantidade de dias passados desde o início do projeto. Por exemplo, a última data de término da atividade 3.1 será 22 dias após o início do projeto.
No fragmento de diagrama de redes apresentado, o caminho crítico passa pelas atividades
Provas
O sucesso depende do foco em saber o que se quer
Em 1982, o Sr. Hiroshito I. Hossaka abriu sua primeira escola de datilografia no bairro do Bom Retiro em São Paulo e logo no primeiro mês já contabilizava uma clientela de 30 alunos matriculados. Anos depois, em 1989, o mesmo curso, já modernizado, utilizava computadores da linha IBM PC AT em 9 filiais espalhadas pelo estado de São Paulo com um total de 550 alunos. Nessa época, todo o controle de caixa e de matrículas era feito utilizando o software Lotus 1-2-3.
Com o crescimento constante do número de filiais e de alunos matriculados, o Sr. Hiroshito percebeu que o controle via planilha não era mais suficiente. Adquiriu alguns softwares de prateleira comercializados em lojas de varejo, mas todos não atendiam suas necessidades. Nessa época, a rede de escolas do Sr. Hiroshito já ministrava cursos em diversas áreas do conhecimento, como informática, enfermagem, eletrônica e contabilidade.
Em 1998, impulsionado pelo apelo das mídias especializadas em tecnologia, o Sr. Hiroshito decidiu contratar uma empresa especializada no desenvolvimento de software para criar um sistema que permitisse integrar todos os processos e resultados da empresa (como compras de materiais, matrículas, cursos, funcionários, contabilidade etc.). Por três anos, a empresa de desenvolvimento contratada manteve especialistas em contato direto com os funcionários das diversas áreas da empresa, levantando suas necessidades. Muitas das necessidades relatadas nunca foram implementadas e diversas delas, por terem sido relatadas de forma imprecisa e dando margem à ambiguidade, foram implementadas de maneira incorreta ou deficiente. Frequentemente, os preços e o prazo de entrega prometidos eram alterados. Um ano depois, a contratada havia aumentado em 40% o preço pedido para a fabricação do software e em 60% o prazo de entrega. Além desses gastos, para atender às necessidades de hardware, software e infraestrutura para executar o sistema e integrar todas as filiais, o Sr. Hiroshito já havia gasto o que equivaleria nos dias de hoje a cerca de 1,5 milhões de reais.
Três anos se passaram e o software, que parecia a galinha dos ovos de ouro, se tornou um pesadelo para o Sr. Hiroshito, que já cogitava voltar a fazer os controles por meio das velhas planilhas de cálculo. Não era homem de desistir facilmente, mas quando toda a parte já desenvolvida do sistema (do qual já tinha certa dependência) parou de funcionar por uma semana sem que a contra-tada apresentasse uma solução clara e coerente, ele rompeu o contrato. A empresa contratada foi penalizada legalmente a devolver 30% dos valores já pagos pelo software.
Por cerca de um ano, todos os controles voltaram a ser feitos por planilhas de cálculo e editores de texto, enquanto o Sr. Hiroshito contratava uma equipe de TI própria para desenvolver um novo sistema. Em 2004, a equipe de TI contava com 1 gerente de projetos, 10 analistas de sistemas, 15 programadores, 2 administradores de banco de dados e 3 especialistas em infraestrutura de redes e servidores. Apesar das perdas geradas pelo fracasso do software anterior, a rede de escolas do Sr. Hiroshito estava em franco crescimento e mais 5 novos cursos passaram a ser oferecidos. Naquele ano, após autorização do MEC, foi inaugurada a Faculdade Integrada Hiroshito. Para dar foco ao novo nicho de mercado voltado para os cursos superiores, ele vendeu a rede de escolas e ficou apenas com a faculdade recém inaugurada.
A equipe de TI recém-contratada foi incumbida de desenvolver o sistema para a faculdade. Para realizar a tarefa, foi feito um levantamento inicial dos softwares, equipamentos de informática e telecomunicações necessários. Teve início também nesse mesmo ano o desenvolvimento do software. A equipe de TI adotou o grupo de conhecimentos de engenharia de requisitos e as melhores práticas no gerenciamento e desenvolvimento de projetos.
Em junho de 2006, 60% das funcionalidades do software haviam sido desenvolvidas atendendo as expectativas do Sr. Hiroshito. O desenvolvimento do software até esse período havia superado em 32% o valor previsto inicialmente, porém, o software havia contribuído com um aumento de 75% no faturamento da empresa. Em janeiro de 2008, o software tinha 90% de suas funcionalidades desenvolvidas e 10% delas foram descartadas por extrapolarem muito o orçamento previsto. Nessa época, o Sr. Hiroshito comemorava a terceira filial da faculdade com muito otimismo.
(Pedro Henrique Leuret, inédito)
Informações adicionais:
Dentre os requisitos obtidos para a construção do software constavam:
1. O software deve permitir as funções de cadastro, consultas diversas, alteração de dados e exclusão de alunos, professores e demais colaboradores.
2. O sistema deve ser fácil de usar, fácil de encontrar o que se procura e fácil de memorizar os passos para executar as operações mais comuns.
3. O sistema deve ter seu funcionamento baseado nas tecnologias web.
4. Todas as operações disponibilizadas no sistema devem contemplar a legislação vigente.
5. O sistema deve fazer interface com o sistema da Receita Federal por meio de requisições/respostas utilizando XML.
6. Os alunos devem poder obter por meio do sistema informações sobre suas faltas e notas em cada disciplina.
7. O boletim e o histórico do aluno poderão ser consultados e visualizados pelos gestores, funcionários da secretaria e pelo próprio aluno.
8. Ao clicar em uma opção para gerar o boletim do aluno, deve ser apresentada ao solicitante uma tabela com todas as disciplinas que o aluno cursou, bem como as notas das provas e o número total de faltas em cada disciplina.
9. O sistema deve responder à solicitação de geração do boletim de um aluno em no máximo 10 segundos.
10. O sistema deve calcular a média aritmética das duas maiores dentre três notas de cada disciplina no final do semestre.
11. Quando o sistema constatar que o aluno tem mais que 25% de faltas em uma disciplina do semestre, deve ser exibida no boletim do aluno a informação "Reprovado".
12. O sistema deverá suportar a execução em qualquer plataforma de hardware e/ou sistema operacional.
13. O sistema deve enviar automaticamente para o e-mail dos gestores autorizados um relatório com o número de alunos inadimplentes por curso.
14. O sistema não deve revelar quaisquer dados pessoais dos alunos aos professores, exceto informações sobre notas e faltas no curso em que o professor leciona.
15. O sistema deve permitir que o professor inclua ou modifique as notas de seus alunos durante o semestre letivo.
16. A quantidade de memória necessária para que um terminal possa executar o sistema nas condições mínimas aceitáveis é de 1 gigabyte.
17. A taxa aceitável de falhas nas operações realizadas pelo usuário no sistema deve ser de 1 falha para cada 200 operações.
18. O sistema e sua respectiva documentação deverão ser entregues em um ano a partir da data atual.
19. O sistema não deve permitir operações que beneficiem alguns usuários em detrimento de outros.
20. A interface do usuário deve ser construída utilizando HTML5 e CSS.
21. Se a média do aluno por disciplina, calculada no final do semestre, for menor do que 7, deve ser exibido no boletim do aluno a informação "Reprovado".
− Para responder à questão utilize como base os conhecimentos disponíveis no Guia PMBoK.
O Gerenciamento do tempo do projeto inclui os processos necessários para gerenciar o término pontual do projeto. Um dos processos de gerenciamento do tempo do projeto é o que permite estimar a duração das atividades. Uma das técnicas utilizadas nessa etapa é a estimativa de três pontos conhecida como Program Evaluation and Review Technique (PERT). A tabela a seguir mostra um exemplo de estimativa de duração das atividades.
| Nível 1 | Nível 2 | Estimativa otimista (tO) |
Estimativa mais provável (tM) |
Estimativa pessimista (tP) |
Tempo esperado (tE) |
||
|---|---|---|---|---|---|---|---|
| 1 | Levantamento | 1 | Formalização das necessidades | 1 | 2 | 3 | |
| 2 | Confecção da Proposta | 1 | 1 | 2 | |||
| 3 | Aprovação da Proposta | 1 | 2 | 5 | |||
| 2 | Análise | 1 | Confecção dos Casos de Uso | 1 | 2 | 4 | |
| 2 | Confecção dos diagramas de domínio | 1 | 1 | 1 | |||
| 3 | Confecção dos diagramas de classes | 1 | 1 | 1 | |||
| 4 | Confecção dos diagramas de sequência | 2 | 5 | 10 | |||
| 3 | Desenvolvimento | 1 | Prototipação | 5 | 12 | 20 | |
| 2 | Homologação | 2 | 3 | 5 | |||
| 3 | Desenvolvimento | 16 | 25 | 40 | |||
| 4 | Testes | 5 | 8 | 30 | |||
| 5 | Documentação | 5 | 8 | 15 | |||
| 4 | Implementação | 1 | Testes de integração | 10 | 15 | 30 | |
| 2 | Treinamento | 3 | 5 | 10 | |||
| 3 | Entrega | 1 | 2 | 3 | |||
Observando-se a tabela e utilizando-se o PERT, o cálculo do tempo esperado (tE) é dado por
Provas
Provas
- Organização do Estado
- Organização dos PoderesRepartição de Competências Constitucionais
- Controle de ConstitucionalidadeControle Abstrato ou ConcentradoADI: Ação Direta de inconstitucionalidade
Nessa hipótese, nos termos da Constituição da República,
Provas
Provas
Provas
Caderno Container