Teste 1 Flashcards

(71 cards)

1
Q

O desenvolvimento de uma linguagem comum a toda a equipa de desenvolvimento, adqua-se a que equipa?

A

Adqua-se a equipas funcionais

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Em git a operação add, ocorre entre o que?

A

Ocorre entre o workspace e o index

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

O que permite um “task level commit” de acordo com os padrões de construção de sistema?

A

Permite que durante a integração se façam rollbacks consistentes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Defina escalonamento do projecto(project scheduling)

A

Nos projectos ágeis, é feita com menor

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

A definição do project scheduling(escalonamento de projecto)

A

Nos projectos ágeis é feita com menor detalhe do que nos projectos baseados no plano.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Num projecto SCRUM, a estimação do product backlog permite?

A

Permite ter um valor inicial do esforço requerido para desenvolver o produto

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Na abordagem XP uma metáfora do sistema é

A

O desenho do sistema com vista à sua apresentação aos novos elementos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

O que diferencia os testes de sistema (system) dos testes de entrega(release)?

A

Os testes de entrega procuram verificar se o sistema possui o valor esperado pelo utilizador

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Qual a vantagem do padrão arquitetural camadas?

A

Tem como vantagem que a implementação de uma camada possa ser alterada sem que as restantes sejam

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Durante a fase de planeamento do risco devemos?

A

Evitar o risco correspondente a reduzir sua probabilidade

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

O que pode vir a acontecer num sistema do tipo P? (Sistema em que se constrói um modelo do problema)

A

Pode vir a verificar-se que a abstração do problema, contida no modelo, não é a mais adequada para resolver o problema

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

O que permite a utilização de interfaces claras entre módulos?

A

Permite reduzir o número de canais de comunicação entre os membros da equipa de desenvolvimento

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Em GIT, após a operação commit, para que estado passa um ficheiro em estado Staged?

A

Passa para Unmodified

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

De acordo com os padrões de construção de sistema um smoke test, quanto tempo leva a executar?

A

Deve levar pouco tempo a executar pois é executado durante as construções privadas(private system build)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Caracterize um sistema de software em E

A

Os sistemas do tipo E são aqueles em que a entrada em operação do sistema altera o contexto onde o sistema se insere, pelo que o desenvolvimento de um novo sistema no mesmo contexto tem que levar em conta com o sistema que entrou em produção.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Como é definido um Sistema S

A

(formal)Definido formalmente e realizado de acordo com a especificação

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Como é definido um Sistema P

A

(modelo) Define uma abstracção e realiza o modelo do problema[jogo]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Como é definido um Sistema E

A

(Integrado na realidade) Define uma abstracção, realiza-a e integra no mundo real[Aplicação Bancária]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Defina o problema e a solução no Sistema S

A

O problema e a solução são bem conhecidos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Especificação de requisitos no Sistema S

A

A especificação de requisitos é formal e a sua implementação é inferida dos requisitos, e.g multiplicação de matrizes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Onde se centra o desenvolvimento no Sistema S?

A

O desenvolvimento centra-se na correcção da implementação da solução

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Defina o sistema no Sistema S

A

O sistema é estático e não suporta facilmente qualquer alteração ao problema

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Defina a evolução no sistema S

A

Não evolui, se o mundo real se altera o resultado é um problema completamente novo que deve ser especificado

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Descreva o problema no sistema P

A

