Engenharia de software

Conceito	Descrição
Engenharia de Software	Aborda a necessidade da área em razão da complexidade e diversidade de padrões para o desenvolvimento de softwares.
Processos de software	Um conjunto de elementos e atividades próprias de um processo de desenvolvimento de software, como atividades metodológicas, ações de engenharia de software, tarefas, produtos de trabalho, garantia de qualidade e mecanismos de controle de mudanças para cada projeto.
Modelos de processos prescritivos	Modelos tradicionais que surgiram para organizar e direcionar atividades de desenvolvimento de software, com capacidade de prescrever um conjunto de elementos e atividades. Denominados "tradicionais" e criados com objetivos específicos para presumir o desenvolvimento de software.
Modelos de processos ágeis	Modelos que representam uma abordagem contrária aos modelos prescritivos, com iterações curtas onde o resultado é medido pelo produto pronto. Serão estudados em detalhes futuramente.
Modelo em cascata	Um dos principais modelos prescritivos, representa as atividades fundamentais do processo: especificação, desenvolvimento, validação e evolução. Precede uma atividade de revisão ao final de cada fase para avaliar se o projeto pode passar à fase seguinte.
Fases do Modelo Cascata	Incluem: Definição dos requisitos (serviços, restrições e metas são estabelecidos e definidos em detalhes); Projeto do sistema e do software (requisitos são repartidos entre hardware e software); Implementação e teste de unidade (projeto é realizado como um conjunto de programas ou unidades de programa que são implementadas e testadas); Integração e teste do sistema (unidades de programa são integradas e testadas como um sistema completo); Operação e manutenção (sistema é instalado, colocado em uso e aperfeiçoado à medida que novos requisitos são descobertos).
Desenvolvimento incremental	Um dos principais modelos prescritivos, intercala as atividades de especificação, desenvolvimento e validação. O sistema é desenvolvido como uma série de versões (incrementos), cada uma acrescentando funcionalidades à versão anterior. A primeira versão pode ter funcionalidades limitadas, e versões posteriores adicionam mudanças.
Integração e configuração	Um dos principais modelos prescritivos, baseia-se na disponibilidade de componentes ou sistemas reutilizáveis, focando na configuração desses componentes para um novo contexto e sua integração em um sistema.
Modelo Espiral	Tem como característica principal a realização de ciclos de prototipação para a redução de riscos de projeto. É fortemente orientado a riscos, proposto por Boehm em 1986, apresentando a ideia em ciclos iterativos. Combina prevenção e tolerância a mudanças, assumindo que mudanças são resultado de riscos e incluindo atividades explícitas de gerenciamento de riscos para sua redução.
Modelo Sashimi	Introduz a noção de que as fases do modelo cascata não são estanques, podendo um projeto estar simultaneamente em mais de uma fase.
Modelos V e W	Focam no teste durante o desenvolvimento de software, indicando que o teste deve ser uma preocupação constante desde o início, não apenas uma etapa final.
Modelo orientado a cronograma	Tem foco prioritário no desenvolvimento das funcionalidades mais importantes, deixando as demais para o final para garantir que as críticas sejam entregues no prazo em caso de atrasos.
Entrega em estágios	Tem como prioridade planejar e entregar partes prontas do sistema antes do final do projeto.
Prototipação evolucionária	Propõe o uso de protótipos para ajudar na definição dos requisitos e na exploração de soluções de projeto. Permite que todo o sistema, ou parte dele, seja construído rapidamente para entender ou esclarecer dúvidas. O protótipo evolui até se tornar um sistema que pode ser entregue.
Métodos para prototipação	Incluem: Throw-away (protótipos descartáveis, usados apenas para estudar aspectos do sistema, entender requisitos e reduzir riscos); e Cornerstone (protótipos fundamentais, usados para compreender todos os aspectos do throw-away e que se tornam parte do sistema final, evoluindo até se tornar o sistema entregue).
Rational Unified Process (RUP)	Um modelo híbrido de processo, contrário a metodologias que oferecem uma visão única do processo. Aborda quatro fases no processo de software. Reúne elementos de outros modelos, apoiando prototipação e entrega incremental. Cada fase pode seguir o modo iterativo, com resultados incrementais, e as quatro fases juntas podem ser aplicadas incrementalmente ou seguir a metodologia espiral.
Fases do RUP	Incluem: Concepção (elaboração de plano de negócios, identificação de entidades externas e requisitos, avaliação da contribuição do sistema para o negócio); Elaboração (desenvolvimento dos requisitos e da arquitetura do sistema); Construção (implementação e testes do sistema); Transição (implantação do sistema em ambiente real).
Disciplinas do RUP	O modelo apresenta um conjunto de seis atividades lógicas de projeto (Modelagem de negócios, Requisitos, Análise e design, Implementação, Teste, Implantação) e três de apoio (Ambiente, Gerenciamento de mudança e configuração, Gerência de projeto) para cada fase.

