Teste 1 Flashcards
O desenvolvimento de uma linguagem comum a toda a equipa de desenvolvimento, adqua-se a que equipa?
Adqua-se a equipas funcionais
Em git a operação add, ocorre entre o que?
Ocorre entre o workspace e o index
O que permite um “task level commit” de acordo com os padrões de construção de sistema?
Permite que durante a integração se façam rollbacks consistentes
Defina escalonamento do projecto(project scheduling)
Nos projectos ágeis, é feita com menor
A definição do project scheduling(escalonamento de projecto)
Nos projectos ágeis é feita com menor detalhe do que nos projectos baseados no plano.
Num projecto SCRUM, a estimação do product backlog permite?
Permite ter um valor inicial do esforço requerido para desenvolver o produto
Na abordagem XP uma metáfora do sistema é
O desenho do sistema com vista à sua apresentação aos novos elementos
O que diferencia os testes de sistema (system) dos testes de entrega(release)?
Os testes de entrega procuram verificar se o sistema possui o valor esperado pelo utilizador
Qual a vantagem do padrão arquitetural camadas?
Tem como vantagem que a implementação de uma camada possa ser alterada sem que as restantes sejam
Durante a fase de planeamento do risco devemos?
Evitar o risco correspondente a reduzir sua probabilidade
O que pode vir a acontecer num sistema do tipo P? (Sistema em que se constrói um modelo do problema)
Pode vir a verificar-se que a abstração do problema, contida no modelo, não é a mais adequada para resolver o problema
O que permite a utilização de interfaces claras entre módulos?
Permite reduzir o número de canais de comunicação entre os membros da equipa de desenvolvimento
Em GIT, após a operação commit, para que estado passa um ficheiro em estado Staged?
Passa para Unmodified
De acordo com os padrões de construção de sistema um smoke test, quanto tempo leva a executar?
Deve levar pouco tempo a executar pois é executado durante as construções privadas(private system build)
Caracterize um sistema de software em E
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.
Como é definido um Sistema S
(formal)Definido formalmente e realizado de acordo com a especificação
Como é definido um Sistema P
(modelo) Define uma abstracção e realiza o modelo do problema[jogo]
Como é definido um Sistema E
(Integrado na realidade) Define uma abstracção, realiza-a e integra no mundo real[Aplicação Bancária]
Defina o problema e a solução no Sistema S
O problema e a solução são bem conhecidos
Especificação de requisitos no Sistema S
A especificação de requisitos é formal e a sua implementação é inferida dos requisitos, e.g multiplicação de matrizes
Onde se centra o desenvolvimento no Sistema S?
O desenvolvimento centra-se na correcção da implementação da solução
Defina o sistema no Sistema S
O sistema é estático e não suporta facilmente qualquer alteração ao problema
Defina a evolução no sistema S
Não evolui, se o mundo real se altera o resultado é um problema completamente novo que deve ser especificado
Descreva o problema no sistema P
Nem sempre é possível entender e especificar completamente o problema
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
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.
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.
Defina a evolução no sistema P
Uma alteração à abstracção do problema provoca a alteração dos requisitos.
Onde está embutido um Sistema E?
O sistema E está embutido no mundo real e vai-se alterar quando este se alterar
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
Defina a evolução do Sistema E
O Sistema E esta constantemente a ser alterado
Lei de Lehman 1
Manutenção é inevitável: ambiente do sistema muda e requisitos mudam
Lei de Lehman 2
Alteração do sistema degrada a sua estrutura: manutenção preventiva
Lei de Lehman 3
Sistemas de grandes possuem dinâmica pŕopria; tamanho e complexidade dificultam alteração
Lei de Lehman 4
Estado Saturado. Alterações de recursos e pessoal não têm efeito. Sistemas grandes e overhead de comunicação
Lei de Lehman 5
Novas funcionalidades introduzem novos defeitos: grandes incrementos implicam grandes correcções de defeitos
Lei de Lehman 6
Um sistema tem de ser continuamente melhorado para manter a sua utilidade
Lei de Lehman 7
Declínio da qualidade é inevitável se não for mantido
Lei de Lehman 8
Aperfeiçoar a partir de sistemas anteriores: feedback
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
GC -> Construção do sistema
gere o processo de construção dos executáveis a partir das versões correctas dos componentes
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.
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
Desenvolvimento do Sistema
Codeline
conjunto de versões de um componente e suas dependências
Desenvolvimento do sistema
baseline
é uma coleção imutável de componentes, uma versão específica de cada um,que permite reconstruir o sistema
Desenvolvimento do sistema
mainline
é uma sequência de baselines representando versões do sistema
Desenvolvimento do sistema
release
é uma versão do sistema instalada (publicada) no cliente
Controlo de versões
versão
é uma instância de um componente que difere de outra instância
Controlo de versões
branch
é uma codeline independente que deriva de uma versão existente
Controlo de versões
merge
é uma junção de duas codelines para produzir uma nova do componente
Controlo de versões
sandbox/workspace
é uma área de trabalho privada que não interfere com o trabalho da restante equipa
Controlo de versões
repositório
é uma área de trabalho partilhada de versões do sistema
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
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
Em GIT, após a operação commit, um ficheiro no estado Staged
Passa para o estado Unmodified
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).
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.
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.
Num projeto SCRUM, o SCRUM master é responsável por
Garantir que os programadores estão focados em terminar o sprint.
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.
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.
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
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.
. A organização de uma equipa de desenvolvimento baseada na tecnologia
Não é o tipo de organização aconselhado pelas metodologias ágeis
Em GIT, a operação add aplicada a um ficheiro no estado Untracked
Passa o ficheiro para o estado Staged.
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.
Nas abordagens ágeis o planeamento
Usa a estimativa dada pelo tempo-do-dia anterior (yesterday’s weather).
As técnicas de gestão de risco efetuam a prioritização dos riscos durante a fase de
Análise do risco.
Num projeto SCRUM, o product owner é responsável por
Indicar quais as histórias de maior valor para serem implementadas no pró-
ximo sprint.
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.
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