Nem sempre é possível entender e especificar completamente o problema

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Descreva a implementação do Sistema P
Mesmo que exista uma solução teórica a sua implementação não é prática ou é impossível, e,g jogo de xadrez
26
Explique o desenvolvimento do sistema P
Para desenvolver uma solução define-se uma abstracção do problema e os requisitos são escritos tendo como base essa abstracção.
27
Quando é que a solução no sistema P é aceitável?
A solução é aceitável se os resultados fazem sentido no mundo que o problema abstrai.
28
Defina a evolução no sistema P
Uma alteração à abstracção do problema provoca a alteração dos requisitos.
29
Onde está embutido um Sistema E?
O sistema E está embutido no mundo real e vai-se alterar quando este se alterar
30
Defina a solução no Sistema E
A solução é um modelo dos processos abstractos que representam o mundo real, ou seja, o sistema é para integral do mundo que modeloa e.g um sistema de gestão de saúde
31
Defina a evolução do Sistema E
O Sistema E esta constantemente a ser alterado
32
Lei de Lehman 1
Manutenção é inevitável: ambiente do sistema muda e requisitos mudam
33
Lei de Lehman 2
Alteração do sistema degrada a sua estrutura: manutenção preventiva
34
Lei de Lehman 3
Sistemas de grandes possuem dinâmica pŕopria; tamanho e complexidade dificultam alteração
35
Lei de Lehman 4
Estado Saturado. Alterações de recursos e pessoal não têm efeito. Sistemas grandes e overhead de comunicação
36
Lei de Lehman 5
Novas funcionalidades introduzem novos defeitos: grandes incrementos implicam grandes correcções de defeitos
37
Lei de Lehman 6
Um sistema tem de ser continuamente melhorado para manter a sua utilidade
38
Lei de Lehman 7
Declínio da qualidade é inevitável se não for mantido
39
Lei de Lehman 8
Aperfeiçoar a partir de sistemas anteriores: feedback
40
Gestão de configurações-> Controlo de versões:
Gere as diversas versões dos componentes do sistema, garantido que não interferem entre si
41
GC -> Construção do sistema
gere o processo de construção dos executáveis a partir das versões correctas dos componentes
42
GC-> Gestão de alterações
Controla os pedidos de alterações dos clientes e programadores, ordenando os pedidos por prioridades e avaliando os custos e impactos.
43
GC -> Gestão de publicações
(release) prepara o software para publicação e mantém o controlo das verses que foram publicadas e quais os clientes
44
Desenvolvimento do Sistema | Codeline
conjunto de versões de um componente e suas dependências
45
Desenvolvimento do sistema | baseline
é uma coleção imutável de componentes, uma versão específica de cada um,que permite reconstruir o sistema
46
Desenvolvimento do sistema | mainline
é uma sequência de baselines representando versões do sistema
47
Desenvolvimento do sistema | release
é uma versão do sistema instalada (publicada) no cliente
48
Controlo de versões | versão
é uma instância de um componente que difere de outra instância
49
Controlo de versões | branch
é uma codeline independente que deriva de uma versão existente
50
Controlo de versões | merge
é uma junção de duas codelines para produzir uma nova do componente
51
Controlo de versões | sandbox/workspace
é uma área de trabalho privada que não interfere com o trabalho da restante equipa
52
Controlo de versões | repositório
é uma área de trabalho partilhada de versões do sistema
53
Controlo de versões | Controlo de versões
é um processo que assegura o correto registo, identificação e manutenção de todas as versões de todos os componentes do sistema
54
A definição de interfaces claras entre módulos
Permite reduzir o número de canais de comunicação entre os membros da equipa de desenvolvimento
55
Em GIT, após a operação commit, um ficheiro no estado Staged
Passa para o estado Unmodified
56
De acordo com os padrões de construção de sistema um smoke test
Deve levar pouco tempo a executar pois é executado durante as construções privadas (private system build).
57
Considere as seguintes três técnicas de estimação do esforço de desenvolvimento de um sistema de software: experiência dos peritos, algorítmica, e tempo-do-dia anterior (yesterday’s weather).
Estas três técnicas são empíricas.
58
Nas técnicas de gestão do risco a prioritização dos riscos é efetuada com base
Na relação entre a probabilidade da sua ocorrência e o seu efeito.
59
Num projeto SCRUM, o SCRUM master é responsável por
Garantir que os programadores estão focados em terminar o sprint.
60
Os testes de componente (component) podem integrar os módulos de diversas formas
A integração top-down pode requerer a utilização de duplos para teste.
61
Suponha que durante uma refactorização se substitui três utilizações de uma variável temporária pela expressão usada para calcular o valor que contém, técnica replace temp with query
Esta substituição apenas é possível se a expressão não tiver efeitos colaterais.
62
O requisito de que os acessos a um sistema apenas devem ser feitos por utilizadores autenticados
Leva à identificação de requisitos funcionais associados ao login de utilizadores
63
Considere a especificação de requisitos não funcionais de fiabilidade. A métrica mais adequada a um sistema em que os danos associados a uma falha sejam significativos é:
Probabilidade de falha por pedido efetuado.
64
. A organização de uma equipa de desenvolvimento baseada na tecnologia
Não é o tipo de organização aconselhado pelas metodologias ágeis
65
Em GIT, a operação add aplicada a um ficheiro no estado Untracked
Passa o ficheiro para o estado Staged.
66
De acordo com os padrões de construção de sistema um integration build
Pode ocorrer num servidor dedicado, pois pode ter uma duração longa.
67
Nas abordagens ágeis o planeamento
Usa a estimativa dada pelo tempo-do-dia anterior (yesterday’s weather).
68
As técnicas de gestão de risco efetuam a prioritização dos riscos durante a fase de
Análise do risco.
69
Num projeto SCRUM, o product owner é responsável por
Indicar quais as histórias de maior valor para serem implementadas no pró- ximo sprint.
70
Os testes de unidade podem usar técnicas de partições de equivalência e análise de valores de fronteira para testar os métodos das classes
Estas técnicas são técnicas de teste de caixa-preta.
71
A abordagem Test-driven development
Pode ser definida como uma junção de Test-first com refactorização, em que ora se está a introduzir funcionalidade ou a alterar a estrutura do código