Considere as seguintes atividades:
I. Identificar os maiores riscos do projeto e, no final da fase, apresentar um modelo de requisitos para o sistema, que pode ser um conjunto de casos de uso da UML, uma descrição da arquitetura ou um plano de desenvolvimento do software.
II. Elaborar o projeto do sistema e o desenvolvimento, em paralelo, das partes do sistema e sua integração.
III. Com base em informações originadas de business cases estabelecidos para o sistema, identificar todas as entidades externas (pessoas e sistemas) que vão interagir com o sistema e definir as interações. Essas informações são usadas para avaliar a contribuição do sistema para o negócio.
Essas atividades são, correta e respectivamente, abordadas nas fases do Rational Unified Process (RUP): 

Em uma aplicação desenvolvida em uma linguagem orientada a objetos, existe uma classe chamada Aposentado com diversos atributos, dentre eles cpf, nome, pis etc. Os objetos manipulados por meio desta classe conterão dados que serão, via conexão de dados, enviados para uma tabela de um banco de dados que terá campos referentes aos atributos da classe Aposentado. Para que a classe Aposentado permita a manipulação dos dados com adequado encapsulamento, os atributos e os métodos setter e getter deverão ser, respectivamente, 

Em uma situação hipotética, ao levantar os requisitos de um sistema de controle de estoque para o Tribunal de Justiça de Santa Catarina, um Analista de Sistema observa que, caso um produto não exista em estoque quando de sua verificação, deverá ser feita a compra do produto. Supondo-se que ele queira modelar os casos de uso Verificar Estoque e Comprar Produto, então o relacionamento entre esses dois casos será do tipo 

Um Diagrama de Fluxo de Dados − DFD que inicia pelo diagrama de contexto e conclui no nível de primitivas funcionais ou processos primitivos utiliza a abordagem 

Considere que uma Analista de Sistemas do TJUSC está atuando em um projeto com base no PMBOK 5ª edição, no processo “Realizar a análise qualitativa dos riscos” da etapa de Gerenciamento de Riscos do Projeto. A Analista construiu o diagrama abaixo que apresenta a análise de riscos. 

Trata-se de um diagrama

De acordo com o PMBOK 6ª edição, os gerentes de projeto precisam empregar ações/comportamentos divididos em 2 aspectos para alcançarem o sucesso junto às equipes com as quais trabalham, encontrando o seu equilíbrio para cada situação. Esses aspectos e algumas ações/comportamentos a eles ligados são:

− Aspecto 1: Influência direta usando o poder posicional; Foco em sistemas e estruturas; Apoio em controles; Foco em metas de curto prazo; Pergunta como e quando; Foco nos resultados; Foco em questões operacionais e solução de problemas.
− Aspecto 2: Influência como guia e colaborador usando o poder relacional; Foco em relacionamento com pessoas; Apoio baseado em inspirar confiança; Foco em visão de longo alcance; Pergunta o que e por que; Foco no horizonte; Foco em visão, alinhamento, motivação e inspiração.

Os aspectos 1 e 2 correspondem, correta e respectivamente, a: 

Considere que a separação de ambientes no TJUSC, de forma hipotética, funcione como mostra a figura abaixo. 

O ambiente de desenvolvimento é utilizado pelos desenvolvedores para construir o software, reunindo máquinas nas quais o código é implementado. O ambiente de produção corresponde àquele em que os usuários finais utilizarão o software. O ambiente de testes

Considere o campo descrição de um dos requisitos definidos para um sistema em desenvolvimento no TJUSC. 

No módulo de Digitalização, o tratamento de documentos digitalizados com certificação digital é um processo oneroso em termos de memória e CPU, devido ao alto volume de dados. Em função disso, o sistema deverá prover recursos para processamento paralelo (multithreading) que possibilite processar lotes de documentos digitalizados de forma paralela, reduzindo o tempo de execução da rotina diária.
A média diária de digitalizações a serem processadas é 80.000. Cada lote contém 500 documentos digitalizados totalizando 160 lotes. A janela de produção disponível para o processamento de todos os lotes é de 4h. Ou seja, o sistema deve processar todos os 160 lotes em, no máximo, 4h.
Para atender a esta alta demanda, o sistema deverá executar os lotes na quantidade máxima permitida de threads, considerando a seguinte especificação do servidor de aplicativos:
− 16 processadores com quatro núcleos cada.

