Engenharia de Software I

Question

O que foi a Crise de Software?

Answer 1

A Crise de Software permitiu o desenvolvimento de software de alta qualidade já que houve um aumento da concorrência.

Answer 2

A Crise de Software foi um termo que surgiu nos anos 70. O termo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por software.

Answer 3

A Crise de Software foi acompanhada pela Crise de Hardware, que acabou gerando inúmeros desempregos na década de 70.

Answer 4

A Crise de Software foi um termo criado para expressar momentos em que um sistema apresenta processamento lento.

Answer 5

A Crise de Software ocorreu após a Segunda Guerra Mundial quando nenhum software era vendido.

Answer 6

A Engenharia de Software foi criada porque nenhum software disponível antes da Engenharia de Software conseguia realizar cálculos complexos.

Answer 7

A Engenharia de Software foi criada para permitir o uso de elementos da engenharia de forma controlada e sistemática no desenvolvimento de software. Também para evitar a Crise de Software.

Answer 8

A Engenharia de Software foi criada para acelerar o desenvolvimento de software no Brasil.

Answer 9

A Engenharia de Software foi criada para facilitar o uso de software.

Answer 10

A Engenharia de Software foi criada para permitir que a produção de novos sistemas tivesse mais elementos gráficos e amigáveis ao usuário.

Answer 11

Iniciou-se o uso de técnicas e metodologias sistemáticas e controladas já presentes na engenharia e amplamente utilizadas em outras áreas.

Answer 12

A Engenharia de Software melhorou o entendimento do desenvolvedor na leitura dos requisitos de Software.

Answer 13

Aumentaram as vendas de sistemas de software na década de 80.

Answer 14

Permitiu que mais pessoas pudessem ter acesso a sistemas de software.

Answer 15

Removeu da criação de software as técnicas e metodologias sistemáticas e controladas já presentes na engenharia e amplamente utilizadas em outras áreas.

Answer 16

Ir para a sua empresa e começar a programar imediatamente.

Answer 17

Modelar algumas telas do sistema e perguntar ao cliente a sua opinião.

Answer 18

Contratar uma grande equipe de desenvolvedores para criar o software o mais rápido possível.

Answer 19

Entender o negócio do cliente e realizar reuniões para mensurar o que ele precisa.

Answer 20

Informar para o cliente que em um mês o sistema estará em pleno funcionamento, além de informar qual será o custo do sistema.

Answer 21

Ferramentas.

Answer 22

Foco na qualidade.

Answer 23

Conceitual.

Answer 24

São oferecidos elementos do sistema que permitem a operação básica ao usuário.

Answer 25

É oferecido um sistema completo, com todas as funcionalidades.

Answer 26

É oferecida apenas a documentação do sistema.

Answer 27

É oferecido apenas um protótipo de telas para o cliente saber como o sistema será implementado.

Answer 28

Não é oferecido um sistema funcional, já que este modelo linear só oferece o produto ao final de todo o projeto.

Answer 29

Um manual de utilização do sistema.

Answer 30

Descarte do protótipo.

Answer 31

Uso exaustivo do sistema para encontrar erros.

Answer 32

Uso, avaliação e feedback sobre o sistema.

Answer 33

Pagamento pelo projeto.

Answer 34

Apenas uma parte, incremento ou uma funcionalidade básica do sistema que esteja em funcionamento e bem testada.

Answer 35

Um sistema parcialmente funcional.

Answer 36

Espera-se um sistema completo e funcional.

Answer 37

Espera-se que o cliente tenha as funcionalidades básicas do sistema funcionando bem e testadas, mas não funções complementares.

Answer 38

Espera-se um sistema que não atenda a nenhum dos requisitos.

Answer 39

Podem surgir problemas com a integração de cada entrega incremental.

Answer 40

Usuários podem solicitar modificações no sistema durante o desenvolvimento.

Answer 41

Os usuários podem ver um protótipo de tela antes do desenvolvimento do sistema.

Answer 42

O sistema é entregue somente no final do projeto de forma integral.

Answer 43

O custo do projeto é sempre respeitado.

Answer 44

O orçamento previsto do projeto pode ser ultrapassado.

Answer 45

O sistema é desenvolvido respeitando os prazos.

Answer 46

Redução de riscos de atraso da entrega.

Answer 47

As partes entregues durante os incrementos não oferecem integração.

Answer 48

O projeto é alinhado com as necessidades do cliente.

Answer 49

Ciclo de vida de software refere-se aos estágios de concepção, projeto, criação e implementação de um software.

Answer 50

