Danilo.Eduardo (discussão | contribs)
Danilo.Eduardo (discussão | contribs)
Sem resumo de edição
Linha 41: Linha 41:


===3.1 Medição Baseada em Objetivos (GQM -  Goal/Question/Metric)===
===3.1 Medição Baseada em Objetivos (GQM -  Goal/Question/Metric)===
O campo de métricas de software foca na necessidade de medição baseada em objetivos para evitar o uso indevido de dados. Medição é o processo de atribuir números a atributos de entidades do mundo real de acordo com regras bem definidas. Os gestores usam métricas para prever custos, avaliar a produtividade da equipe e quantificar a qualidade do código.
O campo de métricas de software foca na necessidade de medição baseada em objetivos para evitar o uso indevido de dados. Medição é o processo de atribuir números a atributos de entidades do mundo real de acordo com regras bem definidas. Os gestores usam métricas para prever custos, avaliar a produtividade da equipe e quantificar a qualidade do código. Essa abordagem evita o mau uso de dados porque garante que as métricas sejam definidas com base em objetivos reais do projeto, impedindo que números sejam coletados sem propósito e evitando interpretações equivocadas.
Para garantir a relevância das métricas, os gestores devem usar o paradigma Goal/Question/Metric (GQM), que começa com um objetivo de negócio explícito, deriva questões e então identifica métricas quantificáveis para respondê-las [4].
Para garantir a relevância das métricas, os gestores devem usar o paradigma Goal/Question/Metric (GQM), que começa com um objetivo de negócio explícito, deriva questões e então identifica métricas quantificáveis para respondê-las [4].


Linha 50: Linha 50:
O valor das métricas é alcançado ao normalizar os dados por tamanho, seja através de medidas diretas como Lines of Code (LOC) ou indiretas como Function Points (FP). LOC e FP servem como variáveis de estimativa para modelos empíricos como COCOMO II (Constructive Cost Model). Outras métricas importantes incluem Métricas Orientadas a Objetos (como as do CK metrics suite, focadas em coesão e acoplamento de classes) e métricas específicas para WebApps [4].
O valor das métricas é alcançado ao normalizar os dados por tamanho, seja através de medidas diretas como Lines of Code (LOC) ou indiretas como Function Points (FP). LOC e FP servem como variáveis de estimativa para modelos empíricos como COCOMO II (Constructive Cost Model). Outras métricas importantes incluem Métricas Orientadas a Objetos (como as do CK metrics suite, focadas em coesão e acoplamento de classes) e métricas específicas para WebApps [4].
Por fim, o foco primordial da Gerência de Engenharia de Software é garantir a entrega de um produto de software que atenda aos requisitos do cliente dentro do prazo e do orçamento. Esta meta é intangível sem uma abordagem proativa e disciplinada. Com um processo disciplinado, comunicação efetiva e métricas bem aplicadas, a gerência transforma a incerteza do desenvolvimento de software em um empreendimento previsível, controlável e capaz de gerar valor real para clientes e organizações.
Por fim, o foco primordial da Gerência de Engenharia de Software é garantir a entrega de um produto de software que atenda aos requisitos do cliente dentro do prazo e do orçamento. Esta meta é intangível sem uma abordagem proativa e disciplinada. Com um processo disciplinado, comunicação efetiva e métricas bem aplicadas, a gerência transforma a incerteza do desenvolvimento de software em um empreendimento previsível, controlável e capaz de gerar valor real para clientes e organizações.
==Perguntas==
# Quais são os quatro pilares da Gerência de Engenharia de Software apresentados no texto? Por que o fator humano é considerado o mais crítico?
# Segundo o texto, o que caracteriza o "scope creep" e por que ele é prejudicial ao desenvolvimento de um projeto de software?
# De acordo com o paradigma Goal/Question/Metric (GQM), qual é a sequência correta para a definição de métricas e por que essa abordagem evita o mau uso de dados?


==Referências==
==Referências==

Edição das 21h17min de 7 de dezembro de 2025

Introdução

O foco da Gerência de Engenharia de Software e Organização (ESOF) gira em torno de processos, pessoas e ferramentas para criar software de alta qualidade de forma eficiente, abordando áreas como Gerenciamento de Configuração (controle de artefatos), Gerenciamento de Projetos (planejamento, custo, cronograma), Modelos de Ciclo de Vida (Espiral, Ágil, Cascata) e Metodologias (Scrum, Kanban, DevOps), buscando rastreabilidade, qualidade, risco e adaptação às necessidades do mercado [2].

