Aula 1234 Engenharia e Projeto de Software

1. O que é Sistemas Legados:
a. São sistemas de software mais velhos que são vitais para uma organização;
b. Geralmente não são os sistemas que foram originalmente fornecidos, uma vez que passaram por diversas mudanças ocasionadas por fatores internos e externos;
c. Essas mudanças geram requisitos de software novos ou modificados;
d. Os sistemas legados incorporam um grande número de alterações, feitas com no decorrer do tempo de uso do software, onde muitas pessoas, diferentes, realizam essas mudanças, e é incomum que quaisquer pessoas tenha uma compreensão completa do sistema;
e. São sistemas que são desenvolvidos especialmente para uma organização têm vida longa;
f. Muitos destes sistemas que ainda estão em uso foram desenvolvidos muito tempo atrás utilizando tecnologia que hoje são ultrapassadas;
g. Embora antigos, esses sistemas ainda são necessários ao negócio, ou seja, são essenciais pelo funcionamento normal do negócio e por isto são chamados de “Sistemas Legados”.
2. Substituição de Sistemas Legados: Há um risco empresarial significante descartando simplesmente um sistema de legado e substituindo por um novo sistema desenvolvido utilizado tecnologia mais modernas, pais:
a. Sistemas de legado raramente têm uma especificação completa;
b. A configuração original pode ter sido válida e caso a mesma exista, é pouco provável que as mudanças principais tenham sido documentadas;
3. Mudança de Sistemas Legados: Sistemas devem ser mudados ordenadamente para permanecerem úteis, contudo, mudanças em sistemas legados podem ter alto custo, pois:
a. Diferentes partes do sistema foram implementadas por diferentes equipes, desta forma não possuindo um estilo de programação consistente;
b. O sistema pode usar uma linguagem de programação obsoleto;
c. A documentação de sistema está frequentemente desatualizada. Em alguns casos a única documentação é o código-fonte;
d. A estrutura do sistema pode ter sido otimizada para melhorar a utilização de espaço ou a velocidade de execução, em vez de ser escrito para facilitar a compreensão;
e. Estruturas de arquivo usadas podem ser incompatíveis.
4. Sistemas Legados Dilemas:
a. É caro e arriscado substituir um sistema legado;
b. É caro manter um sistema legado;
c. Negócios têm que pesar os custos e riscos e podem escolher estender a vida de sistema que utiliza técnicas como reengenharia.


