PROF.

JONATAS
SILVA

Engenharia de
Software
O Docente
• Jonatas da Silva Junior
• Especialista em Gestão da Qualidade e Produtividade, Mestre e
Doutorando em Engenharia Mecânica
• Entusiasta da Educação e da Tecnologia
• Docente em Instituições de Ensino Superior a mais de 10 anos
• Experiência em Ensino a Distância, Presencial e Remoto
• Lattes: http://lattes.cnpq.br/6862227969295030

2
A Disciplina
Engenharia de Software
Ementa: Elicitação dos Requisitos, Identificação das fontes de
informação, técnicas de elicitação, modelagem, técnicas de
modelagem, análise de requisitos, validação e verificação, gerência de
requisitos, certificação e padrões internacionais, ferramentas.
Carga Horária: 60 horas

3
A Disciplina (Avaliações)

Frequência mínima Participação nas Realização / Entrega

de 75%; Atividades em Sala; das Atividades;

Cumprimento de Obtenção de Média

prazos; 7,0.

4
Introdução
• “Um processo de engenharia de software é formado por um
conjunto de passos de processo parcialmente ordenados,
relacionados com artefatos, pessoas, recursos, estruturas
organizacionais e restrições, tendo como objetivo produzir e
manter os produtos de software finais requeridos.”
Wikipedia
Introdução
• Projeto é algo que ocorre em um tempo determinado.
• Processo é um conjunto de regras que definem como um
projeto deve ser executado.
• Modelo de processo é um conjunto de regras mais abstratas
que especificam a forma geral de processos.
• O modelo de processo para as atividades de projeto e
desenvolvimento de software também pode ser chamado
ciclo de vida.
Introdução
• Vantagens em definir o desenvolvimento de software
como um processo:
• Redução do tempo de treinamento
• Uniformização dos produtos
• Possibilidade de capitalizar experiências
Fases (ou estágio) de um
processo
• Primeira grande divisão de um processo.
• Período em que determinadas atividades com
objetivos bem específicos são realizadas.
• Normalmente são poucas (menos que 10)
• Nem todos os modelos de desenvolvimento
apresentam todas as fases claramente.
Fases (ou estágio) de um
processo
• ISO/IEC TS 24748-1:2016:
Concepção: Desenvolvimento: Produção:
• Quando uma primeira exploração das • Quando se modela um produto a • Quando o produto é efetivamente
necessidades dos usuários é feita, partir das necessidades identificadas. construído.
com a possível construção de
modelos ou protótipos de forma a
examinar possíveis soluções
candidatas.

Utilização: Suporte: Desativação:

• Quando o produto é colocado em • Quando o produto recebe • Quando o produto é retirado de uso
operação no ambiente-alvo. intervenções de forma a continuar para possível substituição por outro
funcionando ou se aprimorando de produto.
acordo com novas necessidades.
 Concepção e
Regras do Negócio
Regras de Negócio
• Descrição breve, precisa e sem ambiguidades de uma política, procedimento
ou princípio em uma organização.
• Aplicável a qualquer organização, independente de tamanho, que armazene e
utilize dados para gerar informações
• As regras de negócio decorrentes de uma descrição detalhada das operações de
uma organização ajudam a criar e aplicar ações no interior de seu ambiente
organizacional
• Devem ser fornecidas por escrito e atualizadas
• Devem ser de fácil compreensão e amplamente disseminadas
• Descrevem as características principais e particulares dos dados conforme vistos
pela empresa
Descobrindo as Regras de
Negócio
Gerentes de
departamento
Documentações por
escrito
Elaboradores de • Manuais de
políticas procedimentos,
padrões e
operações de uma
companhia

Principais fontes
Gerentes de Entrevistas diretas
de regras de
empresa dos usuários finais
negócio
Descobrindo as Regras de
Negócio
Ajudam a padronizar a visualização dos dados de uma empresa

Podem constituir uma ferramenta de comunicação entre os usuários e os

projetistas

Permitem que o projetista compreenda a natureza, o papel e o escopo dos

dados

Permitem que o projetista compreenda os processos comerciais

Permitem que o projetista desenvolva regras e restrições adequadas de

