Computer Science › Software + Computação Distribuída
A decisão de escopo real e citável desta disciplina repousa sobre as próprias dezoito áreas de conhecimento do SWEBOK v4.0: `software-construction` já cobre por completo Design, Construção e Teste de Software (o nível unitário de construir software), e esta disciplina cobre o que o SWEBOK trata como conhecimento separado inteiramente, Requisitos, Processo, Gestão e a recém-adicionada Operações de Engenharia de Software, encerrando com um conceito de Economia de Engenharia de Software.
O próprio relatório de experiência de 1992 de Ward Cunningham, sobre um sistema real que ele estava construindo (WyCash), cunhou a metáfora da dívida técnica com uma estrutura econômica real e precisa: um principal (o atalho tomado), uma taxa de juros (o custo contínuo e recorrente de conviver com ele, que genuinamente se compõe quanto mais tempo permanece não pago) e um mecanismo de quitação, uma reescrita deliberada, que a refatoração é a versão concreta e formalizada de.
A Integração Contínua, pela própria definição precisa de Martin Fowler (creditada honestamente ao Extreme Programming de Kent Beck), significa que todo membro da equipe mescla mudanças numa linha principal compartilhada pelo menos diariamente, e todo merge dispara um build automatizado que testa a si mesmo feito para detectar erros de integração tão rápido quanto possível; as suas onze práticas concretas todas defendem uma propriedade: feedback rápido e confiável sobre se a linha principal ainda funciona.
A distinção precisa de Fowler é exata: Entrega Contínua significa que toda mudança na linha principal é comprovada pronta para lançamento pelo pipeline, mas um humano ainda decide quando de fato lançar; a Implantação Contínua remove essa decisão inteiramente, lançando toda mudança verificada automaticamente, e estritamente exige a Entrega Contínua como a sua fundação.
Um pipeline de CI/CD real é uma sequência estrita de estágios com portões, build, teste automatizado, empacotar, implantar, ordenada deliberadamente para que cada estágio pegue a classe mais barata de problema que consegue pegar antes de estágios mais caros rodarem; o estágio de empacotar numa imagem de contêiner é o que torna o artefato testado e o artefato implantado comprovadamente idênticos.
A implantação blue-green mantém dois ambientes de produção completos e troca todo o tráfego entre eles num único cutover instantâneo, comprando rollback instantâneo e limpo; o lançamento canary em vez disso roteia uma fatia pequena e crescente de tráfego real para a nova versão primeiro, comprando detecção mais cedo de falhas que só se manifestam sob condições de produção reais; nenhuma estratégia é universalmente superior.
A escrita de profissional de Cindy Sridharan popularizou o enquadramento agora padrão da observabilidade como três tipos de dados complementares: logs (eventos discretos e com timestamp carregando detalhe), métricas (medições numéricas agregadas revelando tendências e limiares de forma barata) e traces (o caminho causal de uma requisição por todo serviço que ela tocou); os três trabalham juntos numa ordem natural durante um incidente real.
O modelo waterfall organiza um projeto numa sequência estrita e de mão única de fases, sem nenhum mecanismo projetado para revisitar uma fase anterior uma vez fechada; o artigo de 1970 de Winston Royce é a fonte citada para este diagrama, e, lido por completo, esse mesmo artigo chama a versão estrita de arriscada e recomenda a iteração que o modelo como comumente praticado carece, uma ironia histórica genuína.
A Gestão de Engenharia de Software trata estimativa e risco como duas visões da mesma disciplina subjacente: representar incógnitas genuínas honestamente em vez de escondê-las dentro de um plano falsamente confiante; uma estimativa real é uma distribuição de probabilidade, não um único número, e um registro de riscos rastreia um tipo genuinamente diferente de incógnita, eventos específicos e identificáveis, cada um com uma probabilidade, um impacto e um dono nomeado.
O Método Kanban substitui o timebox fixo do Sprint do Scrum por um sistema de puxar contínuo: o trabalho se move por estágios nomeados, e um limite explícito de trabalho-em-progresso (WIP) em cada estágio é o mecanismo de fato que faz surgir um gargalo, forçando uma decisão visível no momento em que um estágio enche; o seu trade-off contra o Scrum é genuíno e simétrico.
O Scrum, como definido pelo seu próprio guia oficial, prescreve exatamente três responsabilidades (Developers, Product Owner, Scrum Master), cinco eventos (o próprio Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e três artefatos (Product Backlog, Sprint Backlog, Increment); o Sprint como um timebox fixo é um trade-off genuíno e deliberado: cadência previsível de planejamento e revisão, ao custo de adiar trabalho recém-descoberto para o próximo Sprint.
As práticas concretas do XP (pair programming, test-first, integração contínua, refactoring e small releases) vistas como um conjunto que se reforça mutuamente, com a evidência real sobre pair programming e uma avaliação honesta de quais práticas viraram prática comum.
Os princípios Lean aplicados a software pelos Poppendiecks (eliminar desperdício, adiar compromissos até o último momento responsável e enxergar o todo), com fluxo, filas e a relação com o Kanban, o XP e o Scrum.
A engenharia de requisitos é três atividades distintas, não uma: a elicitação descobre o que os stakeholders de fato precisam, a especificação escreve essa necessidade de forma precisa o bastante para que dois engenheiros construam a mesma coisa a partir dela, e a validação checa a especificação escrita contra a necessidade real antes de a implementação começar, frequentemente devolvendo o processo à elicitação quando encontra uma incompatibilidade.
User stories e seus critérios de aceitação, a divisão de epics em fatias verticais e a ordenação de um product backlog, como a contrapartida ágil de uma especificação de requisitos, com o que o Scrum Guide define e o que não define.
Velocity, burndown e burnup: como ler esses gráficos, o que eles permitem prever (com intervalos, não com um número único) e por que a velocity não é uma medida de produtividade, com o que o Scrum Guide de fato diz sobre eles.
O achado real e historicamente fundamentado de Barry Boehm, tirado de dados reais de custo na TRW, IBM, GTE e no programa Safeguard da Bell Labs, é que o custo de consertar um defeito sobe significativamente, aproximadamente por uma ordem de magnitude, a cada fase posterior em que é pego; a popularizada regra 1:10:100 simplifica demais uma faixa real e honesta num único número que os próprios dados de Boehm nunca reivindicaram como uma lei fixa.
Um requisito funcional enuncia um comportamento específico dado uma entrada específica, e é verificado exercitando-o e checando a saída; um requisito não funcional em vez disso restringe um atributo de qualidade (desempenho, confiabilidade, segurança, manutenibilidade) por entre muitas ocorrências ou sob condições realistas, verificado como uma distribuição medida; os dois falham de forma diferente em produção.
Por que as equipes modelam, UML como rascunho versus planta de construção, e quais diagramas ainda são desenhados na prática: um modelo é uma simplificação com propósito, mais barata de mudar que o sistema, e no estudo de Petre (2013) a maioria dos 50 desenvolvedores não usava UML, enquanto os que a usavam de forma seletiva preferiam poucos tipos de diagrama.
Classes, atributos, operações, associações, multiplicidade, agregação, composição e herança, com os diagramas de objetos como retratos concretos: o losango vazio e o cheio dizem coisas diferentes, e uma multiplicidade ausente significa que o diagrama não afirma nada.
Atores, diagramas de casos de uso, include e extend, e como escrever uma descrição de caso de uso com fluxo principal e alternativos: o diagrama é só um índice de objetivos, e os requisitos moram no texto.
Linhas de vida, mensagens síncronas e assíncronas, ativações e fragmentos combinados (alt, opt, loop, par), para ler e desenhar uma interação ao longo do tempo.
Eventos, atividades, gateways e raias (swimlanes) do BPMN, e como modelar um processo de negócio que atravessa vários papéis.
O modelo de qualidade de produto da ISO/IEC 25010:2023, com suas nove características, o que a revisão de 2023 mudou em relação a 2011 (inclusive a saída do modelo de qualidade em uso) e como uma característica de qualidade vira um requisito mensurável.
Uma história curta do CMM e do CMMI: por que surgiram, o que os cinco níveis de maturidade diziam (e o que não diziam), quem é dono do CMMI hoje e o que a prática da indústria acrescentou. Tratado como livro versus hoje, nunca como prática atual.
Densidade de defeitos, churn, complexidade ciclomática, cobertura e as cinco métricas de entrega do DORA: o que cada uma pode e não pode dizer, com cálculos resolvidos para densidade, complexidade e métricas do DORA, e por que qualquer uma delas se degrada quando vira meta (a lei de Goodhart, citada com precisão).
Um requisito não funcional, não a preferência ou a tendência, é o que deveria de fato forçar uma escolha entre opções de arquitetura, e um Architecture Decision Record (ADR) torna essa escolha rastreável: o requisito que a dirigiu, as opções reais consideradas, a opção escolhida e o trade-off honestamente aceito; este conceito é deliberadamente a ponte, não um reensino, cruzando com vocabulário introdutório, primitivos teóricos e padrões aplicados.
Este capstone rastreia um requisito (um recurso de pagamento recorrente com uma restrição de disponibilidade real) por cada estágio que esta disciplina cobre: elicitação, análise não funcional, decisão de arquitetura, handoff para a construção, pipeline de CI/CD, implantação, observabilidade em produção e registro de dívida técnica, encerrando com uma decisão deliberada e registrada em vez de um conserto automático.
A gestão de requisitos rastreia duas coisas pela vida inteira de um projeto, não só no seu início: um vínculo de rastreabilidade bidirecional de cada requisito às decisões de design, código e testes que o satisfazem (para frente, para avaliar o impacto de uma mudança; para trás, para pegar escopo que nunca foi uma necessidade validada), e um processo de controle de mudança que avalia uma mudança proposta contra o seu impacto rastreado antes de decidir aceitar, adiar ou rejeitar.
Part of the Computer Science curriculum.
A decisão de escopo real e citável desta disciplina repousa sobre as próprias dezoito áreas de conhecimento do SWEBOK v4.0: `software-construction` já cobre por completo Design, Construção e Teste de Software (o nível unitário de construir software), e esta disciplina cobre o que o SWEBOK trata como conhecimento separado inteiramente, Requisitos, Processo, Gestão e a recém-adicionada Operações de Engenharia de Software, encerrando com um conceito de Economia de Engenharia de Software.
O próprio relatório de experiência de 1992 de Ward Cunningham, sobre um sistema real que ele estava construindo (WyCash), cunhou a metáfora da dívida técnica com uma estrutura econômica real e precisa: um principal (o atalho tomado), uma taxa de juros (o custo contínuo e recorrente de conviver com ele, que genuinamente se compõe quanto mais tempo permanece não pago) e um mecanismo de quitação, uma reescrita deliberada, que a refatoração é a versão concreta e formalizada de.
A Integração Contínua, pela própria definição precisa de Martin Fowler (creditada honestamente ao Extreme Programming de Kent Beck), significa que todo membro da equipe mescla mudanças numa linha principal compartilhada pelo menos diariamente, e todo merge dispara um build automatizado que testa a si mesmo feito para detectar erros de integração tão rápido quanto possível; as suas onze práticas concretas todas defendem uma propriedade: feedback rápido e confiável sobre se a linha principal ainda funciona.
A distinção precisa de Fowler é exata: Entrega Contínua significa que toda mudança na linha principal é comprovada pronta para lançamento pelo pipeline, mas um humano ainda decide quando de fato lançar; a Implantação Contínua remove essa decisão inteiramente, lançando toda mudança verificada automaticamente, e estritamente exige a Entrega Contínua como a sua fundação.
Um pipeline de CI/CD real é uma sequência estrita de estágios com portões, build, teste automatizado, empacotar, implantar, ordenada deliberadamente para que cada estágio pegue a classe mais barata de problema que consegue pegar antes de estágios mais caros rodarem; o estágio de empacotar numa imagem de contêiner é o que torna o artefato testado e o artefato implantado comprovadamente idênticos.
A implantação blue-green mantém dois ambientes de produção completos e troca todo o tráfego entre eles num único cutover instantâneo, comprando rollback instantâneo e limpo; o lançamento canary em vez disso roteia uma fatia pequena e crescente de tráfego real para a nova versão primeiro, comprando detecção mais cedo de falhas que só se manifestam sob condições de produção reais; nenhuma estratégia é universalmente superior.
A escrita de profissional de Cindy Sridharan popularizou o enquadramento agora padrão da observabilidade como três tipos de dados complementares: logs (eventos discretos e com timestamp carregando detalhe), métricas (medições numéricas agregadas revelando tendências e limiares de forma barata) e traces (o caminho causal de uma requisição por todo serviço que ela tocou); os três trabalham juntos numa ordem natural durante um incidente real.
O modelo waterfall organiza um projeto numa sequência estrita e de mão única de fases, sem nenhum mecanismo projetado para revisitar uma fase anterior uma vez fechada; o artigo de 1970 de Winston Royce é a fonte citada para este diagrama, e, lido por completo, esse mesmo artigo chama a versão estrita de arriscada e recomenda a iteração que o modelo como comumente praticado carece, uma ironia histórica genuína.
A Gestão de Engenharia de Software trata estimativa e risco como duas visões da mesma disciplina subjacente: representar incógnitas genuínas honestamente em vez de escondê-las dentro de um plano falsamente confiante; uma estimativa real é uma distribuição de probabilidade, não um único número, e um registro de riscos rastreia um tipo genuinamente diferente de incógnita, eventos específicos e identificáveis, cada um com uma probabilidade, um impacto e um dono nomeado.
O Método Kanban substitui o timebox fixo do Sprint do Scrum por um sistema de puxar contínuo: o trabalho se move por estágios nomeados, e um limite explícito de trabalho-em-progresso (WIP) em cada estágio é o mecanismo de fato que faz surgir um gargalo, forçando uma decisão visível no momento em que um estágio enche; o seu trade-off contra o Scrum é genuíno e simétrico.
O Scrum, como definido pelo seu próprio guia oficial, prescreve exatamente três responsabilidades (Developers, Product Owner, Scrum Master), cinco eventos (o próprio Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e três artefatos (Product Backlog, Sprint Backlog, Increment); o Sprint como um timebox fixo é um trade-off genuíno e deliberado: cadência previsível de planejamento e revisão, ao custo de adiar trabalho recém-descoberto para o próximo Sprint.
As práticas concretas do XP (pair programming, test-first, integração contínua, refactoring e small releases) vistas como um conjunto que se reforça mutuamente, com a evidência real sobre pair programming e uma avaliação honesta de quais práticas viraram prática comum.
Os princípios Lean aplicados a software pelos Poppendiecks (eliminar desperdício, adiar compromissos até o último momento responsável e enxergar o todo), com fluxo, filas e a relação com o Kanban, o XP e o Scrum.
A engenharia de requisitos é três atividades distintas, não uma: a elicitação descobre o que os stakeholders de fato precisam, a especificação escreve essa necessidade de forma precisa o bastante para que dois engenheiros construam a mesma coisa a partir dela, e a validação checa a especificação escrita contra a necessidade real antes de a implementação começar, frequentemente devolvendo o processo à elicitação quando encontra uma incompatibilidade.
User stories e seus critérios de aceitação, a divisão de epics em fatias verticais e a ordenação de um product backlog, como a contrapartida ágil de uma especificação de requisitos, com o que o Scrum Guide define e o que não define.
Velocity, burndown e burnup: como ler esses gráficos, o que eles permitem prever (com intervalos, não com um número único) e por que a velocity não é uma medida de produtividade, com o que o Scrum Guide de fato diz sobre eles.
O achado real e historicamente fundamentado de Barry Boehm, tirado de dados reais de custo na TRW, IBM, GTE e no programa Safeguard da Bell Labs, é que o custo de consertar um defeito sobe significativamente, aproximadamente por uma ordem de magnitude, a cada fase posterior em que é pego; a popularizada regra 1:10:100 simplifica demais uma faixa real e honesta num único número que os próprios dados de Boehm nunca reivindicaram como uma lei fixa.
Um requisito funcional enuncia um comportamento específico dado uma entrada específica, e é verificado exercitando-o e checando a saída; um requisito não funcional em vez disso restringe um atributo de qualidade (desempenho, confiabilidade, segurança, manutenibilidade) por entre muitas ocorrências ou sob condições realistas, verificado como uma distribuição medida; os dois falham de forma diferente em produção.
Por que as equipes modelam, UML como rascunho versus planta de construção, e quais diagramas ainda são desenhados na prática: um modelo é uma simplificação com propósito, mais barata de mudar que o sistema, e no estudo de Petre (2013) a maioria dos 50 desenvolvedores não usava UML, enquanto os que a usavam de forma seletiva preferiam poucos tipos de diagrama.
Classes, atributos, operações, associações, multiplicidade, agregação, composição e herança, com os diagramas de objetos como retratos concretos: o losango vazio e o cheio dizem coisas diferentes, e uma multiplicidade ausente significa que o diagrama não afirma nada.
Atores, diagramas de casos de uso, include e extend, e como escrever uma descrição de caso de uso com fluxo principal e alternativos: o diagrama é só um índice de objetivos, e os requisitos moram no texto.
Linhas de vida, mensagens síncronas e assíncronas, ativações e fragmentos combinados (alt, opt, loop, par), para ler e desenhar uma interação ao longo do tempo.
Eventos, atividades, gateways e raias (swimlanes) do BPMN, e como modelar um processo de negócio que atravessa vários papéis.
O modelo de qualidade de produto da ISO/IEC 25010:2023, com suas nove características, o que a revisão de 2023 mudou em relação a 2011 (inclusive a saída do modelo de qualidade em uso) e como uma característica de qualidade vira um requisito mensurável.
Uma história curta do CMM e do CMMI: por que surgiram, o que os cinco níveis de maturidade diziam (e o que não diziam), quem é dono do CMMI hoje e o que a prática da indústria acrescentou. Tratado como livro versus hoje, nunca como prática atual.
Densidade de defeitos, churn, complexidade ciclomática, cobertura e as cinco métricas de entrega do DORA: o que cada uma pode e não pode dizer, com cálculos resolvidos para densidade, complexidade e métricas do DORA, e por que qualquer uma delas se degrada quando vira meta (a lei de Goodhart, citada com precisão).
Um requisito não funcional, não a preferência ou a tendência, é o que deveria de fato forçar uma escolha entre opções de arquitetura, e um Architecture Decision Record (ADR) torna essa escolha rastreável: o requisito que a dirigiu, as opções reais consideradas, a opção escolhida e o trade-off honestamente aceito; este conceito é deliberadamente a ponte, não um reensino, cruzando com vocabulário introdutório, primitivos teóricos e padrões aplicados.
Este capstone rastreia um requisito (um recurso de pagamento recorrente com uma restrição de disponibilidade real) por cada estágio que esta disciplina cobre: elicitação, análise não funcional, decisão de arquitetura, handoff para a construção, pipeline de CI/CD, implantação, observabilidade em produção e registro de dívida técnica, encerrando com uma decisão deliberada e registrada em vez de um conserto automático.
A gestão de requisitos rastreia duas coisas pela vida inteira de um projeto, não só no seu início: um vínculo de rastreabilidade bidirecional de cada requisito às decisões de design, código e testes que o satisfazem (para frente, para avaliar o impacto de uma mudança; para trás, para pegar escopo que nunca foi uma necessidade validada), e um processo de controle de mudança que avalia uma mudança proposta contra o seu impacto rastreado antes de decidir aceitar, adiar ou rejeitar.