Assim, a Gerência de Engenharia de Software abrange um conjunto de atividades vitais que garantem que os produtos de software sejam desenvolvidos de forma disciplinada, eficiente e com qualidade. Em vez de ser apenas uma atividade tática de cronograma e orçamento, a gestão de software é um esforço estratégico que equilibra as necessidades humanas, os requisitos do produto e a implementação de um processo rigoroso. O foco central da Gerência de Engenharia de Software reside, então, na coordenação eficaz dos quatro pilares do projeto – pessoas, produto, processo e projeto – enquanto se assegura o controle contínuo sobre a qualidade, o escopo e o risco através de medições sistemáticas [2].

1. Os 4 pilares da Gestão em Engenharia de Software: Pessoas, Produto, Processo e Projeto

A gestão eficaz de projetos de software começa pela compreensão da conexão entre os elementos fundamentais: as pessoas, o produto, processo e, por fim, o projeto.

1.1 Pessoas e Liderança (People)

O fator humano é reconhecido como o mais influente para a qualidade e o desempenho organizacional. O objetivo do gestor é fomentar uma equipe coesa. Líderes de projeto bem-sucedidos aplicam um estilo de liderança focado na Motivação, Organização e Ideias (MOI), concentrando-se na compreensão do problema e gerenciando o fluxo de ideias. Em ambientes modernos, a tendência é a formação de equipes ágeis e auto-organizáveis que possuem autonomia para tomar decisões [2]. A gestão de pessoas também implica gerenciar a comunicação e a coordenação, especialmente em projetos de grande escala ou com equipes distribuídas, utilizando canais de comunicação formais e informais [3].

1.2 Definição e Escopo do Produto (Product)

Antes de qualquer planejamento detalhado ou estimativa, o escopo do produto precisa ser estabelecido e delimitado. O escopo é definido por: Contexto (como o software se encaixa em um sistema maior), Objetivos da Informação (dados visíveis ao cliente) e Função e Desempenho (o que o sistema deve fazer e com que eficiência). A gestão inicia com a decomposição do problema, quebra as funções e conteúdos complexos em partes menores e mais gerenciáveis, o que é crucial para uma estimativa precisa [2].

1.3 Adaptação do Processo (Process)

O processo de software serve como o arcabouço para o planejamento e deve ser adaptado para se adequar às pessoas e ao produto. A Gerência de Engenharia de Software deve selecionar o modelo de processo mais apropriado (linear, incremental, evolucionário ou ágil) e, em seguida, definir um conjunto de tarefas (task set) adequado para cada fase do projeto [2].

1.4 Implementação do Projeto (Project)

O projeto é caracterizado como um esforço temporário realizado para criar um produto, serviço ou resultado único. Na Gerência de Engenharia de Software, o projeto representa um dos quatro pilares fundamentais da gestão – ao lado de pessoas, produto e processo – demandando planejamento, gerenciamento e controle. Como um empreendimento com uma natureza temporária (tendo um início e um fim), o projeto funciona dentro de um sistema maior de entrega de valor da organização e, por definição, atua como um agente de mudança, criando algo novo [2].

2. Controles Essenciais: Escopo, Risco e Qualidade

O foco na execução do projeto (Project) exige que o gestor estabeleça controles robustos para gerenciar o escopo, mitigar o risco e garantir a qualidade inerente ao produto. É fundamental que o escopo seja bem definido para evitar ambiguidades e "scope creep" (aumento descontrolado do escopo) [2]. A gestão de stakeholders envolve a comunicação proativa e o engajamento com todas as partes interessadas para manter o alinhamento e promover relacionamentos positivos, garantindo que as expectativas sejam gerenciadas de forma consistente [3].

2.1 Gestão de Riscos e Mudanças:

Em um projeto de software, o risco está sempre presente, caracterizado pela incerteza (pode ou não acontecer) e perda (consequências negativas se ocorrer). Uma estratégia de risco deve ser proativa – identificando riscos, avaliando sua probabilidade e impacto, e priorizando-os. Os riscos são classificados como projetais (ameaçam o cronograma e custo), técnicos (ameaçam a qualidade e a implementação) e de negócio (ameaçam a viabilidade do produto) [3]. A priorização é feita usando uma tabela de riscos, classificando-os por probabilidade e impacto. Riscos de alta probabilidade e alto impacto recebem maior atenção. A resposta mais importante é a mitigação (evitar o risco), seguida pelo monitoramento e gestão de contingência (RMMM Plan – Risk Mitigation, Monitoring and Management) [2]. A gestão de riscos está intimamente ligada à Gestão da Configuração de Software (SCM), que é a atividade responsável por gerenciar a mudança ao longo do ciclo de vida. A SCM envolve [1]:

  • Identificação de itens de configuração (SCIs) e suas versões.
  • Controle de Versão (version control) para gerenciar diferentes variantes.
  • Controle de Mudança (change control), um processo formal para avaliar e aprovar mudanças (ECOs).
  • Auditoria para garantir que as mudanças foram implementadas corretamente.

