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.