ESAB – Pós-graduação em Engenharia de Sistemas Módulo: Engenharia de Software
RESUMO
UNIDADE 1: Conceitos:
• Engenharia de Software: se ocupa dos aspectos de produção de software;
• Engenharia de Sistemas: contém a Eng. De SW e contempla a definição e criação de um sistema em todos os detalhes.
Basicamente 2 metodologias em Eng SW: Estruturada e Orientada a Objetos (maior nível de reutilização de componentes).
UNIDADE 2: Apresenta a descrição padrão de um Sistema, com realimentação, explicando os conceitos básicos (entradas, saídas, feedback, comparação com setpoint, etc).
UNIDADE 3: Atributos de software
• Facilidade de Manutenção: deve atender as mudanças solicitadas pelos clientes; • Nível de confiança: robustez a falhas e defeitos;
• Eficiência: rapidez de resposta, tempo de processamento, etc;
• Facilidade de uso: basicamente deve ser user-friendly para o usuário ao qual foi destinado. Apresenta um breve histórico da Crise do Software e do início da Eng. De SW.
Desafios da Eng. De SW:
• Legado: manutenção e atualização de legado;
• Heterogeneidade: construir softwares flexíveis para lidar com isso;
• Fornecimento: fornecer sistemas cada vez maiores, no menor tempo possível e com facilidade de manutenção (mantendo a qualidade);
UNIDADE 4: Conceitos de Engenharia de Software
Eng. De SW: apresenta processos, ferramentas e métodos para desenvolver de forma racional e controlável um Sistema Computacional com foco na qualidade.
SWEBOK – Software Engineering Body of Knowledge, documento técnico desenvolvido com apoio do IEEE que classifica os tópicos tratados pela Eng. De SW (áreas de conhecimento):
• Requisitos de Software; • Projeto de Software; • Construção de Software • Teste de Software;
• Manutenção de Software;
• Gerência de Configuração de Software; • Gerência de Engenharia de Software; • Processo de Engenharia de Software;
• Ferramentas e métodos de Engenharia de Software; • Qualidade de Software.
UNIDADE 5: Modelos do Processo de Software e paradigmas de desenvolvimento Modelos de Processo de Software, seguem basicamente três etapas:
• Requisitos;
• Projeto/Desenvolvimento; • Implantação/Manutenção.
Outros nomes: Modelos de Ciclo de Vida de Software, Modelos Prescritivos de Processo,
Paradigmas do Ciclo de Vida, Paradigmas do Desenvolvimento de Software, Modelagem do Ciclo de Vida.
• Modelo Balbúrdia: inicial, vida no caos;
• Modelo Cascata: pressupõe o término de uma etapa antes do início da próxima (Ciclo de Vida Clássico). Etapas: Requisitos, Análise, Projeto, Codificação, Testes, Operação e Manutenção.
UNIDADE 6: Modelos do Processo de Software e paradigmas de desenvolvimento (continuação) • Modelo Incremental: ou interativo, utiliza conceito de versões, a partir de ciclos ou
iterações, definem-se requisitos, limita-se o escopo das versões e as funcionalidades são adicionadas a cada versão;
• Prototipação: mesmo objetivo da maquete para o arquiteto, desenvolve-se rapidamente um esboço do sistema para facilitar o entendimento e as discussões de análise crítica (ajuda muito na reavaliação e validação dos requisitos). As etapas são:
• conjunto simples de requisitos;
• em função do protótipo, clientes e usuários fazem testes e experiências, permitindo a revisão dos requisitos e documentação do projeto;
• codificação do sistema;
• apresentam-se novas opções e alternativas repetindo os passos anteriores até o sistema estar completo.
UNIDADE 7: Modelos do Processo de Software e paradigmas de desenvolvimento (continuação) • Modelo Espiral: cada ciclo da espiral representa uma fase do processo de software:
• Ativação: definição de objetivos, restrições, plano de gerenciamento detalhado. Identificação dos riscos (sem detalhamento);
• Análise de Riscos: detalhamento da análise dos riscos identificados na etapa anterior, tomando-se decisões para minimizá-los (podendo usar protótipos);
• Desenvolvimento: implementação do código;
• Planejamento: revisão do projeto e decisão de realizar novo ciclo na espiral (traçando plano para a próxima fase do projeto e reiniciando o ciclo).
• Modelos Mistos: podem misturar 2 ou mais modelos. RAD (Rapid Application Development), focando no “tempo”, com desenvolvimento incremental e ciclo de desenvolvimento curto (uso de componentes). Outro modelo é o RUP, foco no UML. UNIDADE 8: Paradigmas da Engenharia de Software: Processo, Métodos e Ferramentas Eng. De SW: tecnologia em camadas:
• Métodos: ensinam como fazer para construir software. Metodologias usadas:
• Estrutura: clássica, usa Dicionário de Dados, Diagrama de Fluxo de Dados, Modelo Entidade Relacionamento;
• Orientada a Objetos: destaque para o RUP (mais abaixo);
• Desenvolvimento Ágil: XP, ASD, DSDM, Scrum, Crystal, etc (mais abaixo). • Processos: conjunto de atividades e práticas ordenadas para transformar requisitos de
usuário em um produto específico com qualidade. • Qualidade.
UNIDADE 9: Características de um processo e ambiente de desenvolvimento Detalhamento dos Processos de Software: suas características são:
• Configurável para diferentes organizações;
• Adaptável para projetos de tamanhos e tipos diferentes; • Bem definido, gerenciável e repetível;
• Nomenclatura universal e métricas para planejamento e gerenciamento; • Integrado com ferramentas.
Características de um bom ambiente de desenvolvimento: • Processo de desenvolvimento definido;
• Integração entre processo e ferramentas; • Integração entre ferramentas;
• Gerenciamento de configuração; • Gerenciamento de mudanças; • Gerenciamento de projetos;
• Automação de testes funcionais e desempenho; • Documentação consistente;
UNIDADE 10 – Introdução ao RUP
Rational Unified Process (RUP): abordagem orientada a objetos, com foco no UML. Características:
• Desenvolvimento interativo; • Gerência de Requisitos;
• Uso de arquitetura baseada em componentes; • Modelagem visual;
• Controle contínuo da qualidade; • Gerência de mudanças.
O desenvolvimento é iterativo e incremental (ciclos). A modelagem possui as seguintes fases: • Inception: visão, escopo e plano inicial;
• Elaboration: projeta, implementa e testa a arquitetura e completa o plano do projeto; • Construction: desenvolve a primeira versão do sistema;
• Transition: implantação do produto em ambiente de produção. Processo:
• Modelagem do negócio: casos de uso de negócio;
• Requisitos: narrativa da visão do sistema. Descrição de funções do sistema;
• Análise e Projeto: descreve como o sistema será realizado na etapa de implementação; • Implementação: produção do código que resultará em um sistema executável;
• Testes: verificação da integração entre os componentes de software, identificação e correção de erros da implementação;
• Distribuição: gerar um release do produto, entregar o produto e treinar os usuários. Suporte:
• Gestão de Projetos: princípios a aplicar na gestão de projetos (alocação de recursos, planejamento, identificação e gestão de riscos, etc);
• Gestão de Configuração e Mudança: controla mudanças e mantém integridade dos artefatos do projeto;
• Definição de ambiente: infraestrutura necessária para desenvolver um sistema (ferramentas, regras de negócio, interface, testes, etc).
UNIDADE 11: Modelos de Maturidade - CMM
Capability Maturity Model: metamodelo de processo, criado pelo SEI (Software Engineering Institute), definido como a habilitação que a organização deve ter para sistematicamente produzir software com qualidade esperada, dentro dos prazos acordados e com os recursos alocados. Níveis do CMM:
• Nível 1 – Inicial: caótico (maioria das empresas atuais);
• Nível 2 – Repetitivo: capacidade de repetir sucessos anteriores, com acompanhamento de custos, cronogramas e funcionalidades;
• Nível 3 – Definido: processo de software bem definido, documentado e padronizado; • Nível 4 – Gerenciado: realiza gerência quantitativa e qualitativa do processo de software e
de produto;
• Nível 5 – Em otimização: Usa a informação quantitativa para melhorar continuamente e gerenciar o processo de software.
UNIDADE 12: Requisitos de Software, Funcionais e Não funcionais, de usuário e de Sistema As atividades da Análise de Requisitos: identificação, especificação e descrição dos requisitos do sistema. Os requisitos podem ser classificados em:
• Requisitos de Usuário: declarações em linguagem natural e também diagramas, sobre funções que o sistema deve fornecer e restrições sob as quais deve operar;
• Requisitos de Sistema: funções e restrições de sistema. O documento de especificação deve ser preciso (pode servir como contrato entre o cliente e o desenvolvedor);
• Requisitos Funcionais: declarações de funções que o sistema deve fornecer, como reagir a entradas específicas e comportamento em dados cenários;
• Requisitos não funcionais: restrições sobre os serviços ou funções oferecidos pelo sistema (restrições sobre o processo de desenvolvimento, padrões, etc).
UNIDADE 13: Técnicas de Análise de Requisitos – Documento de Requisitos de Software • Escutar, para entender;
• Prepare-se antes de se comunicar (perguntas para a resolução e visão do negócio do cliente); • Facilitador na reunião: não é bom o desenvolvedor ser o moderador;
• Foco na discussão, desenho ou documento, não nas pessoas; • Fazer anotações e documentar decisões;
• Buscar a colaboração de todos; • Mantenha o foco;
• Se precisar, desenhe;
• Prossiga (se não concordar, se concordar, se não estiver claro ou não puder esclarecer naquele momento... prossiga);
• Negociação ganha ganha; Documento de Requisitos de Software:
• Definição de contexto; • Definição de requisitos: • Funcionais; • Interface; • Não funcionais; • Análise de Risco; • Anexos.
UNIDADE 14: Processos de Engenharia de Requisitos – Estudos de Viabilidade
Engenharia de Requisitos: envolve as atividades para criar e manter o documento de requisitos do sistema. Possui 4 atividades de alto nível:
• Estudo de Viabilidade;
• Obtenção e análise de requisitos; • Especificação de Requisitos; • Validação de Requisitos.
O estudo de viabilidade é o primeiro processo a ser realizado. Seu resultado é um relatório com as recomendações de viabilidade técnica ou não do projeto.
• O sistema proposto contribui para os objetivos da organização?
• Poderá ser implementado pela equipe? Possui domínio técnico? Dá pra fazer no prazo? • Precisa de treinamentos adicionais?
• Pode ser integrado e é compatível com outros sistemas em operação? UNIDADE 15: UML – Unified Modeling Language
UML: padrão para modelagem orientada a objetos. É uma linguagem de diagramação (especificar, visualizar e documentar). É controlado pelo OMG (Object Management Group).
Principais diagramas:
• Diagrama de Caso de uso: atores (pessoas ou usuários), cenários de uso e relacionamentos; • Diagrama de Classe: define as classes e relacionamentos entre elas;
• Diagrama de Sequência: mostra objetos e sequência de chamados de métodos feitas para outros objetos;
• Diagrama de Colaboração: objetos e seus relacionamentos com ênfase na troca de mensagens;
• Diagrama de Estado: exibe estados, mudanças de estado e eventos em objetos ou partes do sistema;
• Diagrama de Atividade: atividades e mudanças de uma atividade para outra com eventos ocorridos;
• Diagrama de Componente: mostra os componentes de programação de alto nível; • Diagrama de Distribuição: destaca instâncias dos componentes e seus relacionamentos.
UNIDADE 16: Metodologias Ágeis – XP – FDD - DSDM Manifesto for Agile Software Development. Princípios básicos:
• Simplicidade acima de tudo; • Rápida adaptação às mudanças;
• Desenvolvimento preza pela excelência técnica; • Indivíduos motivados, confiança mútua;
• Cooperação entre desenvolvedores, que trabalham junto com usuários/clientes; • Entregar rapidamente e continuamente produtos funcionais em prazos curtos; • Software funcionando é a principal medida do progresso;
• Mudanças no escopo (ou requisitos), não são um problema;
• Equipe se auto organiza fazendo ajustes e melhorias constantemente. Contraponto à metodologias Prescritivas:
• RUP (Controle/Equipes Grandes); • FDD (Acompanhamento/Equipe Média);
• XP (Liberdade/Equipes Pequenas – 10 ou menos). XP: Extreme Programming, possui 4 atividades:
• Planejamento; • Projeto; • Codificação; • Teste.
FDD (Feature Driven Development): função pequena acertada com o cliente, implementada em menos de 2 semanas. Nesta visão:
• Features são pequenos blocos de funcionalidade (melhora o entendimento);
• Organizam-se as features em agrupamento hierárquico (melhora a visão para o usuário); • Metas de desenvolvimento das features a cada 2 semanas.
Marcos do FDD: • Travessia do projeto; • Projeto; • Inspeção do Projeto; • Código; • Inspeção do Código;
• Promoção para a construção.
UNIDADE 17: Metodologias Ágeis – SCRUM – CRYSTAL – ASD e AM Scrum: similar a atividade de rugby, seus princípios seguem o Manifesto Ágil. Reuniões Scrum: 15 minutos,com 3 questões básicas:
• o que você fez desde a última reunião Scrum?
• Que obstáculos está encontrando que podemos ajudar? • O que você planeja realizar até a próxima reunião Scrum?
Crystal: analogia com cristais geológicos (cada um com sua cor, forma e dureza). Manobrabilidade para entregar softwares úteis funcionando, preparando-se para a próxima fase. É um conjunto de metodologias ágeis que funcionam em casos específicos.
ASD (Adaptative Software Development): Foco na colaboração e auto-organização da equipe, tem três fases:
• Especulação: planejamento e definição do conjunto de ciclos de versão necessários ao projeto;
• Colaboração: baseada na confiança (criticar sem animosidade), ajudar sem ressentimentos ou constrangimentos, trabalhar mais e comunicar problemas de modo a conduzir a ações; • Aprendizado: ao longo do desenvolvimento do componente é dada ênfase ao aprendizado. AM (Agile Modeling): Coleção de valores, princípios e práticas de modelagem, aplicados a um projeto de desenvolvimento de software efetivo e leve. Possui 2 princípios:
• Modelos Múltiplos: há muitos modelos e notações , mas só um pequeno subconjunto é essencial para a maioria dos projetos (usar apenas os que apresentam valor a audiência); • Viajar Leve: a medida que o trabalho prossegue, conserve apenas os modelos com valor a
longo prazo e livre-se do resto.
UNIDADE 18: Engenharia de Projeto – Projeto Modular – Projeto de Interface com usuário Projeto modular: componentes separados e integrados para atender as necessidades.
Prática condenável: software monolítico. Porém, excesso de módulos também vira um problema. Manutenção do sistema: outro problema se poucas pessoas o compreendem.
Diretrizes para projeto de interface com usuário:
• Familiaridade com o usuário: conceitos e termos que o usuário conhece; • Consistência: operações semelhantes executam-se da mesma forma; • Mínimo de surpresa: comportamento do Sistema não deve ser “estranho”;
• Facilidade de recuperação: deve permitir ao usuário recuperação a partir de erros humanos; • Orientação do usuário: em caso de erro, fornecer feedback significativo e oferecer recursos
de ajuda;
• Diversidade de usuários: deve fornecer recursos de interação apropriados a diferentes tipos de usuários do sistema.
UNIDADE 19: Arquitetura de Sistemas Distribuídos – Arquitetura de Multiprocessadores Características de Sistemas Distribuídos:
• Compartilhamento de recursos: gerenciados por computadores centrais ou servidores; • Abertura: para hw e sw de diferentes fabricantes;
• Concorrência de processos; • Escalabilidade;
• Tolerância a defeitos;
• Transparência: usuários conseguem o que querem sem precisar conhecer a complexidade do sistema.
Desvantagens: Alta complexidade, segurança baixa, dificuldade de gerenciamento e imprevisibilidade nos tempos de resposta.
UNIDADE 20: Arquitetura Cliente/Servidor – Arquitetura de objetos distribuídos
Cliente-Servidor: conjunto de serviços fornecidos por servidores e conjunto de clientes que consomem estes serviços. A mais utilizada é a de “duas camadas”.
Arquitetura em 3 camadas: tradicional na web, o modelo tem camada de dados(servidor), camada de negócios(servidor) e camada de apresentação (cliente).
Objetos distribuídos: elimina o conceito de quem é servidor ou cliente, surge o conceito de middleware (seu papel é fornecer uma interface contínua de comunicação entre os objetos). Os objetos podem ser implementados em diferentes linguagens e executados em diferentes plataformas (ex: CORBA e DCOM).
UNIDADE 21: Mudanças em Software – Dinâmica da Evolução de Programas – Evolução da Arquitetura
Estratégias para mudanças:
• Evolução da Arquitetura: normalmente vai da mais centralizada para a cliente/servidor; • Manutenção: estrutura estável, mas sofre modificações para adaptar novos requisitos; • Reengenharia: oposto da manutenção, sofre alterações severas na estrutura.
Estruturas de um sistema (facilitar a Evolução da Arquitetura): • Apresentação;
• Validação dos dados; • Controle de interações; • Aplicação;
• Banco de dados.
UNIDADE 22: Reengenharia de Software – Tradução de código fonte – Engenharia Reversa – Melhoria de estrutura de programa
• Tradução de código fonte: converter de uma linguagem para outra (mais moderna ou adequada);
• Engenharia reversa: extrai informações do programa, a fim de ajudar a documentá-lo; • Melhoria de estrutura do programa: a estrutura é modificada para ficar mais fácil de ser lida
e compreendida (refatoração);
• Modularização do programa: criação de componentes, e remoção de redundâncias; • Reengenharia de dados: mudança nos dados processados pelo programa, para refletir as
mudanças.
UNIDADE 23: Reengenharia de dados e suas abordagens
• Limpeza de dados: análise de registros e valores de dados, remoção de duplicações e informações redundantes (normalmente sem causar impactos nos programas);
• Extensão de dados: dados e programas passam pela reengenharia para aumentar extensão de campos, modificar limites, etc;
• Migração de dados: normalmente para um SGBD com estruturação dos programas para este novo tipo de visão dos dados.
UNIDADE 24: Gerenciamento de Configuração – Gerenciamento de Mudanças – Gerenciamento de Versões e Releases
Gerenciamento de configuração: aplicação de padrões e procedimentos para gerenciar um sistema em desenvolvimento. Possui 4 atividades principais:
• Planejamento e Gerenciamento da Configuração;
forma prática e econômica. Utiliza um formulário de Requisição de Mudança (CRF);
• Gerenciamento de versões e releases: permitir o controle de liberação do sistema. Utilizando 3 técnicas básicas:
• numeração de versões (comum); • baseada em atributos;
• orientada a mudanças;
• Construção de Sistemas: compilação e ligação de componentes para uma configuração-alvo. UNIDADE 25: Construção de Sistemas – Ferramentas CASE
Ferramentas CASE (Computer Aided Software Engineering): apoia as atividades típicas de desenvolvimento, e podem incluir ou não um gerador de código.
Upper-CASE: apoio a análise e ao projeto; Lower-CASE: apoio a implementação e testes.
UNIDADE 26: Sistemas Legados:Estrutura e Avaliação
Estrutura dos Sistemas legados: hardware, software de apoio, software de aplicação, dados de aplicação, processos de negócio e políticas e regras de negócio. É comum as camadas se misturarem ao invés de estar tudo separado (como devia ser).
Avaliação de sistemas legados: VALOR de negócios X Qualidade de Sistemas (ortogonais)
• Alto Valor x Baixa Qualidade: são fortes candidatos a reengenharia (porque são importantes e estão custando caro pra manter);
• Baixo Valor x Baixa Qualidade: manter é caro, e tem baixo retorno, fortes candidatos a serem descartados;
• Alto Valor x Alta Qualidade: devem ser mantidos pela importância, sem precisar investir, continuam operando como estão;
• Baixo Valor x Alta Qualidade: não contribui para o negócio, mas não custa caro manter, podem ser mantidos ou descartados.
UNIDADE 27: Manutenção de Software: fundamentos, tipos procedimentos, técnicas e ferramentas Leis de Lehman (1985):
• Mudança contínua: programa utilizado no mundo real tem que ser modificado ou se tornará menos útil ao longo do tempo;
• Aumento da Complexidade: a medida em que um programa em evolução se modifica, sua estrutura se torna mais complexa.
Tipos de Manutenção:
• Reparo de defeito: correção de erros (erro de codificação = barato; erro de requisito = caro); • Adaptação do software a um ambiente diferente;
• Acréscimo ou modificação de funcionalidade: alteração de requisitos é a mais comum. Procedimentos de Manutenção: segue o mesmo modelo do processo de desenvolvimento de um sistema (espiral, por exemplo).
UNIDADE 28: Gestão de Projetos de Software e PMBOK
Gestão de Projetos de Software: se preocupa em entregar o sistema no prazo e de acordo com os requisitos, levando em conta limitações de orçamento e tempo. Foco nos 4 Ps: Pessoal (padrão
equivalente ao CMM → PM-CC), Produto (determinação adequada de objetivos e escopo), Processo(ferramentas de apoio) e Projeto (diretrizes do PMBOK).
Planejamento de um projeto deve ter: • Organização do projeto;
• Estruturação de tarefas (WBS); • Cronograma de projeto;
• Análise de Risco.
PMBOK (Project Management Body of Knowledge): Desenvolvimento pelo PMI (Project Management Institute). Estrutura baseada em 9 áreas de conhecimento:
• Gerenciamento de Integração do Projeto; • Gerenciamento de Escopo do Projeto; • Gerenciamento de Prazo do Projeto • Gerenciamento de Custo do Projeto; • Gerenciamento de Qualidade do Projeto;
• Gerenciamento de Recursos Humanos do Projeto; • Gerenciamento de Comunicação do Projeto; • Gerenciamento de Riscos do Projeto;
• Gerenciamento de Aquisições do Projeto;
UNIDADE 29: Gerenciamento de Qualidade e Estratégias de Teste de Sofware
Relação direta entre qualidade do produto de software e qualidade de processo para criar esse produto. Os principais itens de PROCESSO, são:
• Facilidade de compreensão (Até que ponto o processo está definido e com que facilidade se compreende essa definição?);
• Visibilidade (As atividades chegam em resultados concretos, progresso é visível?); • Facilidade de suporte (Pode ser apoiado por ferramentas CASE?);
• Aceitabilidade ( o processo é aceitável e utilizável pelos desenvolvedores?); • Confiabilidade (Os erros podem ser evitados ou identificados antes da entrega aos
usuários?);
• Robustez (Existe continuidade no processo mesmo com erros inesperados?);
• Facilidade de Manutenção (existe evolução no processo para requisitos mutáveis ou melhorias?);
• Rapidez (a partir de uma dada especificação, com que rapidez pode ser alterado o processo?).
Principais fatores da qualidade: Tecnologia, Pessoal, Processo, Custo (Tempo e Cronograma). Estratégias de teste: princípio básico → diferentes equipes (desenvolvimento x teste). Top-Down (mais natural) e Bottom-Up.
Software construído para um cliente → Teste de Aceitação. Software construído para vários clientes → Testes Alfa e Beta.
Teste Alfa: ambiente controlado em ambiente especial para registrar informações;
Teste Beta: no ambiente do usuário sem presença de desenvolvedores (importantes a escolha d usuários para este teste).
Teste de caixa branca: foco nos possíveis erros internos ao sistema, usa técnicas como testes de caminho básico, estrutura de controle.
UNIDADE 30: Engenharia de Software na WEB – Sistemas e Aplicações baseadas na Web WebE (Engenharia de Software na Web)
WebApps (aplicações). Requisitos de qualidade: • Usabilidade; • Funcionalidade; • Confiabilidade; • Eficiência; • Manutenibilidade; • Segurança.
Fases do Projeto de WebE: • Projeto de Interface;
• Projeto Estético (cor, layout, fonte, etc); • Projeto de Conteúdo;
• Projeto de Navegação; • Projeto Arquitetural; • Projeto de Componente.
Arquitetura mais usada: MVC (Modelo – Visão - Controlador):
• Modelo: Encapsula funcionalidade, objetos de conteúdo e incorpora estados da aplicação (conteúdo armazenado num DB);
• Visão: prepara dados do modelo, apresenta do usuário (página HTML);
• Controlador: gera requisições de usuário, seleciona comportamento do modelo e seleciona resposta de visão (gera dados dinâmicos da pagina HTML).