− 64 GB de memória RAM.
− 1 TB de espaço de armazenamento.

Uma Analista de Sistemas, ao analisar o requisito e completar outros campos de sua estrutura padrão, o classifica como requisito

Um Analista de Sistemas atua no desenvolvimento de software utilizando diferentes processos e metodologias cujas características são: 

I. A fase de transição se concentra nas atividades necessárias para colocar o software nas mãos dos usuários. Tipicamente, essa fase inclui várias iterações, incluindo versões beta, versões de disponibilidade geral, além de correções de erros e lançamentos de aprimoramento. Um esforço considerável é gasto em atividades ligadas ao usuário: documentação de sistema, treinamento e suporte no uso inicial do produto. Neste ponto, no entanto, o feedback do usuário deve limitar-se principalmente a problemas de ajuste, configuração, instalação e usabilidade do produto. 
II. Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos tenham uma definição padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto. Por exemplo: uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto.
III. A implementação inicial do software apoia duas atividades do processo de engenharia de requisitos: a) levantamento de requisitos, pois os usuários podem realizar experiências para ver como o sistema apoia seu trabalho, podendo ter novas ideias para os requisitos, identificar pontos positivos e negativos do software e até propor novos requisitos de sistema; b) validação de requisitos, pois a implementação pode revelar erros e omissões nos requisitos propostos, levando os usuários a crerem que sua visão inicial era incorreta e incompleta e dando a eles oportunidade de fazerem ajustes na especificação de sistema para refletir sua compreensão alterada dos requisitos. 
IV. O cliente está sempre participando do desenvolvimento do sistema; testes de unidade e de aceitação fornecem feedback sobre o sistema; oportunidades e problemas são identificados o mais rápido possível; os códigos são integrados e testados constantemente, para o caso de algum problema ser detectado, poder ser corrigido imediatamente.

As características I, II, III e IV são, respectivamente,

Considere que uma Analista de Sistemas do TJUSC está fazendo a análise por Pontos de Função (PFs) de um software em desenvolvimento. Ao seguir os passos da técnica, chegou-se à tabela abaixo.
Tabela completa de Pontos de Função do Software

Para o cálculo de PF, utiliza-se a expressão empírica proposta pelo modelo para obtenção dos pontos de função: PF Contagem Total  * (0,65 + 0,01 * )
A Analista já realizou o cálculo que resultou em: , valor que indica que o produto é moderadamente complexo. De acordo com os fundamentos da Análise por Pontos de Função e com os dados apresentados,

A métrica Defect Removal Efficiency (DRE) é definida por:
DRE = Ea/(Ea + Dd) 
Dados:
Ea = número de erros encontrados antes que o software seja entregue ao usuário final.
Dd = número de defeitos encontrados depois que o software foi entregue ao usuário final. 
A métrica DRE

Em uma empresa de desenvolvimento de software, o arquiteto de solução é único e compartilhado entre todos os projetos que ela faz. Com isso, considerando que todos os projetos necessitam do arquiteto para auxiliar na validação dos modelos de dados e de software projetados, as atividades desse arquiteto devem ser planejadas conforme a disponibilidade desse recurso, sem exceder a carga horária da jornada de trabalho, podendo alterar o caminho crítico inicialmente traçado. Essa técnica é conhecida como

Arquitetos de solução estão diagramando Casos de Uso no padrão UML para explicar quais as funcionalidades que um novo sistema de informação terá para atender necessidades de um processo de negócio. Essa atividade de documentação de funcionalidades do software corresponde à fase de arquitetura do modelo TOGAF-ADM:

Considere o seguinte Diagrama de Fluxo de Dados:

Os elementos de 1 a 4 representam, correta e respectivamente,

Para um cálculo hipotético de Ponto por Função − PF, considere as quantidades e correspondentes funções:

− 3 EE baixa complexidade

