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

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.

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

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

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

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

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.

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

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

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.

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

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

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

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

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.

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

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

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

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

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.

Métodos.

Ferramentas.

Foco na qualidade.

Processo.

Conceitual.

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

É oferecido um sistema completo, com todas as funcionalidades.

É oferecida apenas a documentação do sistema.

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

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

Um manual de utilização do sistema.

Descarte do protótipo.

Uso exaustivo do sistema para encontrar erros.

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

Pagamento pelo projeto.

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

Um sistema parcialmente funcional.

Espera-se um sistema completo e funcional.

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

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

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

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

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

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

O custo do projeto é sempre respeitado.

O orçamento previsto do projeto pode ser ultrapassado.

O sistema é desenvolvido respeitando os prazos.

Redução de riscos de atraso da entrega.

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

O projeto é alinhado com as necessidades do cliente.

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

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

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

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

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

Na fase de projeto.

Na fase de levantamento de requisitos.

Na fase de implementação.

Na fase de testes e manutenção.

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

É realizada a implementação do sistema.

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

É realizada a análise de requisitos.

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

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

Modelo V.

Cascata.

Espiral.

Prototipagem.

Incremental.

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

É um modelo bastante simples.

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

Apresenta o problema de reatividade a mudanças.

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

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

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

É 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.

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

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

Definem propriedades e restrições do sistema.

escrevem explicitamente as funcionalidades e serviços do sistema.

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

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

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

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

É um tipo de requisito fácil de estimar.

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

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

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

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.

Definem propriedades e restrições do sistema.

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

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

É um tipo de requisito difícil de estimar.

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

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

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.

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.

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

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.

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

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.

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.

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

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

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

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

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

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

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

É aquilo que existe independente do sistema/software.

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.

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

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

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

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

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.

São requisitos definidos pelas tarefas que eles realizam.

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

Observação in loco/etnografia.

Encontros.

Entrevista.

Ligação.

Contato.

É 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.

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

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

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

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

Com uma elipse.

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

Com uma seta pontilhada.

Com um círculo com bordas pontilhadas.

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

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.

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.

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

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.

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

Na execução dos testes de software.

Implementação do software.

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

Na entrega do software para o cliente.

Na fase de manutenção do software.

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

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

Para definir uma grande função do sistema.

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

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

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

...descreve uma sequência de objetos.

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

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

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

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

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

Representa uma entidade externa que interage com o sistema.

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

É uma ação realizada no sistema.

Fluxo alternativo.

Fluxo básico.

Fluxos de exceção.

Pós-condições.

Pré-condições.

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

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

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

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

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

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

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

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

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

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

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

...descreve uma sequência de objetos.

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

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

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

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

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

Representa uma entidade externa que interage com o sistema.

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

É uma ação realizada no sistema.

Fluxo alternativo.

Fluxo básico.

Fluxos de exceção.

Pós-condições.

Pré-condições.

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

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

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

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

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

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

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

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

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

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

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

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

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

É 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.

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

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

Fluxo de uma atividade para outra.

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

Diferenciação de unidades organizacionais.

Um comportamento a ser realizado.

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.

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

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

Descrever como grupo de objetos colaboram em um determinado comportamento.

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

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

Para controlar os desvios do fluxo de controle.

Para diferenciar diferentes unidades organizacionais do sistema.

Para representar as atividades.

Para informar o fim de um fluxo de atividades.

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

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

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

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

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

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.

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.

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

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

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

Teste de caixa-preta.

Teste de caixa-branca.

Regressão.

Técnicas não funcionais.

Caixa-cinza.

Teste de aceitação.

Teste de sistema.

Teste de operação.

Teste de integração.

Teste de unidade.

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

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

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

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

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

Planejamento.

Preparação.

Execução.

Especificação.

Entrega.

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

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

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

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

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

Manutenção evolutiva.

Manutenção corretiva.

Manutenção adaptativa.

Manutenção preventiva.

Manutenção total.

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

Para que o software seja inutilizado antes do previsto.

Para que os desenvolvedores finalizem o projeto mais rapidamente.

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

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

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

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.

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

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

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

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

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

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

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