Ciclo de vida de software refere-se aos estágios de levantamento de requisitos.

Answer 51

Ciclo de vida de software refere-se ao tempo de implementação estimado pelo analista.

Answer 52

Ciclo de vida de software refere-se aos estágios de análise do software.

Answer 53

Ciclo de vida de software ocorreu antes da Crise do Software, em 1970.

Answer 54

Na fase de projeto.

Answer 55

Na fase de levantamento de requisitos.

Answer 56

Na fase de implementação.

Answer 57

Na fase de testes e manutenção.

Answer 58

Em nenhuma fase, estas questões são decididas pelo programador.

Answer 59

É realizada a implementação do sistema.

Answer 60

É realizada uma verificação de todas as necessidades do cliente.

Answer 61

É realizada a análise de requisitos.

Answer 62

São realizados testes no sistema para verificar quais as necessidades de implementação.

Answer 63

É a etapa onde o sistema é entregue para o usuário/cliente.

Answer 64

Prototipagem.

Answer 65

Incremental.

Answer 66

Nenhum. O sistema cascata foi utilizado durante anos e até o momento não precisou de correções.

Answer 67

É um modelo bastante simples.

Answer 68

O sistema prevê a revisão das fases e é totalmente iterativo.

Answer 69

Apresenta o problema de reatividade a mudanças.

Answer 70

O modelo cascata é top-down e isso faz com que o software seja construído de maneira incorreta.

Answer 71

Um requisito pode ser definido como uma condição ou uma capacidade com a qual o sistema deve estar de acordo.

Answer 72

É uma declaração sobre políticas ou condições que devem ser satisfeitas.

Answer 73

É uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário.

Answer 74

É uma técnica de desenvolvimento de software em que se utiliza camadas.

Answer 75

É um conjunto de elementos que um software entrega, podendo ser dados ou valores.

Answer 76

Definem propriedades e restrições do sistema.

Answer 77

escrevem explicitamente as funcionalidades e serviços do sistema.

Answer 78

É mais voltado para características que podem ser mensuradas e testadas facilmente.

Answer 79

Expressam informações relacionadas com a segurança do sistema.

Answer 80

Expressam informações relacionadas com a arquitetura do sistema.

Answer 81

É um tipo de requisito que o usuário geralmente conhece bem.

Answer 82

É um tipo de requisito fácil de estimar.

Answer 83

É um tipo de requisito que define propriedades e restrições do sistema. É mais voltado para características que podem ser mensuradas e testadas facilmente.

Answer 84

É um tipo de requisito que geralmente descreve explicitamente as funcionalidades e serviços do sistema.

Answer 85

É um tipo de requisito que é flexível e não impacta no desenvolvimento.

Answer 86

Regras de negócio são premissas e restrições aplicadas a uma operação comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da maneira esperada.

Answer 87

Definem propriedades e restrições do sistema.

Answer 88

É um tipo de requisito que geralmente descreve explicitamente as funcionalidades e serviços do sistema.

Answer 89

É um requisito que o usuário não conhece muito bem durante a criação de um sistema.

Answer 90

É um tipo de requisito difícil de estimar.

Answer 91

Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.

Answer 92

Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos.

Answer 93

Nesta atividade, os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

Answer 94

Em qualquer definição de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes.

Answer 95

É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos.

Answer 96

Os recursos destinados para projetos são limitados e, em alguns casos, é necessário deixar de lado alguns dos requisitos levantados para entregar o software com a qualidade esperada, mas não completo.

Answer 97

A priorização de requisitos de software permite que o software desenvolvido execute com melhor desempenho.

Answer 98

Devido ao tempo disponível para a criação de software, muitos projetos utilizam a classificação dos requisitos em diferentes níveis de prioridade para que o projeto dure mais tempo, agregando valor ao produto.

Answer 99

Devido à limitação de recursos e tempo, os requisitos são priorizados para que os mais importantes sejam desenvolvidos primeiro e os menos importantes depois.

Answer 100

A priorização deve ocorrer para que o projeto finalize com custos mais altos que o previsto.

Answer 101

Clientes de sistemas – não tem acesso aos documentos de requisitos, pois este é um documento utilizado pelos desenvolvedores, gerentes e testadores.

Answer 102

Engenheiros de sistema – usam os requisitos para compreender qual sistema será desenvolvido

Answer 103

Gerentes – especificam e leem os requisitos para verificar se eles atendem às suas necessidades

Answer 104

Engenheiros de teste de sistema – usam os requisitos somente em planos de testes e em testes de usabilidade.

Answer 105