Conceito	Descrição
Métodos ágeis de desenvolvimento de software	Surgiram em um esforço para sanar fraquezas da engenharia de software convencional, especialmente a sobrecarga dos modelos prescritivos em sistemas menores.
Desenvolvimento ágil	Abordagem de desenvolvimento de software que busca sanar fraquezas da engenharia convencional.
Manifesto Ágil	Documento que define a filosofia ágil, valorizando indivíduos e interações, software em funcionamento, colaboração com o cliente e resposta a mudanças, mais que processos e ferramentas, documentação abrangente, negociação de contratos e seguir um plano.
Agilidade	Mais que uma resposta à mudança, abrange a filosofia do manifesto ágil. Incentiva comunicação fácil em equipe, entrega rápida de software operacional, cliente como parte da equipe e planos flexíveis. Pode ser aplicada a qualquer projeto, sendo essencial que a equipe possa adaptar tarefas, planejar compreendendo a fluidez, eliminar artefatos não essenciais e enfatizar entrega incremental.
Princípios do Manifesto Ágil	Doze princípios que definem o espírito ágil, incluindo priorizar satisfação do cliente, aceitar mudanças, entregar software frequentemente, colaborar com cliente, confiar em indivíduos motivados, comunicação face a face, software em funcionamento como medida de progresso, desenvolvimento sustentável, excelência técnica, simplicidade, equipes auto-organizadas e autoavaliação regular.
Método XP (Extreme Programming)	Um método ágil que requer seguir uma série de práticas relacionadas ao cliente, gerência, programação e testes.
Práticas do Método XP	Incluem: Jogo de planejamento (equipe e cliente priorizam funcionalidades semanalmente); Programação em pares (dois programadores na mesma máquina, um usando a máquina e outro auxiliando); Padrões de codificação (equipe segue padrões para o código parecer ter sido desenvolvido pela mesma pessoa); Testes de aceitação (planejados e conduzidos com o cliente para verificar requisitos); Desenvolvimento orientado a teste (definir e implementar testes antes de programar a unidade); Refatoração (não fugir da refatoração para manter complexidade gerenciável); Integração contínua (integrar funcionalidade assim que viável para evitar surpresas).
Método FDD (Feature Driven-Development)	Método ágil que enfatiza orientação a objetos, apresentado em 1997. Dividido em duas fases.
Fases do Método FDD	Incluem: Concepção e planejamento (pensar antes de construir, em geral de uma a duas semanas); Construção (desenvolvimento iterativo do produto em ciclos de uma a duas semanas).
Disciplinas do Método FDD	Na fase de Concepção e planejamento: Desenvolver Modelo Abrangente (uso de modelagem orientada a objetos); Construir Lista de Funcionalidades (decomposição funcional para identificar funcionalidades); Planejar por Funcionalidade (planejamento de ciclos iterativos baseado em funcionalidades). Na fase de Construção: Detalhar por Funcionalidade (design orientado a objetos); Construir por Funcionalidade (construir e testar software usando linguagem e técnica orientadas a objetos).
Método DSDM (Dynamic Systems Development Method)	Modelo ágil baseado em desenvolvimento iterativo e incremental com participação ativa do usuário. Composto por três fases.
Fases do Método DSDM	Incluem: Pré-projeto (projeto é identificado, negociado, orçamento definido, contrato assinado); Ciclo de vida (inicia com análise de viabilidade e negócio, depois entra em ciclos iterativos de desenvolvimento); Pós-projeto (período considerado de manutenção). A fase de Ciclo de Vida se concentra nas atividades de Exploração, Engenharia e Desenvolvimento em ciclos iterativos.
Princípios da filosofia DSDM	Incluem: Envolvimento do usuário o tempo todo; Autonomia dos desenvolvedores para tomar decisões; Entregas frequentes de releases suficientemente boas; Eficácia das entregas na solução de problemas de negócio; Feedback dos usuários realimentando o processo; Reversibilidade de todas as ações; Previsibilidade do escopo e objetivos das iterações; Ausência de testes no escopo (considera teste fora do ciclo de vida).
Método Crystal Clear	Método ágil criado por Alistair Cockburn em 1997, adequado para equipes pequenas (até 8 pessoas) que trabalham juntas. Propõe o uso de radiadores de informação, acesso fácil a especialistas, eliminação de distrações, cronograma e ajuste do método.
Ciclo de vida do Crystal Clear	Organizado em três níveis: Iteração (estimação, desenvolvimento, celebração, dura poucas semanas); Entrega (várias iterações, entrega funcionalidades úteis em no máximo dois meses); Projeto (conjunto de todas as entregas).
Pilares do Crystal Clear	Incluem: Entrega frequente de software utilizável; Melhoria reflexiva (equipe reflete regularmente sobre seu processo); Comunicação osmótica (equipe na mesma sala ou contíguas para ouvir conversas relevantes); Segurança pessoal (desenvolvedores podem falar sem medo); Foco (membros da equipe têm tópicos de alta prioridade para trabalhar tranquilamente); Cooperação; Ambiente técnico com integração frequente e testes automatizados.
Método ASD (Adaptive Software Development)	Modelo ágil baseado em desenvolvimento cíclico iterativo. Fundamenta-se em três grandes fases.
Fases do Modelo ASD	Incluem: Especular (início do projeto, planejamento de ciclos adaptáveis, definindo duração, ciclos, objetivos, componentes, tecnologias e tarefas); Colaborar (foco no desenvolvimento dos componentes especificados); Aprender (revisão da qualidade, testes e manutenção). As três fases formam um ciclo iterativo.
Método Scrum	Modelo ágil para a gestão de projetos de software. Um dos conceitos mais importantes é o Sprint. Segue três fases na execução.
Fases do Método Scrum	Incluem: Planejamento geral (estabelece objetivos gerais do projeto e arquitetura); Série de ciclos de Sprint (cada ciclo desenvolve um incremento do sistema); Encerramento do projeto (completa documentação e avalia lições aprendidas).
Papéis do Método Scrum	Incluem: Scrum Master (responsável por manter o time em ambiente propício, facilitador e solucionador de conflitos); Product Owner (representa a voz do cliente, responsável pelo valor de negócio e necessidades dos clientes, indica requisitos mais importantes por sprint); Scrum team (responsável pelo desenvolvimento das entregas, entende requisitos, equipe de desenvolvimento geralmente com 6 a 10 pessoas).
Product Backlog (Scrum)	Lista das funcionalidades a serem implementadas em cada projeto, como os requisitos. Não precisa ser completo no início do projeto, podendo começar com as funcionalidades mais evidentes.
Sprint (Scrum)	Ciclo de desenvolvimento com poucas semanas de duração. No início de cada Sprint, a equipe prioriza elementos do Product Backlog para o Sprint Backlog.
Sprint Backlog (Scrum)	Lista de funcionalidades a serem implementadas no ciclo (Sprint) que se inicia. O Product Owner deve mantê-lo atualizado durante o Sprint.
Reuniões no Scrum	Incluem: Reuniões diárias (equipe se reúne diariamente para compartilhar o que fez ontem, o que fará hoje e quais impedimentos enfrenta); Reunião de Revisão (ao final de cada Sprint, para avaliar o que foi feito e receber feedback do Product Owner e stakeholders); Reunião de Retrospectiva (ao final de cada Sprint, para a equipe autoavaliar seu desempenho e identificar melhorias).

