1
Qual a diferença entre análise e projeto de sistemas?
A análise de sistemas envolve entender e definir os requisitos do sistema, enquanto o projeto de sistemas é a atividade de projetar a solução que atenda a esses requisitos.
A análise de sistemas envolve a implementação do sistema, enquanto o projeto de sistemas se concentra na identificação de problemas.
A análise de sistemas é uma etapa opcional do desenvolvimento de software, enquanto o projeto de sistemas é obrigatório.
A análise de sistemas é realizada após o projeto de sistemas para validar os requisitos do sistema.
2
Qual a importância da Engenharia de Software?
A Engenharia de Software é importante apenas para a fase inicial de desenvolvimento de software, não tendo impacto significativo nas etapas posteriores.
A Engenharia de Software é importante apenas para grandes empresas, não sendo relevante para projetos menores.
A Engenharia de Software é importante porque fornece métodos e técnicas para desenvolver software de alta qualidade, dentro do prazo e do orçamento.
A Engenharia de Software é importante apenas para garantir a segurança do software, não influenciando em sua qualidade ou prazo de entrega.
3
Como a Engenharia de Requisitos contribui para o desenvolvimento de software?
A Engenharia de Requisitos contribui para o desenvolvimento de software garantindo que as necessidades dos usuários sejam corretamente identificadas, documentadas e compreendidas pelos desenvolvedores.
A Engenharia de Requisitos não tem impacto real no desenvolvimento de software, sendo uma etapa desnecessária.
A Engenharia de Requisitos contribui para o desenvolvimento de software apenas definindo requisitos superficiais, sem considerar aspectos essenciais do sistema.
A Engenharia de Requisitos contribui para o desenvolvimento de software apenas no início do processo, perdendo relevância nas fases posteriores.
4
Qual a relação entre análise de sistemas e engenharia de requisitos?
A análise de sistemas se concentra na decomposição do sistema em componentes menores, enquanto a Engenharia de Requisitos lida com a identificação e priorização dos requisitos do usuário.
A análise de sistemas é uma parte da Engenharia de Requisitos, que é responsável por entender os requisitos do sistema e transformá-los em especificações.
A análise de sistemas é uma etapa anterior à Engenharia de Requisitos, focando na compreensão dos processos de negócio antes da identificação dos requisitos.
A análise de sistemas e a Engenharia de Requisitos são disciplinas independentes, cada uma com seu próprio conjunto de atividades e objetivos.
5
Qual a diferença entre licitação, análise, especificação, V&V e gerência de requisitos?
Licitação é o processo de contratação de fornecedores, análise é a compreensão dos requisitos do sistema, especificação é a descrição dos requisitos, V&V é a verificação e validação dos requisitos, e gerência de requisitos é o controle e gerenciamento dos requisitos durante todo o ciclo de vida do projeto.
Licitação é o processo de seleção de fornecedores, análise é a compreensão dos requisitos do sistema, especificação é a documentação dos requisitos, V&V é a verificação e validação dos requisitos, e gerência de requisitos é o controle e gerenciamento dos requisitos ao longo do ciclo de vida do projeto.
Licitação é o processo de seleção de fornecedores, análise é a compreensão dos requisitos, especificação é a documentação dos requisitos, V&V é verificação e validação, e gerência de requisitos é o controle e gerenciamento dos requisitos ao longo do ciclo de vida do projeto.
Licitação é o processo de escolha de fornecedores, análise é a interpretação dos requisitos do sistema, especificação é a elaboração dos requisitos, V&V é a validação e verificação dos requisitos, e gerência de requisitos é o gerenciamento dos requisitos durante todo o projeto.
6
Qual o papel do projeto de software?
O projeto de software, quando conduzido de forma inadequada, pode levar a análises excessivamente detalhadas, atrasando o progresso do desenvolvimento.
O projeto de software é frequentemente negligenciado em favor de abordagens mais iterativas, tornando-se obsoleto em ambientes ágeis de desenvolvimento.
O projeto de software é muitas vezes confundido com a fase de implementação, resultando em arquiteturas inadequadas e sistemas mal estruturados.
O projeto de software envolve a definição da arquitetura e da estrutura do sistema, traduzindo requisitos em um plano detalhado para implementação.
7
Qual a diferença entre os diferentes critérios de qualidade propostos na IEEE 830?
Os diferentes critérios de qualidade na IEEE 830 incluem funcionalidade, design, requisitos não funcionais, segurança, documentação, testes e eficiência.
Os diferentes critérios de qualidade na IEEE 830 incluem funcionais, desempenho, confiabilidade, segurança, usabilidade, manutenibilidade e portabilidade.
Os diferentes critérios de qualidade na IEEE 830 incluem desempenho, testabilidade, rastreabilidade, adaptabilidade, integridade, eficácia e conformidade.
Os diferentes critérios de qualidade na IEEE 830 incluem usabilidade, escalabilidade, interoperabilidade, manutenibilidade, confiabilidade, disponibilidade e resiliência.
8
Qual a diferença e como aplicar a decomposição, abstração, modularização?
A decomposição divide um sistema em partes menores, a abstração simplifica o sistema para entender melhor suas funcionalidades e a modularização organiza o sistema em módulos independentes.
A decomposição é apenas uma técnica teórica, sem aplicabilidade prática no desenvolvimento de software, enquanto a abstração e a modularização são essenciais para a implementação eficaz do sistema.
A decomposição se concentra apenas na divisão do sistema em partes menores, negligenciando a simplificação e a organização necessárias para a compreensão e manutenção do software.
A decomposição é uma abordagem exclusivamente top-down, enquanto a abstração e a modularização podem ser aplicadas tanto top-down quanto bottom-up.
9
O que significa dizer que projeto de software envolve tomadas de decisão em diferentes níveis de abstração?
Significa que o projeto de software é uma atividade puramente teórica, sem impacto prático na implementação real do sistema.
Significa que o projeto de software é uma atividade isolada, sem conexão direta com outras etapas do ciclo de vida do software, como requisitos ou teste.
Significa que o projeto de software envolve decisões em diferentes níveis de detalhe, desde decisões de alto nível sobre a arquitetura até decisões de baixo nível sobre a implementação específica.
Significa que o projeto de software envolve decisões em diferentes níveis de detalhe, desde decisões de alto nível sobre a arquitetura até decisões de baixo nível sobre a implementação específica.
Significa que o projeto de software envolve apenas decisões técnicas, sem considerar aspectos estratégicos ou de negócios.
10
Como o processo de projeto contribui para a qualidade do software?
O processo de projeto ajuda a garantir que o software atenda aos requisitos, seja robusto, eficiente, fácil de manter e evoluir.
O processo de projeto só contribui para a qualidade do software se for aplicado rigidamente, sem permitir flexibilidade ou adaptação às mudanças nos requisitos ou no ambiente de desenvolvimento.
O processo de projeto pode, na verdade, prejudicar a qualidade do software, se as decisões tomadas durante o projeto não forem revisadas ou validadas adequadamente.
O processo de projeto é irrelevante para a qualidade do software, sendo apenas uma formalidade no ciclo de desenvolvimento.
11
Qual a diferença entre ocultamento de informações, separação de responsabilidades e integridade conceitual?
O ocultamento de informações é uma técnica para proteger dados confidenciais, a separação de responsabilidades é uma prática de governança corporativa e a integridade conceitual é um conceito relacionado à segurança da informação.
O ocultamento de informações é uma prática obsoleta, a separação de responsabilidades é uma abordagem para evitar conflitos de interesse entre os membros da equipe, e a integridade conceitual é uma medida para garantir que o software seja livre de defeitos.
O ocultamento de informações não está relacionado à implementação, mas sim à interface do usuário, a separação de responsabilidades refere-se à distribuição de tarefas entre os membros da equipe de desenvolvimento, e a integridade conceitual diz respeito à conformidade com os padrões de codificação.
O ocultamento de informações visa esconder detalhes de implementação, a separação de responsabilidades divide o sistema em componentes distintos e a integridade conceitual garante que o sistema funcione de acordo com o esperado.
12
Qual a diferença entre Padrões Arquiteturais e Padrões de Projeto?
Padrões Arquiteturais definem a estrutura geral de um sistema, enquanto Padrões de Projeto fornecem soluções para problemas específicos de design.
Padrões Arquiteturais são exclusivamente aplicados em projetos de grande escala, enquanto Padrões de Projeto são mais adequados para projetos menores e individuais.
Padrões Arquiteturais são estáticos e definidos uma vez para todo o sistema, enquanto Padrões de Projeto são dinâmicos e podem ser modificados ao longo do tempo.
Padrões Arquiteturais são úteis apenas durante a fase de planejamento do projeto, enquanto Padrões de Projeto são implementados durante a fase de desenvolvimento do software.
13
O que é e como aplicar Design Thinking na prática?
Design Thinking é uma técnica exclusiva de designers profissionais, sem aplicabilidade para desenvolvedores de software ou equipes de negócios.
Design Thinking é uma abordagem demorada e dispendiosa, adequada apenas para projetos de grande escala ou organizações com recursos abundantes.
Design Thinking é uma abordagem centrada no ser humano para resolver problemas complexos e encontrar soluções inovadoras. Ele envolve uma série de etapas, incluindo empatia, definição, ideação, prototipagem e teste.
Design Thinking é um processo linear, onde cada etapa deve ser rigorosamente seguida, sem espaço para flexibilidade ou adaptação.
14
Qual a relação entre modelagem e abstração?
A modelagem é uma prática estática, enquanto a abstração é dinâmica e pode evoluir ao longo do ciclo de vida do projeto.
A modelagem é uma atividade exclusivamente técnica, enquanto a abstração envolve aspectos mais conceituais e criativos do processo de desenvolvimento de software.
A modelagem é uma atividade isolada, realizada apenas durante a fase de planejamento do projeto, enquanto a abstração é aplicada continuamente em todas as etapas do desenvolvimento.
A modelagem é o processo de representar aspectos de um sistema de forma simplificada e estruturada. A abstração é a técnica utilizada na modelagem para focar nos aspectos mais relevantes do sistema, ignorando detalhes desnecessários.
15
Por que a adoção de UML é importante para qualidade de software?
A adoção de UML pode ser excessivamente complexa para pequenas equipes ou projetos de curto prazo, levando a uma sobrecarga de trabalho e atrasos no desenvolvimento.
A adoção de UML pode ser considerada uma abordagem ultrapassada por algumas equipes de desenvolvimento ágil, que priorizam a colaboração e a comunicação verbal sobre a documentação extensiva.
A adoção de UML é irrelevante para a qualidade do software, pois é uma linguagem que se concentra apenas na representação visual do design, sem impacto direto na funcionalidade ou eficiência do sistema.
A UML é importante para a qualidade do software porque fornece uma linguagem padronizada para comunicar e visualizar o design do software.
16
Quando é pertinente utilizar UML como blueprint, linguagem de programação ou sketch?
Utilizar UML como blueprint pode ser inadequado para projetos simples ou pequenas funcionalidades, e como linguagem de programação pode ser impraticável, pois a UML não é uma linguagem de programação executável. Além disso, usar UML como sketch pode ser ineficaz para comunicar ideias de design de forma rápida e informal.
Utilizar UML como blueprint pode ser restritivo demais para projetos que exigem flexibilidade, e como linguagem de programação pode ser inadequado, já que a UML é uma linguagem de modelagem. Além disso, usar UML como sketch pode ser ineficaz para comunicar ideias de design de forma rápida e informal.
Utilizar UML como blueprint pode ser excessivamente detalhado e rígido para alguns projetos, e como linguagem de programação pode ser inadequado, pois a UML é uma linguagem de modelagem gráfica. Além disso, usar UML como sketch pode ser ineficaz para comunicar ideias de design de forma rápida e informal.
A UML é pertinente como blueprint para planejar o design do software, como linguagem de programação para implementar o software e como sketch para comunicar ideias de design de forma rápida e informal.
17
Qual a diferença entre modelagem de sistemas e modelagem de domínio?
A modelagem de sistemas é uma abordagem mais técnica, envolvendo diagramas e modelos específicos para descrever a arquitetura e o funcionamento do software, ao passo que a modelagem de domínio é mais conceitual, focando nas entidades e relacionamentos do contexto de negócios.
A modelagem de sistemas aborda apenas os aspectos funcionais e técnicos do software, enquanto a modelagem de domínio também considera aspectos organizacionais e de negócios do ambiente em que o software será utilizado.
A modelagem de sistemas é utilizada apenas para representar o software em si, enquanto a modelagem de domínio é voltada apenas para representar o ambiente externo ao software.
A modelagem de sistemas se concentra na representação do software, enquanto a modelagem de domínio se concentra na representação do ambiente em que o software opera.
18
Qual a diferença entre os Diagramas Estáticos e Diagramas Dinâmicos?
Os Diagramas Estáticos são mais úteis para desenvolvedores, enquanto os Diagramas Dinâmicos são mais úteis para os usuários finais.
Os Diagramas Estáticos representam a estrutura estática do sistema, enquanto os Diagramas Dinâmicos representam o comportamento dinâmico do sistema.
Os Diagramas Estáticos são usados apenas na fase de design do sistema, enquanto os Diagramas Dinâmicos são usados apenas na fase de implementação.
Os Diagramas Estáticos descrevem apenas a interação entre os componentes do sistema, enquanto os Diagramas Dinâmicos descrevem apenas a estrutura de dados do sistema.
19
O que significa dizer que Diagramas Estáticos e Diagramas Dinâmicos apresentam uma complementaridade de perspectivas?
Significa que ambos os tipos de diagramas oferecem visões diferentes do sistema, combinando uma visão estrutural (estática) e uma visão comportamental (dinâmica).
Significa que os Diagramas Estáticos e Diagramas Dinâmicos são utilizados para descrever apenas um aspecto do sistema, seja estrutural ou comportamental, o que não reflete a natureza complementar desses diagramas.
Dizer que os Diagramas Estáticos e Diagramas Dinâmicos apresentam uma complementaridade de perspectivas significa que ambos os tipos de diagramas oferecem visões semelhantes do sistema, o que não é verdadeiro.
Significa que os Diagramas Estáticos e Diagramas Dinâmicos fornecem apenas uma visão do sistema, em vez de múltiplas perspectivas, o que não é preciso.
20
Quando o Diagrama de Atividades é relevante para ser utilizado?
O Diagrama de Atividades é relevante apenas para a fase de implementação de um projeto, não sendo útil durante as fases de análise e design.
O Diagrama de Atividades é relevante para representar o fluxo de trabalho de um sistema.
O Diagrama de Atividades é relevante apenas para projetos de pequena escala, não sendo adequado para sistemas complexos.
O Diagrama de Atividades é relevante apenas para representar a estrutura de dados de um sistema, não sendo útil para descrever o fluxo de trabalho.
21
Quais os elementos básicos que compõem um Diagrama de Atividades?
Os elementos básicos de um Diagrama de Atividades incluem atividades, transições, pontos de decisão e ramificações.
Os elementos básicos de um Diagrama de Atividades incluem estados, eventos, ações e linhas de vida, deixando de fora elementos como atividades e transições.
Os elementos básicos de um Diagrama de Atividades incluem objetos, mensagens, classes e interfaces, excluindo elementos como atividades e pontos de decisão.
Os elementos básicos de um Diagrama de Atividades incluem fluxos de controle, exceções, inclusões e extensões, ignorando elementos como atividades e transições.
22
O que é um Caso de Uso?
Um Caso de Uso descreve as funcionalidades internas de um sistema, sem considerar as interações com os usuários finais.
Um Caso de Uso descreve os requisitos de infraestrutura de um sistema, deixando de lado as interações específicas dos usuários.
Um Caso de Uso descreve os protocolos de comunicação entre sistemas, sem abordar diretamente as interações com os usuários.
Um Caso de Uso descreve uma interação entre os usuários e o sistema.
23
Quando o Diagrama de Caso de Uso é relevante para ser utilizado?
O Diagrama de Caso de Uso é relevante para representar os requisitos funcionais do sistema e as interações entre os atores e os casos de uso.
O Diagrama de Caso de Uso é relevante apenas para a fase inicial de análise de requisitos, não sendo útil durante as fases de implementação e teste do sistema.
O Diagrama de Caso de Uso é relevante apenas para representar os requisitos não funcionais do sistema, excluindo as interações entre atores e casos de uso.
O Diagrama de Caso de Uso é relevante apenas para sistemas de pequena escala, não sendo adequado para projetos maiores ou mais complexos.
24
Quais os elementos básicos que compõem um Diagrama de Caso de Uso?
Os elementos básicos de um Diagrama de Caso de Uso incluem atores,
casos de uso e relações entre eles.
Os elementos básicos de um Diagrama de Caso de Uso incluem atores, descrições de cenários e fluxos alternativos, excluindo adequadamente casos de uso ou suas interações.
Os elementos básicos de um Diagrama de Caso de Uso incluem atores, diagramas de sequência e diagramas de comunicação, negligenciando a representação completa dos casos de uso ou suas interações.
Os elementos básicos de um Diagrama de Caso de Uso incluem atores, descrições de testes e documentação de requisitos, sem abordar adequadamente a estrutura e as relações dos casos de uso.
25
Qual a diferença entre Caso de Uso e História de Usuário?
Um Caso de Uso descreve uma funcionalidade do sistema do ponto de vista do usuário, enquanto uma História de Usuário descreve um requisito específico do ponto de vista do usuário.
Um Caso de Uso descreve uma sequência de ações do usuário, enquanto uma História de Usuário descreve as características técnicas do sistema.
Um Caso de Uso é uma ferramenta utilizada apenas por desenvolvedores, enquanto uma História de Usuário é uma ferramenta utilizada apenas por usuários finais.
Um Caso de Uso é uma representação visual do sistema, enquanto uma História de Usuário é uma narrativa textual das interações do usuário com o sistema.