Engenheiro de manutenção de sistema – profissional que trabalha com sistemas legados, principalmente quando não existe o documento de requisitos.

Answer 106

É um diagrama com tarefas associadas à cada papel de usuário.

Answer 107

É aquilo que existe independente do sistema/software.

Answer 108

Consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções.

Answer 109

São requisitos que descrevem, em termos do negócio, o que deve ser entregue ou conseguido para fornecer valor.

Answer 110

Representação do fluxo de informação.

Answer 111

São requisitos que estabelecem detalhadamente as funções e restrições do sistema.

Answer 112

São solicitações do próprio cliente sobre o produto, como quantidade, tipo ou data de entrega.

Answer 113

São basicamente as declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. Escrito para os usuários.

Answer 114

São requisitos definidos pelas tarefas que eles realizam.

Answer 115

É uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos).

Answer 116

Observação in loco/etnografia.

Answer 117

Encontros.

Answer 118

Entrevista.

Answer 119

Ligação.

Answer 120

É uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que ele mostra os objetos que foram instanciados das classes.

Answer 121

É uma representação da estrutura e relações das classes que servem de modelo para objetos.

Answer 122

É um diagrama comportamental (que especifica o comportamento do software).

Answer 123

É um diagrama que descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema.

Answer 124

É um diagrama que descreve os componentes do software, suas interfaces e suas dependências.

Answer 125

Com uma elipse.

Answer 126

Com um simbolo de uma pessoa, também chamado de "stick man".

Answer 127

Com uma seta pontilhada.

Answer 128

Com um círculo com bordas pontilhadas.

Answer 129

Com um triângulo e o nome do ator na parte superior.

Answer 130

Quando o caso de uso Y estende o caso de uso X, significa que quando o caso de uso X for executado o caso de uso Y poderá (poderá – talvez não seja) ser executado também.

Answer 131

Quando o caso de uso Y generaliza o caso de uso Z isso significa que, além de fazer tudo que nele está especificado, ele também executará tudo que está especificado no caso de uso Z.

Answer 132

Quando um caso de uso X pertence ao caso de uso Y, fazendo com que todos os atributos sejam removidos.

Answer 133

Quando o caso de uso A inclui o caso de uso B, significa que sempre que o caso de uso A for executado, o caso de uso B também será executado.

Answer 134

Quando um caso de uso Z não disponibiliza a execução de um caso de uso Y.

Answer 135

Na execução dos testes de software.

Answer 136

Implementação do software.

Answer 137

Definição dos requisitos e comunicação com o cliente.

Answer 138

Na entrega do software para o cliente.

Answer 139

Na fase de manutenção do software.

Answer 140

Para demonstrar algum tipo de relação entre dois elementos por meio do uso de linhas e setas.

Answer 141

Para definir uma funcionalidade do sistema do ponto de vista do usuário.

Answer 142

Para definir uma grande função do sistema.

Answer 143

Possibilita um certo grau de extensibilidade aos componente ou associações da UML.

Answer 144

Serve para especificar o número de vezes que um ator pode utilizar um determinado caso de uso.

Answer 145

... permite descrever detalhes técnicos do software como linguagens de programação que serão utilizadas.

Answer 146

...descreve uma sequência de objetos.

Answer 147

...possui como objetivo mostrar como um sistema faz determinada ação.

Answer 148

... utiliza casos de uso para expressar as pessoas e elementos que interagem com o sistema.

Answer 149

...não deve detalhar aspectos de implementação.

Answer 150

É estado que deve ser sempre verdadeiro antes do cenário ser iniciado em um caso de uso.

Answer 151

É uma sequência de ações que representam os cenários possíveis para um caso de uso.

Answer 152

Representa uma entidade externa que interage com o sistema.

Answer 153

É um elemento que deve abordar o que "geralmente" ocorre quando o caso de uso é executado.

Answer 154

É uma ação realizada no sistema.

Answer 155

Fluxo alternativo.

Answer 156

Fluxo básico.

Answer 157

Fluxos de exceção.

Answer 158

Pós-condições.

Answer 159

Pré-condições.

Answer 160

São utilizados para definir quem são os elementos que interagem com o sistema.

Answer 161

Este item representa o fluxo de alternativas que um caso de uso pode seguir.

Answer 162

Permite referenciar três elementos internos e quatro elementos externos.

Answer 163

Este item permite a definição dos aspectos técnicos do sistema.

Answer 164

Este item descreve a referência do caso de uso em relação ao fluxo.

Answer 165

É um tipo de classificador representando uma unidade funcional coerente provida pelo sistema.