Conceito	Descrição
Projeto de arquitetura de software	Tarefa de definir a estrutura geral do sistema, partindo do contexto geral para então distribuir os processos e componentes. Representa a estrutura de dados e componentes necessários, considerando o estilo de arquitetura, estrutura e propriedades dos componentes e suas inter-relações.
Projeto	Definido como "um esforço temporário empreendido para criar um produto, serviço ou resultado único" (Guia PMBOK) e "um empreendimento planejado, orientado a resultados, possuindo atividades com início e término, para atingir um objetivo claro e definido" (Metodologia SISP).
Projeto de software	Um processo em várias etapas onde representações de dados, estrutura do programa, características de interfaces e detalhes procedurais são sintetizados com base nos requisitos. Corresponde a um esquema preliminar pelo qual o software é construído, considerando domínios de dados, funcional e comportamental.
Estilo ou padrão de arquitetura	Descrição abstrata, estilizada, de práticas recomendadas testadas e aprovadas em diferentes subsistemas e ambientes. O projeto de arquitetura considera o estilo que o sistema assumirá.
Etapas do projeto de arquitetura	Incluem: Definir entidades externas com as quais o software interage; Identificar arquétipos arquiteturais (abstrações de elementos do sistema, similares a classes); Análise de estilos ou padrões de arquitetura alternativos; Implementação da arquitetura utilizando um modelo de processos.
Projeto conceitual	Primeira fase do processo iterativo de projeto, apresenta ao cliente o que o sistema fará.
Projeto técnico (ou lógico)	Deriva do projeto conceitual após aprovação do cliente, sendo um modelo mais detalhado focado nas definições técnicas para o desenvolvimento.
Padrões de arquitetura de software	Diversos padrões que podem ser utilizados no desenvolvimento de sistemas, como arquitetura centralizada em dados, fluxo de dados, orientada a objetos, MVC, entre outros.
Arquitetura centralizada em dados	Padrão comum em sistemas de informação, onde um repositório de dados (banco de dados) reside no centro e é acessado por outros componentes para modificar dados.
Arquitetura de fluxo de dados (Duto e filtro)	Padrão aplicado quando dados de entrada devem ser transformados por uma série de componentes de processamento (filtros), onde cada componente realiza uma transformação de dados discreta.
Arquitetura orientada a objetos	Padrão que fornece uma descrição abstrata do software, aproximando as estruturas do programa de conceitos do mundo real. Baseia-se em classes (conjunto de características e comportamentos) e objetos (instâncias de uma classe).
Arquitetura Modelo, Visão e Controlador (MVC)	Padrão que foca em separar a apresentação e interação dos dados do sistema. Estruturado em três componentes lógicos: Modelo (gerencia dados e operações); Visão (define e gerencia como dados são apresentados ao usuário); Controlador (gerencia interação do usuário e a passa para Visão e Modelo).
Levantamento de requisitos	Primeira etapa na construção de um sistema. Processo no qual engenheiros de software trabalham com clientes e usuários para obter informações sobre o domínio da aplicação, serviços, desempenho, restrições, etc..
Requisitos de um sistema	Descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento. Refletem as necessidades dos clientes. Classificados como funcionais e não funcionais.
Descoberta de requisitos	Processo de reunir informações sobre o sistema requerido e sistemas existentes, separando requisitos de usuário e sistema de fontes como documentações, usuários e sistemas similares.
Técnicas de levantamento de requisitos	Incluem: Entrevistas (formais/informais com usuários e partes interessadas); Cenários (descrições textuais ou diagramáticas de interações); Casos de uso (abordagem estruturada de cenários, identificando atores e tipo de interação); Etnografia (observação para compreender processos operacionais).
Especificação de requisitos	Processo de escrever os requisitos de usuário e de sistema em um documento de requisitos.
Métodos de especificação de requisitos	Incluem: Sentenças em linguagem natural (requisitos escritos em frases numeradas); Linguagem natural estruturada (requisitos em linguagem natural em formulário/template); Notações gráficas (modelos gráficos, como diagramas UML, suplementados por texto); Especificações matemáticas (baseadas em conceitos matemáticos, podem reduzir ambiguidade mas são menos compreendidas por clientes).
Gerenciamento de configuração e mudança	Conjunto de atividades para gerenciar alterações em sistemas de software, identificando artefatos e controlando mudanças.
Atividades da gestão de configuração de software	Incluem: Controle de versão (gerenciar diferentes versões de artefatos); Construção de sistema (reunir componentes, dados e bibliotecas para criar executável); Gerenciamento de mudanças (controlar solicitações de mudança, avaliar custo/impacto e decidir implementação); Gerenciamento de lançamentos (preparação de versões do sistema).
Controle de versão (Git)	Sistema de controle de versão. Permite criar, gerenciar e trocar entre ramificações (branchs).
Ramificação (Git)	Permite criar novas linhas de desenvolvimento separadas. Podem ser associadas à ramificação principal (master).
GitHub	Plataforma para hospedagem de projetos gerenciados com Git.
Manutenção de software	Processo geral de mudança em um sistema após sua liberação para uso.
Tipos de manutenção de software	Incluem: Correção de defeitos; Adaptação ambiental; Adição de funcionalidade. Na prática, as distinções podem ser tênues.

