Utilizando as recomendações do COBIT 5, uma equipe de Analistas do TJUSC, hipoteticamente, definiu, após a conclusão da análise das necessidades das partes interessadas, que a melhoria da satisfação da sociedade, com os serviços prestados, seria prioridade estratégica para o Tribunal. A partir dessa definição, buscou-se definir o que precisaria ser melhorado nos seguintes aspectos relativos à TI, obtidos da cascata de objetivos:

I. 01 Alinhamento da estratégia de TI e das atividades do Tribunal.

II. 04 Gestão do risco organizacional de TI.

III. 07 Prestação de serviços de TI em consonância com os requisitos de trabalho do Tribunal. IV. 09 Agilidade de TI.

V. 10 Segurança da informação, infraestrutura de processamento e aplicativos.

VI. 14 Disponibilidade de informações úteis e confiáveis para a tomada de decisão.

VII. 17 Conhecimento, expertise e iniciativas para inovação do trabalho do Tribunal.

Com base no exposto,

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

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 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 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 o método abaixo, em uma classe PHP chamada Cliente.

public function setNome($Nome) {

$this->Nome = $Nome;

}

A partir de outra classe, um objeto na classe Cliente foi instanciado por meio da instrução $cli = new Cliente;. Para chamar o método acima e passar o nome 'Paulo' como parâmetro, utiliza-se a instrução

No trecho da mensagem SOAP abaixo um GetProcesso é enviado para o servidor, passando como parâmetro o número de um processo.

<...^I... xmlns:m="https://www.tjsc.jus.br/processo">

<m:GetProcesso>

<m:NumeroProcesso>20120385259</m:NumeroProcesso>

</m:GetProcesso>

</ ...^I ...>

Nesse trecho, em condições ideais, a lacuna I deve ser corretamente preenchida por

O Modelo de Acessibilidade em Governo Eletrônico (eMAG), norteador no desenvolvimento e na adaptação de conteúdos digitais do governo federal para acessibilidade, recomenda que

Considerando o catálogo GoF.

I. Bridge.

II. Mediator.

III. Proxy.

Os padrões de projeto são, respectivamente, do tipo