Answer 166

É quem faz uma ação ou executa uma funcionalidade no sistema.

Answer 167

É uma forma de expressar uma relação entre dois elementos da especificação de casos de uso.

Answer 168

É estado que deve ser sempre verdadeiro antes do cenário ser iniciado.

Answer 169

É um estado que deve ser sempre verdadeiro depois da execução de uma ação pelo ator.

Answer 170

... permite descrever detalhes técnicos do software como linguagens de programação que serão utilizadas.

Answer 171

...descreve uma sequência de objetos.

Answer 172

...possui como objetivo mostrar como um sistema faz determinada ação.

Answer 173

... utiliza casos de uso para expressar as pessoas e elementos que interagem com o sistema.

Answer 174

...não deve detalhar aspectos de implementação.

Answer 175

É estado que deve ser sempre verdadeiro antes do cenário ser iniciado em um caso de uso.

Answer 176

É uma sequência de ações que representam os cenários possíveis para um caso de uso.

Answer 177

Representa uma entidade externa que interage com o sistema.

Answer 178

É um elemento que deve abordar o que "geralmente" ocorre quando o caso de uso é executado.

Answer 179

É uma ação realizada no sistema.

Answer 180

Fluxo alternativo.

Answer 181

Fluxo básico.

Answer 182

Fluxos de exceção.

Answer 183

Pós-condições.

Answer 184

Pré-condições.

Answer 185

São utilizados para definir quem são os elementos que interagem com o sistema.

Answer 186

Este item representa o fluxo de alternativas que um caso de uso pode seguir.

Answer 187

Permite referenciar três elementos internos e quatro elementos externos.

Answer 188

Este item permite a definição dos aspectos técnicos do sistema.

Answer 189

Este item descreve a referência do caso de uso em relação ao fluxo.

Answer 190

É um tipo de classificador representando uma unidade funcional coerente provida pelo sistema.

Answer 191

É quem faz uma ação ou executa uma funcionalidade no sistema.

Answer 192

É uma forma de expressar uma relação entre dois elementos da especificação de casos de uso.

Answer 193

É estado que deve ser sempre verdadeiro antes do cenário ser iniciado.

Answer 194

É um estado que deve ser sempre verdadeiro depois da execução de uma ação pelo ator.

Answer 195

É um diagrama que descreve as principais funcionalidades do sistema e a sua interação com os usuários do mesmo sistema.

Answer 196

É uma representação da estrutura e relações das classes que servem de modelo para objetos.

Answer 197

É um diagrama comportamental (que especifica o comportamento do software) do ponto de vista funcional.

Answer 198

É uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que ele mostra os objetos que foram instanciados das classes.

Answer 199

É um diagrama que descreve os componentes do software, suas interfaces e suas dependências.

Answer 200

Separa uma transição em várias transições executadas ao mesmo tempo.

Answer 201

Fluxo de uma atividade para outra.

Answer 202

Dependendo de uma condição, mostra as diferentes transições

Answer 203

Diferenciação de unidades organizacionais.

Answer 204

Um comportamento a ser realizado.

Answer 205

Ilustrar graficamente como será o funcionamento do software, como será a execução de alguma de suas partes e como será a atuação do sistema na realidade de negócio em que ele está inserido.

Answer 206

Descrever os vários tipos de objetos no sistema e o relacionamento entre eles.

Answer 207

Auxiliar a comunicação entre os analistas e o cliente.

Answer 208

Descrever como grupo de objetos colaboram em um determinado comportamento.

Answer 209

Mostrar os possíveis estados de um objeto e as transações responsáveis pelas mudanças de estado.

Answer 210

Para representar o fluxo de trabalho de uma atividade para outra.

Answer 211

Para controlar os desvios do fluxo de controle.

Answer 212

Para diferenciar diferentes unidades organizacionais do sistema.

Answer 213

Para representar as atividades.

Answer 214

Para informar o fim de um fluxo de atividades.

Answer 215

Para documentar as classes e os objetos que o sistema terá durante a sua modelagem.

Answer 216

Para documentar o aspecto funcional (não estrutural) do software durante a modelagem do sistema.

Answer 217

Para documentar e modelar os detalhes presentes na especificação de casos de uso durante a modelagem do sistema.

Answer 218

Para documentar e planejar a sequência de testes que será realizada durante a implementação do sistema.

Answer 219

Para utilizar na priorização de requisitos de software durante a fase de levantamento de requisitos.

Answer 220

O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.

Answer 221