5. Estruturas de Sistema Legado: São considerados como sistemas sócio-técnicos e não simplesmente de software, visto que são compostos por:
a. Hardware de sistema – pode ser hardware mainframe;
b. Software de apoio – sistemas operacionais e utilitários;
c. Software de aplicação- vários programas diferentes;
d. Dados de aplicação – dados processados por sistemas de aplicação, possuindo um imenso volume de dados e que podem estar inconsistentes ou duplicados em diferentes arquivos;
e. Processos de negócios – os processos usados nas empresas a fim de atingir algum objetivo;
f. Políticas e regras de negócio – São as definições de como a empresa deve ser conduzida e as restrições às quais vão se submeter.
6. Modelo em Camadas: Sistema Sócio-Técnico
a. Processos de negócios
b. Software de aplicação
c. Software de apoio
d. Hardware
7. Mudança de Sistema: Em princípio, deveria ser possível substituir um modelo de sistema partindo de outros novos modelos. Na prática, isso é normalmente impossível, pois:
a. Mudando um modelo, introduz novas facilidades e modelos em níveis mais elevados têm que ser mudado para que se possa fazer uso deste;
b. Mudando software pode reduzir a velocidade de processamento, assim então são requeridas mudanças de hardware;
c. É frequentemente impossível manter interfaces de hardware por causa da diferença entre mainframes e sistemas de cliente-servidor.
8. Sistemas Legados de Aplicação: O Software de Aplicação em um sistema legado não é o único programa de aplicação, mas sim uma série de diferentes programas.
9. Sistemas Centrados em BD:
a. Um grande número de sistemas corporativos centralizou seu gerenciamento de dados em um único SGBD;
b. A grande vantagem é que usa o mesmo modelo lógico e físico de dados, reduzindo assim a redundância de duplicação dos dados;
10. Projeto de Sistemas Legados:
a. A maioria dos sistemas legados que foram projetados antes da orientação a objetos ser usado, eram utilizadas estratégias orientando a funções, usando técnicas de projeto estruturado de sistemas;
b. Em lugar de ser organizado como um conjunto de objetos interagindo, estes sistemas que têm sido projetados usando uma estratégia de projeto orientado a objeto;
c. Vários métodos e ferramentas CASE estão disponíveis para suportar projetos orientados a função de aproximação ainda e usada em muitas áreas comerciais;
11. Avaliação dos Sistemas Legados: Organizações que confiam em sistemas de legado devem escolher uma estratégia para a atualização destes sistemas:
a. Descartar completamente o sistema e modifique processos empresariais;
b. Continue mantendo sistema;
c. Transforme o sistema usando a re-engenharia para melhorar a sua manutenibilidade;
d. Substitua o sistema por um sistema novo
e. A estratégia escolhida deve depender do sistema e do seu valor empresarial;
12. Grupos de Sistemas Legados:
a. Baixa qualidade, baixo valor de negócios
i. Estes sistemas deveriam ser descartados;
b. Baixa qualidade alto valor de negócios
i. Estes prestam uma importante contribuição a empresa, mas é caro mantê-lo, porém, não pode ser descartado. Aplicar a reengenharia ou substitui-lo por um outro sistema;
c. Alta qualidade, baixo valor de negócios;
i. Não vale o risco de substituir esses sistemas de modo que a manutenção pode ser continuada;
d. Alta qualidade, alto valor de negócios
i. Continue em operação usando normalmente a manutenção do sistema;
13. Avaliação do Valor de Negócios
a. É um julgamento subjetivo, não existindo nenhum método confiável que possa ser utilizado. Assim sendo é recomendável utilizar uma abordagem de pontos de vista;
b. Os pontos de vista devem ser considerados e as possíveis questões são: usuários finais do sistema, clientes, gerentes de linha, gerentes de TI, gerentes seniores;
c. Uma vez identificados os pontos de vista suas respostas devem ser registradas e com isso será possível fazer um quadro geral de seu negócio;
14. Manutenção:
a. A manutenção de software é o processo geral de modificação de um sistema depois ele foi colocado no ar;
b. As modificações podem ser:
i. Simples: destinadas a corrigir erros de código;
ii. Mais extensas: a fim de corrigir os erros de projeto;
iii. Significativas: com a finalidade de corrigir erros de especificação ou acomodando requisitos;
c. As mudanças são implementadas pela alteração dos componentes de sistema já existentes e, quando necessários, adicionando se novos componentes ao sistema.
15. Tipos de Manutenção:
a. Identificar e corrigir erros (Manutenção Corretiva);
b. Adaptar o software ao ambiente (Manutenção Adaptativa);
c. Atender pedidos dos usuários para modificar funções existentes, incluir novas funções e efetuar melhoramento gerais (Manutenção Perfectiva);
d. Melhorar a manutenibilidade ou confiabilidade futuras e fornece uma base melhor para os futuros melhoramentos (Manutenção Preventiva);
e. A partir desses números temos:
i. Reparar defeitos não é a atividade mais dispendiosa;
ii. A evolução do sistema para atender a novos ambientes e a requisitos novos ou modificados consome a maios parte do esforço;
f. A manutenção é uma continuação do processo de desenvolvimento de sistema, com atividades associadas de: Especificação, Projeto, **, Implementação e Testes.
16. Custos de Manutenção:
a. Representam uma grande proporção do orçamento da maioria das organizações que usam software;
b. Apesar do consumo de sistemas de prateleira ter aumentado nos últimos anos, as alterações em software continuam sendo um custo importante para todas as organizações;
c. Custos não monetários:
i. Adiamento de oportunidades de novos sistemas;
ii. Redução da qualidade global do software;
iii. Insatisfação do cliente;
iv. Insatisfação do pessoal de manutenção;
17. O Processo de Manutenção:
a. Os processos de manutenção variam dependendo do tipo de software que está em manutenção, dos processos de desenvolvimento utilizados e da organização do pessoal envolvido no processo.
18. Problemas da Manutenção:
a. A maioria dos problemas com a manutenção do software é causada por deficiências na maneira como o software foi planejado e desenvolvido;
b. Problemas Clássicos:
i. É difícil ou impossível traçar a evolução do software através das várias versões. As alterações não são adequadamente documentadas;
ii. Difícil ou impossível traçar o processo através do qual o software foi criado.