participações em relacionamentos, e crie um modelo de dados preciso
Regras de Negócio  Componentes do
Models
• Geralmente, um substantivo em uma regra de negócio será
traduzido como entidade no modelo
• Um será traduzido como um relacionamento entre entidades
• Relacionamentos são bidirecionais
• Para identificar adequadamente o tipo de relacionamento,
deve-se fazer duas perguntas:
– Quantas instâncias de B são relacionadas a uma instância
de A?
– Quantas instâncias de A são relacionadas a uma instância
de B?
 Concepção e
Levantamento de
Requisitos
Levantamento de requisitos
• Etapa de compreensão do problema aplicada ao desenvolvimento de software.
• A mais importante em termos de retorno em investimentos feitos para o projeto de
desenvolvimento.
• Objetivos:
• Fazer com que usuários e desenvolvedores tenham a mesma visão do problema a ser
resolvido.
• Levantar e definir as necessidades dos futuros usuários do sistema a ser
desenvolvido.
• Entregável:
• Documento de declaração de requisitos
• Não deve conter informações sobre as soluções técnicas que serão adotadas
para desenvolver o sistema.
Requisito
• Condição ou capacidade que deve ser alcançada ou possuída por um
sistema ou um de seus componentes para satisfazer um contrato, padrão,
especificação ou outros documentos formalmente impostos.
• Deve ser expresso de uma maneira tal que possam ser verificado e
comunicado a leitores técnicos e não técnicos.
• Um ponto importante sobre os requisitos é sua característica de
volatilidade.
• No desenvolvimento de sistemas de software, muitas vezes a existência de
requisitos voláteis corresponde mais à regra do que à exceção.
Requisito
• São identificados a partir de um domínio.
• Área de conhecimento ou atividade específica caracterizada por um
conjunto de conceitos e de terminologia compreendidos por
especialista nessa área.
• Parte relevante do mundo real (algumas informações e processos
desse domínio precisam ser incluídos no sistema em
desenvolvimento).
• Também chamado de domínio do problema ou domínio do negócio.
Definição de requisitos
• Termo de consenso entre a equipe técnica (desenvolvedores)
e o cliente.
• Constitui a base para as atividades subsequentes do
desenvolvimento do sistema
• Fornece um ponto de referência para qualquer validação
futura do software construído.
Definição de requisitos
• Estabelece o escopo do sistema
• Pode mudar durante o seu desenvolvimento.
• O planejamento inicial do projeto deve se basear no escopo
inicial.
• Desejável:
• Requisitos ordenados pelos usuários em função do seu grau de
prioridade.
• Estabelecido em função da adição de valor que o
desenvolvimento desse requisito no sistema trouxer aos
usuários.
Objetivos dos requisitos de
sistema
• Definir características críticas de cada componente do
sistema;
• Estabelecer critérios de aceitação em nível de sistema;
• Servir de base para os requisitos alocados a cada
componente:
• cada componente de software;
• hardware;
• bancos de dados;
• etc.
Limites do enunciado dos
requisitos
• Definir completa e corretamente todos os requisitos do
produto;
• Não descrever decisões de desenho ou de implementação:
• partição em componentes, estruturas internas...
• Não descrever aspectos gerenciais do projeto:
• custos, prazos, métodos requeridos.
Um bom enunciado dos
requisitos é:
Completo:
• Contém todos os requisitos significativos:
• funcionalidade, desempenho, restrições de desenho,
atributos e interfaces externas.
• Define entradas válidas e inválidas:
• define respostas do software para todas as entradas
válidas.
• Contém glossário de todos os termos técnicos e
unidades de medida:
• referências completas a todos os diagramas, figuras e
tabelas.
Consistente:
• Não há conflitos entre os subconjuntos de requisitos
presentes;
• Tipos comuns de conflitos entre requisitos:
• conflito entre características de objetos do mundo
real;
• conflito lógico ou temporal entre ações;
• uso de termos diferentes para designar o mesmo
objeto do mundo real.
Um bom enunciado dos
requisitos é:

Correto: Preciso:
• Todo requisito presente realmente é um requisito do • Todo requisito presente possui apenas uma única
produto a ser construído; interpretação:
• checa a coerência dos requisitos com outros • aceita tanto pelos desenvolvedores quanto pelos
documentos da aplicação; usuários;
• solicita a aprovação formal da especificação de • suficiente para o desenho dos testes de aceitação.
requisitos por parte do cliente. • Para melhorar a precisão:
• revisões e inspeções;
• notações formais, como a UML;
• ferramentas de modelagem com recursos de
verificação e validação.
Um bom enunciado dos
requisitos é:
Priorizado:
• Requisitos devem ser classificados quanto à estabilidade e
importância;
• Exemplo de classificação por importância:
• requisito essencial – sem atendimento o produto é
inaceitável;
• requisito desejável – atendimento aumenta o valor do
produto, mas ausência pode ser relevada em caso de
necessidade;
• requisito opcional – a ser cumprido se houver
disponibilidade de prazo e recursos.
Verificável:
• Todos os seus requisitos são verificáveis:
• requisito é verificável se existir um processo finito;
• com custo compensador;
• que possa ser executado por uma pessoa ou máquina;
• que mostre a conformidade do produto final com o
requisito.
• Requisitos não verificáveis:
• requisitos ambíguos;
• requisitos definidos em termos qualitativos;
• requisitos contrários a fatos técnicos e científicos.
Um bom enunciado dos
requisitos é:
Modificável:
• Estrutura e estilo permitem a mudança de qualquer
requisito:
• de forma fácil, completa e consistente.
• A modificabilidade geralmente requer:
• organização coerente, com índices e referências
cruzadas;
• ausência de redundância entre requisitos;
• definição separada de cada requisito.
Rastreável:
• Permite a fácil determinação dos antecedentes e
consequências de todos os requisitos;
• Rastreabilidade para trás:
• localiza origem de cada requisito;
• por que existe cada requisito;
• quem ou o que o originou.
• Rastreabilidade para frente:
• localiza resultados do desenvolvimento que serão
afetados por cada requisito.
Seções de uma Definição de
requisitos
• Requisitos funcionais
• Definem as funcionalidades do sistema.
• Requisitos não funcionais
• Declaram as características de qualidade que o sistema deve
possuir e que estão relacionadas às suas funcionalidades.
• Requisitos normativos
• Declaração de restrições impostas sobre o desenvolvimento do
sistema.
Seções de uma Definição de
requisitos
• Requisitos funcionais
• “O sistema deve permitir que cada professor realize o lançamento
de notas das turmas nas quais lecionou.”
• “O sistema deve permitir que um aluno realize a sua matrícula nas
disciplinas oferecidas em um semestre letivo.”
• “Os coordenadores de escola devem poder obter o número de
aprovações, reprovações e trancamentos em cada disciplina
oferecida em um determinado período.”
Seções de uma Definição de
requisitos
• Requisitos não funcionais
• Confiabilidade: corresponde a medidas quantitativas da
confiabilidade do sistema, tais como tempo médio entre falhas,
recuperação de falhas ou quantidade de erros por milhares de
linhas de código-fonte.
• Desempenho: requisitos que definem os tempos de resposta
esperados para as funcionalidades do sistema.
Seções de uma Definição de
requisitos
• Requisitos não funcionais
• Portabilidade: restrições quanto às plataformas de hardware e software nas
quais o sistema será implantado e quanto ao grau de facilidade para
transportar o sistema para outras plataformas.
• Segurança: limitações sobre a segurança do sistema em relação a acessos não
autorizados.
• Usabilidade: requisitos que se relacionam ou afetam a usabilidade do sistema.
Exemplos incluem requisitos sobre a facilidade de uso e a necessidade ou não
de treinamento dos usuários.
Seções de uma Definição de
requisitos
• Requisitos normativos
• Adequação a custos e prazos
• Plataforma tecnológica
• Aspectos legais (licenciamento)
• Limitações sobre a interface com o usuário
• Componentes de hardware e software a serem adquiridos
• Eventuais necessidades de comunicação do novo sistema com sistemas pré-
existentes
• Também regras do negócio, restrições ou políticas de funcionamento específicas
do domínio
Técnicas de Obtenção

Entrevistas

Desenvolvimento Conjunto de Aplicações (JAD)

Questionários

Análise de Documentos

