Prova de Engenharia de Software

Uma metodologia ágil para gestão e planejamento de projetos de software.

Uma linguagem?

Um carro?

Uma metodologia de Engenharia

Sprint Backlog.

Product Backlog.

uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia.

Uma reunião para falar das facilidades e implementações.

Um software de preparação para o início das reuniões e planejamentos do projeto.

Requisições.

Tarefas.

Requisitos não funcionais.

Requisitos funcionais.

uma breve reunião (normalmente de manhã).

uma breve reunião (normalmente de tarde).

uma breve reunião (normalmente de noite).

O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint.

O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que seguinte. Ao final de um Sprint, a equipe apresenta as Regras implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do Sprint anterior.

Uma simples reunião.

São aqueles usados para definir o sistema OP que será usado.

São implementados no caso de uso.

São aqueles que são transformados e utilizados em diagramas, é parte funcional do planejamento do sistema que vai implicar diretamente no uso e gestão de funcionalidades do sistema, descrevendo seu comportamento esperado.

São aqueles que servem apenas para o diagrama de classes.

São aqueles usados para reuniões.

São aqueles usados para descrever caso de uso.

São aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema.

Requisitos de Produto, Requisitos Organizacionais, Requisitos Externos.

Requisitos internos, Requisitos externos, Requisitos Prévios.

Pré-requisitos, pós-requisitos, anti-requisitos.

O RUP possui um conjunto de beneficíos bem definidos, com responsáveis, com artefatos de entrada e saída, meio e fim, com dependências entre as mesmas e ordem de execução, com modelo de ciclo de vida, descrição sistemática de como devem ser realizadas, Utiliza a UML.

O RUP possui um conjunto de atividades bem definidas, com responsáveis declarados, com artefatos de entrada e saída, com dependências entre as mesmas e ordem de execução, com modelo de ciclo de vida, descrição sistemática de como devem ser realizadas as atividades físicas, Utiliza a UML.

O RUP possui um conjunto de atividades bem definidas, com responsáveis, com artefatos de entrada e saída, com dependências entre as mesmas e ordem de execução, com modelo de ciclo de vida, descrição sistemática de como devem ser realizadas, Utiliza a UML.

O objetivo é estabelecer uma visão clara do projeto, definindo o escopo, os principais requisitos e as restrições.

Esta fase foca em entender melhor os requisitos e desenvolver uma arquitetura sólida para o sistema.

Durante essa fase, o sistema é realmente construído, com o desenvolvimento incremental das funcionalidades.

O objetivo é entregar o sistema aos usuários finais e garantir que ele esteja totalmente operacional.

Durante essa fase, o sistema é realmente construído, com o desenvolvimento incremental das funcionalidades.

O objetivo é entregar o sistema aos usuários finais e garantir que ele esteja totalmente operacional.

O objetivo é estabelecer uma visão clara do projeto, definindo o escopo, os principais requisitos e as restrições.

Esta fase foca em entender melhor os requisitos e desenvolver uma arquitetura sólida para o sistema.

Durante essa fase, o sistema é realmente construído, com o desenvolvimento incremental das funcionalidades.

O objetivo é entregar o sistema aos usuários finais e garantir que ele esteja totalmente operacional.

Esta fase foca em entender melhor os requisitos e desenvolver uma arquitetura sólida para o sistema.

O objetivo é estabelecer uma visão clara do projeto, definindo o escopo, os principais requisitos e as restrições.

Esta fase foca em entender melhor os requisitos e desenvolver uma arquitetura sólida para o sistema.

Durante essa fase, o sistema é realmente construído, com o desenvolvimento incremental das funcionalidades.

O objetivo é entregar o sistema aos usuários finais e garantir que ele esteja totalmente operacional.

O objetivo é estabelecer uma visão clara do projeto, definindo o escopo, os principais requisitos e as restrições.

Modelagem do negócio, Requisitos, Análise & Projeto, Implementação, Testes, Implantação, Gerenciamento e planejamento, Gerência de configuração e mudanças, Ambiente

Requisitos, Análise e Depuração, Implementação de Dados, Treinamento de Usuários, Testes Unitários, Implantação de Recursos, Monitoramento e Ajuste, Controle de Qualidade e Mudanças, Suporte ao Cliente

Modelagem de Dados, Desenvolvimento de Requisitos, Especificação de Interfaces, Codificação Modular, Simulação de Erros, Entrega de Protótipos, Coordenação de Projetos, Auditoria de Configuração, Infraestrutura de Rede

Levantamento de Dados, Design de Interface, Planejamento de Testes, Implementação Paralela, Análise de Desempenho, Distribuição de Atualizações, Gestão de Licenciamento, Controle de Versões, Personalização de Ambiente

Time, requisitos, tempo, qualidade.

Serviço, escopo, hora, qualidade.

Escopo, tempo, custo e qualidade.

Definição de Custos, Elicitação de Feedback, Planejamento de Infraestrutura, Validação de Interfaces, Monitoramento de Performance.

Estudo de viabilidade, elicitação e análise de requisitos, validação dos requisitos, gerenciamento dos requisitos.

Pesquisa de Mercado, Coleta de Informações de Usuários, Revisão de Design, Verificação de Segurança, Controle de Documentação.

Avaliação de Riscos, Desenvolvimento de Protótipos, Análise de Dados Históricos, Integração de Sistemas, Gestão de Testes Automáticos.

mostrar que os requisitos realmente representam o sistema que o usuário deseja; descobrir problemas.

mostrar que os requisitos realmente representam o sistema que o usuário deseja; descobrir problemas.

Declarações em linguagem natural, mais diagramas de serviços, que o sistema deverá fornecer e suas restrições operacionais. Escritos para os usuários.

Contido em um documento estruturado, estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor

Declarações em linguagem natural, mais diagramas de serviços, que o sistema deverá fornecer e suas restrições operacionais. Escritos para os usuários.

Contido em um documento estruturado, estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor

Comunicação, Simplicidade, Feedback, Coragem, Respeito.

Tempo, Dinheiro, Feedback, Coragem, Tabalho.

Escopo, Reunião, Coragem, Empenho.

Coretiva, Adaptativa, Perfectiva, Preventiva.

Cuidado, Prevenção, Trabalho, Usuário.

Processo que inclui o diagnóstico e a correção de erros, na maioria das vezes não detectados na fase de testes.

Processo que inclui a modificação do software para que ele tenha interface adequada com o ambiente de hardware e software, em constante mutação.

Processo de modificação de um software para incorporar novas funcionalidades e ampliações gerais solicitadas pelos usuários.

Simulação - O software deve prever possíveis falhas e erros. Estabilização - O software deve ser mantido em um estado constante de operação.

Documentação - O software deve ter toda a sua estrutura descrita em detalhes. Configuração - O software deve ser configurado conforme as preferências do desenvolvedor.

Correção - O software deve estar isento de qualquer tipo de erro. Revisão - O software deve ser atualizado com as novas tecnologias.

Verificação - O software deve estar de acordo com a especificação. Validação - O software deve fazer o que o usuário deseja.