19. Manutenibilidade:
a. A Manutenibilidade pode ser definida quantitativamente como a facilidade com eu o software pode ser entendido, corrigido, adaptado e/ou melhorado;
b. A Manutenibilidade é afetada por muitos fatores:
i. Cuidado adequado com o projeto, codificação e teste;
ii. Configuração de software ruim;
iii. Disponibilidade de pessoal qualificado de software;
iv. Facilidade de manusear o sistema;
v. Uso de linguagens de programação padronizada;
vi. Uso de sistemas operacionais padronizados;
vii. Estruturas padronizadas de documentação;
viii. Disponibilidade de um computador próprio para a manutenção;
ix. Disponibilidade da pessoa ou grupo que desenvolveu o software;
x. O fator mais importante que afeta a manutenibilidade é o planejamento.
20. Manutenção de Código Alienígena:
a. Os programas “Alienígenas” são assim chamados porque:
i. Programas com fluxo de controle equivalente a uma tigela de espaguete;
ii. Módulos muitos grandes;
iii. Poucas linhas de comentários significativos;
iv. Nenhum outro elemento da configuração de software além do código;
v. Nenhum membro do pessoal atual da manutenção trabalhou no desenvolvimento do programa;
vi. Nenhuma metodologia de desenvolvimento aplicada;
vii. Projeto de dados e projeto arquitetural ruins;
viii. Documentação e registro histórico das alterações incompletos;
21. Engenharia Reversa e Reengenharia:
a. Engenharia Reversa: Processo de análise de um software, partindo-se inicialmente da implantação para um nível mais alto de abstração;
b. Reengenharia: Implica no exame e na alteração do software para reconstruí-lo em uma nova forma.
22. Verificação E Validação (V & V): Assegurar que um software atenda às necessidades do usuário.
23. Verificação versus Validação:
a. Verificação: Um software deve cumprir com suas especificações;
i. “Estamos construindo o certo produto?”
b. Validação: O software deve fazer aquilo que os usuários esperam que faça;
i. “Estamos construindo o produto certo?”

24. Verificação e Validação Objetivos:
a. Verificação e Validação devem estabelecer a confiança de que o software é adequado ao seu propósito;
b. Isso não significa que o software tenha de ser inteiramente livre de defeitos;
c. Em vez disso, ele deve ser suficientemente bom para o uso pretendido. O tipo de uso determinará o grau de confiança necessário.
25. Verificação e Validação Nível de Confiança:
a. Depende do proposito do sistema, das expectativas dos usuários e do ambiente de mercado, onde se analisa;
b. Função do software
i. O nível de confiança depende de quão critico o software é para uma organização
c. Expectativas do usuário
i. Usuários pode ter poucas expectativas para certos tipos de software;
d. Ambiente de mercado
i. Oferecer um produto para o mercado mais cedo pode ser mais importante que encontrar defeitos em um programa
e.
26. O Processo de Verificação e Validação:
a. No processo de V & V, podemos ter duas abordagens:
i. Inspeções de software ou revisão por pares: Verificam as representações do sistema, usadas em todos os estágios do processo, Utiliza a análise da representação estática para descobrir problemas (verificação estática);
b. Testes de Software: Executam uma implementação de testes com dados de teste checando as saídas do software, verificam se seu desempenho esta conforme o necessário (verificação dinâmica).

