A Engenharia de Software (ES) é uma área da computação voltada à especificação, desenvolvimento, manutenção e criação de software, com a aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade. Atualmente essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões de projeto de software, processo de software, qualidade de software. Além disso, a ES deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema computacional de qualidade e que atenda às necessidades de um requisitante de software. Os principais fundamentos científicos para a ES envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, além de:

Considere o seguinte Diagrama de Classes da UML.

O símbolo indica

Leia a descrição seguir.

Em modelos de processo de software, a concepção tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possível.

Esta descrição esta relacionada ao modelo

Gerência de Configuração de Software (GCS) é um conjunto de atividades de apoio que permite a absorção ordenada das mudanças inerentes ao desenvolvimento de software, mantendo a integridade e a estabilidade durante a evolução do projeto. Um exemplo de ferramenta de controle de versão é:

O processo de engenharia de requisitos é composto de quatro atividades de alto nível, que são:

Para preencher as colunas (c) e (d), dessa planilha, deve-se utilizar a tabela da Figura 9(b). Nesse caso, ao final do preenchimento dessa planilha, pode-se afirmar que será apresentada, no local apontado pela seta nº 1, a estimativa total do tamanho funcional desse projeto, que será um número

O processo de engenharia de requisitos inclui algumas etapas de alto nível, em que, em uma delas, procura-se verificar se os requisitos realmente definem o sistema que o cliente quer. Para isso, nessa etapa, podem ser realizadas uma ou mais das seguintes atividades: (1) avaliação se os requisitos realmente atendem a comunidade de stakeholders; (2) verificação de consistência, de modo a garantir que não haja conflitos entre os requisitos documentados; (3) avaliação, para verificar se os documentos incluem todos os requisitos e se efetivamente definem os comportamentos e restrições definidas pela comunidade de stakeholders; (4) verificação do realismo, para assegurar que os requisitos podem ser implementados usando as tecnologias disponíveis; e (5) escrita dos testes que assegurem que o sistema entregue atenderá a cada requisito especificado. Nesse caso, tais atividades são realizadas em uma etapa de alto nível, da engenharia de requisitos, chamada de:

Para responder à questão, considere a Figura 8, que mostra, esquematicamente, um modelo de processo ou paradigma da engenharia de software, utilizado no desenvolvimento de sistemas computacionais. A Figura 8 exibe, esquematicamente, o modelo de processo de desenvolvimento de software, chamado de:

Analise as seguintes assertivas sobre a metodologia ou framework ágil Scrum mostrada na Figura 7: I. A seta nº 1 aponta para uma etapa do framework chamada Product Backlog, que é uma lista das funcionalidades desejadas para um produto. No Scrum, o conteúdo dessa lista é definido e mantido pelo Scrum Master. II. A seta nº 2 aponta para uma atividade chamada de Daily Scrum, que consiste em reuniões diárias envolvendo, sempre que possível, toda a equipe de projeto, como, por exemplo, Product Owner, Scrum Master, Scrum Team e Representante do Cliente, para avaliarem, em conjunto, o andamento do projeto, assim como na identificação e resolução imediata dos problemas, de modo que eles não evoluam e comprometam o andamento dos trabalhos. III. No Scrum, a equipe monitora seu progresso em relação a um plano estabelecido, por meio da atualização de um Release Burndown Chart, ao final de cada Sprint.
Quais estão corretas?

1. O Jogador 1 inicializa o jogo.

2. O sistema solicita os dados do Jogador 2, para estabelecer a comunicação.

3. O Jogador 1 insere os dados do Jogador 2.

4. O sistema estabelece a comunicação virtual entre o Jogador 1 e 2 e emite alerta visual e sonoro informando para ambos que o jogo pode ser iniciado.

7. Quando o Jogador 2 aceita o jogo, o sistema desativa os alertas e possibilita o início do jogo entre ambos os jogadores.

8. O sistema ativa, obrigatoriamente, nesse momento, a funcionalidade que calcula a pontuação do jogo, baseado em uma série de dados e condições distintas.

9. Se o Jogador 1 desejar, poderá acrescentar, simultaneamente ao jogo, mais um novo participante, estabelecendo mais uma comunicação virtual agora com o Jogador 3.

10. O Jogo prossegue durante determinado tempo. Quando for encerrado o jogo entre os envolvidos, o sistema registra o vencedor, as pontuações e a hora de término do jogo e libera todos os recursos da comunicação virtual.

11. O caso de uso é encerrado

Figura 6 – Especificação de caso de uso

Tomando-se como base a especificação de caso de uso da Figura 6, assinale, dentre as alternativas a seguir, o Diagrama de Casos de Uso que melhor representa, de forma correta, tal especificação:

Uma equipe de teste de software identificou erros em algumas funcionalidades de um aplicativo durante a execução de suas atividades. Os erros foram reportados ao Gerente de Projetos que acionou imediatamente a equipe de desenvolvimento para a realização dos ajustes necessários. Concluídas as correções, a equipe de testes recebeu novamente as funcionalidades e confirmou que os erros foram devidamente corrigidos. Apesar disso, essa equipe irá realizar mais um ciclo de teste com o objetivo de verificar se a nova versão do software, ajustada pelos desenvolvedores, não introduziu novos defeitos, em outros pontos do aplicativo, em consequência dos ajustes realizados. Nesse caso, esse tipo de teste é chamado de teste:

A equipe responsável pelo desenvolvimento de um software está agilizando a conclusão de um release para entregá-lo estável ao cliente. No momento, as funcionalidades de tal release estão sendo submetidas a testes intensivos, pela equipe de testes. Essa equipe, antes de iniciar suas atividades, estudou os artefatos da linha base elaborados no projeto, tais como os documentos de viabilidade e visão, diagrama de casos de uso e as suas especificações, casos de teste, regras de negócio, modelo de dados, lista de mensagens e os tipos de dados e valores válidos para os diversos campos do sistema, dentre outros. Esses testadores encontram-se realizando diversas simulações, com a entrada de dados certos e errados, de modo a observar se o sistema se comporta conforme os documentos da linha base, acordados com o cliente. Não faz parte do escopo da equipe de teste, validar a linguagem de programação, a estrutura de dados, os algoritmos ou qualquer outro aspecto da arquitetura e estrutura interna do sistema. Nesse caso, o tipo de teste de software, que se encontra sendo realizado pela equipe de teste, é chamado de teste:

A figura abaixo ilustra um diagrama estrutural empregado pela UML com o objetivo de representar os subsistemas englobados por um sistema de forma a determinar as partes que o compõem.

Essa figura é denominada diagrama de:

O principal objetivo do RUP é atender as necessidades dos usuários garantindo uma produção de software de alta qualidade que cumpra um cronograma e um orçamento previsíveis. Nesse contexto, observe o fragmento abaixo, que trata das fases do RUP.

• Fase de ____________ - abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.

• Fase de ____________ - abrange a modelagem do modelo genérico do processo. O objetivo é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa.

• Fase de ____________ - desenvolve ou adquire os componentes de software. O principal objetivo desta fase é o desenvolvimento de componentes e outros recursos do sistema. É nesta fase que a maior parte de codificação ocorre.

• Fase de _____________ - abrange a entrega do software ao usuário e a fase de testes. O objetivo é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

As palavras que completam corretamente as lacunas no fragmento acima são respectivamente:

A figura abaixo ilustra a metodologia Extreme Programming (XP) que usa uma abordagem orientada a objetos, incluindo um conjunto de regras e práticas que ocorrem ao longo do desenvolvimento do projeto.

As fases I, II, III e IV são denominadas respectivamente:

SCRUM é um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. O SCRUM chama seus eventos de timeboxes, uma vez que são eventos de duração fechada, sendo o componente principal conhecido por Sprint, havendo alguns tipos, dos quais quatro são detalhados a seguir:
( I ) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint Backlog. ( II ) Time-box de 4h, onde o incremento do produto que está pronto para uso, é apresentado ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada pelo Scrum Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor representa o pilar de inspeção do Scrum. ( III ) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua apenas como facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas, para a partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação. ( IV ) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

Os tipos (I), (II), (III) e (IV) são denominados respectivamente:

O desenvolvimento de sistemas de software demanda que o Analista tenha a possibilidade de estudar o sistema a partir de diversas perspectivas, havendo cinco visões independentes sugeridas pelos autores da UML. Neste contexto, relacione as visões com as correspondentes descrições.
(1) Visão de Projeto
(2) Visão de Processo
(3) Visão de Implantação
(4) Visão de Casos de Uso
(5) Visão de Implementação
✓ Enfatiza as características de concorrência, sincronismo e desempenho do sistema. ✓ Enfatiza a distribuição física do sistema em seus subsistemas e a conexão entre essas partes. ✓ Enfatiza o sistema do ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos ao sistema. ✓ Enfatiza o gerenciamento de versões do sistema construídas por meio do agrupamento de módulos e subsistemas. ✓ Enfatiza as características do sistema que dão suporte, tanto estrutural quanto comportamental, às funcionalidades externamente visíveis do sistema.
Essas descrições se relacionam respectivamente com as visões:

No que diz respeito aos requisitos funcionais e não funcionais, analise as afirmativas a seguir.
I. Requisitos funcionais são as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir às entradas específicas e como o sistema deve se comportar em determinadas situações, podendo também estabelecer explicitamente o que o sistema não deve fazer. II. Requisitos não funcionais são aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema, incluindo restrições sobre o processo de desenvolvimento e padrões, aplicando-se ao sistema como um todo. III. Os requisitos não funcionais surgem devido às necessidades do usuário, às restrições de orçamento, às políticas organizacionais, à necessidade de interoperabilidade com outros sistemas de software ou de hardware ou a fatores externos, como regulamentos de segurança ou legislação a respeito de privacidade.
Assinale a alternatica correta:

Identifique os itens que constituem boas práticas do RUP (Rational Unified Process).
1. Desenvolvimento iterativo
2. Utilização de componentes
3. Gestão dos requisitos
4. Modelagem visual, empregando diagramas
Assinale a alternativa que indica todos os itens corretos.

No contexto do RUP (Rational Unified Process), assinale a alternativa que contém a fase do RUP responsável pelo deployment.