Observação
Técnicas de Obtenção
• Entrevistas
Técnicas de Obtenção
• Desenvolvimento Conjunto de Aplicações
(JAD)
• Processo estruturado, no qual 10 a 20
usuários se reúnem sob a direção do
facilitador (ou mediador) treinado que
define a agenda e as diretrizes da reunião,
mas não participa dela.
• Não expressa ideias ou opiniões sobre
os tópicos em discussão e permanece
neutro durante a sessão.
• Um ou dois auxiliares (escrevente) ajudam
o facilitador fazendo anotações, cópias e
etc.
Técnicas de Obtenção
Fases (ou estágio) de um
processo
• Muitas variações da estrutura apresentada pela norma são
encontradas entre os modelos de desenvolvimento de
software.
• o Modelo Cascata e suas variantes, têm fases sequenciais e
que se concentram em uma única Disciplina.
• Outros modelos tem fases cíclicas (Modelo Espiral, Modelo
de Prototipação Evolucionária e quase todos Modelos
Ágeis).
O modelo de ciclo de vida em
cascata (Clássico ou linear)
O modelo de ciclo de vida em
paralelo
O modelo de ciclo de vida em
V
O modelo de ciclo de vida
Iterativo
O modelo de ciclo de vida
Iterativo
Modelo iterativo e incremental
– vantagens e desvantagens
• Incentiva a participação do usuário.
• Riscos do desenvolvimento podem ser mais bem gerenciados.
• Um risco de projeto é a possibilidade de ocorrência de algum
evento que cause prejuízo ao processo de desenvolvimento,
juntamente com as consequências desse prejuízo.
• Influências: custos do projeto, cronograma, qualidade do
produto, satisfação do cliente, etc.
• Mais difícil de gerenciar
Fases (ou estágio) de um
processo
• O Processo Unificado (UP) é estruturado em quatro a
seis fases, que são sequenciais no tempo.
• Mas dentro de cada fase, todas as disciplinas podem ser
exercidas com maior ou menor intensidade.
• Obs: Cada fase de um processo deve ter um macro
objetivo bem estabelecido.
Disciplina
• Conjunto de atividades correlacionadas, as quais servem a um
objetivo específico dentro do processo de desenvolvimento.
• Usualmente compostas por atividades que se organizam em um grafo
de dependências, que estabelece em que ordem (se for o caso) as
atividades devem ser executadas.
• Processo Unificado: todas as disciplinas são exercitadas em todas
as fases, cada uma com maior ou menor intensidade.
• Modelo Cascata: cada fase exercita apenas uma única disciplina,
havendo assim uma coincidência entre o que é fase e o que é
disciplina neste modelo.
Atividades
• A maioria dos processos de software tem como
fundamento um conjunto de atividades.
• Toda atividade tem um objetivo principal estabelecido
e visa criar ou produzir uma mudança de estado
visível em um ou mais artefatos durante a execução
de um projeto.
Atividades
• Devem:
• Ter entradas e saídas bem definidas.
• Uma atividade toma artefatos de entrada e produz como saída
novos artefatos e/ou promove uma modificação bem definida nos
artefatos de entrada.
• Identificar os responsáveis e participantes.
• Responsáveis: Pessoas que devem realizar a atividade e responder
pela sua conclusão (o ideal é que seja uma única pessoa).
• Participantes: Todas as outras pessoas (perfis ou papéis) que
precisam participar de alguma atividade para que ela seja concluída.
Agem apenas em resposta à iniciativa dos responsáveis.
Atividades
• Pode ser necessária a alocação de um conjunto de
recursos (Humanos, físicos, financeiros, técnicos e
tempo).
• Atividades também podem ser detalhadas em passos,
complementadas por procedimentos e restringidas
por regras.
• São normalmente documentadas.
Atividades
Corpo
Cabeçalho: Com o detalhamento da atividade através de um conjunto
de passos; cada um contém:
• Nome do processo • Número do passo
• Número e nome da fase • Descrição
• Número e nome da disciplina (caso não coincida com a • Pré-condições (passos da mesma tarefa que já devem ter
fase) sido completados)
• Número e nome da atividade (normalmente um número • Regras (opcional)
individual prefixado com o número da fase e da disciplina) • Procedimentos (opcional)
• Histórico de versões do documento, destacando a versão
atual
• Responsável (perfil ou papel)
• Participantes (opcional)
• Artefatos de entrada (opcional)
• Artefatos de saída
• Recursos alocados (opcional)
Artefatos
• Quaisquer documentos que puderem ser produzidos durante um
projeto de desenvolvimento de software.
• Alguns modelos de processo (como UP e FDD) determinam que
cada artefato tenha um dono, que é o único que pode modificar
ou permitir sua modificação.
• Outros modelos (como XP) determinam que artefatos não tenham
dono e que possam ser modificados à vontade por qualquer
desenvolvedor, desde que exista uma boa razão para isso.
 Artefatos