27. Tipos de Testes:
a. Testar envolve exercitar (executar) o programa com dados reais processados pelo programa;
b. Testes de Validação (Estático);
i. Sua finalidade é mostrar que o software é o que o cliente deseja;
ii. São testes projetados para refletir a frequência de entradas do usuário para a estimativa de confiabilidade;
c. Testes de Defeitos:
i. Testes projetados para descobrir defeitos no sistema;
ii. Um teste de defeito bem sucedido é aquele que revela a presença de defeitos em um sistema
28. Teste de Depuração:
a. Teste de defeitos e depuração são processos distintos;
b. Verificação e validação estabelece a existência de defeitos em um programa;
c. Depuração lida com a localização e correção desses erros;
d. Depuração envolve formular uma hipótese sobre o comportamento do programa e então testa essas hipóteses para encontrar os erros do sistema;

29. Planejamento de Verificação e Validação:
a. É um processo dispendioso (caro);
b. Planejamento cuidadoso é necessário para obter o melhor dos processos de testes e inspeções;
c. O plano deve identificar o equilíbrio entre a verificação estática e testes;
d. Plano de teste define padrões para o processo de testes em vez de descrever testes que serão realizados no produto.
30. Plano de Teste:
a. Não é um documento estático;
b. Mudam devido a atrasos em outros processos de desenvolvimento;
c. No modelo de processo XP o teste é inseparável do desenvolvimento;
d. Se uma parte do sistema está incompleta, o resto não pode ser testado.
31. Estrutura de um Plano de Teste de Software:
a. Processo de teste:
i. Descrição das principais fases do processo de teste;
b. Rastreabilidade dos Requisitos:
i. Os testes devem ser planejados para que todos os requisitos do sistema sejam testados individualmente;
c. Itens testados:
i. Todos os itens a serem testados devem ser especificados;
d. Cronograma de testes:
i. Um cronograma de testes e de alocação de recursos deve ser estabelecido;
e. Procedimento de registros de testes:
i. Todos os resultados dos testes devem ser registrados para uma posterior auditoria;
f. Requisitos de hardware w software:
i. Devem ser estabelecidas as ferramentas de hardware e de software necessárias;
g. Restrições:
i. Restrições
32. Inspeções de Software:
a. É um processo de V&V estático;
b. Envolve pessoas examinando a representação original de um sistema (modelo de sistema) com o objetivo de descobrir erros, anomalias e defeitos;
c. Não requer a execução de um sistema de forma que pode ser utilizado antes da implementação;
d. Pode ser aplicados a qualquer representação do sistema requisitos, projetos, dados de testes;
e. Técnica bastante eficaz para descobrir erros;
f. Inspeções e testes são técnicas complementares e não concorrentes;
g. Ambas devem ser utilizadas durante o processo de V&V;
h. Inspeções podem checar a conformidade com uma especificação mas não, a conformidade com os requisitos reais dos usuários;
i. Inspeções não podem verificar características não funcionais como desempenho, usabilidade.
33. Inspeções de Programa:
a. Processos formais cuja função explicita é a DETECÇÃO de defeitos no programa (não a correção);
b. Defeitos podem ser erros lógicos, anomalias no código que podem indicar uma condição errônea (ex. uma variável não inicializada) ou não conformidade com padrões;
34. Uso da Análise Estática:
a. Particularmente valiosa quando uma linguagem como C é utilizada. C é fracamente tipada e, portanto muitos erros podem não ser detectados pelo compilador;
b. Pode ter uma baixa relação custo-beneficio para linguagens com Java que tem uma checagem forte de tipos e pode detectar muitos erros durante a compilação;
35. Desenvolvimento de Software CleanRoom;
a. O nome é derivado do processo “Cleanroom” na fabricação de semicondutores. A filosofia é evitar defeitos em vez de removê-lo;
b. Processo de desenvolvimento de software baseia-se em:
i. Especificação formal;
ii. Desenvolvimento incremental;
iii. Verificação estática;
iv. Teste estático do sistema para determinar a confiabilidade;
36. Características do Processo Cleanroom:
a. Especificação formal utilizando um modelo de transição de estados;
b. Desenvolvimento incremental;
c. Programação estruturada – é utilizado um número limitado de construções abstratas de controle de dados;
d. Verificação estática utilizando rigorosas inspeções de software;
e. Teste estático do sistema;

