Resumo das Disciplina de Engenharia e Projeto de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Resumo das aulas de 
Engenharia e Projeto de Software – UNOPAR – ADS 2018
*Coloquei aqui o que achei mais importante nas aulas*
Aula 1
Leis de Lehman – Evolução: Um software deve: 
 Mudança Contínua: Um software deve ser continuamente adaptado, senão torna-se aos poucos, cada vez menos satisfatório.
Complexidade Crescente: Se não forem tomadas medidas para reduzir ou manter a complexidade de um software, conforme ele é alterado sua complexidade irá aumentar progressivamente. 
Conservação da estabilidade organizacional: A empresa que utiliza um software espera que consiga trabalhar de acordo com a necessidade do mercado.
Conservação de familiaridade: Ao evoluir um software manter funções que já são mais conhecidas.
*https://www.baguete.com.br/colunas/jorge-horacio-audy/17/04/2014/as-8-leis-de-lehman-foram-o-manifesto-do-seculo-xx* mais sobre as leis de Lehman nesse site.
Sistemas Legados: Softwares mais velhos, mas que são vitais para uma organização. Passam por varias mudanças externas e internas gerando novos requisitos, isso quando existir um inicial.
Características Principais: 
		Alto Custo de OPEX (operação e manutenção);
		Obsolescência (ultrapassado);
		Não Integra (com o sistema de automação);
Principais Problemas dos Sistemas legados:
		Sem Suporte ou peças de reposição;
Na empresa pode não haver entendimento completo a respeito do funcionamento;
Difícil encontrar pessoal especializado, aumentando o custo de manutenção;
Difícil integração com sistemas novos, barreiras tecnológicas, protocolos diferentes e etc.
Programação com linguagem e estruturação obsoleta;
Migração: Muda-se a tecnologia mantendo a mesma função; 
Vantagens:
-Ganho de Performance;
-Novas Ferramentas;
-Facilidade de Operação e Manutenção;
-Menos paradas no processo;
-Mais segurança e consistência nas informações;
Também ocorrem erros na hora de migrar, por exemplo:
-A empresa que quer migrar toma ação de curto prazo, querendo resolver tudo rapidamente e não presta atenção em todo o software, assim acaba tendo resultado negativos e tendo mais problemas. 
	
Tipos de Migração: Podem ser feitos todos, isolados ou em conjuntos;
-De Hardware;
-De Software;
-De Infraestrutura;
-De dados;
*https://pt.slideshare.net/MHVenturelli/migrao-de-sistemas-legados* mais sobre migração nesse site.
	Riscos em mudar o sistema legado para um novo:
	-Documentação incompleta ou desatualizada;
-Complexidade nas regras de negócio (deve entender as necessidades da empresa antes de substituir).
	Cuidados que demos tomar antes de migrar:
	-Analisar os riscos da substituição;
-Analisar o custo da manutenção;
-Aplicar a Reengenharia;
-Prolongar a vida do Sistema (pensar em como essa mudança ajuda na vida do sistema);
	Estruturas Envolvidas:
Engenharia de Sistema: Se preocupa tanto com o sistema como o hardware; e
Engenharia de Software: Preocupa-se com apenas o software (códigos/interface etc).
Manutenção: Processo geral de modificação de um sistema depois que ele foi colocado em uso.
Abrangências: Tem a mais simples, destinadas a corrigir erros de códigos, as mais extensas, a fim de corrigir erros de projetos (reengenharia) e tem as significativas, com a finalidade de corrigir erros específicos ou analisar novos requisitos (envolve o usuário).
Tipos de Manutenção:
Corretiva: identifica e corrige erros \_(‘- ‘)_/
Adaptativa: adapta o software ao ambiente (se a empresa comprou uma nova impressora, por exemplo, precisa adaptar o software a ela).
Perfectiva/ Evolutiva: Atender pedidos do usuários para modificar funções existentes, incluir novas funções e efetuar melhoramentos gerais.
Preventiva/Reengenharia: Melhorar a manutebilidade ou confiabilidade FUTURAS e fornecer uma base melhor para futuros melhoramentos (vida longa);
Problemas na Manutenção:
Falha na documentação da manutenção;
Equipe de desenvolvimento diferente da equipe de manutenção;
A Documentação inicial fica desatualizada;
Falta de plano de evolução;
Disponibilização do pessoal para manutenção;
Engenharia Progressiva/ Engenharia Reversa/ Reengenharia :
Num primeiro momento (quando o software não existe) iniciamos pela engenharia progressiva, ou seja estamos construindo (do zero). Depois, poderá optar pela engenharia reversa se decidir reconstruir o software a partir da revisão de requisitos. Ou, optar pela reengenharia caso faça a reconstrução do sistema apenas utilizando técnicas de análise do projeto e de codificação.
Aula 2
Verificação e Validação: 
	Um software deve cumprir com suas especificações (sem executar o sistema). “Estamos construindo certo o produto?”. Seria a parte do código, banco de dados, operações internas.
	O software deve fazer aquilo que os usuários esperam que ele faça. “Estamos construindo o produto certo?”. Seria a parte da interface, o projeto já pronto. 
Objetivos: V e V devem estabelecer a confiança de que o produto é aquilo que o usuário requisitou, não significa que o software tenha de ser livre de erros, ele deve ser suficiente bom para o uso desejado.
 Processo de V e V: Precisa ser aplicados em cada estágio do ciclo de vida do projeto. Existem dois objetivos principais:
Descoberta de defeitos no sistema;
A Avaliação se um sistema é ou não utilizável em condições operacionais;
NO PROCESSO DE V e V PODEMOS TER DUAS ABORDAGENS:
Inspeção de software ou revisão por pares: Verifica o sistema por pares, códigos do banco, da interface etc, pra ver se tá tudo certo antes de testar por completo. Identifica erros antes de testar por completo. Teste estático
Testes de Software: Executa o projeto por completo. Teste Dinâmico.
Testes: Executar o programa com dados reais processados pelo sistema. 
Tipos de Testes:
Validação: como o próprio nome diz, valida o que criamos, testa entradas de códigos, links, cliques em abas navegáveis etc.
Defeitos: o foco é causar defeito propositalmente, para diminuir os riscos de erros futuros.
Depuração: Testes de defeitos e depuração são processos diferentes; Depuração seriam a localização e correção dos erros depois de realizados os testes (acredito que façam na manutenção).
Planejamento de Testes: 
Envolve altos custos; 
Se alguma parte do sistema está incompleta, o resto não pode ser testado;
 Devemos ter um plano de ação para correção.
Desenvolvimento de Software CLEANROOM: Evita os defeitos ao invés de removê-los;
Ao fazer uma codificação é importante seguir padrões, mas também é importante codificar corretamente assim evita esforços desnecessários na hora da correção;
Especificação Formal;
Desenvolvimento por partes;
Verificação Estática;
Teste estático para determinar confiabilidade;
 FALHA/ FALTA e ERRO:
Uma falha é quando um software apresenta mal funcionamento devido a uma circunstancia externa não prevista como por exemplo, volume muito grande de dados ou um conteúdo não previsto num pacote de dados. Exemplo: um sistema de venda de ingressos online entra em colapso quando muita gente tenta comprar ingressos ao mesmo tempo, o sistema não aguenta a quantidade de acessos concorrentes e trava.
Uma falta é quando se esperava que o software fizesse alguma coisa e ele simplesmente não faz porque não ficou claro que ele deveria fazer tal coisa ou simplesmente não foi dito.
Exemplo: no sistema de venda de ingressos online não tem a possibilidade de se pagar o ingresso usando boleto, por exemplo.
Um erro é quando o software se propõe a fazer alguma coisa e a faz erradamente.
Exemplo: no sistema de venda de ingressos, quando o cliente pede para ser entregue em casa o sistema cobra errado o valor do delivery.
Em relação a CONFIABILIDADE: seria para garantir que o software está liberado para uso; Quanto menos erros tiver, melhor.
Em relação a FINALIDADE: verificar a integração entre todos os componentes do software; 
Abordagem Funcional (Caixa Preta): Se preocupa com a visão do usuário, voltado para a interface, testando-a apenas a interface para detectar erros de funcionalidades. 
Abordagem Estrutural (caixa branca):
Se preocupa com o código fonte e verifica comando a comando para detectar comandos incorretos e arruma-los;
Estágios de testes:
Testes de Unidade: Efetuado por componente a componente;
Testes de Aspectos Orientados a Objetos: Verifica como fiz o projeto, como modelei a ideia.
Testes de Integração: Quando estamos colocando todas as unidades em conjunto.
Testes de Sistemas: Visualiza os testes de execução, colocando os dados reais.
Testes de Aceitação: De acordo com o que especifiquei, com os requisitos funcionais.
Mais alguns tipos de testes:
Aula 3
Gerenciamento da qualidade: Um produto deve atender as especificações; É importante que todos os envolvidos no projeto se interessem a buscar uma boa qualidade. 
Processo e Atividades:
Garantia da Qualidade: Pensa-se em todas as atividades envolvidas para que, tanto o processo como produto, consigam atender um nível de qualidade satisfatória. Envolve tanto o planejamento como o controle.
Planejamento da Qualidade: Seleciona os procedimentos e padrões aplicáveis para um projeto específico. Quem vai fazer o que e quais as ferramentas utilizadas.
Controle da Qualidade: Assegurar que os procedimentos e os padrões sejam seguidos.
Revisões de Qualidade: Processo de curta duração, todos os documentos revisados inclusive códigos. Tipos de Revisão:
Técnica Formal de Revisão (Formal Technical Review);
Inspeções para detectar os defeitos (no produto);
Revisões para avaliação de progresso (produto e processo);
Revisões de qualidade (produto e padrões);
Prática de Processo:
Definir padrões de processo.
Monitorar o processo de desenvolvimento
Estabelecer processo de revisão.
Envolve o usuário e cliente.
Modelos de Qualidade de Software
CMMI: Modelo internacional, possui representação por estágios (5 níveis) e contínua (6 níveis), tem um custo maior.
MPS.br: Modelo Brasileiro, possui representação em 7 níveis, custo mais acessível. Ele é baseado no modelo CMMI quanto na ISO-12207/15504. A primeira ISO trata-se do ciclo de vida do produto, pode ser mostrado tanto para a equipe tanto para o cliente de como esta o produto. Já a segunda ISO, tem foco em avaliação, tanto para o processo (como estou desenvolvendo?) quanto do produto (o que estou desenvolvendo?).
A DIFERENÇA de cada um é que no MPS existe uma “Granularidade” maior, ou seja, os níveis são menores de um para o outro. 
Gerenciamento de Configuração: Define procedimentos e padrões para garantir um produto de software, envolve o gerenciamento de qualidade, uma equipe, controla os esforços dessa equipe, controla os custos, controla o histórico de versões (pois a cada funcionalidade nova é uma versão nova, se necessário). 
Versão, Variante e Release (Corrijam-me se eu estiver errada, pois fiquei em duvida nessa parte e os tutores/professor n me responderam):
Seria a versão de partida, com poucas funcionalidades, por exemplo: versão 1 tem quatro funcionalidades.
Seria a versão 1 com mais funcionalidades então, ficaria versão 1.1, com as funcionalidades anteriores mais outras novas ou se o cliente desejar com algumas funcionalidades antigas deletadas.
Aqui seria o programa pronto, a principio.
Existem duas técnicas dentro da gestão de configuração:
Branching: Quando precisamos explicar o núcleo de um sistema e a partir dele precisa-se dividi-lo.
Merging: Junta todos os componentes separados para ter uma versão.
Planejamento de Gerência de Configuração: Devemos definir os documentos ou classes de documentos que serão gerenciados vai desde as especificações dos documentos até manuais dos usuários, ou seja, projetos, programas e dados de testes entram no planejamento.
Plano: Define os tipos de documentos os quais serão gerenciados, utiliza ferramentas, define politicas de controle de mudança e gerencia de versão e define registros de gerencias de configuração que devem ser mantidos. 
Gerência de mudanças:
Evolução da TI e comunicação;
Requisitos de usuários específicos;
Demandas físicas e legais;
Demandas técnicas dos desenvolvedores;
Por seguranças da informação;
Demandas de mercado;
Concorrência no setor de negócios;
Aula 4
Projeto de Software: As ações a serem realizadas para atingir os objetivos levantados na analise.
Gerenciamento: Na aplicação de conhecimentos, habilidades, ferramentas e técnicas em projetos com objetivos de atingir ou até mesmo exceder as necessidades e expectativas dos clientes e demais partes interessadas.
Gerenciamento do Caminho Crítico (CPM): Garante que tudo que está sendo desenvolvido seja concluído com sucesso.
Restrições de um Projeto: *Os itens em negrito são os mais importantes*.
Escopo: Objetivos, funcionalidades, ambiente de desenvolvimento;
Recursos: Documentação, dinheiro gasto;
Tempo: Prazo;
Documentar: validar o que o cliente esta pedindo;
Comunicar: sempre deve ter entre o cliente e a empresa;
Liderar: quem vai liderar o que.
Negociar: se precisar renegociar orçamentos, prazos;
No ciclo de vida do Projeto: Definir padrão de qualidade -> planejar -> garantir que tudo vai ser executado certo senão planeja de novo -> Realizar monitoramento e controle -> Encerramento.
1-PLAN(planejar), 2-DO(fazer), 3-CHECK(avaliar) e 4-ACTION(ação): 
Estabelece os objetivos e define o caminho para chegar neles, sempre obedecendo as diretrizes da organização;
Executa atividades de acordo com o plano estabelecido na etapa anterior. Caso tenham falhas nos resultados esperados, os dados devem ser catalogados para serem analisados pela etapa seguinte:
Comparar o resultado obtido na etapa de execução com objetivos estabelecidos na etapa de planejamento(1). Aqui também são comparados os resultados com o padrão de qualidade;
Todas as falhas encontradas, principalmente da fase de planejamento e de execução devem ser separados para o novo ciclo ou projeto;