2.2 Garantia e Controle de Qualidade (SQA/QC)

A Gerência de Engenharia de Software deve garantir que os produtos de software sejam criados com a qualidade em mente. A qualidade do software é definida como: “um processo de software eficaz aplicado de maneira a criar um produto útil que forneça valor mensurável para aqueles que o produzem e aqueles que o usam” [3]. Os objetivos de qualidade (como correção, manutenibilidade, usabilidade e confiabilidade) são alcançados através de revisões técnicas (como filtro de erros antecipado) e testes. A medição da Defect Removal Efficiency (DRE) — a eficácia na filtragem de erros — é crucial para avaliar a maturidade do processo [2].

3. Medição: O Motor da Melhoria Contínua

“Não se gerencia o que não se mede” – William Edwards Deming. A Gerência de Engenharia de Software deve ser quantitativa para ser eficaz. O uso de métricas transforma a gestão de uma atividade subjetiva para uma atividade baseada em dados.

3.1 Medição Baseada em Objetivos (GQM - Goal/Question/Metric)

O campo de métricas de software foca na necessidade de medição baseada em objetivos para evitar o uso indevido de dados. Medição é o processo de atribuir números a atributos de entidades do mundo real de acordo com regras bem definidas. Os gestores usam métricas para prever custos, avaliar a produtividade da equipe e quantificar a qualidade do código. Essa abordagem evita o mau uso de dados porque garante que as métricas sejam definidas com base em objetivos reais do projeto, impedindo que números sejam coletados sem propósito e evitando interpretações equivocadas. Para garantir a relevância das métricas, os gestores devem usar o paradigma Goal/Question/Metric (GQM), que começa com um objetivo de negócio explícito, deriva questões e então identifica métricas quantificáveis para respondê-las [4].

3.2 Métricas de Processo e Produto

As métricas são aplicadas em dois domínios principais [4]:

  1. Métricas de Processo: Coletadas ao longo de muitos projetos e visam a melhoria estratégica de longo prazo do processo de desenvolvimento.
  2. Métricas de Projeto: Táticas e usadas para rastrear o status, identificar riscos e adaptar o fluxo de trabalho durante um projeto em andamento .

O valor das métricas é alcançado ao normalizar os dados por tamanho, seja através de medidas diretas como Lines of Code (LOC) ou indiretas como Function Points (FP). LOC e FP servem como variáveis de estimativa para modelos empíricos como COCOMO II (Constructive Cost Model). Outras métricas importantes incluem Métricas Orientadas a Objetos (como as do CK metrics suite, focadas em coesão e acoplamento de classes) e métricas específicas para WebApps [4]. Por fim, o foco primordial da Gerência de Engenharia de Software é garantir a entrega de um produto de software que atenda aos requisitos do cliente dentro do prazo e do orçamento. Esta meta é intangível sem uma abordagem proativa e disciplinada. Com um processo disciplinado, comunicação efetiva e métricas bem aplicadas, a gerência transforma a incerteza do desenvolvimento de software em um empreendimento previsível, controlável e capaz de gerar valor real para clientes e organizações.


Perguntas

  1. Quais são os quatro pilares da Gerência de Engenharia de Software apresentados no texto? Por que o fator humano é considerado o mais crítico?
  1. Segundo o texto, o que caracteriza o "scope creep" e por que ele é prejudicial ao desenvolvimento de um projeto de software?
  1. De acordo com o paradigma Goal/Question/Metric (GQM), qual é a sequência correta para a definição de métricas e por que essa abordagem evita o mau uso de dados?

Referências

[1]

@BOOK {iansommerville2011,

   author    = "Ian Sommerville",
   title     = "Engenharia de Software",
   publisher = "Pearson Education do Brasil",
   year      = "2011",
   address   = "Rua Nelson Francisco, 26, CEP 02712-100, São Paulo - SP, Brasil",
   edition   = "ninth"

}


[2]

@BOOK {rogers.pressman2010,

   author    = "Roger S. Pressman",
   title     = "Software Engineering - A Practitioner's Approach",
   publisher = "McGraw-Hill",
   year      = "2010",
   edition   = "seventh"

}

[3]

@BOOK {projectmanagementinstitute2021,

   author    = "Project Management Institute",
   title     = "Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK)",
   publisher = "Project Management Institute, Inc",
   year      = "2021",
   address   = "14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 USA",
   edition   = "seventh"

}

[4]

@BOOK {normanfentonjamesbieman2015,

   author    = "Norman Fenton, James Bieman",
   title     = "Software Metrics",
   publisher = "CRC Press",
   year      = "2015",
   address   = "6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742",
   edition   = "third"

}