37. Testes de Software Conceitos Básicos:
a. Falha:
i. Incapacidade do software de realizar a função requisitada (aspectos externo);
b. Falta:
i. Causa de uma falha;
c. Erro:
i. Estado intermediário (instabilidade);
ii. Provém de uma falha;
iii. Pode resultar em falha, se propagando até a saída;
38. Confiabilidade:
a. Algumas faltas escaparão inevitavelmente:
i. Tanto dos testes;
ii. Quanto da depuração;
b. Falta pode ser mais ou menos perturbadora:
i. Dependendo do que se trate e em qual frequência irá surgir para o usuário final;
c. Assim, precisamos de uma referência para decidir:
i. Quando liberar ou não sistemas para uso;
d. Confiabilidade de Software:
i. É uma estimativa probabilística;
ii. Mede a frequência com que um software irá executar sem falha num dado ambiente e por determinado período de tempo;
e. Assim, entradas para testes devem se aproximar do ambiente dos usuários final;
39. Finalidade dos Testes:
a. Averiguar se todos os requisitos do sistema foram corretamente implementados;
b. Assegurar, na medida do possível, a qualidade e a corretude do software produzido;
c. Reduzir custos de manutenção corretiva e retrabalho;
d. Assegurar a satisfação do cliente com o produto desenvolvido;
e. Identificar casos de teste de elevada probabilidade para revelar erros ainda não descobertos (com quantidade mínima de tempo e esforço);
f. Verificar a correta integração entre todos os componentes de software
40. Eficácia de Testes:
a. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro;
b. Um bom caso de teste é aquele que apresenta uma elevada probabilidade de revelar um erro ainda não descoberto;
c. Um teste bem sucedido é aquele que revela um erro ainda não descoberto;

41. Padronização de testes:
a. Testes aleatórios não são suficientes;
b. Testes devem cobrir todos os fluxos possíveis do software;
c. Testes devem representar situações de uso reais;
42. Documentado:
a. Que testes foram feitos, resultados, etc.
43. Repetitivel:
a. Se encontrou ou não erro em determinada situação, deve-se poder repeti-lo;
44. Abordagem Funcional (Caixa Preta):
a. Os testes são gerados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários;
b. Geralmente é aplicado durante as últimas etapas do processo de teste;
45. Abordagem de Caixa Branca:
a. Tem por Objetivo:
i. Garantir que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez;
ii. Realiza todas as decisões lógicas para valores falsos e verdadeiros;
iii. Executa laços dentro dos valores limites;
iv. Avaliar as estruturas de dados internos;
46. Estágios de Teste:
a. Testes de Unidade;
b. Teste de Aspectos OO;
c. Teste de Integração;
d. Teste de Sistema;
e. Teste de Aceitação;
47. Tipos de Teste
a. Teste funcional;
b. Teste de recuperação de falhas;
c. Teste de Segurança;
d. Teste de performance;
e. Teste de carga;
f. Teste de Estresse;
g. Teste de configuração ou portabilidade;
h. Teste de instalação e desinstalação;
i. Teste da GUI (usuário);
j. Teste de documentação;
k. Teste de ciclo de negócios;
l. Teste de regressão;


48. Teste funcional (regras de negócio)
a. A funcionalidade geral do sistema em termos de regras de negócio (fluxo de trabalho) é testada;
b. Condições válidas e inválidas
49. Teste de recuperação de falhas
a. O software é forçado a falhas de diversas maneiras para que seja verificado o seu comportamento;
50. Usando Ferramentas – CASE
a. Proporciona apoio ao processo de software pela automação de algumas atividades de processo e pelo fornecimento de informações sobre o software que está sendo desenvolvido.
51. Como projetar um software?
a. Analise Orientada a Objetos:
i. Diagrama de Casos de Uso;
ii. Diagrama de Atividades;
iii. Diagrama de Classes;
iv. Diagrama de Sequência;
v. Diagrama de Estado;
vi. Outros;
b. Analise de dados:
i. Modelo de Entidades e Relacionamento;
ii. Projeto de Banco de Dados;
52. Protótipos:
a. Exploratória;
b. Evolucionaria;
53. Cronograma:
a. Atividade;
b. Datas;
c. Responsáveis;
d. Resultados;
e. Dependências;
54. Escopo:
a. Sistemas;
b. Módulos;
c. Funcionalidades;
d. Departamentos;
e. Região;
f. Prioridades;
g. Importância;

