Questões Essenciais de Engenharia de Software: ISO 25000, Paradigmas e Testes

Atributos ISO/IEC 25000 em Cenários de Software

Para cada uma das histórias abaixo, enumere e justifique os atributos aplicáveis (Grupo/Atributo, Ex: Funcionalidade/Acurácia):

1. O sistema X possui um programa de instalação no Windows, porém, para instalar no Linux, o usuário precisa recorrer a um processo manual - Portabilidade/Capacidade para ser Instalado.
2. Quando temos que efetuar alguma manutenção no software Y, em função da arquitetura ruim e do alto acoplamento entre os módulos, qualquer alteração no código pode facilmente contaminar negativamente uma série de funcionalidades presentes em diferentes módulos - Manutenibilidade/Estabilidade.
3. O sistema Z permanece estável durante o tempo médio de uma semana, sendo observado o consumo crescente de memória e CPU ao longo do tempo e a cada reinicialização do sistema - Eficiência de Desempenho/Utilização de Recursos.
4. Tivemos grande dificuldade em ensinar a operação do software W aos usuários do departamento de RH em função da ruim disponibilização de suas funcionalidades, distribuídas em muitas telas, menus e submenus - Usabilidade/Apreensibilidade.
5. O software K, no período de um ano, apresentou pouquíssimos problemas ou bugs, surpreendente - Confiabilidade/Maturidade.
6. No sistema A, qualquer um senta na cadeira e sai mexendo no software - Funcionalidade/Segurança de Acesso.
7. No sistema C de um cirurgião robótico, precisamos ter cuidado com a precisão dos movimentos a serem comandados pelo software - Funcionalidade/Acurácia.

Paradigmas de Desenvolvimento de Software

Associe os paradigmas às suas características:

(A) Modelo Clássico

Atividades de desenvolvimento sequenciais e com apresentação da "cara" do sistema apenas nas etapas finais do desenvolvimento.

Acarreta muito retrabalho no caso de rejeição do software pelo cliente em sua fase de validação ou implantação.

(B) Prototipação

Objetiva alinhar as expectativas do cliente com o que se está propondo para o sistema, a partir dos artefatos de projeto produzidos após a fase de análise dos requisitos.

Esboço de tela (aplicação Desktop) ou página (aplicação Web).

(C) Modelo em Espiral

Defende a construção incremental do software.

Associa um subconjunto dos requisitos do software com um módulo particular do mesmo.

É base dos princípios do Scrum (Sprints).

Métodos de Desenvolvimento de Software

Associe os métodos às suas características e contextos:

(A) Particionamento de Funções (DFD)

Cliente é um administrador de empresas e grande conhecedor dos processos e normas da empresa.

Processos, Fluxos, Depósitos de Dados, Entidades Externas, Dicionário de Dados.

(B) Estrutura de Dados (DER)

Cliente já fez um sisteminha em Microsoft Access.

Chaves Primárias e Estrangeiras.

(C) Orientação a Objetos (UML)

Cliente é um desenvolvedor Java, .NET ou C++.

Diagrama de Classes e Objetos.

Diagrama de Implantação.

Casos de Uso, BO, AN, EN.

Tipos de Manutenção de Software

Preencha o conteúdo dos parênteses presentes no texto abaixo, usando uma das seguintes palavras: corretiva, adaptativa, evolutiva, preventiva.

Na empresa XYZ, além de bugs (corretiva), diariamente seus desenvolvedores se veem tendo que proteger as aplicações de eventualidades muito sinistras, robustecendo o código (preventiva). Outras tantas vezes, tentam incrementar a performance de sistemas que já se encontram em produção (evolutiva) ou portam aplicações de mundos clássicos (leia-se Desktops) para a computação móvel (smartphones e tablets) (adaptativa). Enfim, os desafios são diversos e a criatividade e o conhecimento são cada vez mais exigidos.

Tipos de Teste de Software

Preencha o conteúdo dos parênteses presentes no texto abaixo, usando uma das seguintes palavras: unitário, integração, aceitação, alfa, beta.

Diante da versão X.Y.Z que a empresa ABC liberou para download e experimentação pelo usuário (beta), foram detectados vários problemas que não foram descobertos e tratados durante o período em que os desenvolvedores estavam junto aos usuários (alfa), o que gerou alguns questionamentos da diretoria, tais como: como o cliente que validou o sistema em fábrica (aceitação) não reparou nem reportou esses problemas? Sobre os problemas de troca de mensagens entre módulos distintos do sistema (integração), eles não ocorreram antes da disponibilização da versão de experimentação? Para alguns erros reportados, o desenvolvedor não detectou logo após a sua execução imediata, em seus testes individuais (unitário)?