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,
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á 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.
Para o cálculo de PF, utiliza-se a expressão empírica proposta pelo modelo para obtenção dos pontos de função:
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,
Considere que uma Analista de Sistemas do TJUSC está atuando em um projeto com base no PMBOK 5a 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
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
De acordo com o PMBOK 6a 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:
