Desenvolvimento de Software

Question 1

Processo de Software:

• metodologia para as atividades, ações e tarefas necessárias para desenvolver um software de alta qualidade.
• conjunto de atividades relacionadas que levam à produção de um produto de software.

Question 2

Atividades do processo de software (Pressman):

• comunicação.
• planejamento.
• modelagem.
• construção.
• entrega.

Question 3

Atividades do processo de software (Sommervile):

• especificação.
• projeto e implementação.
• validação.
• evolução.

Question 4

Fluxo do processo de software:

Descreve como são organizadas as atividades metodológicas, bem como as ações e tarefas que ocorrem dentro de cada atividade em relação à sequência e tempo.

Pode ser:

• linear.
• iterativo.
• evolucionário.
• paralelo.

Question 5

Modelo de processo de software:

Fornece um guia específico para o trabalho de engenharia de software. Define o fluxo de todas as atividades, ações e tarefas, o grau de iteração e a organização do trabalho a ser feito.

Os modelos não prescritivos são denominados “ágeis”.

Question 6

Modelo espiral de processo de software:

Une o modelo em cascata com o modelo evolucionário.
Ou seja, constitui-se de seguidos ciclos. Cada ciclo segue a linha do modelo cascata, mas são repetidos diversos ciclos seguidamente, de maneira que o software é regularmente melhorado.
É baseado na prototipagem, como se o software produzido em cada ciclo fosse o protótipo para o próximo ciclo.

Seu diferencial é o reconhecimento ao risco.

Question 7

Modelo em cascata de processo de software = modelo linear.

Question 8

Engenharia de software orientada a reuso:

Baseia-se no desenvolvimento e uso de chamados componentes.

O foco é reutilizar componentes já implementados ou desenvolver novos componentes que poderão ser reutilizados no futuro.

Com isso, se reduz a quantidade de software a ser desenvolvido.

Question 9

Modelo incremental de processo de software:

Desenvolve diversas partes independentes do software seguindo o modelo em cascata.
Mas cada parte representa uma fase de desenvolvimento e entrega.
Cada entrega inclui uma nova parte/funcionalidade ao software, de maneira que o software é gradativamente incrementado, até todas as partes serem entregues.

Question 10

Os modelos evolucionários são baseados em prototipagem e melhoria continua do software.

A cada ciclo se produz uma versão do software (como um protótipo) que é então avaliada.
No próximo ciclo se considera a avaliação da versão anterior para definir as mudanças a serem implementadas neste novo ciclo.
Assim o software está continuamente evoluindo.

Question 11

Modelo RAD - Rapid application development

Reduz o tempo que é investido na fase de planejamento.

1. Planejamento: uma fase de planejamento mais curta, na qual se define um esboço dos requisitos e funcionalidades do software.
2. Prototipagem: desenvolvem-se protótipos com novas funcionalidades e recebe-se o feedback dos clientes. Com base no feedback, fazem alterações e novas funcionalidades. No final dessa fase, tem-se um modelo do que o cliente quer.
3. Construção e deploy: uma vez estabelecido o modelo que o cliente quer, passa-se para a fase de construir um software robusto que implemente o modelo e então entrega-se o software (deploy).

Question 12

Modelo RUP - Rational Unified Process ou Processo Unificado

• é um modelo incremental e iterativo.

A cada ciclo o software é estendido e melhorado.

É marcado por necessariamente envolver a orientação a objetos e documentação em UML.

4 fases:

1. Concepção/Iniciação: modelagem dos negócios e definição do escopo e requisitos do software.
2. Elaboração: arquitetura do software, incluindo UML.
3. Construção do software.
4. Transição: testes e validação, e implantação e disponibilização do software aos usuários.

Disciplinas: modelagem de negócios, requisitos, análise e projeto, implementação, testes, implantação.

Question 13

Sobre o Rational Unified Process (RUP)

Artefatos: nome dado aos resultados de trabalho, como exemplo documentos, código, etc.

Workflows: descrevem, em detalhes, o passo a passo, as tarefas, produtos a serem gerados e papéis dos profissionais envolvidos.