• Descrevem as características esperadas:
Funcionalidade: Interfaces externas:
• O que o produto deverá fazer? • Como o produto interage com:
• as pessoas;
• o hardware do sistema;
• outros produtos?
Desempenho:
• Quais os requisitos de:
• velocidade de processamento;
• tempo de resposta;
• outros parâmetros de
desempenho?

Outros atributos: Restrições de desenho

• Considerações devem ser impostas pela aplicação,
observadas sobre: exigem padrões a serem
• portabilidade; seguidos, como:
• manutenibilidade;
• linguagem de implementação;
• confiabilidade.
• ambientes de operação.
Artefatos

• Todos os artefatos devem estar submetidos a um

sistema de controle de versão para que eventuais
mudanças indevidas possam ser desfeitas.
• Toda atividade deve produzir um novo artefato ou
uma alteração bem definida sobre um artefato
existente.
Artefatos
• Possíveis artefatos:
• Modelo do sistema;
• Documento de definição de produto;
• Proposta de desenvolvimento de sistema.
Responsáveis e Participantes

• As atividades devem ser atribuídas a perfis ou papéis, e

não a pessoas na fase de construção do projeto,
passando a ser atribuídos a pessoas apenas em sua fase
de execução (aqui a atividade será chamada de tarefa).
• Mas, nem desenvolvedores nem clientes ou usuários são
aptos para escreverem por si sós o modelo do problema.
Responsáveis e Participantes
• Outras atividades com participação dos usuários-chave:
• Desenho das interfaces de usuário;
• Revisões;
• Avaliações do produto;
• Testes de aceitação;
• Procedimentos de implantação.
• Outras equipes de modelagem de sistema:
• Desenvolvedores de hardware, redes e bancos de dados;
• Especialistas da área de aplicação;
• Pessoal de marketing e das áreas administrativa e financeira.
Recursos

• Não se deve confundir os recursos com as entradas

de uma atividade.
• Entradas são artefatos que servirão de fonte de
informação ou que serão transformados na atividade
para produzir os artefatos de saída.
• Estas são específicas do projeto.
Recursos

Humanos

Recursos Consumíveis

