Exercícios de Exame

c) Nos anos 40, manualmente.

Nos anos 40, os computadores enchiam salas inteiras e o seu calor atraía insetos, que provocavam curto-circuitos. A 9 de setembro de 1945, a oficial Grace Hopper encontrou manualmente uma traça entre os relés do Harvard Mark II, registando o primeiro bug de software.

• Nos anos 50, com os sistemas avançados de identificação de bugs da NATO. Não existiam sistemas de identificação de bugs da NATO nos anos 50.
• Nos anos 80, por análise de serviços críticos. A análise de serviços críticos não foi o método de identificação do primeiro bug.
• Nos anos 40, manualmente. Em 1945, nos anos 40, Grace Hopper encontrou manualmente uma traça (moth) entre os relés do computador Harvard Mark II.
• Nos anos 90, com testes automatizados. Os testes automatizados não foram usados na identificação do primeiro bug registado.

b) Complexidade acidental e complexidade essencial.

A complexidade essencial resulta da dificuldade intrínseca do problema, enquanto a acidental resulta das ferramentas, linguagens e métodos escolhidos. Reduzir a complexidade acidental não resolve o problema em si.

• Complexidade acidental e complexidade de gestão. A complexidade de gestão não é uma das duas classes fundamentais da complexidade do software.
• Complexidade acidental e complexidade essencial. A complexidade do software divide-se na essencial, que vem da dificuldade do problema, e na acidental, que vem das ferramentas e métodos usados.
• Complexidade técnica e complexidade de gestão. Esta não é a classificação habitual da complexidade global dos projetos de software.
• Complexidade técnica e complexidade essencial. A complexidade técnica não substitui a distinção entre complexidade essencial e acidental.

a) É uma atividade do processo de reengenharia.

A engenharia inversa consiste em analisar um programa ou código existente, de forma estática ou dinâmica, para o compreender melhor. Tal como as outras atividades de reengenharia, ajuda a reestruturar e a documentar o software para o tornar mais fácil de perceber e de alterar.

• É uma atividade do processo de reengenharia. A engenharia inversa analisa um programa existente para o compreender melhor, servindo de base à reengenharia.
• Significa converter código para uma nova linguagem. Converter código para outra linguagem é uma tarefa específica, não a definição de engenharia inversa.
• É limpar e reestruturar os dados do sistema. A reestruturação dos dados é outra atividade da reengenharia, não a engenharia inversa.
• É reorganizar a estrutura do programa. Reorganizar a estrutura do programa é reengenharia, não engenharia inversa.

a) Engenharia de requisitos.

A engenharia de requisitos é o processo global que transforma necessidades vagas numa definição clara e percebida do sistema, incluindo elicitação, análise, especificação e validação.

• Engenharia de requisitos. A engenharia de requisitos engloba elicitar, analisar, especificar e validar os requisitos, levando das necessidades vagas até à definição clara do sistema.
• Especificação de requisitos. A especificação é apenas uma parte do processo, a produção do documento de requisitos.
• Análise de requisitos. A análise estuda e organiza os requisitos já elicitados, não cobre todo o processo.
• Elicitação de requisitos. A elicitação é a recolha das necessidades junto das partes interessadas, apenas o início do processo.

c) O sistema deve ser desenvolvido com uma base de dados SQL.

As opções a), b) e d) descrevem o que o sistema faz, ou seja, requisitos funcionais. A opção c) restringe como o sistema é construído, sendo uma restrição de projeto que se classifica como requisito não funcional.

• O sistema deve permitir ao cliente comprar vários bilhetes de uma só vez. É uma funcionalidade do sistema, logo um requisito funcional.
• O sistema deve permitir ao cliente iniciar sessão. O início de sessão é uma funcionalidade, logo um requisito funcional.
• O sistema deve ser desenvolvido com uma base de dados SQL. Impor uma tecnologia de implementação é uma restrição de projeto, que conta como requisito não funcional.
• O sistema deve permitir ao cliente comprar bilhetes presencialmente. Descreve uma funcionalidade, logo é um requisito funcional.

b) Todas as ideias são bem-vindas.

Numa sessão de brainstorming há um moderador e cerca de 4 a 8 pessoas com perspetivas diferentes sobre o produto. Todas as ideias são bem-vindas, por mais criativas que pareçam, dando prioridade à quantidade sobre a qualidade; num passo posterior são discutidas, revistas e organizadas.