Conceito	Descrição
Estimativas de esforço para desenvolvimento de softwares	Processo para realizar estimativas adequadas de tempo, tamanho da equipe e custo para aplicação de modelos de processos e arquiteturas.
Análise de Ponto de Função (APF)	Técnica de medição do tamanho funcional de um software. Mede o que o software faz, não como ele foi construído, baseada nos requisitos lógicos do usuário. Uma medida de tamanho funcional, usada com outras variáveis para derivar produtividade, custo e esforço.
Tamanho funcional de um software	O que é medido pela Análise de Ponto de Função.
Processo de contagem de pontos de função	Dividido em seis etapas: determinar tipo de contagem; identificar escopo e fronteira; contar funções (dados e transação); determinar pontos não ajustados; determinar fator de ajuste; calcular pontos ajustados (AFP).
Tipos de contagem (APF)	Incluem: Projeto de desenvolvimento (novo projeto); Projeto de melhoria (funções adicionadas, modificadas, eliminadas em projeto existente); Aplicação (projeto finalizado).
Escopo de contagem (APF)	Determinar se a contagem foca em um ou mais sistemas ou partes deles. Define quais funções serão incluídas.
Fronteira da aplicação (APF)	Estabelece um divisor entre componentes do aplicativo e de outros aplicativos. É a linha que separa uma aplicação de outra.
Funções tipo dados (APF)	Referem-se a funcionalidades para armazenamento de dados da aplicação, caracterizadas como arquivos lógicos (ALI e AIE).
ALI (Arquivos Lógicos Internos) (APF)	Arquivos lógicos mantidos dentro da fronteira da aplicação. Ex: arquivos de configuração, tabelas de BD mantidas pela aplicação.
AIE (Arquivos de Interface Externa) (APF)	Arquivos lógicos mantidos fora da aplicação ou lidos de outra. Ex: dados de segurança, dados salariais em outra aplicação.
RLR (Registros Lógicos Referenciados) (APF)	Subgrupo de DER, reconhecido pelo usuário. Ex: uma tabela do banco de dados.
DER (Dados Lógicos Referenciados) (APF)	Campo único, reconhecido pelo usuário, não repetido. Ex: um atributo de uma tabela do banco de dados. Chaves estrangeiras não são contadas como DER.
Funções tipo transação (APF)	Representam funcionalidades de processamento de dados do sistema, classificadas em EE, SE e CE. Denominadas processos elementares.
Processos elementares (APF)	A menor unidade de uma função disponível ao usuário, única e independente.
EE (Entrada Externa) (APF)	Processo elementar que manipula dados ou informações de controle originados fora da fronteira, com intenção de manter (incluir, alterar, excluir) ALI ou alterar comportamento do sistema.
SE (Saída Externa) (APF)	Processo elementar que envia dados ou informações de controle para fora, com intenção de apresentar informação ao usuário via lógica de processamento (não apenas recuperação). Ex: Relatórios com totalização, informações gráficas.
CE (Consulta Externa) (APF)	Processo elementar que envia dados ou informações de controle para fora, com intenção de apresentar informação via simples recuperação de dados de ALI/AIE. A lógica de processamento não deve conter fórmulas/cálculos. Ex: Informações com formato gráfico.
Pontos de função não ajustados (AFP não ajustados)	Total obtido somando-se os pontos das funções tipo dados e funções tipo transação. Representam o tamanho funcional da aplicação.
Fator de ajuste (APF)	Fator derivado dos itens de influência que afetam o tamanho funcional de um aplicativo. Calculado por: (pontos de influência x 0,01) + 0,65.
Itens de influência (APF)	14 características intrínsecas a um aplicativo que afetam seu tamanho funcional, cada uma pontuada de 0 a 5. Ex: Comunicação de dados, Funções distribuídas, Performance, Interface com o usuário, Reusabilidade, Facilidade de mudanças, etc..
Pontos de função ajustados (AFP)	Obtidos multiplicando os pontos de função não ajustados pelo fator de ajuste. Processo opcional; os pontos não ajustados podem ser considerados AFP.
Duração e custo de um projeto (Estimativa)	Para calcular o custo, é necessário saber o esforço total e o custo por hora/mês de trabalho. O custo é obtido multiplicando o esforço total pelo custo por hora/mês. A duração do projeto em horas por ponto de função varia por linguagem/tecnologia.
Esforço (Estimativa)	O esforço total do desenvolvimento é calculado com base no tamanho funcional (AFP) e na produtividade (pontos de função produzidos por hora/mês). Obter histórico de projetos ajuda a estimar com maior precisão.
Pontos de Casos de Uso (PCU)	Técnica de estimativa surgida em 1993, considerada mais simples que APF. Baseia-se na análise da quantidade e complexidade de atores e casos de uso, gerando pontos não ajustados (UUCP) e depois ajustados (UCP) pela aplicação de fatores.
UUCP (Pontos de caso de uso não ajustados)	Soma dos pontos atribuídos aos casos de uso e do peso não ajustado dos atores.
UCP (Pontos de caso de uso ajustados)	Obtidos multiplicando-se o total de UUCP pelo TCF e EF.
Complexidade dos atores (PCU)	Definida como simples (pessoa), média (outro sistema), ou complexa (outro sistema com interface gráfica). Cada ator é contado uma única vez.
Complexidade dos casos de uso (PCU)	Definida de três formas: por número de transações (simples: até 3, média: 4-7, complexo: acima de 7); por quantidade de classes necessárias (simples: até 5, média: 6-10, complexo: mais de 10); por análise de risco (simples: baixo risco, média: padronizado, complexo: não padronizado, alto risco). Somente casos de uso completos são contados.
Fatores técnicos (PCU)	Treze fatores que recebem pontuação de 0 a 5, usados na análise de PCU ajustados. Ex: Sistema distribuído, Performance, Segurança, Portabilidade.
TCF (Fator de complexidade técnica) (PCU)	Fator calculado com base nos 13 fatores técnicos: 0,6 + (0,01 * total da soma dos pontos de fatores técnicos).
Fatores ambientais (PCU)	Oito fatores específicos às características da equipe de desenvolvimento, usados na análise de PCU ajustados. Ex: Familiaridade com o processo, Experiência com a aplicação, Motivação, Equipe em tempo parcial.
EF (Fator ambiental total) (PCU)	Fator calculado com base nos 8 fatores ambientais: 1,4 – (0,03 x total da soma dos fatores ambientais).
Pontos de Histórias (PH)	Técnica de estimativa variante da APF, preferida em métodos ágeis como Scrum e XP. Medida de esforço relativa à equipe de desenvolvimento, não de complexidade funcional.
História de usuário (PH)	Explicação informal e geral sobre um recurso de software, escrita sob a perspectiva do usuário final. A estimativa de pontos de história pode ser feita subjetivamente pela equipe ou atribuindo pontos de acordo com o tempo de desenvolvimento.
Ksloc (Miles de Linhas de Código Fonte)	Métrica rudimentar de estimativa baseada na quantidade de linhas de código fonte. Pode ser estimada pela equipe com valores otimista, pessimista e esperado.
Modelo COCOMO (Constructive Cost Model)	Principal modelo de estimativa de tamanho de equipe e tempo linear de desenvolvimento. Considera Ksloc e outros fatores para estimar esforço, tempo e pessoas. Possui três modos de implementação (básica, intermediária, avançada) e considera o tipo de projeto (orgânico, semidestacado, embutido).
Esforço (E) (COCOMO)	Esforço estimado em desenvolvedor/mês. Calculado com base em Ksloc e constantes (modelo básico) ou Ksloc e fatores influenciadores de custo (modelos intermediário/avançado).
Tempo linear de desenvolvimento (T) (COCOMO)	Tempo sugerido em meses corridos. Calculado com base no esforço e constantes.
Número médio de pessoas (P) (COCOMO)	Número médio de pessoas recomendado para a equipe. Calculado dividindo o esforço pelo tempo linear de desenvolvimento (E/T).
Fatores influenciadores de custo (COCOMO Intermediário/Avançado)	15 fatores que afetam o esforço, relacionados a produto, hardware, pessoal e processo. Cada fator tem pesos que variam de Muito baixo a Muito alto.
EAF (Esforço de Ajuste de Fatores) (COCOMO Intermediário/Avançado)	Valor obtido pela multiplicação dos 15 fatores influenciadores de custo. Utilizado no cálculo do esforço.