− 1 EE média complexidade

− 2 EE alta complexidade

− 3 ALI baixa complexidade

− 2 ALI média complexidade

− 4 AIE baixa complexidade

− 3 AIE alta complexidade

− 5 SE baixa complexidade

− 5 CE média complexidade

E os seguintes valores padrão:

− 3, para EE baixa

− 4, para EE média

− 6, para EE alta

− 7, para ALI baixa

− 10, para ALI média

− 5, para AIE baixa

− 10, para AIE alta

− 4, para SE baixa

− 4, para CE média

Sem considerar o fator de ajuste, o total de pontos Função de Dados e o total de pontos Função de Transação são, respectivamente,

Considere os seguintes objetivos das Fases do Rational Unified Process - RUP:

I. Analisar de forma mais detalhada o domínio do problema, revisando os riscos que o projeto pode sofrer. A arquitetura do projeto inicia-se com sua forma básica elaborada. Indagações como "O plano do projeto é confiável?", "Os custos são admissíveis?" são esclarecidas nesta fase.

II. Abranger as tarefas de comunicação com o cliente e o planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, o levantamento dos requisitos do sistema e a análise preliminar. Nesta fase, deve haver concordância dos stakeholders quanto ao escopo do projeto.

III. Disponibilizar o sistema de forma que seja compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e a realização de testes da versão beta do sistema visando garantir a sua qualidade.

IV. Desenvolver ou adquirir componentes de software. O principal objetivo desta fase é codificação do software, com foco nos componentes e outros recursos do sistema.

Os objetivos I a IV estão correlacionados, correta e respectivamente, às fases de

Considere a lista abaixo, elaborada durante um levantamento de requisitos na Assembleia Legislativa do Amapá, para um sistema hipotético de avaliações internas:

1. Registrar avaliação de colaborador por parlamentar: O sistema deve permitir ao parlamentar, em uma única tela, a avaliação de todos os seus colaboradores.

2. Considerar Aspectos Legais: O sistema deve seguir orientações elencadas na Resolução 099/XXXX do Conselho Legislativo do Estado.

3. Registrar autoavaliação de parlamentar: O sistema deve permitir ao parlamentar sua autoavaliação em relação às disposições legais sob as quais atuou no período.

4. Atentar à Segurança: O sistema deve fornecer mecanismos de segurança e autenticação alinhados com os adotados pelo processo XPTO.

5. Impedir acesso direto ao processo XPTO: O sistema deverá mostrar ao usuário que existem formulários de avaliação a serem respondidos e dará a opção de respondê-los depois.

Adotando RFU para requisitos funcionais e RNF para não-funcionais, a classificação correta e respectiva da lista 1 a 5 acima é:

Considere as seguintes abordagens no contexto da Engenharia de Software.

I. Intercala as atividades de especificação, desenvolvimento e validação. O sistema é desenvolvido como uma série de versões, de maneira que cada versão adiciona funcionalidade à anterior.

II. Indivíduos e interações mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos e Responder a mudanças mais que seguir um plano.

III. Tem por referência a matriz Fase versus Fluxos de Trabalho. São alguns destes fluxos: Modelagem de negócios, Requisitos, Análise e Projeto, Implementação, Teste e Implantação.

IV. Processo dirigido a planos em que se deve planejar e programar todas as atividades do processo antes de começar a trabalhar nelas. Seus principais estágios são: Análise e definição de requisitos; Projeto de sistema e de software; Implementação e teste unitário; Integração e teste de sistema e Operação e manutenção.

Correspondem, correta e respectivamente, às abordagens

Considere as seguintes situações:

1. Um grupo foi formado por um conjunto de pessoas que têm vida própria, independente desse grupo.

2. Uma equipe de TI é formada por um conjunto de programadores com dependência de vida dessa equipe.

Na modelagem Orientação a Objetos com UML, essas situações são reconhecidas, respectivamente, como

Atribuindo-se a letra C para comportamental e E para estrutural, na UML 2.5, os diagramas de Caso de Uso, Sequência, Atividade e Classe são utilizados para representar, correta e respectivamente, elementos do modelo no contexto