Tradução do Swebok v 3

Prévia do material em texto

Tradução do Swebok v 3.0 
Guia para o corpo de conhecimento da Engenharia de software. 
Acrônimos: 
BPMN ->Notação de Modelagem de Processos de Negócios; 
CASE -> Engenharia de Software Assistido por Computador; 
CM -> Gerenciamento de Configurações; 
CMMI-> Integração de Modelo de Maturidade Capacitiva; 
GQM -> Objetivo-Pergunta-Métrica; 
IDEF0 -> Definição de Integração; 
LOE -> Nível de Esforço; 
ODC -> Classificação de Defeito Ortogonal; 
SDLC -> Ciclo de Vida de Engenharia de Software; 
SPLC -> Ciclo de Vida do Produto de Software; 
UML -> Linguagem de Modelagem Unificada. 
Introdução. 
Um processo de engenharia consiste em um conjunto de atividades inter-relacionadas que 
transformam uma ou mais entradas em saídas enquanto consome recursos para realizar a 
transformação. Muitos dos processos de disciplinas tradicionais de engenharia (por exemplo, 
elétrica, mecânica, civil e química) estão preocupados transformando energia e entidades físicas 
de uma forma em outra, como em uma barragem hidrelétrica que transforma energia potencial 
em energia elétrica ou uma refinaria de petróleo que usa processos químicos para transformar 
petróleo bruto em gasolina. Nesta área de conhecimento (KA), engenharia de software, os 
processos estão preocupados com atividades de trabalho realizados por engenheiros de 
software para desenvolver, manter e operar softwares, como requisitos, projeto, construção, 
teste, gerenciamento de configuração e outros processos de engenharia de software. Para 
facilitar a leitura, “processo de engenharia de software” será referido como “processo de 
software” neste KA. Além disso, observe que “processo de software” denota atividades de 
trabalho - não a processo de execução para software implementado. 
Os processos de software são especificados por um número de razões: para facilitar a 
compreensão humana, comunicação e coordenação; para ajudar na gestão de projetos de 
software; medir e melhorar a qualidade dos produtos de software de uma maneira eficiente; 
para apoiar a melhoria de processos; para fornecer uma base para suporte automatizado de 
execução do processo. 
O SWEBOK Kas está intimamente relacionado com este software KA de processo de engenharia 
que inclui: Software de Gestão de Engenharia, Modelos de Engenharia de Software e Métodos 
e Qualidade de Software. O tópico Medição e Análise de causa raiz encontrado nas Fundações 
de Engenharia KA também é relacionado. A Gestão de Engenharia de Software está ligada com 
alfaiataria, adaptação e implementação de processos para um projeto de software específico 
(Planejamento no Gerenciamento de Processos de Engenharia de Software(KA). Modelos e os 
métodos apoiam uma abordagem sistemática para desenvolvimento e modificação de software. 
O KA de Qualidade de Software se preocupa com os processos de planejamento, garantia e 
controle para projetos e qualidade do produto. Medição e resultados de medições nas 
Fundações de Engenharia KA são essenciais para avaliar e controlar os processos de software. 
Dissolução de tópicos para processos de engenharia de software. 
Conforme ilustrado na Figura 8.1, este KA está relacionado com a definição de processos de 
software, ciclos de vida de software, avaliação e melhoria do processo de software, medição de 
software e ferramentas de processos de engenharia de software. 
 
Figure 8.1. Repartição de tópicos para KA de processo de engenharia de software 
1 – Definição de Processo de Software. 
[1*, p177] [2*, p295] [3*, p28–29, p36, c5] 
Este tópico trata de uma definição de processo de software, gerenciamento de processo de 
software e infraestrutura de processo de software. 
Como dito acima, um processo de software é um conjunto de atividades e tarefas inter-
relacionadas que transformam produtos de trabalho de entrada em produtos de trabalho de 
saída. No mínimo, a descrição de um processo de software inclui entradas necessárias, trabalho 
de transformação de atividades e resultados gerados. Conforme ilustrado na Figura 8.2, um 
processo de software também pode incluir seus critérios de entrada e saída e decomposição das 
atividades de trabalho em tarefas, que são as menores unidades de trabalho sujeitas à gestão 
de prestação de contas. Uma entrada de processo pode ser um evento gatilho ou a saída de 
outro processo. Entrada de critérios devem ser satisfeitas antes que um processo possa 
começar. Todas as condições especificadas devem ser satisfeitas antes que um processo possa 
ser concluído e bem sucedido, incluindo os critérios de aceitação para o produto de trabalho de 
saída ou produtos de trabalho. 
Um processo de software pode incluir subprocessos. Por exemplo, a validação de requisitos de 
software é um processo usado para determinar se os requisitos fornecerão uma base adequada 
para o desenvolvimento de software então é um subprocesso do processo de requisitos de 
software. Entradas para validação de requisitos são normalmente uma especificação de 
requisitos de software e os recursos necessários para realizar a validação (pessoal, ferramentas 
de validação, tempo suficiente). As tarefas da atividade de validação de requisitos podem incluir 
análises de requisitos, prototipagem, e validação do modelo. Essas tarefas envolvem atribuições 
de trabalho para indivíduos e equipes. A saída de validação de requisitos é normalmente uma 
especificação de requisitos de software validada que fornece entradas para o design e teste de 
processos de software. Validação de requisitos e outros subprocessos do processo de requisitos 
de software são frequentemente intercalados e iterados de várias maneiras. 
 
Figure 8.2. Elementos de um Processo de Software 
O processo de requisitos de software e seus subprocessos podem ser inseridos e encerrados 
várias vezes durante o desenvolvimento ou modificação do software. A definição completa de 
um processo de software pode também incluir as funções e competências, suporte de TI, 
técnicas e ferramentas de engenharia de software, e ambiente de trabalho necessário para 
realizar o processo, bem como as abordagens e medidas (Indicadores-chave de desempenho) 
usados para determinar a eficiência e eficácia de realizar o processo. 
Além disso, um processo de software pode incluir intercaladas atividades técnicas, colaborativas 
e administrativas. 
Notações para definir processos de software incluem listas textuais de atividades constituintes 
e tarefas descritas em linguagem natural; fluxo de dados e diagramas; gráficos de estado; BPMN; 
IDEF0; Redes de Petri; e diagramas de atividades UML. A transformação das tarefas dentro de 
um processo pode ser definida como procedimentos; um procedimento pode ser especificado 
como um pedido de conjunto de etapas ou alternativamente, como uma lista de verificação do 
trabalho a ser realizado na execução de uma tarefa. 
Deve ser enfatizado que não existe o melhor processo de software ou conjunto de processos de 
software. Programas e processos devem ser selecionados, adaptados e aplicados conforme seja 
apropriado para cada projeto e cada contexto organizacional. Nenhum processo ideal, ou 
conjunto de processos, existe. 
1.1. Gerenciamento de processos de software 
[3 *, s26.1] [4 *, p453-454] 
Dois objetivos do gerenciamento de processos de software são perceber a eficiência e eficácia 
que o resultado de uma abordagem sistemática tem para realizar processos de software e 
produção de produtos de trabalho - seja no indivíduo, projeto ou nível de organização - e para 
introduzir novos ou melhorados processos. 
Os processos são alterados com a expectativa de que um processo novo ou modificado melhore 
a eficiência e / ou eficácia do processo e a qualidade dos produtos de trabalho resultantes. 
Mudando para um novo processo, melhorando um processo existente, a mudança 
organizacional e mudança de infraestrutura (inserção de tecnologia ou mudanças nas 
ferramentas) são intimamente relacionadas, já quetodos são geralmente iniciados com o 
objetivo de melhorar o custo, cronograma de desenvolvimento, ou qualidade dos produtos de 
software. Esse processo de mudança tem impactos não apenas para o software produtos, 
muitas vezes levam a mudanças organizacionais. Mudar um processo ou introduzir um novo 
processo pode ter um efeito cascata em toda a organização. Por exemplo, mudanças na 
infraestrutura de TI ferramentas e tecnologia frequentemente requerem alterar processos. 
Os processos existentes podem ser modificados quando outros novos processos são 
implantados para o primeiro tempo (por exemplo, a introdução de uma inspeção atividade 
dentro de um projeto de desenvolvimento de software provavelmente impactará o processo de 
teste de software — veja Revisões e Auditorias na Qualidade do Software KA e no Software 
Testing KA). Essas situações também pode ser denominadas "evolução do processo". Se as 
modificações forem extensas, então as mudanças na cultura organizacional e no modelo de 
negócios provavelmente será necessária para acomodar o processo alteraração. 
1.2. Infraestrutura de processo de software 
[2 *, p183, p186] [4 *, p437-438] 
Estabelecer, implementar e gerenciar processos de software e modelos de ciclo de vida de 
software frequentemente ocorrem no nível de projetos de software individual. No entanto, a 
aplicação sistemática de processos de software e modelos de ciclo de vida de software em uma 
organização podem fornecer benefícios a todo o trabalho de software dentro da organização, 
embora exija comprometimento no nível organizacional. Uma infraestrutura de processos de 
software pode fornecer definições de processo, políticas para interpretação e aplicação de 
processos e descrições dos procedimentos a serem usados para implementar os processos. Além 
disso, um processo de infraestrutura de software pode fornecer financiamento, ferramentas, 
treinamento, e membros da equipe que foram designados as responsabilidades para 
estabelecer e manter a infraestrutura de processo de software. 
A infraestrutura de processo de software varia, dependendo no tamanho e complexidade da 
organização e os projetos realizados dentro da organização. Organizações e projetos pequenos 
e simples têm necessidades de infraestrutura pequenas e simples. Amplas organizações e 
projetos complexos, por necessidade, tem software maior e mais complexas infraestruturas de 
processos. No último caso, várias unidades organizacionais podem ser estabelecidas (como um 
grupo de processo de engenharia de software ou uma direção comitê) para supervisionar a 
implementação e melhoria dos processos de software. 
Um equívoco comum é estabelecer uma infraestrutura de processo de software e 
implementação de processos de software repetitivos que irão adicionar tempo, custo de 
desenvolvimento e manutenção de software. Há um custo associado à introdução ou melhorar 
um processo de software, no entanto a experiência mostrou que a implementação sistemática 
e a melhoria dos processos de software tendem a resultar em custos mais baixos por meio de 
eficiência aprimorada, prevenção de retrabalho e programas mais confiáveis e acessíveis. O 
desempenho do processo, portanto, influencia qualidade do produto de software. 
2. Ciclos de vida do software 
[1 *, c2] [2 *, p190] 
Este tópico aborda categorias de processos de software, modelos de ciclo de vida de software, 
software, adaptação do processo e considerações práticas. Um ciclo de vida do produto de 
software (SDLC) inclui os processos de software usados para especificar e transformar os 
requisitos de software em um produto de software. O ciclo de vida do produto de software 
(SPLC) inclui um desenvolvimento de ciclo de vida de software mais processos de software 
adicionais que fornecem implantação, manutenção, suporte, evolução, aposentadoria e todos 
os outros inception to- processos de aposentadoria de um produto de software, incluindo o 
gerenciamento de configuração de software e processos de garantia de qualidade de software 
que são aplicados ao longo do ciclo de vida de um produto de software. O ciclo de vida de um 
produto de software pode incluir vários ciclos de vida de desenvolvimento de software para 
evolução e aprimoramento do software. Os processos de software individuais não têm 
ordenamento entre eles. As relações temporais entre os processos de software são fornecidas 
por um modelo de ciclo de vida de software: um SDLC ou SPLC. Modelos de ciclo de vida 
normalmente enfatizam os principais processos de software dentro do modelo e suas 
interdependências temporais, lógicas e relacionamentos. Definições detalhadas dos processos 
de software em um modelo de ciclo de vida podem ser fornecidos diretamente ou por 
referência a outros documentos. Além de transmitir o temporal e relacionamentos lógicos 
entre os processos de software, o modelo de ciclo de vida de desenvolvimento de software (ou 
modelos usados dentro de uma organização) incluem os mecanismos de controle para 
aplicação de critérios de entrada e saída (por exemplo, análises de projetos, aprovações de 
clientes, teste de software, limites de qualidade, demonstrações, consenso da equipe). A saída 
de um processo de software muitas vezes fornece a entrada para outros (por exemplo, os 
requisitos de software fornecem informações para um processo de design de arquitetura de 
software e os processos de construção e teste de software). Execução simultânea de várias 
atividades de processo de software pode produzir uma saída compartilhada (por exemplo, as 
especificações de interface para interfaces entre vários componentes de software 
desenvolvidos por equipes diferentes). Alguns processos de software podem ser considerados 
menos eficazes, a menos que outros processos de software estejam sendo executados ao 
mesmo tempo (por exemplo, planejamento de teste de software durante a análise de 
requisitos de software pode melhorar os requisitos de software). 
 
2.1. Categorias de processos de software 
[1 *, Prefácio] [2 *, p294–295] [3 *, c22 – c24] 
Muitos processos de software distintos foram definidos para uso nas várias partes dos ciclos de 
vida de desenvolvimento e manutenção de software. Esses processos podem ser categorizados 
como: 
1. Os processos primários incluem processos de software para desenvolvimento, operação e 
manutenção de software. 
2. Os processos de apoio são aplicados de forma intermitente ou continuamente ao longo de 
um software ciclo de vida do produto para apoiar os processos primários, eles incluem processos 
de software como gerenciamento de configuração, garantia de qualidade, verificação e 
validação. 
3. Os processos organizacionais fornecem suporte para engenharia de software, eles incluem 
treinamento, análise de medição de processo, gestão de infraestrutura, portfólio e gestão de 
reutilização, processo organizacional melhoria e gestão de modelos de ciclos de vida de 
software. 
4. Processos de projetos cruzados, como reutilização, software linha de produtos e engenharia 
de domínio, eles envolvem mais do que um único software projeto em uma organização. 
Processos de software além daqueles listados acima incluem os seguintes. Os processos de 
gerenciamento de projetos incluem processos para planejamento e estimativa, recursos de 
gestão, medição e controle, liderança, gerenciamento de risco, gerenciamento de partes 
interessadas e coordenação principal de apoio organizacional, processos de projetos cruzados 
de desenvolvimento de software e projetos de manutenção. Processos de software também são 
desenvolvidos para necessidades particulares, como atividades de processo que abordar as 
características de qualidade do software (ver a qualidade do software KA). Por exemplo, 
segurança, preocupações durante o desenvolvimento de software podem precisar de um ou 
mais processos de software para proteger a segurança do ambiente de desenvolvimento e 
reduzir orisco de atos maliciosos. Programas processos também podem ser desenvolvidos para 
fornecer motivos adequados para estabelecer confiança em integridade do software. 
2.2. Modelos de ciclo de vida de software 
[1 *, c2] [2 *, s3,2] [3 *, s2,1] [5] 
A natureza intangível e maleável do software permite uma grande variedade de 
desenvolvimento de modelos de ciclo de vida de software, variando de modelos lineares em 
quais as fases de desenvolvimento de software são realizadas sequencialmente com feedback e 
iteração conforme necessário, seguida de integração, teste, e entrega de um único produto; 
para modelos iterativos em que os softwares são desenvolvidos em incrementos de aumentar a 
funcionalidade nos ciclos iterativos para modelos ágeis que normalmente envolvem 
demonstrações frequentes de software funcional para um cliente ou representante do usuário 
que dirige desenvolvimento do software em ciclos iterativos curtos que produzem pequenos 
incrementos de trabalho, software para entrega. Incremental, iterativo e modelos ágeis podem 
fornecer subconjuntos iniciais de software de trabalho no ambiente do usuário, se desejado. Os 
modelos SDLC lineares às vezes são referidos para um modelo de ciclo de vida de 
desenvolvimento de software preditivo, enquanto os SDLCs iterativos e ágeis são referidos como 
modelos de ciclo de vida desenvolvimento de software adaptativo. Deve-se notar que várias 
atividades de manutenção durante um SPLC podem ser conduzidas usando diferentes modelos 
SDLC, como apropriado para as atividades de manutenção. Uma característica distintiva dos 
vários modelos de ciclo de vida de desenvolvimento de softwares é o caminho para quais 
requisitos de software são gerenciados. Modelos Lineares de desenvolvimento normalmente 
desenvolvem um conjunto de requisitos de software, na medida possível, durante o início e 
planejamento do projeto. Os requisitos de software são então rigorosamente controlados. 
Mudanças nos requisitos de software são baseados em solicitações de mudança que são 
processadas por uma placa de controle de mudança (consulte Solicitação, Avaliação e aprovação 
de mudanças de software em “Change Control Board” na configuração do software Gestão KA). 
Um modelo incremental produz incrementos sucessivos de trabalho, software entregue com 
base em particionamento dos requisitos de software a serem implementados em cada um dos 
incrementos. Os requisitos de software podem ser rigorosamente controlados, como em um 
modelo, ou pode haver alguma flexibilidade na revisão dos requisitos de software como o 
produto de software evolui. Modelos ágeis podem definir o escopo do produto e recursos de 
alto nível inicialmente, porém os modelos agéis são projetados para facilitar a evolução dos 
requisitos de software durante o projeto. Deve ser enfatizado que o continuum de SDLCs de 
linear para ágil não é um fino, linha direta. Elementos de diferentes abordagens podem ser 
incorporados a um modelo específico, por exemplo, um modelo de ciclo vida incremental de 
desenvolvimento de software pode incorporar requisitos sequenciais de software e fases de 
design, mas permitem flexibilidade considerável na revisão dos requisitos de software e 
arquitetura durante a construção do software. 
2.3. Adaptação de processo de software 
 [1 *, s2,7] [2 *, p51] 
SDLCs predefinidos, SPLCs e processos individuais de software muitas vezes precisam ser 
adaptados (ou “Sob medida”) para melhor atender às necessidades locais. O contexto 
organizacional, inovações em tecnologia, tamanho do projeto, criticidade do produto, requisitos 
regulatórios, práticas da indústria e cultura corporativa podem determinar as adaptações 
necessárias. Adaptação de processos de software individuais e modelos de ciclo de vida útil do 
software (desenvolvimento e produto) podem consistir em adicionar mais detalhes aos 
processos de software, atividades, tarefas e procedimentos para abordar preocupações críticas. 
Pode consistir no uso de uma alternativa conjunto de atividades que atingem o propósito e 
resultados do processo de software. Adaptação também pode incluir omitir processos de 
software ou atividades de um desenvolvimento ou modelo de ciclo de vida de produto que são 
claramente inaplicáveis ao âmbito do trabalho a ser realizado. 
2.4. Considerações práticas 
[2 *, p188-190] 
Na prática, os processos e atividades de software são frequentemente intercalados, sobrepostos 
e aplicados simultaneamente. Modelos de ciclo de vida de software que especificam processos 
de software discretos, com especificações rigorosas critérios de entrada e saída e limites 
prescritos e interfaces, devem ser reconhecidas como idealizações que deve ser adaptado para 
refletir as realidades de desenvolvimento e manutenção de software dentro do contexto 
organizacional e ambiente de negócios. Outra consideração prática: processos de software 
(como gerenciamento de configuração, construção e teste) podem ser adaptados para facilitar 
operação, suporte, manutenção, migração, e retirada do software. Fatores adicionais a serem 
considerados quando definir e adaptar um modelo de ciclo de vida de software incluem a 
conformidade exigida com os padrões, diretivas, e políticas demandas do cliente, criticamente 
do produto de software, e maturidade organizacional e competências. Outros fatores incluem a 
natureza do trabalho (por exemplo, modificação do software existente versus novo 
desenvolvimento) e o domínio do aplicativo (por exemplo, aeroespacial versus hotel gestão). 
3. Avaliação do processo de software e Melhoria 
[2 *, P188, P194] [3 *, C26] [4 *, P397, C15] 
Este tópico aborda a avaliação do processo de modelos de software, métodos de avaliação de 
processo de software, modelos de melhoria de processo de software e classificações de 
processos contínuos e em estágios. Programas deavaliações de processo são usadas para avaliar 
o formulário e o conteúdo de um processo de software, que pode ser especificado por um 
conjunto padronizado de critérios. Em alguns casos, os termos "avaliação de processo" e 
"avaliação de capacidade" são usados em vez de avaliação do processo. Avaliações de 
capacidade são normalmente realizados por um adquirente (ou potencial adquirente) ou por 
um agente externo em nome de um adquirente (ou adquirente potencial). Os resultados são 
usados como um indicador de se os processos de software usados por um fornecedor (ou 
fornecedor potencial) são aceitáveis para o adquirente. As avaliações são normalmente 
realizadas dentro de uma organização para identificar processos de software que precisam de 
melhoria ou para determinar se um processo (ou processos) satisfazem os critérios em um 
determinado nível da capacidade ou maturidade do processo. 
As avaliações do processo são realizadas nos níveis de organizações inteiras, unidades 
organizacionais dentro das organizações e projetos individuais. A avaliação pode envolver 
questões como avaliar se os critérios de entrada e saída do processo de software estão sendo 
atendidos, para revisar os fatores de risco e gestão de riscos ou para identificar as lições 
aprendidas. A avaliação do processo é realizada usando um modelo de avaliação e um método 
de avaliação. 
O modelo pode fornecer uma norma para uma comparação de benchmarking entre projetos 
dentro de uma organização e entre organizações. 
Uma auditoria de processo difere de uma avaliação de processo. As avaliações são realizadas 
para determinar níveis de capacidade ou maturidade e para identificar processos de software a 
serem melhorados. Auditorias são normalmente conduzidas para verificar a conformidade com 
as políticas e padrões. As auditorias fornecem gerenciamento e visibilidade das operações reais 
sendo realizadas na organização para que decisões significativas possam ser feitas em relação a 
problemas que estão impactando um projeto de desenvolvimento, uma atividade de 
manutenção ou relacionadaao tema software. 
Fatores de sucesso para avaliação de processo de software e melhoria na engenharia de 
software nas organizações incluem gestão de patrocínio, planejamento, treinamento, 
experiencia e líderes capazes, comprometimento da equipe, gestão de expectativas, o uso de 
agentes de mudança, além de projetos-piloto e experimentação com ferramentas. Fatores 
adicionais incluem independência do avaliador e oportunidade da avaliação. 
3.1. Modelos de avaliação de processos de software 
[2 *, s4,5, s4,6] [3 *, s26,5] [4 *, p44-48] 
Modelos de avaliação de processo de software normalmente incluem critérios de avaliação para 
processos de software que são consideradas boas práticas. Essas práticas podem abordar o 
desenvolvimento de processos de software apenas, ou eles também podem incluir tópicos como 
manutenção de software, gerenciamento de projetos de software, engenharia de sistemas ou 
gestão de Recursos Humanos. 
3.2. Métodos de avaliação de processos de software 
 [1 *, p322-331] [3 *, s26.3] [4 *, p44-48, s16.4] [6] 
Um método de avaliação de processo de software pode ser qualitativo ou quantitativo. 
Avaliações qualitativas confiam no julgamento de especialistas; quantitativo as avaliações 
atribuem pontuações numéricas a processos de software com base na análise de objetivos e 
evidências que indicam o alcance dos objetivos e resultados de um processo de software 
definido. Por exemplo, uma avaliação quantitativa do processo de software de inspeção pode 
ser realizada se examinando as etapas processuais seguidas e resultados obtidos mais dados 
relativos a defeitos encontrados e tempo necessário para encontrar e corrigir os defeitos em 
comparação com o teste de software. 
Um método típico de avaliação de processo de software inclui planejamento, apuração de fatos 
(coletando evidências por meio de questionários, entrevistas, e observação das práticas de 
trabalho), coleta e validação dos dados do processo, e análise e comunicação. As avaliações do 
processo podem contar com o julgamento subjetivo e qualitativo do avaliador, ou na presença 
ou ausência objetiva de artefatos, registros e outras evidências. 
As atividades realizadas durante um processo de avaliação de software e distribuição de esforço 
para atividades de avaliação são diferentes dependendo do propósito da avaliação do processo 
de software. Avaliações de processo de software podem ser realizadas para desenvolver 
classificações de capacidade usadas para fazer recomendações para melhorias de processo ou 
pode ser realizada para obter uma classificação de maturidade do processo para se qualificar 
para um contrato ou recompensa. 
A qualidade dos resultados da avaliação depende do método de avaliação do processo de 
software, da integridade e qualidade dos dados obtidos, da capacidade e objetividade da equipe 
de avaliação, e das evidências examinadas durante a avaliação. O objetivo de uma avaliação de 
processo de software é obter uma visão que estabelecerá o status atual de um processo ou 
processos e fornece uma base para melhoria de processos. Executando um software avaliação 
do processo, seguindo uma lista de verificação para conformidade sem obter insight acrescenta 
pouco valor. 
3.3. Modelos de melhoria de processos de software 
[2 *, p187-188] [3 *, s26,5] [4 *, s2,7] 
Modelos de melhoria de processo de software enfatizam ciclos iterativos de melhoria contínua. 
Um ciclo de melhoria de processo de software normalmente envolve os subprocessos de 
medição, análise, e mudança. O modelo Plan-Do-Check-Act é uma abordagem iterativa bem 
conhecida para melhoria de processos de software. Melhorar as atividades incluem identificar 
e priorizar melhorias desejadas (planejamento); apresentando uma melhoria, incluir gestão de 
mudanças e treinamento (fazer); avaliar a melhoria em comparação com o processo anterior ou 
resultados e custos exemplares (verificação); e fazendo mais modificações (atuação). O modelo 
Plan-Do-Check-Act de melhoria de processo pode ser aplicado, por exemplo, para melhorar os 
processos de software que melhoraram a prevenção de defeitos. 
3.4. Processo de software contínuo e em etapas Avaliações 
 [1 *, p28-34] [3 *, s26,5] [4 *, p39-45] 
Capacidade do processo de software e maturidade de processo de software são normalmente 
avaliadas em cinco ou seis níveis para caracterizar a capacidade ou maturidade dos processos 
de software usados dentro de uma organização. Um sistema de classificação contínua envolve 
a atribuição de uma classificação para cada processo de software de interesse; um sistema de 
classificação faseada é estabelecido atribuindo a mesma classificação de maturidade para todo 
o processo de software dentro de um nível de processo especificado. Uma representação de 
níveis de processos contínuos e em estágios é fornecido na Tabela 8.1. Modelos contínuos 
normalmente usam uma classificação de nível 0; modelos encenados tipicamente não. 
 
Nível Representação de níveis de 
capacidade Contínua 
Representação de níveis de 
maturidade encenados 
0 Incompleto 
1 Realizado Inicial 
2 Gerenciado Gerenciado 
3 Definido Definido 
4 Gerenciado 
Quantitativamente 
5 Otimizado 
 
 
Na Tabela 8.1, o nível 0 indica que um software ou processo é executado de forma incompleta 
ou pode não ser realizado. No nível 1, um processo de software está sendo realizado 
(classificação de capacidade), ou o processo de software em um grupo de nível de maturidade 
1 está sendo realizado, mas numa base ad hoc e informal. Em nível 2, um processo de software 
(classificação de capacidade) ou os processos no nível de maturidade 2 estão sendo realizados 
de uma maneira que fornece gerenciamento e visibilidade em produtos de trabalho 
intermediários e podem exercer algum controle sobre as transições entre processos. No nível 3, 
um único processo de software ou os processos em um grupo de nível de maturidade 3 mais o 
processo ou processos no nível de maturidade 2 estão bem definidos (talvez em políticas 
organizacionais e procedimentos) e estão sendo repetidos em diferentes projetos. Nível 3 de 
capacidade do processo ou a maturidade fornece a base para a melhoria do processo em uma 
organização porque o processo é (ou os processos são) conduzido(s) de maneira semelhante. 
Isso permite a coleta de dados de desempenho de maneira uniforme em vários projetos. Em 
nível de maturidade 4, as medidas quantitativas podem ser aplicadas e usadas para avaliação de 
processos; análise estatística pode ser usada. No nível de maturidade 5, os mecanismos para 
melhorias contínuas de processos são aplicados. Representações contínuas e encenadas podem 
ser usadas para determinar a ordem em que processos de software devem ser melhorados. Na 
representação contínua, os diferentes níveis de capacidade para diferentes processos de 
software fornecem uma diretriz para determinar a ordem em que os processos de software 
serão melhorados. Na representação encenada, satisfazer os objetivos de um conjunto de 
processos de software dentro de um nível de maturidade é realizado para esse nível de 
maturidade, que fornece uma base para melhorar todos os processos de software no próximo 
nível superior. 
Tabela 8.1. Níveis de classificação de processos de software 
4. Medição de software 
[3 *, s26.2] [4 *, s18.1.1] 
Este tópico trata do processo e produto medição de software, qualidade dos resultados da 
medição, modelos de informação de software e processo de software e técnicas de medição 
(ver Medição nas Fundações de Engenharia KA). Antes que um novo processo seja 
implementado ou um atual processo seja modificado, resultados de medição para a situação 
atual devem ser obtidos para fornecer uma linha de base para comparação entre as atuais 
situações e a nova situação. Por exemplo, antes de introduzir a inspeção de processos de 
software, o esforço necessário para corrigir os defeitos descobertos por meio de testes devem 
sermedidos. Após um período de inicialização seguindo o processo de inspeção inicial é 
introduzido o esforço combinado de inspeção e teste que pode ser comparado ao anterior em 
quantidade de esforço necessário para o teste sozinho. Considerações semelhantes se aplicam 
se um processo for alterado. 
4.1. Processo de Software e Medição de Produto 
[1 *, s6.3, p273] [3 *, s26.2, p638] 
Processo de software e medição de produto se preocupam em determinar a eficiência e eficácia 
de um processo de software, atividade ou tarefa. A eficiência de um processo de software, 
atividade ou tarefa é a proporção de recursos realmente consumidos aos recursos esperados ou 
desejados para serem consumidos na realização de um processo de software, atividade ou 
tarefa (ver Eficiência na Engenharia de Software Economia KA). Esforço (ou custo equivalente) é 
a medida primária de recursos para a maioria dos processos de software. Atividades e tarefas 
são medidos em unidades, como horas por pessoa, dias por pessoa, semanas de trabalho, ou 
equipe-meses de esforço ou unidades monetárias equivalentes, como euros ou dólares. 
A eficácia é a relação entre a produção real e saída esperada produzida por um processo de 
software, atividade ou tarefa, por exemplo, o número real de defeitos detectados e corrigidos 
durante o teste de software para o número esperado de defeitos a serem detectados e 
corrigidos, talvez com base no histórico de dados para projetos semelhantes (ver eficácia no KA 
Economia da Engenharia de Software). Observe que a medição da eficácia do processo de 
software requer medição dos atributos do produto relevantes, por exemplo, medição de 
defeitos de software descobertos e corrigidos durante teste de software. É preciso ter cuidado 
ao medir os atributos de produto para fins de determinação da eficácia do processo. Por 
exemplo, o número de defeitos detectados e corrigidos por meio de testes pode não atingir o 
número esperado de defeitos e ainda assim, fornece uma medida de eficácia enganosamente 
baixa, porque o software sendo testado é melhor do que a qualidade usual ou talvez porque a 
introdução de uma inspeção upstream recentemente introduzida no processo reduziu o número 
restante de defeitos no software. 
Medidas do produto que podem ser importantes em determinar a eficácia dos processos de 
software incluem a complexidade do produto, defeitos totais, densidade de defeitos e a 
qualidade dos requisitos, documentação de design e outros trabalhos relacionados a produtos. 
Observe também que a eficiência e a eficácia são conceitos independentes. Um processo de 
software eficaz pode ser ineficiente na obtenção de um resultado de software desejado do 
processo, por exemplo, a quantidade de esforço despendido para encontrar e corrigir defeitos 
de software pode ser muito alto e resultar em baixa eficiência, como em comparação com as 
expectativas. Um processo eficiente pode ser ineficaz na realização da transformação desejada 
do trabalho de produtos de entrada em trabalho de produtos de saída, por exemplo, falha em 
encontrar e corrigir um número suficiente de defeitos de software durante o processo de teste. 
Causas de baixa eficiência e / ou baixa eficácia na forma de um processo de software, a atividade 
ou a tarefa executada pode incluir um ou mais dos seguintes problemas: produtos de trabalho 
de entrada deficientes, pessoal inexperiente, falta de ferramentas e infraestrutura, aprendizado 
de um novo processo, um produto complexo ou um produto de domínio desconhecido. A 
eficiência e eficácia do software e a execução do processo também são afetadas (ou positiva ou 
negativamente) por fatores como rotatividade na equipe de software, mudanças de 
cronograma, um novo representante do cliente ou uma nova política de organização. Em 
engenharia de software, produtividade no desempenho de um processo, atividades ou tarefas 
é a proporção de produção produzida dividida pelos recursos consumidos, por exemplo, o 
número de defeitos de software descobertos e corrigidos dividido por horas-pessoa de esforço 
(ver Produtividade na Engenharia de Software Economia KA). Medição precisa de produtividade 
deve incluir o esforço total usado para satisfazer os critérios de saída de um processo de 
software, atividade ou tarefa, por exemplo, o esforço necessário para corrigir defeitos 
descobertos durante o teste de software deve ser incluído no desenvolvimento de 
produtividade de software. 
O cálculo da produtividade deve levar em conta o contexto em que o trabalho é realizado. Por 
exemplo, o esforço para corrigir defeitos serão incluídos no cálculo de produtividade de uma 
equipe de software se membros da equipe corrigirem os defeitos que encontrarem - como em 
testes de unidade por desenvolvedores de software ou em uma equipe multifuncional e ágil. Ou 
o cálculo da produtividade pode incluir o esforço dos desenvolvedores de software ou o esforço 
de um teste de equipe independente, dependendo de quem corrige os defeitos encontrados 
pelos testadores independentes. Observe que este exemplo refere-se ao esforço de equipes de 
desenvolvedores ou equipes de testadores e não para indivíduos. Produtividade de software 
calculada no nível de indivíduos podem ser enganosas por causa de muitos fatores que podem 
afetar a produtividade individual de engenheiros de software. 
Definições padronizadas e regras de contagem para medição de processos de software e 
produtos trabalho são necessários para fornecer resultados de medição em projetos dentro de 
um organização, para preencher um repositório de dados “histórico” que podem ser analisados 
para identificar processos de software que precisam ser melhorados e para construir modelos 
preditivos baseados em dados acumulados. No o exemplo acima, definições de defeitos de 
software e horas de esforço da equipe de teste mais contagem de regras para defeitos e esforço 
seriam necessárias para obter resultados de medição satisfatórios. Até que ponto o processo de 
software é institucionalizado e importante. Falha em institucionalizar um processo de software 
pode explicar por que “Bons” processos de software nem sempre produzem resultados 
antecipados. Processos de software podem ser institucionalizados por adoção na unidade local 
organizacional ou em unidades maiores de um empreendimento. 
4.2. Qualidade dos resultados de medição 
[4 *, s3,4-3,7] 
A qualidade do processo e medição do produto e resultados são determinados principalmente 
pela confiabilidade e validade dos resultados medidos. Medidas que não satisfazem esses 
critérios de qualidade podem resultar em interpretações incorretas e falhas iniciativas de 
melhoria de processos de software. De outras propriedades desejáveis de medições de software 
incluem facilidade de coleta, análise e apresentação além de uma forte correlação entre causa 
e efeito. O tópico de medição de engenharia de software no KA de Gerenciamento de 
Engenharia de Software descreve um processo para implementar um programa de software de 
medição. 
4.3. Modelos de Informação de Software 
[1 *, p310-311] [3 *, p712-713] [4 *, s19.2] 
Modelos de informações de software permitem modelagem, análise e previsão do processo de 
software e atributos do produto de software para fornecer respostas para questões relevantes 
e alcançar processos e produtos objetivos de melhoria. Os dados necessários podem ser 
coletados e retidos em um repositório. Os dados podem ser analisados e os modelos podem ser 
construídos. Validação e refinamento dos modelos de informação de software ocorrem durante 
projetos de software e após os projetos são concluídos para garantir que o nível de precisão é 
suficiente e que suas limitações são conhecidas e entendidas. Modelos de informação de 
software podem também serem desenvolvidos para contextos diferentes de projetos de 
software, por exemplo, uma informação de modelo de software pode ser desenvolvida para 
processos que se aplicamem uma organização, como configuração de gerenciamento de 
software ou garantia de qualidade de software e processos no nível organizacional. 
Modelo de informação de software baseado em análise e construção envolve o 
desenvolvimento, calibração, e avaliação de um modelo. Uma informação de modelo de 
software é desenvolvido estabelecendo um transformação hipotética de variáveis de entrada 
em saídas desejadas; por exemplo, tamanho do produto e a complexidade pode ser 
transformada em estimativa esforço necessário para desenvolver um produto de software 
usando uma equação de regressão desenvolvida a partir de dados observados de projetos 
anteriores. Um modelo é calibrado ajustando parâmetros no modelo para combinar os 
resultados observados de projetos anteriores, por exemplo, o expoente em um modelo de 
regressão não linear pode ser alterado aplicando a regressão da equação a um conjunto 
diferente de projetos anteriores além dos projetos usados para desenvolver o modelo. Um 
modelo é avaliado comparando resultados em resultados reais para um conjunto diferente de 
dados semelhantes. Existem três avaliações de resultados possíveis: 
1. os resultados calculados para um conjunto de dados diferente variam amplamente a 
partir de resultados reais para esses dados definidos, caso em que o modelo derivado 
não é aplicável para o novo conjunto de dados e não deve poder ser aplicado para 
analisar ou fazer previsões para projetos futuros; 
2. os resultados calculados para um novo conjunto de dados estão perto dos resultados 
reais para esse conjunto de dados, nesse caso, pequenos ajustes são feitos aos 
parâmetros do modelo para melhorar a concordância; 
3. os resultados calculados para o novo conjunto de dados e os conjuntos de dados 
subsequentes são muito próximos e não são necessários ajustes no modelo. 
A avaliação contínua do modelo pode indicar a necessidade de ajustes ao longo do tempo 
conforme o contexto em que o modelo é aplicado muda. O método Objetivos / Perguntas / 
Métricas (GQM) foi originalmente planejado para estabelecer medição de atividades, mas 
também pode ser usado para orientar análise e melhoria de processos de software. Ele pode ser 
usado para guiar o software orientado para análise de construção de modelos de informação. 
Resultados obtidos do modelo de informação de software pode ser usado para orientar a 
melhoria do processo. O exemplo a seguir ilustra a aplicação do método GQM: 
• Meta: Reduzir a solicitação de mudança e média de tempo de processamento em 10% 
em seis meses. 
• Pergunta 1-1: Qual a mudança da linha de base que requer tempo de processamento? 
• Métrica 1-1-1: Média de solicitação de mudança de tempo de processamento na data 
de início 
• Métrica 1-1-2: Desvio padrão da mudança requer tempo de processamento na data de 
início 
• Pergunta 1-2: Qual a mudança atual requer tempo de processamento? 
• Métrica 1-2-1: Média de solicitação de mudança de tempo de processamento 
atualmente 
• Métrica 1-2-2: Desvio padrão da mudança requer tempo de processamento atualmente 
4,4. Técnicas de medição de processos de software 
[1 *, c8] 
As técnicas de medição de processos de software são usadas para coletar dados de processo e 
dados de produto de trabalho, transformar os dados em informações úteis, e analisar as 
informações para identificar o processo de atividades que são candidatas a melhorias. Em alguns 
casos, novos processos de software podem ser necessários. 
As técnicas de medição de processos também fornecem as informações necessárias para medir 
os efeitos de iniciativas de melhoria de processos. Medição de técnicas de processo podem ser 
usadas para coletar ambos os dados quantitativos e qualitativos. 
4.4.1. Medição Quantitativa do Processo Técnicas 
[4 *, s5,1, s5,7, s9,8] 
O objetivo da medição quantitativa do processo de técnicas é coletar, transformar e analisar o 
processo quantitativo e os dados do produto de trabalho que podem ser usados para indicar 
onde as melhorias de processo são necessárias e para avaliar os resultados de iniciativas de 
melhoria de processos. Técnicas quantitativas de medição de processo são usadas para coletar 
e analisar os dados de forma numérica para os quais técnicas matemáticas e estatísticas possam 
ser aplicadas. 
Os dados quantitativos do processo podem ser coletados como um subproduto dos processos 
de software. Por exemplo, o número de defeitos descobertos durante os testes de software e 
as horas de trabalho gastas podem ser coletados por medição direta, e a produtividade de 
descoberta de defeitos pode ser derivada calculando defeitos descobertos por equipe-hora. 
Ferramentas básicas para controle de qualidade podem ser usadas para analisar dados 
quantitativos de medição de processo (por exemplo, folhas de verificação, diagramas de Pareto, 
histogramas, diagramas de dispersão, gráficos de execução, gráficos de controle e diagramas de 
causa e efeito) (consulte Causa raiz Análise nas Fundações de Engenharia KA). Além disso, várias 
técnicas estatísticas podem ser usadas que variam de cálculo de medianas e médias para 
métodos de análise multivariada (ver Estatística Análise nas Fundações de Engenharia KA). 
Dados coletados por meio de medição quantitativa de técnicas de processos também podem 
ser usadas como entradas para modelos de simulação (ver Modelagem, Prototipagem, e 
Simulação nas Fundações de Engenharia KA), esses modelos podem ser usados para avaliar o 
impacto de várias abordagens ao processo de melhoria de software. 
Classificação de defeito ortogonal (ODC) pode ser usado para analisar a medição quantitativa do 
processo de dados. ODC pode ser usado para agrupar defeitos detectados em categorias e 
vincular os defeitos em cada categoria ao processo de software ou processos de software onde 
um grupo de defeitos se originou (ver Caracterização de Defeito no Software Qualidade KA). 
Defeitos de interface de software, por exemplo, podem ter se originado durante um processo 
inadequado de design de software. Melhorando o processo de design de software reduzirá o 
número de defeitos de interface de software. ODC pode fornecer dados quantitativos para 
aplicação de análise de causa raiz. O controle estatístico do processo pode ser usado para 
rastrear estabilidade do processo, ou a falta de estabilidade do processo, usando cartas de 
controle. 
4.4.2. Medição de Processo QualitativoTécnicas 
[1 *, s6,4] 
Técnicas de medição qualitativa do processo - incluindo entrevistas, questionários e julgamento 
de especialistas - podem ser usados para aumentar a medição de técnicas de processos. 
Consenso de técnicas de grupo, incluindo a técnica Delphi, pode ser usada para obter consenso 
entre grupos de acionistas. 
5. Ferramentas de processo de engenharia de software 
[1 *, s8,7] 
Ferramentas de processo de software suportam muitas das notações usadas para definir, 
implementar e gerenciar processos de software individuais e de modelos de ciclo de vida útil do 
software. Eles incluem editores para notações como diagramas de fluxo de dados, gráficos de 
estado, BPMN, Diagramas IDEF0, redes de Petri e atividade UML diagramas. Em alguns casos, 
ferramentas de processo de software permitem diferentes tipos de análises e simulações (por 
exemplo, simulação de eventos discretos). Além disso, ferramentas de negócios de uso geral, 
como uma planilha, pode ser útil. 
Engenharia de Software Assistida por Computador (CASE) e ferramentas podem reforçar o uso 
de ferramentas integradas a processos, apoiar a execução de definições de processo, e fornecer 
orientação aos humanos no desempenho de processos bem definidos. Ferramentas simples 
como processadores de texto e planilhas podem ser usadas para preparar descrições textuais 
de processos, atividades e tarefas. Essas ferramentas também suportam rastreabilidade entre 
as entradas e saídas de vários processos de software (como as partes interessadas na análise de 
necessidades,especificação de requisitos de software, arquitetura de software e design de 
software detalhado), bem como os resultados dos processos de software como documentação, 
componentes de software, casos de teste e relatórios de problemas. 
A maioria das áreas de conhecimento neste Guia descreve ferramentas especializadas que 
podem ser usadas para gerenciar os processos dentro desse KA. Em particular, veja o 
Gerenciamento de Configuração de Software KA para uma discussão sobre configuração de 
ferramentas de software de gestão que podem ser usadas para gerenciar os processos de 
construção, integração e liberação para produtos de software. Outras ferramentas, como 
aquelas para gerenciamento de requisitos e testes, são descritas nos KAs apropriados. 
Ferramentas de processo de software podem apoiar projetos que envolvem equipes 
geograficamente dispersas (virtuais). Cada vez mais, as ferramentas de processo de software 
estão disponíveis através de instalações de computação em nuvem bem como através de 
infraestruturas dedicadas. Um painel de controle do projeto ou painel pode exibir o processo 
selecionado e atributos de produto para projetos de software que indicam medidas que estão 
dentro dos limites de controle e aqueles que precisam de ação/correção.