Os testes de software são ações tomadas para que um projeto demore mais do que o esperado, não sendo necessário em projetos críticos.

Answer 222

Os testes de software são realizados no início do projeto, antes da implementação do software.

Answer 223

Testes de software buscam demonstrar a incapacidade dos desenvolvedores na criação de soluções de qualidade.

Answer 224

Testes de software são um conjunto de atividades realizadas somente pelo cliente quando recebe o produto.

Answer 225

Teste de caixa-preta.

Answer 226

Teste de caixa-branca.

Answer 227

Regressão.

Answer 228

Técnicas não funcionais.

Answer 229

Caixa-cinza.

Answer 230

Teste de aceitação.

Answer 231

Teste de sistema.

Answer 232

Teste de operação.

Answer 233

Teste de integração.

Answer 234

Teste de unidade.

Answer 235

É um ciclo de vida desenvolvido para facilitar a criação de testes.

Answer 236

TDD é uma técnica de testes de software utilizada pelos usuários dos sistemas.

Answer 237

TDD é um modelo clássico da Engenharia de Software e não é mais utilizado.

Answer 238

TDD é um sistema usado para testar software de forma automatizada.

Answer 239

O TDD é uma técnica de desenvolvimento de software que se baseia na criação inicial de testes de software antes mesmo do desenvolvimento.

Answer 240

Planejamento.

Answer 241

Preparação.

Answer 242

Execução.

Answer 243

Especificação.

Answer 244

É o processo de melhoria e otimização de um sistema já desenvolvido, como também é o reparo dos seus defeitos.

Answer 245

É o processo em que o software é testado em busca de falhas.

Answer 246

É a etapa em que o software é desenvolvido pelos programadores.

Answer 247

É o processo de análise das necessidades do cliente.

Answer 248

É a fase que existe o planejamento do projeto realizado pelo gerente de projetos.

Answer 249

Manutenção evolutiva.

Answer 250

Manutenção corretiva.

Answer 251

Manutenção adaptativa.

Answer 252

Manutenção preventiva.

Answer 253

Manutenção total.

Answer 254

Devido à manutenção ser realizada mais rapidamente do que a implementação do software.

Answer 255

Para que o software seja inutilizado antes do previsto.

Answer 256

Para que os desenvolvedores finalizem o projeto mais rapidamente.

Answer 257

Devido à manutenção de software, geralmente, possuir um custo mais elevado do que o próprio desenvolvimento.

Answer 258

Para que os defeitos e falhas não sejam encontrados.

Answer 259

A maioria dos problemas com a manutenção do software é causada pelo uso de testes unitários.

Answer 260

A maioria dos problemas com a manutenção do software é causada por implementações bem estruturadas e codificadas, pois utiliza padrões de projetos e conceitos bem definidos.

Answer 261

A maioria dos problemas com a manutenção do software é causada pela existência de uma documentação vasta e bem elaborada.

Answer 262

A maioria dos problemas com a manutenção do software é causada por deficiências na maneira como ele foi planejado e desenvolvido.

Answer 263

Manutenibilidade pode ser definida como a forma de manutenção do software.

Answer 264

Manutenibilidade pode ser definida como o conjunto de técnicas utilizadas para verificar se o software atende às necessidades do cliente.

Answer 265

Manutenibilidade pode ser definida como a facilidade com que o software pode ser entendido, corrigido, adaptado e/ou melhorado.

Answer 266

Manutenibilidade pode ser definida como o conjunto de técnicas de implementação de software.

Answer 267

Manutenibilidade pode ser definida como a possibilidade de um software obter manutenção.

	Erstellt von Rodrigo Nass vor mehr als ein Jahr

Nächster

Engenharia de Software I

Beschreibung

Zusammenfassung der Ressource

Frage 1

Frage 2

Frage 3

Frage 4

Frage 5

Frage 6

Frage 7

Frage 8

Frage 9

Frage 10

Frage 11

Frage 12

Frage 13

Frage 14

Frage 15

Frage 16

Frage 17

Frage 18

Frage 19

Frage 20

Frage 21

Frage 22

Frage 23

Frage 24

Frage 25

Frage 26

Frage 27

Frage 28

Frage 29

Frage 30

Frage 31

Frage 32

Frage 33

Frage 34

Frage 35

Frage 36

Frage 37

Frage 38

Frage 39

Frage 40

Frage 41

Frage 42

Frage 43

Frage 44

Frage 45

Frage 46

Frage 47

Frage 48

Frage 49

Frage 50

Frage 51

Frage 52

Frage 53

Frage 54

Frage 55

ähnlicher Inhalt