Papéis e atividades: um papel define um conjunto de atividades a serem executadas e os artefatos a serem produzidos.

Question 14

Engenharia de Requisitos: processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.

Question 15

Validação: estamos construindo o produto certo?
É a atividade em que obtemos o aceite do cliente sob determinado artefato.

Verificação: estamos construindo o produto da maneira certa?
Examina a especificação do software, de maneira a assegurar sua conformidade, e detectando e corrigindo possíveis problemas.

Question 16

Requisito de Usuário:

• definido em linguagem natural.
• são as restrições com as quais o sistema deve operar.
• é o que o sistema deve fornecer aos usuários.

Question 17

Requisito de Sistema:

• especificação de requisitos do sistema.
• define exatamente o que deve ser implementado.
• serve para os desenvolvedores.

Question 18

Requisitos funcionais: descrevem as funções/ações que o sistema fornece ao usuário.
Ex: o sistema envia um email de confirmação uma vez que o usuário se cadastra.

Requisitos não-funcionais: descrevem restrições e limitações do sistema. Geralmente diz respeito à eficiência, performance, disponibilidade, etc do sistema.
Ex: a página deve carregar em menos de 3 segundos.

Question 19

Requisitos do negócio: descrevem em termos do negócio o que deve ser entregue para fornecer valor.

Requisitos do produto: descrevem as propriedades que o sistema deve satisfazer.

Requisitos do processo: especifica as metodologias a serem seguidas e a restrições que devem ser obedecidas durante o desenvolvimento do sistema.

Question 20

O documento de requisitos de software, também chamado de especificação de requisitos de software, é um documento oficial que descreve o que os desenvolvedores devem implementar, incluindo requisitos do sistema e do usuário.

Question 21

Sobre o documento da engenharia de requisitos:

• clientes do sistema: especificam e leem os requisitos para saber se o sistema atende suas necessidades. Também especificam mudanças e novos requisitos.

Question 22

Sobre o documento da engenharia de requisitos:

• gerentes: usam o documento para planejar uma proposta para o sistema e para planejar o processo de desenvolvimento.

Question 23

Sobre o documento da engenharia de requisitos:

• engenheiros do sistema: consideram os requisitos para entender e conceber o sistema que será desenvolvido.

Question 24

Sobre o documento da engenharia de requisitos:

• engenheiros de teste: consideram os requisitos para desenvolver testes de validação do sistema.

Question 25

Sobre o documento da engenharia de requisitos: - engenheiros de manutenção: consideram os requisitos para entender o sistema e o relacionamento entre suas partes.

Question 26

Engenharia de Requisitos 4 etapas: 1. descoberta dos requisitos: interação com os stakeholders para descobrir os requisitos desejados para o sistema. 2. classificação dos requisitos: agrupa os requisitos relacionados e organiza em grupos coerentes. 3. priorização e negociação de requisitos. 4. especificação e documentação dos requisitos.

Question 27

Técnicas de levantamento de requisitos: - entrevistas: entrevistas formais ou informais com stakeholders. - cenários: cenários e exemplos práticos de situações reais de uso do sistema. - casos de uso: identifica uma interação, os atores envolvidos e dá um nome à interação. - etnografia: observar o dia a dia dos funcionários e usuários finais do sistema. - prototipação: é desenvolvido um protótipo satisfazendo alguns requisitos e deve ser validado. - joint application development: preve reuniões envolvendo tanto desenvolvedores quanto usuários.

Question 28

Requisitos de Software: - requisitos normais (explícitos). - requisitos esperados (implícitos). - requisitos fascinantes.

Question 29

Validação de Requisitos - verificação de validade. - verificação de consistência. - verificação de completude. - verificação de realismo. - verificabilidade: os requisitos do sistema devem ser passíveis de verificação, i.e, deve ser possível escrever um conjunto de testes que demonstrem que o sistema atende aos requisitos. - adaptabilidade.

Question 30

Técnicas de validação de requisitos 1. revisão de requisitos. 2. prototipação. 3. geração de casos de testes.

Question 31