Conceito	Descrição
Teste de software	Uma das fases mais importantes do desenvolvimento, tem como objetivo compreender seus conceitos para identificar possíveis defeitos e revelar esses defeitos através de casos de teste adequados. É o processo de executar um programa com a intenção de revelar defeitos, não provar a ausência deles.
Técnicas de teste de software	Três técnicas propostas na literatura: funcional, estrutural e baseada em defeitos. Distinguem-se pela fonte utilizada para definir os requisitos de teste.
Critérios de teste	Propostas dentro das técnicas de teste que visam atingir o objetivo de revelar defeitos. Cada critério procura explorar determinados tipos de defeitos, estabelecendo requisitos de teste.
Engano (Conceito de teste)	Caracteriza-se como uma ação equivocada de um conceito específico do domínio, geralmente causado por humanos. Pode ser, por exemplo, um erro de digitação ou lógica ao escrever o código.
Defeito (Conceito de teste)	A existência de um defeito em um programa leva à ocorrência de um erro, desde que o defeito seja executado. Por exemplo, uma condição lógica incorreta que causa um comportamento inesperado.
Erro (Conceito de teste)	Caracteriza-se por um estado inconsistente ou inesperado devido à execução de um defeito.
Falha (Conceito de teste)	Pode ser ocasionada por um estado inconsistente ou inesperado (erro).
Dados de teste	É um elemento do domínio de entrada de um programa. Ex: Para um programa que computa xy com x, y > 1, (2, 5) é um dado de teste.
Casos de teste	É um par formado por um dado de teste mais o resultado esperado para a execução do programa com aquele dado de teste. Ex: Para o dado de teste (2, 5), o caso de teste é ((2, 5), 10).
Domínio de entrada	O conjunto de todos os possíveis valores que podem ser utilizados para executar um programa. Ex: Para um programa que computa xy para x, y > 1, o domínio de entrada são todos os pares (x, y) de inteiros maiores que 1.
Domínio de saída	O conjunto de todos os possíveis resultados produzidos por um programa.
Oráculo de teste	Necessário para saber o resultado esperado para a execução de um dado de teste. Permite comparar os resultados obtidos com os esperados para verificar a correção do programa.
Teste de seleção	Procura identificar quais dados de teste devem ser selecionados do domínio de entrada.
Teste de partição	Procura estabelecer subconjuntos de dados de teste e selecionar casos de teste em cada subconjunto. Dados que satisfazem o mesmo requisito de teste (ex: executar determinada estrutura) pertencem ao mesmo subconjunto.
Teste de Funcionalidade (Caixa preta)	Método de teste que verifica e valida se as funções implementadas no software estão corretas em seus diversos níveis. Executado sobre as entradas e saídas do programa sem conhecimento do código-fonte. Inclui testes de unidade, integração, sistema e aceitação.
Testes de unidade	Os testes mais básicos, consistem em verificar se um componente individual do software funciona corretamente.
Testes de integração	Feitos quando unidades prontas e testadas isoladamente precisam ser integradas para gerar uma nova versão do sistema.
Estratégias de integração	Incluem: Big-bang (constrói e testa todas as classes/unidades juntas); Top-down (integração e teste de cima para baixo na hierarquia do sistema); Bottom-up (integração e teste de baixo para cima).
Testes de sistema	Testes feitos quando o sistema está completo e integrado. Focam em verificar se os requisitos funcionais e não funcionais foram atendidos. A execução do fluxo principal e fluxos alternativos do caso de uso é verificada.
Teste de Aceitação	Similar aos testes de sistema, com o foco principal em verificar se os requisitos foram atendidos conforme a especificação.
Teste Estrutural (Caixa branca)	Técnica em que todos os testes são executados com conhecimento do código-fonte. Capaz de detectar quantidade substancial de erros garantindo a execução de comandos e condições. Inclui critérios baseados na complexidade e fluxo de controle.
Critérios baseados na complexidade (Teste Estrutural)	Utilizam informações sobre a complexidade do programa para derivar requisitos de software. Ex: complexidade ciclomática e caminhos linearmente independentes.
Complexidade ciclomática	Métrica de software que proporciona uma medida quantitativa da complexidade lógica de um programa. Para n estruturas de seleção/repetição, a complexidade é n+1. Indica o número máximo de caminhos necessários para exercitar todos os comandos. Programas com complexidade <= 10 são simples.
Caminhos linearmente independentes	Qualquer caminho do programa que introduza pelo menos um novo conjunto de instruções ou uma nova condição. Determinados a partir do grafo de fluxo de controle (GFC).
Grafo de fluxo de controle (GFC)	Representação de um programa colocando comandos em nós e fluxos de controle em arestas. Nodos em sequência podem ser um nó; estruturas de seleção/repetição são nós distintos com arestas de decisão/repetição.
Critérios baseados no fluxo de controle (Teste Estrutural)	Utilizam o GFC para determinar quais estruturas são necessárias. Ex: Todos-Nós, Todas-Arestas, Todos-Caminhos.
Todos-Nós (Critério de teste estrutural)	Exige que a execução do programa passe ao menos uma vez em cada vértice do GFC, ou seja, que cada comando seja executado pelo menos uma vez.
Todas-Arestas (Critério de teste estrutural)	Requer que cada aresta do GFC (cada desvio de fluxo) seja exercitada pelo menos uma vez.
Todos-Caminhos (Critério de teste estrutural)	Requer que todos os caminhos possíveis do programa sejam executados.
Teste Funcional (Caixa preta)	Executado sobre as entradas e saídas do programa sem conhecimento do código-fonte. Pode detectar todos os defeitos submetendo o programa a todas as entradas possíveis (teste exaustivo). Inclui critérios como particionamento em classes de equivalência, análise do valor-limite e error-guessing.
Teste exaustivo	Submeter um programa a todas as possíveis entradas. Geralmente impraticável devido à cardinalidade do domínio de entrada.
Particionamento em classes de equivalência (Teste Funcional)	Técnica que divide o domínio de entrada de um programa em conjuntos disjuntos (classes de equivalência), com a suposição de que testar um elemento de um conjunto equivale a testar todos. Requer testar pelo menos um elemento de cada conjunto.
Análise do valor-limite (Teste Funcional)	Consiste em considerar valores fronteiriços com outras classes de equivalência para teste, não apenas um valor qualquer dentro de uma classe. Existem diretrizes para definir esses valores (ex: limites de intervalo, valores imediatamente subsequentes, quantidade de valores).
Error-guessing (Teste Funcional)	Critério de teste funcional baseado na intuição sobre onde os defeitos provavelmente ocorrem.
Teste baseado em defeitos	Técnica em que a fonte para definir os requisitos de teste é uma lista de defeitos conhecidos e suas causas. Inclui a análise de mutantes.
Análise de mutantes (Teste baseado em defeitos)	Critério que consiste em simular defeitos conhecidos no código-fonte, criando programas mutantes, e confrontá-los com o código original para revelar defeitos e avaliar a qualidade dos casos de teste.
Programa mutante (Análise de mutantes)	Um novo programa produzido pela aplicação de um operador de mutação no programa original.
Operadores de mutação (Análise de mutantes)	Regras ou padrões que simulam a forma como os programadores cometem erros. A escolha depende da linguagem de programação e dos tipos de defeitos a serem revelados. Ex: Eliminação de comandos, troca de operador relacional, troca de variáveis.