Físicos
Não consumíveis
*Podem sofre depreciação
Passos
• Deve-se informar como cada um dos artefatos de
saída é produzido a partir dos artefatos de entrada.
• Mas sem entrar em detalhes quanto às tecnologias
a serem usadas.
• Nem sempre os passos de uma atividade são
estritamente sequenciais.
• Indicar em cada passo quais as suas precondições.
Procedimentos
• Explicação adicional à atividade, indicando como
realizá-la com as ferramentas e a tecnologia
disponíveis.
• Se houver mudança de tecnologia na empresa,
podem-se manter os procedimentos antigos
para registro e, ao mesmo tempo, acrescentar os
novos procedimentos.
Regras
• Podem se referir a passos, recursos, artefatos etc.
• As atividades correspondem aos requisitos funcionais
(são coisas que devem ser executadas) e as regras aos
requisitos não funcionais (a maneira como as coisas
devem ser executadas)
Template de documentação de
atividade de projeto
Processo: <nome do processo>
Fase: <número e nome da fase>
Disciplina: <número e nome da disciplina>
Atividade <número e nome da atividade>
Versão: <número da versão atual, data e autor da modificação>
<número da versão, data e autor da modificação>
...
Responsável <perfil ou papel>
Participantes (Opcional): <perfil ou papel 1>
<perfil ou papel 2>
...
Entradas(Opcional): <artefato 1>
<artefato 2>
...
Template de documentação de
atividade de projeto (cont...)
Saídas: <artefato 1>
<artefato 2>
...
Recursos (opcional): <recurso 1>
<recurso 2>
...
Passos:
<Passo 1> <descrição>
Precondições: <números de atividades>
Regras:
• <regra 1>
• <regra 2>
...
<procedimento segundo tecnologia 1>
<procedimento segundo tecnologia 2>
...
... ...
Template de documentação de
atividade de projeto (Exemplo)
Processo: MPU – Meu Processo Unificado
Fase: 1. Concepção
Disciplina: 1.2. Requisitos
Atividade 2.5 Captura de Requisitos a Partir das Entrevistas.
Versão: 2.0 13/07/2018 Raul Sidnei Wazlawick
1.1 05/06/2012 Raul Sidnei Wazlawick
1.0 18/01/2012 Raul Sidnei Wazlawick
Responsável Analista de requisitos
Participantes NA
(Opcional):
Entradas • Transcrição de entrevistas com o cliente.
(Opcional): • Sumário executivo do projeto.
• Definição de escopo do projeto.
Template de documentação de
atividade de projeto (Exemplo)
Saídas: • Documento de requisitos iniciais.
Recursos (opcional): • Template de documento de requisitos.
• Ferramentas CASE.
Passos:
1 Listar requisitos funcionais candidatos.
Precondições: -
Regras:
• Numerar os requisitos funcionais como RF01, RF02 etc.
• Iniciar sempre com verbo no infinitivo.
EA v6.0: Criar diagrama de requisitos e criar uma caixa para cada requisito
candidato preenchendo o texto do requisito no campo “description”
VP v8.3: Criar um diagrama de requisitos e uma classe estereotipada como
<<requirement>> para cada requisito, preenchendo o texto do requisito no
atributo “text”, e prenchendo o atributo “kind” com “functional”.
Template de documentação de
atividade de projeto (Exemplo)
2 Listar requisitos suplementares e não funcionais.
Precondições: 1
Regras:
• Associar requisitos não funcionais a algum requisito funcional.
• Classificar requisitos suplementares pelo seu tipo: interface, segurança,
tolerância a falhas, performance etc.
• Não criar requisitos desnecessários.
EA v6.0: Criar requisitos suplementares em um pacote separado dos
funcionais. Indicar os requisitos não funcionais após o texto do requisito
funcional associado indicado pela marca “RESTRIÇÕES”.
VP v8.3: Criar requisitos suplementares em um pacote separado. Criar
requisitos não funcionais como classes estereotipadas do diagrama com
atributo “kind” preenchido com o tipo do requisito (interface, segurança etc.)
Template de documentação de
atividade de projeto (Exemplo)
3 Agrupar requisitos funcionais em pacotes.
Precondições: 1
Regras:
• Não permitir que mais de 20 requisitos estejam em cada pacote, a não ser em
casos que se trate efetivamente de requisitos altamente coesos.
• Agrupar os requisitos em pacotes por afinidade, ou seja, requisitos mais
próximos são aqueles que tratam dos mesmos objetos.
• Requisitos do tipo inserir, alterar, remover e consultar, sobre um objeto devem
ser agrupados em um único requisito “manter” estereotipado como <<crud>>.
4 Gerar o documento de requisitos.
Precondições: 2, 3
Regras:
• Deve ser gerada uma versão pdf para impressão e uma versão html que ficará
on-line na intranet do projeto.
EA v6.0: Usar o gerador de documentação acessível a partir do menu superior.
VP v8.3: Usar a opção “generate report” disponível no menu superior.
Observações sobre o Template
• No caso dos procedimentos suportados por ferramentas, é importante anotar
também a versão da ferramenta para a qual esse procedimento foi escrito.
• Cada vez que a ferramenta for atualizada no ambiente de trabalho, deve-se
revisar se os procedimentos continuam os mesmos e registrar o novo
procedimento, se for o caso.
• Se os usuários desse documento acharem que alguma parte não está
suficientemente clara, devem solicitar mudanças ao engenheiro de software que
cuida do processo.
• As organizações devem ter equipes de processo constituídas por um ou mais engenheiros de
software, que serão responsáveis pela manutenção, avaliação e otimização do processo.
• É altamente recomendável que tais documentos sejam elaborados como hipertextos
que o leitor possa ler no nível de detalhe que lhe interessa no momento.
Processos da Indústria de
Software
• Processos de acordo: Incluem as atividades de aquisição e
fornecimento (de acordos cliente-fornecedor, definindo marcos e
entregáveis, por exemplo).
• Processos organizacionais de viabilização de projetos (processos de
suporte): Dão apoio às atividades de engenharia.
• Processos de gerenciamento técnico: Processos de gerenciamento
de projeto mais fortemente relacionados com o produto de software
em si.
• Processos técnicos: Atividades que historicamente sempre foram
associadas à produção de software especificamente.
Processos de gerenciamento
técnico

Planejamento de Avaliação e Gerenciamento de

projeto controle de projeto decisão

Gerenciamento de Gerenciamento de Gerenciamento de

risco configuração informação

Garantia de
Medição
qualidade
Processos técnicos

Necessidades dos
Análise de negócio ou Definição de requisitos Definição de
interessados e definição
missão de sistema/software arquitetura
de requisitos

Análise de sistema Implementação Integração Verificação

Transição Validação Operação Manutenção

Desativação