Gerenciamento de requisitos: é o processo de controle das mudanças nos requisitos do sistema. 1. identificação dos requisitos. 2. processo de gerenciamento de mudanças. 3. políticas de rastreabilidade: definem os relacionamentos entre um requisito, suas fontes e seus artefatos. Permite a identificação dos antecedentes e consequências de um requisito. 4. ferramentas de apoio: para a documentação e acompanhamento dos requisitos.

Question 32

Gerenciamento de Mudanças de Requisitos 1. análise de problemas e especificação de mudanças. 2. análise de mudanças e custos, prazos, esforços e riscos. 3. implementação de mudanças.

Question 33

Testes de software: destinado a mostrar que um programa faz o que proposto a fazer e para identificar defeitos antes de seu uso. Tem dois objetivos: 1. demonstrar que o software atende aos requisitos. (testes de validação) 2. descobrir casos em que o software se comporta de maneira incorreta. (testes de defeito)

Question 34

Verificação: checar se o software atende seus requisitos funcionais e não funcionais. Verificação da conformidade com as especificações. Validação: é o processo mais geral, seu objetivo é verificar que o software atende às expectativas do cliente.

Question 35

Inspeções e revisões: analisam e verificam os requisitos, modelos de projeto, código-fonte e testes, mas sem necessidade de executar o software. Focam principalmente no modelo e código-fonte.

Question 36

Três estágios de teste de software: 1. testes em desenvolvimento: o sistema é testado durante o desenvolvimento para descobrir bugs e defeitos. 2. testes de release: uma equipe de teste independente testa uma versão completa do sistema antes de ser liberado para os usuários. 3. teste de usuários: os usuários testam o sistema em seu próprio ambiente.

Question 37

Os testes em desenvolvimento podem ser: - testes unitários: testa as unidades individuais do programa, como classes e métodos, de maneira individual e independente. Testes unitários consistem de chamadas individuais para cada rotina com diferentes valores para as entradas. - testes de componentes: diversas unidades são integradas para criar uma componente composta. O objetivo é testar a interface (interação) entre os componentes. - teste de sistemas: alguns ou todos os componentes do sistema são integrados e o sistema é testado como um todo. O objetivo é descobrir bugs.

Question 38

Modelo tradicional de testes de software: 1. projetar casos de teste. 2. preparar dados de teste. 3. executar programas com dados de teste. 4. comparar os resultados. 5. elaborar relatórios.

Question 39

Testes de Release: é o processo de testar um release do sistema que se destina para uso fora da equipe de desenvolvimento.

Question 40

- testes de sistema: feitos pela equipe de desenvolvimento com o objetivo de descobrir bugs (testes de defeitos). - testes de release (testes funcionais): uma equipe que não é a de desenvolvimento. Têm o objetivo de verificar se o sistema atende aos requisitos e é bom para uso pelo usuário (validação).

Question 41

- testes caixa-preta: não leva em conta conhecimento sobre a estrutura do sistema ou do código-fonte. - testes caixa-branca: leva em conta conhecimento sobre a estrutura do sistema ou do código-fonte. Buscam verificar o comportamento interno do software.

Question 42

Testes de release, também conhecidos como testes funcionais, costumam ser caixa-preta. O objetivo é verificar que o software atende as funcionalidades e requisitos do cliente/usuário.

Question 43

Testes de release: Para cada requisito/funcionalidade do software, elabora-se um conjunto de testes. O objetivo é a validação, ou seja, mostrar que o software atende ao requisito adequadamente.

Question 44

Rastreabilidade dos testes: propriedade de ligar os testes elaborados aos requisitos/funcionalidades que motivaram aquele teste.

Question 45

Testes de cenário: um tipo de teste de release na qual se imagina um cenário típico de uso do software.

Question 46

Testes de desempenho: testa requisitos não-funcionais do sistema, como desempenho ou confiabilidade. Testam a capacidade do sistema em suportar a carga a que se destina. Testes de estresse levam o sistema ao seu limite.

Question 47

Testes de usuário: é o estágio no qual os clientes/usuários fornecem dados de entrada e conselhos para os testes do software. Inclui: - testes alfa. - testes beta. - testes de aceitação.

Question 48