• As ideias vêm apenas dos utilizadores finais do sistema. Participam pessoas com várias perspetivas sobre o produto, não apenas os utilizadores finais.
• Todas as ideias são bem-vindas. O objetivo é recolher o maior número de ideias novas, dando prioridade à quantidade sobre a qualidade; só depois são discutidas e organizadas.
• Não existe um facilitador. Existe um moderador que conduz a sessão.
• O limite é de 15 pessoas na sala. A sessão reúne normalmente cerca de 4 a 8 pessoas com perspetivas diferentes.

a) Ator, caso de uso, fronteira do sistema, nome do sistema.

Num diagrama de casos de uso representam-se os atores, os casos de uso que eles iniciam e a fronteira do sistema, identificada pelo nome do sistema. Classes, pacotes e testes pertencem a outros tipos de diagrama.

• Ator, caso de uso, fronteira do sistema, nome do sistema. Um diagrama de casos de uso mostra atores, casos de uso e a fronteira do sistema com o seu nome.
• Ator, pacote, nome do sistema, sistema externo. Pacotes e sistemas externos não são elementos próprios deste diagrama.
• Caso de uso, ator, classe principal, nome do sistema. Classes não fazem parte de um diagrama de casos de uso.
• Caso de uso, generalização, nome do sistema, teste. Testes não são um elemento deste diagrama.

c) Diagrama de classes.

Os diagramas de atividades, de casos de uso e de máquina de estados descrevem aspetos dinâmicos do sistema. O diagrama de classes descreve a estrutura estática: classes, atributos e relações entre elas.

• Diagrama de atividades. Modela fluxos de atividades, incluindo paralelismo com fork e join.
• Diagrama de casos de uso. Mostra as interações entre atores e o sistema, sendo usado para modelar comportamento.
• Diagrama de classes. O diagrama de classes modela a estrutura estática do sistema, não o seu comportamento.
• Diagrama de máquina de estados. Modela o ciclo de vida de objetos com comportamento orientado por eventos.

c) Representar comportamento obrigatório.

Quando vários casos de uso partilham algum comportamento comum, esse comportamento pode ser separado e descrito num novo caso de uso, que os primeiros incluem. Esse comportamento comum é sempre obrigatório e não pode ser removido.

• Representar comportamento opcional. O comportamento opcional modela-se com relações extend, não include.
• Representar comportamento crítico. O include não distingue comportamento crítico de outro tipo.
• Representar comportamento obrigatório. Quando vários casos de uso partilham um comportamento comum, esse comportamento separa-se num novo caso de uso incluído por eles, e é sempre executado.
• Representar comportamento importado de outro sistema. O comportamento incluído pode ou não vir de outro sistema, mas é sempre obrigatório.

d) O cliente prioriza quais as histórias de utilizador a implementar.

No Planning Game, o cliente apresenta as histórias de utilizador por ordem de prioridade de negócio e os programadores estimam o esforço de cada uma. A combinação das duas perspetivas define o que entra em cada entrega.

• Os gestores estimam o tamanho de cada história de utilizador. No Planning Game são os programadores que estimam o esforço.
• Os programadores contribuent para uma lista de funcionalidades que desejam. A lista de funcionalidades vem do cliente, não dos programadores.
• Os programadores decidem quando as funcionalidades devem ser entregues. As entregas resultam das iterações combinadas com o cliente.
• O cliente prioriza quais as histórias de utilizador a implementar. No Planning Game o cliente ordena as histórias por valor de negócio e os programadores estimam o esforço de cada uma.

a) Test-driven Deployment.

On-Site Customer, Planning Game e Continuous Integration são práticas de XP. O que existe é desenvolvimento orientado a testes (test-driven development), não "test-driven deployment".

• Test-driven Deployment. O XP pratica desenvolvimento orientado a testes (TDD), não "test-driven deployment".
• On-Site Customer. Ter o cliente presente na equipa é uma prática clássica de XP.
• Planning Game. O Planning Game é a prática de planeamento conjunto de XP.
• Continuous Integration. A integração contínua é uma prática central de XP.

A equipa de desenvolvimento, com contributos do cliente, escreve os testes antes de abordar novas funcionalidades.