Conceito	Descrição
Cultura de desenvolvimento e operações (DevOps)	Refere-se à junção dos conceitos de desenvolvimento (Dev) e operações (Ops). É uma cultura que faz uso dos conceitos da engenharia de software (processos, testes, projeto, arquitetura, métodos ágeis) de forma colaborativa. Não é uma tecnologia específica, ferramenta ou automatização de processo. Abrange todo o ciclo de vida do desenvolvimento de software.
Desenvolvimento (Dev) (DevOps)	Uma das partes que compõem o termo DevOps. Refere-se à equipe de desenvolvimento.
Operações (Ops) (DevOps)	Uma das partes que compõem o termo DevOps. Refere-se à equipe de operações.
Integração Contínua	Prática na qual o código é compilado para cada mudança e executa testes automatizados minimamente confiáveis. Contrária aos métodos tradicionais que adiam a integração. O time integra o código pelo menos uma vez por dia em um único tronco. A segmentação de implementação é iniciada automaticamente a cada mudança.
Princípios da Integração Contínua (Fowler)	Onze princípios que visam tornar a integração contínua mais efetiva, como manter repositório único, automatizar versão, fazer autoteste, commit diário, centralizar commit, corrigir quebra de código imediatamente, manter construção rápida, testar em ambiente próximo à produção, obter executável mais recente, possibilitar visibilidade, automatizar implantação.
Arquitetura de referência DevOps	Apresenta a perspectiva dos principais recursos que o DevOps pretende fornecer.
Caminhos de adoção do DevOps	Quatro caminhos propostos: Conduzir (estabelecer objetivos de negócio e ajustar com feedback, inclui planejamento contínuo); Desenvolver/testar (duas práticas: desenvolvimento colaborativo e teste contínuo); Entregar (duas práticas: entrega contínua e implantação contínua); Operar (duas práticas: monitoramento contínuo e feedback contínuo).
Planejamento contínuo do negócio (DevOps - Conduzir)	Prática incluída no caminho Conduzir.
Desenvolvimento colaborativo (DevOps - Desenvolver/testar)	Permite que profissionais trabalhem juntos, fornecendo práticas e plataforma comuns; sua atividade central é a integração contínua.
Teste contínuo (DevOps - Desenvolver/testar)	Significa testar mais cedo e continuamente ao longo do ciclo.
Entrega contínua (DevOps - Entregar)	Prática incluída no caminho Entregar.
Implantação contínua (DevOps - Entregar)	Prática incluída no caminho Entregar.
Monitoramento contínuo (DevOps - Operar)	Prática incluída no caminho Operar.
Feedback contínuo (DevOps - Operar)	Prática incluída no caminho Operar.
Fontes de ineficiências na entrega de software	Categorias de ineficiências que o DevOps busca mitigar: supercarga desnecessária (comunicar várias vezes a mesma informação); retrabalho desnecessário (defeitos descobertos tardiamente); superprodução (funcionalidades desenvolvidas não requeridas).
Construir uma cultura DevOps	Requer que líderes trabalhem com equipes para criar ambiente de colaboração e compartilhamento, removendo barreiras à cooperação. Medições típicas que colocam Dev e Ops uns contra os outros devem ser substituídas por responsabilidade compartilhada. Práticas ágeis como Scrum estão no centro do DevOps.
Princípios básicos para implementar a cultura DevOps	Incluem: foco no que se deseja melhorar; estabelecer métricas para medir desempenho (somente é possível melhorar o que se pode medir); padronizar tarefas.
Planejamento de liberação (DevOps)	Função impulsionada pelas necessidades comerciais de oferecer recursos mais rápido; aproveita práticas ágeis para planejar prazos com mais frequência e focar na qualidade.
Mitos sobre DevOps	Crenças comuns e incorretas sobre o DevOps, como a de que é apenas para desenvolvedores e administradores de sistemas (quando na verdade abrange todas as funções da organização).

Esta página contém resumos dos principais conceitos da disciplina sistema gerenciador de banco de dados, extraídos de arquivos no formato PDF com a ferramenta NotebookLM.

De forma simples, enviei os arquivos para o NotebookLM e pedi os resumos com os seguintes comandos:

Organize uma tabela com os principais conceitos do texto. Na primeira coluna, o nome do conceito e na segunda, o conceito em si.

A partir do segundo pedido, usei o comando:

Repita o processo anterior para este texto.

No terceiro pedido, recebi a mensage de:

O comando fornecido solicita que o processo anterior seja repetido. No entanto, não há processo anterior no histórico de conversas fornecido. [Me] Para obter uma resposta abrangente, forneça o processo anterior que você gostaria que fosse repetido.

Desta forma, alternei entre o primeiro e segundo comando até o último arquivo, que veio com a formatação Markdown deformada. Então, pedi uma última revisão com o comando:

Refaça a tabela para uma melhor formatação em Markdown.

A publicação final continua uma exportação simples, do formato org mode para HTML, usando o Emacs.