55. Kanban
a. Cartão;
b. Status;
c. Agilidade;
d. Sinalização;
e. Visual;
f. Linguagem;
56. Gerenciamento de Projetos
a. Empreendedorismo que produzirá um software, no prazo estimado e com as funcionalidades desejadas;
b. Seguir um padrão de qualidade requer Gerenciamento constante;
c. O papel do Gerente de Projetos, importância da experiência;
57. Definindo o Escopo:
a. Objetivo geral do projeto
i. Solução de um problema;
ii. Oportunidade de negócio;
b. Objetivos específicos do projeto
i. Processos de entrada e de saída;
ii. Controles fundamentais;
c. Critérios de sucesso
i. Prazos, Custos, e Qualidade;
58. Criando uma WBS
a. Diagrama específicos para o escopo do projeto;
b. Visualizar fases atividades, responsáveis e entregas;
c. Orientar na Estimativa de Esforço, Duração e Custo;
d. Facilitar a Identificação de Riscos;
e. Tipos:
i. Fases;
ii. Entregas;
iii. Equipes;
59. Definindo Requisitos
a. Uma condição ou capacidade que deve ser atendida ou possuída por um sistema;
b. Para satisfazer um contrato, uma norma, uma especificação ou outros documentos impostos formalmente;
c. Incluem necessidades, desejos e expectativas quantificados e documentados do patrocinador, do cliente e de outras partes interessadas;


60. A Atividade é composta por:
a. Projeto  Atividade  Tarefa  Operação
i. A partir da WBS, refina-se para cada “Entrega”;
b. Encontrar o “produto da atividade”;
i. Definir a atividade;
c. Escolher o papel (responsável);
i. Determinar as instruções (premissas, limitações, padrões, ente outros);
d. Estabelecer datas de início e término;
61. Cronograma Dependências
a. Programar atividades em paralelo reduz o prazo total;
b. Atividades dependentes é que determinam o prazo máximo do projeto (caminho crítico);
c. Atividades podem ser executadas em paralelo desde que tenham responsáveis diferentes e a execução de uma não dependa do resultado (subproduto) da outra;
d. Outros recursos que podem determinar a dependências: espaço físico, viagens, reuniões com representantes, uso de máquinas / equipamentos / licenças, entre outros;
62. Cronograma Estimativa:
a. O prazo para executar uma atividade depende de:
i. Tamanho do resultado esperado;
ii. Restrições e critérios de qualidade;
iii. Proficiência dos responsáveis e envolvidos;
iv. Troca de pessoas envolvidas;
v. Máquinas e equipamentos;
vi. Disponibilidade dos recursos;
b. Possibilidade de atrasos;
c. Fatos determinante é a experiências da equipe de projetos anteriores;
d. O tamanho preciso após a conclusão:
i. O uso de COTS e componentes;
ii. A linguagem de programação;
iii. Distribuição do sistema;
e. Estimativa mais exata, à medida em que o desenvolvimento progride;
63. Cronograma Estimativa Top-Down:
a. Pode ser usado sem o conhecimento da arquitetura do sistema e os componentes que podem ser parte do sistema;
b. Leva em conta os custos, tais como integração, gestão de configuração e documentação;
c. Pode subestimar o custo de resolver difíceis problemas técnicos de baixo nível;

64. Bottom-Up:

a. Utilizável quando a arquitetura do sistema é conhecida e os componentes identificados;
b. Método preciso, se o sistema foi concebido em detalhes;
c. Podem subestimar os custos de atividades a nível do sistema, tais como a integração e documentação;
65. Qualidade baseada em modelos:
a. ISSO 15540 – (spice) aplicado à avaliação do processo;
b. ISSO 9126 – medição da qualidade do software (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade);
c. CMMI – modelo de maturidade;
d. PMBOK – Project Management Body of Knowledge;
e. SWEBOK – Software Engineering Body of Knowledge;
f. MPS-Br Melhoria do Processo do Software Brasileiro;