Eng Software

Prévia do material em texto

Aula 01: Introdução à Engenharia de Software
A Engenharia de Software (ES) é uma disciplina da Ciência da Computação que estuda todos os processos envolvidos no desenvolvimento de software. É crucial porque monitora as diversas atividades do processo de desenvolvimento de sistemas.
A Engenharia de Software envolve:
· Planejamento
· Qualidade
· Requisitos
· Desenvolvimento
Sistema de Informação Baseado em Computador (SIBC): É um conjunto de elementos organizado para processar informações.
· Elementos do SIBC: Procedimento, Documentos, Banco de Dados, Pessoas, Hardware, Software.
Onde utilizamos Software (Aplicações):
· Básico: Suporte a outros programas (compiladores, sistemas operacionais).
· De Tempo Real: Monitora, analisa e controla eventos do mundo real.
· Comercial: Sistemas para operações e decisões administrativas.
· Científico e de Engenharia: Algoritmos de processamento de números (biologia molecular, manufatura automatizada).
· Embutido: Reside em memórias ROM, controla produtos e sistemas (teclado de micro-ondas).
· De Computador Pessoal: Processamento de textos, planilhas, diversão.
· De Inteligência Artificial: Algoritmos não numéricos para resolver problemas complexos (sistemas especialistas, reconhecimento de padrões).
· Para Web: Software que incorpora instruções executáveis e dados (CGI, HTML, Perl, Java).
Crise de Software: Refere-se a problemas encontrados no desenvolvimento de software.
· Problemas comuns: Estimativas imprecisas de prazos e custos, insatisfação do cliente, baixa qualidade, software difícil de manter.
· Causas: O software é lógico e não físico (não se desgasta, mas deteriora), falhas humanas como falta de experiência, ausência de treinamento formal e resistência a mudanças.
Processo de Software: É a aplicação de uma abordagem sistemática, disciplinada e mensurável para o desenvolvimento, operação e manutenção do software.
· Características de um processo: Prescreve atividades principais, utiliza recursos, sujeito a restrições (cronograma), gera produtos intermediários e finais, pode ser composto por subprocessos.
· Componentes de um processo de software: Procedimentos e Métodos, Ferramentas e Equipamentos, Pessoas.
Modelos de Processo de Software: Descrevem formalmente as atividades para a obtenção de um produto de software seguro. A escolha do modelo depende da natureza do projeto, métodos e ferramentas a serem usadas, e controles e produtos a serem entregues.
Fases Genéricas do Processo de Software:
· Definição: "O Quê" — informações a serem processadas, funções, desempenho, interfaces, restrições e critérios de validação.
· Construção: "Como" — projeto da estrutura de dados, arquitetura do software, implementação de procedimentos, tradução para linguagem de programação e execução de testes.
· Manutenção: Mudanças no software após a entrega (erros, adaptações, acréscimos).
Modelos de Processo de Software Tradicionais:
· Modelo Cascata (Sequencial Linear): Mais antigo e amplamente usado, requer abordagem sistemática e sequencial.
· Fases: Definição de requisitos, Projeto de sistema e software, Implementação e teste unitário, Integração e teste de sistema, Operação e manutenção.
· Problemas: Dificuldade em seguir fluxo sequencial, requisitos difíceis de estabelecer no início, cliente espera muito por uma versão executável.
· Modelo Prototipação: Objetivo é entender os requisitos do usuário, criando um protótipo do software. Apropriado quando o cliente tem objetivos gerais, mas não requisitos detalhados.
· Ciclo: Obter Requisitos, Elaborar Projeto Rápido, Construir Protótipo, Avaliar Protótipo, Refinamento do Protótipo.
· Problemas: Qualidade e manutenibilidade não consideradas globalmente, implementação comprometida. Solução: Definir regras claras no início sobre o protótipo.
· Modelo Incremental: Trabalha com o usuário para descobrir requisitos de forma incremental até o produto final. Combina benefícios da cascata e prototipação.
· Vantagens: Clientes não esperam pela versão final, podem usar incrementos como protótipos para refinar requisitos, menor risco de fracasso, funções prioritárias são testadas mais intensivamente.
Metodologia Ágil: Surgiu para resolver problemas do modelo clássico, como feedback tardio, ausência de colaboração, inflexibilidade e retrabalho.
· Características: Habilidade de criar e responder a mudanças, diminuir documentação, foco em pessoas e interações. Ser ágil é entregar valor mais rápido ao cliente, dividindo o projeto em partes menores com entregas parciais.
· Exemplos: Scrum, XP (Extreme Programming), Kanban, entre outros.
Scrum: Focado em planejamento contínuo, aceitação de mudanças e entregas constantes, ideal para ambientes em constante mudança. Trabalha com equipes pequenas.
· Fases Principais:
· Pré-Planejamento: Requisitos no Product Backlog (priorizados por esforço e prioridade), definição de equipes, ferramentas e riscos.
· Desenvolvimento: Riscos controlados, desenvolvido em Sprints (iterações de 1 semana a 1 mês), Sprints seguem análise, projeto, implementação e teste.
· Pós-Desenvolvimento: Análise de progresso, demonstração de funcionalidades ao cliente.
· Papéis no Scrum:
· Product Owner: Dono do produto, define características, identifica requisitos, define ordem de desenvolvimento, disponível e bom comunicador.
· Scrum Master: Responsável pelo andamento do projeto e aplicação do Scrum, busca o melhor resultado da equipe (motivador), auxilia nos riscos e mantém a equipe focada.
· Equipe (Development Team): De 3 a 10 membros, multi-habilidades (desenvolvedores, analistas, projetistas, designers, testadores, etc.).
· Eventos/Reuniões no Scrum:
· Sprint Planning: Dividida em duas partes, onde a equipe e o Product Owner definem os itens do Product Backlog a serem desenvolvidos. O Scrum Master conduz.
· Daily Meeting (Reunião Diária): Máximo 15 minutos, para que a equipe saiba o andamento do projeto e reporte impedimentos. Scrum Master conduz. Perguntas: O que foi concluído? Quais impedimentos? Próxima tarefa?
· Sprint Review: Apresentação da nova funcionalidade ao Product Owner para validação. Duração máxima de 4 horas. Não usar slides, demonstrar funcionalidade.
· Retrospective Meeting: Sem o Product Owner, máximo 3 horas. Liderada pelo Scrum Master, discute melhorias no processo de desenvolvimento. Perguntas: O que foi bom? O que pode ser melhorado?
· Product Backlog: Lista de requisitos a serem desenvolvidos, levantados em reuniões iniciais, visível no Task Board.
· Sprint Backlog: Tarefas a serem desenvolvidas para a iteração atual.
Aula 02: Requisitos de Software
Definição de Requisitos: Descrições do que o sistema deve fazer, os serviços que oferece e as restrições ao seu funcionamento. Descrevem o que deve ser feito, não como. Uma condição ou capacidade que o sistema deve satisfazer.
"Requisito não é sinônimo de arquitetura. Requisito não é sinônimo de projeto nem de interface do usuário. Requisito é sinônimo de necessidade." (Andrew Hunt e David Thomas)
Tipos de Requisitos:
· Requisitos de Usuários: Declarações em linguagem natural com diagramas, sobre serviços que o sistema deve fornecer e restrições de operação. (Ex: Gerar relatórios gerenciais mensais de custos de medicamentos por clínica).
· Requisitos de Sistema: Detalham restrições, funções e serviços que o sistema deve atender. São mais detalhados que os requisitos de usuário e servem como ponto de partida para o projeto. (Ex: Gerar resumo de medicamentos prescritos no último dia útil do mês após 17:30h).
· Requisitos Funcionais: Declarações das funções que o software deve fornecer, como deve reagir a entradas e se comportar em situações específicas. Podem também declarar o que o sistema não deve fazer. (Ex: Calcular folha de pagamento, emitir relatórios, armazenar informações de clientes).
· Requisitos Não-Funcionais: Restrições sobre os serviços ou funções, como tempo de resposta, padrões, restrições no processo de desenvolvimento. (Ex: Acesso restrito ao BD, tempo de resposta abaixo de 30 segundos, operacionalizar em Windows).
· Requisitos de Domínio:Derivados do domínio da aplicação do software, não de necessidades específicas dos usuários. (Ex: Interface-padrão com usuário para todos os bancos de dados baseada em Z39.50).
Engenharia de Requisitos (ER): Fornece mecanismos para entender o cliente, analisar necessidades e o que é possível, negociar soluções, especificar e gerenciar requisitos. Transforma um problema do mundo real em uma solução de software. É a área que estuda métodos e técnicas para elicitação, análise, modelagem, validação e gerenciamento de requisitos.
Produção de Requisitos:
1. Estudo de Viabilidade: Avalia 4 áreas:
· Econômica: Custo de desenvolvimento vs. benefício.
· Técnica: Função, desempenho e restrições que afetam a capacidade de se obter um software aceitável.
· Legal: Infrações, violações ou responsabilidades legais.
· Alternativas: Avaliação de abordagens alternativas de desenvolvimento.
· Como fazer: Identificar a alternativa (recursos, funcionamento), análise de custos (tabela) e benefícios (justificativa).
2. Elicitação de Requisitos: Descobrir e tornar explícito o máximo de informações para o conhecimento do software a ser desenvolvido.
· Técnicas: Entrevistas (estruturadas, desestruturadas), Brainstorming, Questionário, Prototipagem, Etnografia (Observação/Análise documental).
· Entrevista: Discussão com stakeholders para entender requisitos. Níveis de perguntas: primárias (introduzir áreas) e secundárias (explorar informações).
· Brainstorming: Geração de ideias espontâneas em grupo. Regras: qualquer um pode apresentar ideias, relacionadas ao tópico, sem críticas, mas com possibilidade de expansão.
· Questionário: Preparado antecipadamente com questões objetivas. Benefícios: economia de tempo e baixo custo. Desvantagem: comunicação restrita.
· Prototipagem: Desenvolvimento de uma versão inicial das telas do software para demonstrar conceitos e experimentar opções. Ajuda a entender problemas e soluções.
· Observação/Análise Documental: Contato pessoal com stakeholders. Útil para descobrir novos aspectos e confirmar informações.
· Classificação Temporal das Técnicas:
· Iniciais: Entrevista desestruturada, Questionário (sim/não), Brainstorming.
· Intermediárias: Entrevista estruturada.
· Finais: Entrevistas fechadas (questionários específicos), Rastreamento de Processo, Simulações e Protótipos.
· Não existe a melhor técnica, mas sim a mais adequada para cada situação.
3. Documento de Requisitos: Declaração oficial do que os desenvolvedores devem implementar, incluindo requisitos de usuário e especificação detalhada dos requisitos de sistema.
Aula 03: Especificação dos Requisitos de Software (ERS) - Capítulo 01
ERS (ou SRS - Software Requirements Specification): Documento que permite ao cliente descrever suas necessidades e ao desenvolvedor compreendê-las. Define todos os requisitos do software e estabelece uma base de acordo entre cliente e desenvolvedor. A norma IEEE Std 830 recomenda abordagens para a ERS.
Considerações para produzir uma boa ERS:
· Natureza da ERS: É uma especificação do produto que realiza funções em um ambiente específico.
· Questões básicas: Funcionalidade (o que o software faz), Interfaces Externas (interação com pessoas, hardware, outros softwares), Performance (velocidade, tempo de resposta), Atributos (portabilidade, manutenibilidade, segurança), Restrições de implementação (padrões, linguagem, recursos).
· Ambiente da ERS: Deve estar de acordo com os requisitos do sistema, definir corretamente os requisitos de software, não descrever detalhes de projeto ou implementação nem estabelecer restrições adicionais (especificadas em outros documentos).
· Características da ERS:
· Correta: Cada requisito deve ser encontrado no software.
· Não Ambígua: Cada requisito deve ter uma única interpretação.
· Completa: Inclui todos os requisitos significativos (funcionalidade, desempenho, restrições), respostas para todas as entradas e saídas, nomes e referências de tabelas/figuras, e definições de termos/unidades.
· Consistente: Não há conflitos entre requisitos.
· Grau de Importância e/ou Estabilidade: Identifica a importância (essencial, desejável) ou estabilidade de cada requisito.
· Verificável: Possível verificar cada requisito, usando termos concretos e quantidades mensuráveis.
· Modificável: Requisitos podem ser facilmente alterados. A ERS deve ser organizada, não redundante e expressar cada requisito separadamente.
· Rastreável: A origem de cada requisito é clara e facilita referência futura.
· Preparação da ERS: Cliente e fornecedor devem trabalhar juntos. Um protótipo pode ser usado para elicitar requisitos.
Partes da ERS segundo IEEE 830 (Estrutura Genérica):
1. Introdução: Objetivo, Escopo, Definições/Siglas/Abreviações, Referências, Visão Geral.
· Objetivo: Delinear o propósito da ERS e público alvo.
· Escopo: Descrever o produto e suas funcionalidades, o que fará e o que não fará, aplicação do software e benefícios.
· Definições, Siglas e Abreviações: Fornecer definições necessárias para interpretar a ERS.
· Referências: Lista completa de documentos referenciados.
· Informações Adicionais: Dados da Instituição, Dados da Empresa, Legislação de Software (opcional).
· Visão Geral: Descrever o conteúdo e organização da ERS.
2. Descrição Geral do Produto: Descreve fatores gerais do produto e seus requisitos, sem detalhar especificamente. Serve como background para a seção 3.
Aula 04: Especificação dos Requisitos de Software (ERS) - Capítulo 02
2. Descrição Geral do Produto:
· 2.1 Estudo de Viabilidade: Apresentar a alternativa de informatização escolhida, considerando viabilidades técnica, econômica e legal, e destacando vantagens/desvantagens com base em custo x benefício.
· 2.1.1 Justificativa para Alternativa Selecionada: Explicar o motivo da escolha da alternativa em relação às rejeitadas (que devem ser colocadas em um apêndice).
· 2.2 Funções do Produto (Item mais importante):
· Funções Básicas (RF_B): Operações CRUD (Create, Read, Update, Delete), como "Gerenciar".
· Funções Fundamentais (RF_F): Transações de negócio que agregam valor ao cliente e são o motivo da organização existir.
· Funções de Saída (RF_S): Geram informações relevantes de saída (consultas/relatórios com cruzamento de informações).
· Estrutura da Tabela:
· Referência: Identificador (RF_B1, RF_F1, RF_S1).
· Função: Nome que identifica a função.
· Visibilidade: Evidente (visível ao usuário) ou Oculta (imperceptível).
· Atributo: Requisitos não-funcionais (tolerância a falhas, tempo de resposta, segurança).
· Detalhes e Restrições: Descreve o atributo em detalhes.
· Categoria: Classifica o atributo como Obrigatório ou Desejável.
· 2.3 Características do Usuário: Descrever o nível educacional, experiência e conhecimento em informática dos usuários para diagnosticar necessidade de treinamento.
· 2.4 Limites, Suposições e Dependências: Descrição de itens que limitarão as opções do desenvolvedor (normas, hardware, linguagem de programação, segurança) e fatores que afetam os requisitos. Ex: Não adquirir ponto eletrônico limita funcionalidade.
· 2.5 Requisitos Adiados: Identificar e justificar requisitos adiados no projeto.
Aula 04: V&V e Gerenciamento de Requisitos
Validação e Verificação (V&V) de Requisitos: Garantem que os requisitos de software descrevem com precisão as capacidades e propriedades do software.
· Validação: Assegura que o produto final corresponda aos requisitos, ou seja, se os requisitos representam o software corretamente. (Ex: "Vender Produto" deve ser executado pelo Vendedor, não pelo Gerente).
· Verificação: Assegura que o requisito seja consistente, completo e correto, ou seja, se os requisitos estão representados corretamente. (Ex: O Gerente deve executar "Gerar Relatórios" e "Exportar Estatística").
· Checklist: Questionário com perguntas relacionadas ao produto de software, respondidas pelos stakeholders durante a inspeção, para verificar os requisitos.
Gerenciamento de Requisitos: Acompanha a evolução dos requisitos ao longo do processo de desenvolvimento, mantendo registro do status, atividadesde visibilidade e controle sobre as etapas do ciclo de vida do produto. Fundamental para lidar com mudanças de ideia do usuário ou entendimento incorreto pelo analista.
Espero que este resumo te ajude a ter uma visão clara e objetiva para seus estudos! Boa sorte na prova!