Testes alfa: tipo de teste no qual os usuários do software trabalham junto com a equipe desenvolvimento para testar o software no local do desenvolvedor. - reduzem o risco de mudanças inesperadas no software que impactem os negócios. - podem ser usados no desenvolvimento de softwares customizados ao cliente.

Question 49

Testes beta: tipo de teste no qual o software é disponibilizado aos usuários para que possam experimentá-lo em seu próprio ambiente. - possibilita o teste do software nos mais diversos ambientes.

Question 50

Testes de aceitação: tipo de teste no qual o cliente testa formalmente o software para decidir se ele deve ser aceito ou se é necessário alterações/desenvolvimento adicional. - costuma envolver testes manuais e automatizados.

Question 51

Testes de regressão: consiste na reexecução de testes anteriores com o objetivo de verificar que alterações no software não introduziram novos bugs em partes anteriormente testadas.

Question 52

Testes de desenvolvimento: ocorrem durante o desenvolvimento do software com o objetivo de descobrir bugs e defeitos. Tipos: - testes unitários: testam unidades individuais do software, como classes e métodos, de maneira isolada e individual. - testes de componentes: testam a interação/interface entre diferentes unidades, que quando combinadas são chamadas de componentes. - testes de sistema: testa uma versão integrada do sistema, com vários ou todos os componentes. O sistema é testado como um todo.

Question 53

Testes de release: uma equipe de teste, independente da equipe de desenvolvimento, testa uma versão completa do sistema antes da liberação aos usuários. Tipos: - baseado em requisitos: para cada requisito é desenvolvido um conjunto de testes para verificá-lo. - testes de cenário: cenários típicos de uso são emulados como teste do sistema. - testes de desempenho: testam requisitos não funcionais, como consumo de memória, tempo de resposta, capacidade de carga.

Question 54

Testes de usuário: testes nos quais os clientes ou usuários testam o software. Tipos: - alfa: os usuários trabalham conjuntamente com a equipe de desenvolvimento para testar o software no ambiente do desenvolvedor. - beta: uma versão do software é disponibilizada para os usuários utilizarem em seus próprios ambientes. - testes de aceitação: o cliente testa formalmente o sistema para decidir se aceita a versão ou se deve haver trabalho adicional de desenvolvimento.

Question 55

Testes de release funcionais: os testes são derivados da especificação/requisitos do sistema. Tipos: - caixa-preta: objetivo de verificar se o software atende os requisitos, sem conhecimento do código e estrutura interna. - caixa-branca: buscam verificar o comportamento interno do software, incluindo o código. - testes de regressão: reexecução de testes anteriores para verificar que novas mudanças não introduziram novos bugs.

Question 56

Testes de release desempenho: testa o software para requisitos não funcionais, como desempenho e confiabilidade. Tipos: - teste de carga: testar se o sistema é capaz de processar a carga a que se destina. - teste de estresse: verificar se o software atende os requisitos e explorar os limites do software.

Question 57

Testes de integração: combinam componentes em conjuntos e testam a sua integração. Tipos: - incrementais (top-down ou bottom-up): os componentes são incluídos incrementalmente/gradativamente. - big-bang: todos os componentes são combinados de uma só vez

Question 58

Teste fumaça: utilizado principalmente para projetos com prazo crítico. É uma estratégia de integração contínua. São efetuados testes todos os dias. A finalidade é identificar erros bloqueadores, que bloqueiam o progresso e atrasam o desenvolvimento.

Question 59

Teste de classe: é o equivalente ao teste de unidade porém no contexto de orientação à objetos. É um teste baseado em sequência de execução, e integra o conjunto de classes necessárias para responder a uma entrada ou evento do sistema.

Question 60

Testes de validação: o foco está em verificar se o software atende aos requisitos, i.e, aqueles requisitos que envolvem o usuário.

Question 61

Teste de configuração: é o processo de testar o sistema em cada configuração de software e hardware. Ex: navegadores, OS, dispositivos, driver...

Question 62

Testes de sistema: série de testes cuja finalidade é exercitar totalmente o sistema. Têm o objetivo de verificar se os elementos do sistema foram integrados corretamente e executam as funções apropriadas.

Question 63