São os programadores que escrevem os testes unitários antes de implementar cada nova funcionalidade. O cliente participa especificando os testes de aceitação: uma história de utilizador só está completa quando todos os testes de aceitação passam. Os testes unitários testam métodos, classes ou cenários específicos e são internos à equipa de desenvolvimento.

c) As estimativas de esforço e a velocidade podem ser usadas para prever quando o backlog ficará completo.

Em cada sprint mede-se a velocidade e o esforço da equipa, para que nos sprints seguintes essa informação permita prever que progresso é possível fazer. Com este método, a equipa percebe melhor como avança e pode prioritar as próximas tarefas de forma mais informada, aumentando a probabilidade de cumprir os prazos e de estimar quando o backlog ficará completo.

• O Scrum garante apenas que existe um incremento do produto no fim de cada sprint, mas não a quantidade de funcionalidades. O Scrum não se limita a garantir a existência do incremento; usa a medição para prever o progresso.
• O Scrum Master é responsável por garantir que a equipa é eficiente e entrega o software a tempo. O Scrum Master facilita o processo, mas não é o responsável direto pela entrega a tempo.
• As estimativas de esforço e a velocidade podem ser usadas para prever quando o backlog ficará completo. Em cada sprint mede-se a velocidade e o esforço da equipa para prever, nos sprints seguintes, quanto falta para completar o backlog.
• Um processo bem definido garante eficiência no desenvolvimento e, por isso, o cumprimento do prazo. Um processo rígido não garante por si só o cumprimento dos prazos.

a) Partição por classes de equivalência.

No teste de caixa preta os casos de teste são escolhidos a partir da especificação do componente, sem olhar para o código. A partição por classes de equivalência agrupa as entradas equivalentes e escolhe representantes de cada classe. O teste estrutural e o teste de mutação são de caixa branca.

• Partição por classes de equivalência. A partição por classes de equivalência deriva os casos de teste apenas da especificação, sem conhecer a estrutura interna do código.
• Nenhuma das opções. Existe pelo menos uma opção correta.
• Teste estrutural, por exemplo baseado em cobertura. O teste estrutural é de caixa branca, pois usa o conhecimento do código.
• Teste de mutação. O teste de mutação também se apoia na estrutura interna do programa.

b) Testar a integração e a interação entre diferentes unidades ou componentes.

O teste unitário testa cada unidade isoladamente, o teste de componentes testa widgets ou ecrãs, e o teste de desempenho mede tempos de resposta. O teste de integração junta as unidades já testadas e verifica se comunicam e funcionam corretamente em conjunto.

• Verificar o comportamento e a funcionalidade corretos de um widget ou ecrã específico. Isso é objetivo do teste de componentes ou de interface.
• Testar a integração e a interação entre diferentes unidades ou componentes. O teste de integração verifica se os componentes funcionam corretamente em conjunto.
• Testar as unidades ou componentes individuais de forma isolada. O teste isolado de unidades é o teste unitário.
• Garantir que a aplicação cumpre os requisitos de desempenho e capacidade de resposta especificados. Isso é objetivo do teste de desempenho.

d) Model-View-Controller.

O padrão Model-View-Controller separa os dados (modelo), a apresentação (vista) e o controlo da interação (controlador), sendo o mais adequado para aplicações com interface de utilizador interativa. Repository e pipes and filters servem outros tipos de problema.

• Repository. O padrão Repository organiza o acesso centralizado a dados, não a interface interativa.
• Pipes and filters. Pipes and filters adequa-se a fluxos de processamento de dados em cadeia, não a interfaces interativas.
• Todas as outras opções. Nem todos os padrões listados servem para interfaces interativas.
• Model-View-Controller. O MVC separa o modelo, a vista e o controlador, sendo o padrão clássico para aplicações com interface interativa.

As disciplinas mais ativas são a conceção (analysis & design), a implementação e os testes.

Na fase de construção o software é desenvolvido mais ativamente, ou seja, é implementado. Ao mesmo tempo, é testado de forma extensiva segundo os critérios de avaliação definidos, e os produtos libertados são avaliados segundo os critérios de aceitação da visão, pelo que os testes também têm um papel importante. Além disso, deve haver atenção à gestão de recursos, ao controlo e à otimização do processo, análise que pode levar a alterações de conceção.