Testes de sistema: Tipos: - recuperação: verifica o comportamento das funções de recuperação do sistema após falhas. - segurança: verifica a eficácia dos mecanismos de segurança do sistema. - esforço ou estresse: coloca o sistema em condições anormais, a fim de testar os seus limites e quando ele falha. - desempenho. - disponibilização ou configuração: examina os procedimentos de instalação do sistema e a documentação.

Question 64

Depuração ou debugging: tem o objetivo de encontrar e corrigir as causas dos erros.

Question 65

teste funcional = teste caixa-preta teste estrutural = teste caixa-branca

Question 66

Testes caixa-branca Tipos: - caminho básico: testes criados para garantir que cada instrução será executada pelo menos uma vez. - testes de condição: testa as condições lógicas de uma componente. - teste de fluxo de dados: exercita caminhos de definição de uma variável e seus usos seguintes. Por exemplo, pode-se acompanhar o valor da variável ao longo do caminho, sua devida inicialização e deleção. - teste de ciclo: testa laços dentro do programa e na validade da suas condições de loop.

Question 67

Testes caixa-preta Tipos: - baseado em grafo: os objetos e suas relações são representados por um grafo. Com base no grafo se elabora testes que exercitem os objetos e relações. - particionamento de equivalência: particiona o domínio de todos os possíveis valores de entrada em classes de equivalência (ou seja, valores que vão seguir o mesmo caminho). Basta realizar um teste para cada classe, reduzindo assim o esforço. É comum particionar em valores válidos (que devem ser aceitos pelo sistema) e valores inválidos (que devem ser rejeitados pelo sistema).

Question 68

Outros exemplos de testes: - teste de conteúdo: para webapps. - teste de base de dados: para sistemas que interagem com base de dados. - teste de usabilidade.

Question 69

Teste estático: ocorrem sem a execução do código. São métodos caixa-branca. Teste dinâmico: ocorrem com a execução do código. Um exemplo é executar o código para diferentes entradas. Costumam ser métodos caixa-preta.

Question 70

Ferramentas de teste estático: - código: aceitam o código-fonte como entrada e executam uma série de análises que geram casos de teste. Ex: Sonar. - linguagens de teste especializadas: permitem ao desenvolvedor escrever especificações detalhadas sobre a geração de testes. Ex: Atlas. - baseada em requisitos: consideram requisitos de maneira isolada e desenvolvem testes para aquele requisito específico.

Question 71

Ferramentas de teste dinâmicos: interagem com um programa em execução, possibilitando testes sobre os valores das variáveis durante execução, instrumentando o fluxo de execução. Ex: Jupit, Selenium, JMeter.

Question 72

Desenvolvimento Ágil: concebido para produzir softwares úteis de maneira rápida. Manifesto Ágil: 12 princípios ágeis. O software é desenvolvido como uma série de incrementos. Os usuários e stakeholders fazem parte da especificação e avaliação de cada versão. A documentação de requisitos é sucinta.

Question 73

Valores ágeis: - indivíduos e interações mais do que pessoas e ferramentas. - software em funcionamento mais do que documentação abrangente. - colaboração com o cliente mais do que negociação de contratos. - responder a mudanças mais do que seguir um plano.

Question 74

Manifesto Ágil 12 princípios: - Garantir a satisfação do cliente, entregando rápida e continuamente software funcional. - Até mesmo mudanças tardias de escopo no projeto são bem-vindas. - Software funcional é entregue frequentemente (semanal ou mensal - o menor intervalo possível). - Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores. - Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança. - A melhor forma de transmissão de informação entre desenvolvedores é através da conversa 'cara a cara'. - Software funcional é a principal medida de progresso do projeto. - Novos recursos de software devem ser entregues constantemente. Clientes e desenvolvedores devem manter um ritmo até a conclusão do projeto. - Design do software deve prezar pela excelência técnica. - Simplicidade – a arte de maximizar a quantidade de trabalho que não é feito – é essencial. - As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. - Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento.

Question 75

- engenharia de software: aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, operação e manutenção de software. - processo de software: sequencia de atividades que leva a produção de um produto de software. - metodologia: se refere a um conjunto de práticas adotadas para resolver um determinado problema.