Resumo - Engenharia de software - Estácio

Prévia do material em texto

ENGENHARIA DE SOFTWARE 
TEMA 2: FUNDAMENTOS DE SOFTWARE E GERENCIAMENTO DE PROJETOS 
Módulo 1. Reconhecer os conceitos básicos relacionados com o desenvolvimento de software 
• A importância do software é facilmente perceptível em função dos inúmeros serviços digitais 
disponíveis na nossa Sociedade 
• O software tem que ser projetado aplicando-se as melhores práticas da engenharia. 
• A engenharia de software é uma disciplina que aborda aspectos técnicos para a criação de 
software. 
• A engenharia, em geral, depende de processos estruturados, ou seja, não existe engenharia 
sem processo. 
• O Gerenciamento de Projetos é uma área essencial em qualquer engenharia para otimizar 
recursos (pessoas, materiais, equipamentos). 
• O Gerenciamento de Projetos é uma metodologia que permite planejar e controlar a geração 
do produto conforme os requisitos identificados. 
• Gerenciamento de Projetos é fundamental para engenheiros de software. 
• Destaca-se, ainda o Gerenciamento de Riscos, especialmente na seleção de portfólio de projetos 
de software. 
 
SOFTWARE 
Importância do Software no Cotidiano: 
• A maioria das pessoas considera impossível viver sem smartphones hoje em dia. 
• A atratividade do smartphone está fortemente ligada ao software, que oferece usabilidade 
interativa e intuitiva, resultado do trabalho multidisciplinar de diversos profissionais. 
Definição de Software: 
1. Conjunto de instruções que, quando executadas, fornecem funções e desempenho. 
2. Estruturas de dados que permitem a manipulação adequada das informações. 
3. Informação descritiva sobre a operação e uso dos programas. 
Relação Software e Hardware: 
• Implicitamente, o software relaciona-se com o hardware. 
• Essa relação gerou a denominada “Crise do Software”: 
✓ Edsger Dijkstra (1972) destacou que a causa principal da crise é o aumento significativo da potência 
das máquinas. 
✓ Programação era um problema menor com computadores fracos, mas se tornou gigantesco com 
computadores potentes. 
• A frase destaca que o aumento exponencial da capacidade dos computadores, ao invés de 
simplificar, amplificou os desafios da programação, contribuindo significativamente para a Crise 
do Software, onde os problemas associados ao desenvolvimento de software se tornaram 
proporcionalmente maiores e mais complexos. 
Finalidade do Software: 
• Uma das principais finalidades do software: a geração de informação. 
• O software distribui o produto mais importante da nossa era: a informação. 
• Gerar informação e agregar valor aos dados para diferentes níveis de gestão empresarial 
(operacional, gerencial e estratégico). 
• Exemplo: Software embarcado em aeronaves para controle total e informações críticas para o 
piloto. 
O software pode ter dois papéis: 
• Produto utilizado pelos usuários. 
• Veículo de distribuição de informações, essencial para a comunicação entre componentes de 
um sistema de informação. 
Desafios do Engenheiro de Software: 
• Software de sistema: Atende outros softwares (sistemas operacionais, drivers). 
• Software de aplicação: Software com escopo específico (sistemas de gestão empresarial). 
• Software de engenharia/científico: Aplicado em áreas como engenharia civil ou processamento de 
imagem. 
• Software embarcado: Instalado em produtos com funções específicas (controle de veículos). 
• Software para linha de produtos: Projetado com determinado conjunto de funcionalidades e utilizado 
por diferentes clientes (sistemas emissores de nota fiscal). 
• Softwares para aplicações web/aplicativos móveis: Software específico para dispositivos móveis. 
• Software de inteligência artificial: Utiliza técnicas de inteligência artificial, como redes neurais, sistemas 
especialistas e aprendizado de máquinas. 
 
ENGENHARIA DE SOFTWARE 
Complexidade do Software: 
• No exemplo de software embarcado em aeronaves e no controle de tráfego aéreo destaca-se a 
complexidade. 
• Tratar a complexidade no desenvolvimento de software é fundamental. 
• Portanto, a aplicação de metodologias que permita a decomposição do problema em 
problemas menores de forma sistemática, cabe à engenharia. 
Importância da Engenharia: 
• Engenharia é essencial para solucionar problemas complexos. 
• Quanto maior a complexidade dos produtos, mais a engenharia faz-se necessária. 
Exemplo Comparativo: 
• Construção de uma casa simples pode ser resolvida por um engenheiro. 
• Construção de um edifício inteligente requer uma abordagem multidisciplinar e sistemática, 
envolvendo vários profissionais (arquiteto, engenheiros civis, mecânicos, elétricos, de software 
etc). 
• A mesma correlação pode ser aplicada quando o produto a ser gerado é o software. No caso 
do software, aplica-se a Engenharia de Software. 
Engenharia de Software: 
• A engenharia de software aplica os mesmos princípios das engenharias tradicionais ao 
desenvolvimento de software. 
• O desenvolvimento de software, é diferente dada a sua intangibilidade e alta volatilidade, e 
devido a constantes evoluções tecnológicas e de requisitos. 
Origem do Termo "Engenharia de Software": 
• A primeira referência ao termo engenharia de software surgiu em 1968, durante uma 
conferência organizada pelo Comitê de Ciência da NATO (North Atlantic Treaty Organization). 
Definição de Engenharia de Software: 
• Aplicação de uma abordagem sistemática, disciplinada e quantificável para desenvolvimento, 
operação e manutenção de software. 
• É a aplicação de engenharia ao software. 
 
TECNOLOGIA EM CAMADAS 
• A Engenharia de Software é uma tecnologia em camadas: 
✓ Camada de qualidade: Garante que os requisitos que atendem às expectativas do usuário serão 
cumpridos. 
✓ Camada de processo: Determina as etapas de desenvolvimento do software. 
✓ Camada de métodos: Define quais as técnicas de elicitação de requisitos, os artefatos gerados em 
função da técnica de modelagem adotada, tal como, modelo de casos de uso ou de classes. 
✓ Camada de ferramentas: Estimula a utilização de ferramentas “CASE” (Computer-Aided Software 
Engineering) no desenho dos diversos artefatos ou mesmo na geração automática de código, entre 
outras aplicações; a tecnologia 
CASE está disponível para uso em 
todas as etapas do processo de 
desenvolvimento de software. 
 
• A construção de um software necessita de processo; esse deverá ocorrer de acordo com as 
melhores práticas estabelecidas pela Engenharia de Software. 
• A base da Engenharia de Software é a camada de processo. 
 
PROCESSO DE SOFTWARE 
Definição de Processo de Software: 
• Processo é uma sequência de etapas que permite gerar um produto (software). 
• O processo facilita a gestão da complexidade do desenvolvimento. 
• Uma vez que envolve trabalho multidisciplinar (analistas, programadores, gerentes de projeto, 
gerentes de teste, etc.). 
Diversidade de Modelos de Processos na Engenharia de Software: 
• A Engenharia de Software possui diversos modelos que atendem a diferentes problemas de 
desenvolvimento de software. 
• A seleção do processo depende da complexidade do sistema. 
• Quanto maior a complexidade um sistema, mais formal deve ser o processo adotado. 
• Importância da Qualidade: A qualidade é a camada base que sustenta o processo de 
desenvolvimento de software. 
Metodologia de Processo Genérica compreende cinco atividades: 
1. Comunicação: 
✓ Envolve comunicação intensiva com os usuários. 
✓ Busca entender o problema, definir objetivos e identificar requisitos. 
2. Planejamento: 
✓ Permite a elaboração de um Plano de Gerenciamento do Projeto. 
✓ O Plano de Gerenciamento do Projeto inclui entregas importantes, como o cronograma e as 
principais atividades a serem desenvolvidas. 
✓ O Plano de Gerenciamento do Projeto deve ser executado e monitorado. 
3. Modelagem: 
✓ Busca geração de modelos (diagramas) que podem ser complementados por descrições textuais. 
✓ Exemplos: Diagramas de casos de uso. 
4. Construção: 
✓ Implementaçãosoftware ao usuário final. 
o Pode ser manual ou automática com ferramentas específicas. 
4. Instalação do Software: 
o Inclui o processo de instalar todos os arquivos necessários para executar o software. 
5. Prestação de Suporte aos Usuários: 
o Quando a complexidade do software exige um serviço de atendimento aos clientes para esclarecimentos sobre 
funcionalidades e suporte técnico. 
o Exemplo: serviço de help desk para resolver dúvidas e problemas técnicos. 
 
 
GESTÃO DE CONFIGURAÇÕES x IMPLANTAÇÃO 
• Exemplo: Estamos desenvolvendo um software utilizando o fluxo de processo iterativo e 
incremental, ou evolucionário. 
• Após os testes, é gerada a primeira versão e a disponibilizamos no ambiente de produção. 
• Posteriormente, é realizada a implantação da primeira versão. 
• Segunda versão é desenvolvida em paralelo, com a disponibilização da primeira versão. 
• Durante o desenvolvimento da segunda versão, é analisado um conjunto de requisitos e um 
novo ciclo interativo. 
• O engenheiro deve lidar com dois problemas: o controle de alterações e o controle de versões. 
• Nesta etapa deve-se considerar aspectos que relacionam a gestão de configurações com a 
implantação de um sistema. 
• Gestão de Configuração: É um conjunto de tarefas que visa gerenciar as alterações durante o 
desenvolvimento de software. 
• Aplicação da gestão de configuração: É aplicada em todas as etapas do processo de 
desenvolvimento de software. 
• Uma das tarefas do processo de gestão de configuração é denominada controle de alterações. 
• Controle de alterações: Permite solucionar o primeiro problema 
apresentado, ou seja, é essencial para resolver problemas identificados 
após a implantação. 
Exemplo: A Figura ao lado ilustra um processo de controle de alterações, que, a partir 
de uma solicitação de alteração. A solicitação de alteração requer a avaliação do mérito 
técnico, dos efeitos colaterais em potencial, do impacto global em termos de 
configuração e da funcionalidade e do custo da alteração. Na referida figura, o acrônimo 
ECO (Engineering Change Order) representa um pedido de alteração de engenharia. 
 
• Importância do Controle de Alterações: 
• O processo tem de estar bem definido e ajustado à complexidade 
do software quando implantado. 
• Porque os defeitos serão identificados em produção, e os 
procedimentos de alteração estarão definidos. 
• Em projetos complexos, a falta de um controle de alterações pode 
gerar o caos. 
• Isso porque a fase de testes não é capaz de zerar a existência de erros. 
• Controle de versões: No contexto do gerenciamento de configuração, podemos destacar o 
gerenciamento de releases. 
• O controle de versões gerencia diferentes releases do software. 
• Um release de sistema é uma versão do sistema distribuída aos clientes. 
• A gestão de releases determina quando um release será liberado para o cliente, gerencia o 
processo de criação e os de meios de distribuição, bem como documenta o release. 
• Um release pode incluir: 
✓ Arquivos de configuração 
✓ Arquivos de Dados 
✓ Um Programa de instalação 
✓ Documentação eletrônica ou em papel. 
✓ Empacotamento e publicidade associada. 
 
MANUTENÇÃO 
• A manutenção é iniciada imediatamente após a implantação do software. 
• É a etapa mais longa do ciclo de vida do software. 
• Objetivos da Manutenção: 
✓ Corrigir defeitos não identificados nas etapas anteriores. 
✓ Aprimorar a implementação dos subsistemas. 
✓ Disponibilizar novas funcionalidades baseadas em novos requisitos. 
• Desafios: 
✓ Após o início da etapa de manutenção, relatos de erros e solicitações de adaptação e 
melhorias começam a chegar rapidamente. 
✓ Correções, adaptações e melhorias devem ser planejadas, programadas e executadas. 
✓ Portanto, a gestão de alterações é crucial para o sucesso da manutenção. 
✓ Além disso, a mobilidade dos engenheiros de software, com possíveis substituições ou 
dissolução da equipe original, pode dificultar a manutenção eficiente. 
• Importância do Cumprimento de Etapas: 
✓ Garantir que todas as etapas do processo de desenvolvimento de software sejam 
corretamente seguidas. 
✓ De modo que gere uma solução bem estruturada para o projeto. 
✓ O que permite o entendimento da solução por parte de um engenheiro de software que 
não trabalhou no desenvolvimento do produto. 
• Manutenibilidade: 
✓ Toda solução que aplica as melhores práticas da engenharia de software busca o 
cumprimento do requisito não funcional denominado manutenibilidade. 
✓ A manutenibilidade é um indicativo qualitativo da facilidade de corrigir, adaptar ou 
melhorar o software. 
 
• Objetivo da Engenharia de Software: Criar sistemas com alta manutenibilidade, permitindo 
fácil manutenção e evolução do software ao longo do tempo. 
 
MANUTENÇÃO x REENGENHARIA DE SOFTWARE 
• Manutenção ao Longo do Tempo: Ao longo do tempo, a equipe de engenheiros de 
software realiza as manutenções necessárias em função da: 
✓ Correção de erros detectados. 
✓ Alterações devido à volatilidade dos requisitos. 
• Paralelamente, a tecnologia torna-se obsoleta, dificultando a manutenção. 
• Solução para isso é a reengenharia. 
• Definição de reengenharia: A reengenharia é o processo de reconstrução do produto com 
mais funcionalidades, melhor desempenho, confiabilidade e manutenibilidade. 
• A reengenharia possui dois níveis: 
✓ Reengenharia de processos de negócio. 
✓ Reengenharia de software. 
• Reengenharia de Processos de Negócio: 
✓ A reengenharia de processos de negócio é também conhecida como estratégico. 
✓ Visa aumentar a eficiência e competitividade da empresa por meio de alterações em regras de 
negócio. 
 
• Um software tem como importante objetivo agregar valor a uma organização por meio da 
automação de processos. 
• Alterações no negócio devem ser refletidas na engenharia de software, gerando dois 
cenários: 
✓ Cenário 1: Construção de um novo software. 
✓ Cenário 2: Modificação de um software existente. 
• Na modificação de um software existente (cenário 2), aplicamos a reengenharia de software, 
o que extrapola os objetivos da etapa manutenção, ou seja, vai além dos objetivos da 
manutenção. 
• Reengenharia de Software: Permite a modificação de um software existente a partir de 
alterações significativas nas regras de negócio. 
 
TEMA 4: MODELOS DE PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 
• Para o desenvolvimento de um software, temos vários especialistas, tais como: engenheiros 
de software, web designers, administradores de banco de dados, arquitetos de software e 
outros. 
• Esta equipe de composição multidisciplinar, reflete uma característica do software: a 
complexidade. 
• Tratar a complexidade requer a aplicação da Engenharia de Software que, por sua vez, tem 
como base a camada de processos. 
• Dito isso, podemos afirmar que não existe engenharia sem processo. 
• Nesse contexto, é essencial conhecermos os principais modelos de processos de 
desenvolvimento de software. 
• A escolha dos modelos depende da sua complexidade, pois quanto mais complexo, mais 
formalismo deve estar embutido no modelo adotado. 
 
Módulo 1: Descrever os modelos prescritivos do processo de desenvolvimento e software 
ENGENHARIA DE SOFTWARE 
• Os modelos de Processo de Desenvolvimento de Software têm este como principal produto 
no contexto da Engenharia de Software. 
• O software possui alta volatilidade em função dos requisitos, visto que é constantemente 
impactado pelas evoluções na tecnologia. 
• Estes fatores agregam a ele uma complexidade adicional. 
 
• A melhor tratativa para a complexidade é a aplicação de metodologia que permita a 
decomposição do problema em outros menores de forma sistemática, cabendo à Engenharia 
de Software tal sistematização. 
• A Engenharia de Software é uma tecnologia em camadas: 
✓ Camada de qualidade: Garante o cumprimento dos requisitos que atendem às expectativas dos 
usuários. 
✓ Camadade processo: Determina as etapas de desenvolvimento do software. 
✓ Camada de métodos: Define as técnicas de levantamento de requisitos, os artefatos gerados em 
função da técnica de modelagem (como modelos de casos de uso ou de classes). 
✓ Camada de ferramentas: Estimula a utilização de ferramentas “CASE” no desenho dos diversos 
artefatos ou mesmo na geração automática de código, entre outras aplicações. 
 
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 
✓ O processo de desenvolvimento de software é iniciado com especificações e modelos com 
alto nível de abstração. 
✓ À medida que o desenvolvimento de software se aproxima da codificação, o nível de 
abstração diminui. 
✓ O código representa o nível mais baixo de abstração (maior detalhamento). 
• Atividades Típicas no Processo de Desenvolvimento: São as atividades genéricas 
incorporadas por qualquer processo, onde a ênfase dada a cada atividade varia entre 
diferentes modelos de processo. 
 
Atividades Típicas de um Processo de Desenvolvimento de Software 
✓ Comunicação: 
o São as primeiras atividades de um processo de software. 
o Requerer uma comunicação intensiva com os usuários, buscando o entendimento do 
problema, a definição de objetivos para o projeto, bem como a identificação de requisitos. 
✓ Planejamento: 
o Envolve conhecimento e gerenciamento de projeto, o que permite a elaboração do Plano de 
Gerenciamento do Projeto. 
o Entrega importante: criação de um cronograma das atividades a serem desenvolvidas. 
✓ Modelagem: 
o Envolve a geração de modelos gráficos (diagramas) e descrições textuais. 
o Exemplo: modelo de casos de uso. 
✓ Construção: 
o Ocorre a implementação do software a partir dos modelos gerados. 
o Os modelos determinam o comportamento do software. 
o Inclui codificação e testes de software conforme o planejamento. 
✓ Entrega: 
o Trata-se da finalização e entrega do produto de software em produção. 
o A Entrega deve estar alinhada com o plano de projeto de software. 
 
MODELOS DE PROCESSOS PRESCRITIVOS 
• A Engenharia de Software permite: Sistematizar o desenvolvimento de software por meio de 
processos. 
• Modelo de Processo: 
✓ Identifica as atividades a serem desenvolvidas. 
✓ Sistematiza o trabalho de engenharia de software. 
✓ Inclui atividades, fluxos de processos, artefatos gerados, etc. 
✓ Proporciona estabilidade, controle e organização. 
• O que diferencia os modelos dos processos? 
✓ Todas as atividades típicas do processo (comunicação, planejamento, modelagem, construção e entrega) são 
utilizadas em todos os modelos. 
✓ Porém, cada modelo enfatiza de forma diferente cada atividade. 
✓ O encadeamento dessas ações é denominado fluxo de processo. 
• Definição de Modelos de Processos Prescritivos: 
✓ Modelos de Processos Prescritivos representam um conjunto estruturado de elementos de 
processo. 
✓ Definem metodologias, tarefas, artefatos, garantia da qualidade e mecanismos de controle 
de mudanças. 
• Tipos de Modelos de Processos Prescritivos: 
1. Modelo em cascata 
2. Modelo de processo incremental 
3. Modelo de processo evolucionário 
4. Prototipação 
5. Modelo espiral 
 
 
❖ MODELO EM CASCATA 
• Descrição do Modelo em Cascata: 
✓ Utiliza uma abordagem sequencial para a execução das atividades do desenvolvimento 
de software, ou seja, as atividades são executadas de forma encadeada. 
✓ É o modelo de processo mais antigo, utilizado na engenharia de software. 
✓ Era dominante na era do desenvolvimento estruturado. 
• Características Negativas do Modelo em Cascata: 
✓ Volatilidade dos Requisitos: Os projetos raramente seguem um fluxo sequencial devido às 
mudanças nos requisitos. 
✓ Requisitos Detalhados Antecipadamente: Supõe que o cliente pode detalhar todas as 
necessidades antes do desenvolvimento, o que é impraticável e pode levar à propagação de erros. 
✓ Inflexibilidade na divisão do projeto: Possui uma divisão rígida em fases, com o software 
disponível somente ao final do projeto. 
• Podemos aplicar o modelo em cascata em projetos com requisitos fixos e de forma que o 
fluxo de trabalho possa ser realizado sequencialmente até o seu encerramento. 
 
❖ MODELOS DE PROCESSO INCREMENTAL E EVOLUCIONÁRIO 
• Desenvolvimento em Ciclos: 
✓ Tanto o modelo de processo incremental quanto o modelo de processo evolucionário, 
dividem o desenvolvimento do software em ciclos, cada um contendo todas as 
atividades do processo de software. 
✓ Cada ciclo resulta em uma entrega ao usuário final, adicionando novas funcionalidades. 
• Como ocorre as iterações e Entregas: 
✓ Ocorre a repetição iterativa das atividades típicas do processo de software. 
✓ Onde, cada iteração aborda um subconjunto de requisitos, havendo uma entrega a cada 
final de ciclo. 
✓ As entregas frequentes agregam valor imediato ao usuário. 
• Vantagens do modelo de processo incremental e evolucionário: 
✓ Adaptam-se bem a restrições de prazo e alta volatilidade dos requisitos. 
✓ Permitem gerar versões limitadas rapidamente, oferecendo valor imediato. 
• Diferenças entre os Modelos: 
✓ Modelo Incremental: 
o Inicialmente ocorre a entrega de um produto essencial. 
o Iterações subsequentes são bem definidas e adicionam funcionalidades incrementais. 
✓ Modelo Evolucionário: 
o Inicialmente a entrega é baseada em um entendimento parcial dos requisitos. 
o As diferentes versões são criadas em função desse entendimento parcial dos requisitos. 
o Iterações subsequentes refinam o entendimento do problema e adicionam novos requisitos. 
o Assim, são geradas novas versões conforme o entendimento e os requisitos evoluem. 
 
Figura – O modelo incremental. 
❖ PROTOTIPAÇÃO 
• Prototipação: Envolve a criação de um protótipo em escala reduzida para testes e avaliações 
iniciais. 
✓ Na prototipação o desenvolvedor colabora diretamente com o usuário. 
✓ Ocorre um feedback contínuo que permite desenvolvimento iterativo e evolucionário do 
protótipo. 
• Usos do Protótipo: 
✓ O primeiro protótipo gerado, geralmente serve para validar requisitos. 
✓ Que pode ser descartado ou refinado e integrado ao sistema final, dependendo das 
necessidades e complexidade. 
• Aplicabilidade da prototipação: 
✓ Modelo de processo efetivo para resolver problemas de baixa complexidade. 
✓ Útil para obter feedback rápido e ajustar requisitos antes do desenvolvimento final. 
 
❖ MODELO ESPIRAL 
• O Modelo Espiral foi originalmente proposto por Barry Boehm em 1988. 
• Funcionamento da estrutura do modelo espiral: 
✓ Cada quadrante da espiral representa uma etapa do desenvolvimento. 
✓ Cada loop da espiral representa uma fase do processo de software. 
✓ O loop mais interno pode estar relacionado à viabilidade do sistema, seguido pelo 
levantamento de requisitos e assim por diante. 
• Etapas do Modelo: 
✓ Primeira Etapa (Analysis): 
o Inclui a determinação de objetivos, alternativas, riscos e restrições. 
o Envolve o comprometimento dos stakeholders. 
o E o estabelecimento de uma estratégia para alcançar os objetivos. 
✓ Segunda Etapa (Evaluation): 
o Inclui a avaliação de alternativas, identificação de 
riscos e análise de riscos. 
o Utilização da prototipação como ferramenta para 
mitigação de ameaças e riscos potenciais. 
✓ Terceira Etapa (Development): 
o Ocorre o desenvolvimento do produto. 
✓ Quarta Etapa (Planning): 
o Ocorre a avaliação do produto desenvolvido. 
o É realizado um planejamento para o início de um 
novo ciclo na espiral. 
Figura – O modelo espiral. 
Pode ser utilizada a abstração de forma a visualizar o modelo espiral como um metamodelo, apresentado na Figura 
abaixo, na qual a espiral do modelo é dividida nas atividades genéricas. 
 
Figura – O modelo espiral. 
 
• O Modelo Espiral, incorpora as melhores características do Ciclo de Vida Clássico e da 
Prototipação e acrescenta o seguinte elemento: Análise dos riscos. 
✓ Modelo Espiral: 
o Combinação do Ciclo de Vida Clássico e da Prototipação. 
o Estrutura em formade espiral com múltiplos loops que representam diferentes fases do 
desenvolvimento. 
✓ Análise de Riscos: 
o Introduzido como um componente fundamental em cada loop da espiral. 
o Foca na identificação, avaliação e mitigação de riscos ao longo do processo de 
desenvolvimento. 
✓ Características Incorporadas: 
o Ciclo de Vida Clássico: Sequencialidade das fases, como análise de requisitos, projeto, 
implementação e testes. 
o Prototipação: Uso de protótipos para validar e refinar requisitos. 
✓ Objetivo do Modelo espiral: 
o Gerenciar riscos de forma proativa, adaptando-se às mudanças e incertezas durante o 
desenvolvimento. 
• Portanto, o Modelo Espiral é reconhecido por integrar esses elementos para proporcionar um 
processo de desenvolvimento mais flexível e adaptável, especialmente em projetos onde a 
incerteza e a complexidade são altas. 
 
Módulo 2: Explicar o processo unificado para o desenvolvimento de software 
UNIFIED MODELING LANGUAGE (UML): 
Evolução do uso do paradigma estruturado para o paradigma orientado a objetos: 
• Até a década de 1990, o paradigma estruturado era o padrão de desenvolvimento mais 
utilizado na indústria de software. 
• Os métodos utilizados no paradigma estruturado aplicavam os conceitos estruturados nos 
artefatos gerados, como o diagrama de fluxo de dados na etapa de análise. 
• A unidade básica do software desenvolvido no paradigma estruturado era a função. 
• Com a evolução da complexidade do software, a adoção da orientação a objetos permite 
lidar melhor com complexidade, reuso e manutenibilidade. 
• A unidade básica do software passou a ser o objeto, que inclui dados ou atributos, e 
funções ou métodos, encapsulados. 
A Linguagem de Modelagem Unificada (UML): 
• É um padrão de modelagem para desenvolvimento no contexto do paradigma orientado a 
objetos. 
• A UML foi introduzida em 1996 e adotada como padrão pelo Object Management Group 
(OMG) em 1997. 
• É uma linguagem visual, que independe da linguagem de programação e do processo de 
desenvolvimento. 
Características da UML: 
• A UML envolve a criação de artefatos gráficos (diagramas) e descrições textuais. 
• Serve como linguagem de comunicação entre diferentes stakeholders no desenvolvimento 
de software. 
Definição como Linguagem: 
• A UML foi definida como linguagem, pois serve para comunicação possuindo uma sintaxe 
em uma semântica associada. 
• A UML possui sintaxe e semântica claras para estruturar diagramas. 
• A sintaxe determina o padrão de escrita (ex. como a estrutura de uma frase formada por 
“sujeito + verbo + predicado”); 
A figura ao lado ilustra a estrutura de uma classe 
(com o nome da classe, atributos e métodos). 
Esse padrão de desenho (sintaxe do modelo), é 
definido pela UML. 
• A semântica está associada ao significado 
da frase (ex. como “Carlos foi ao clube”). 
Semântica refere-se à formação de uma rede semântica com objetos e associações representando domínios 
específicos de problema, conforme imagem abaixo. 
 
• A linguagem serve para a comunicação. 
• A UML facilita a comunicação no desenvolvimento de software. 
Interação entre Profissionais: 
• A UML permite a comunicação entre engenheiros de software. 
• Facilita a validação dos modelos pelos usuários. 
• Suporta a interação com gerentes de projeto e programadores. 
Compreensão Universal: 
• Diagramas de classes desenhados por um engenheiro de software são compreensíveis por 
outros engenheiros que utilizam o paradigma orientado a objetos. 
Os diagramas especificados na UML, se dividem em duas categorias: diagramas estruturais e diagramas 
comportamentais, como mostra a Figura abaixo. 
✓ Diagramas estruturais: Descrevem a estrutura estática do sistema, incluindo a estrutura dos dados e a 
relação entre os diferentes elementos. Eles mostram os componentes do sistema e como eles se 
relacionam. 
✓ Diagramas comportamentais: Descrevem o comportamento dinâmico do sistema, ou seja, como o 
sistema funciona e interage ao longo do tempo. Eles mostram a lógica de negócios e o fluxo de 
controle. 
 
Figura – Diagramas da UML 
 
PROCESSO UNIFICADO 
Origem do RUP: O Processo Unificado também denominado de Rational Unified Process (RUP) 
foi criado pela Rational Software Corporation (fundadores da UML), adquirida pela IBM. 
Rational Unified Process (RUP): 
✓ É um modelo de processo prescritivo. 
✓ É um processo formal adaptável a problemas de alta complexidade. 
✓ Ele é caracterizado por sua formalidade e estruturação, garantindo que cada etapa do 
desenvolvimento seja realizada de maneira consistente e repetível. 
✓ Apesar de ser um processo prescritivo, ele pode ser customizado para projetos de qualquer 
escala. 
Três Princípios do RUP: 
1. Guiado por Casos de Uso: 
o O desenvolvimento é planejado com base nos casos de uso. 
o O processo é iniciado pela abstração funcional, focando nos serviços desejados pelos usuários. 
2. Centrado em Arquitetura: 
o Enfatiza o papel da arquitetura para focar em metas como compreensibilidade, confiança em 
mudanças futuras e reutilização. 
o A arquitetura está alinhada com os requisitos e decisões estruturais e comportamentais, 
destacando a modularização da solução. 
3. Iterativo e Incremental: 
o Aplica modelo de processo de software iterativo e incremental. 
o O RUP possui como princípio ser iterativo e incremental. 
▪ Iterativo: porque as atividades se repetem a cada nova iteração, permitindo um melhor 
entendimento do negócio, ou seja, compreensão gradativa dos requisitos de software à 
medida que o desenvolvimento avança. 
▪ Incremental: porque de acordo com a evolução do projeto, são incorporados novos 
requisitos, permitindo versionamento das entregas. 
o Entretanto, as entregas não necessariamente ocorrem ao final de cada iteração. 
 
• O RUP possui um aspecto bidimensional, conforme mostra a figura abaixo: 
✓ Dimensão Horizontal: Representa as fases do projeto, capturando o aspecto temporal e podendo 
ser usadas como marcos. 
✓ Dimensão Vertical: Representa as atividades iterativas. 
 
Figura – O Processo Unificado 
 
• O processo RUP possui as seguintes fases (dimensão horizontal): 
1. Iniciação 
2. Elaboração 
3. Construção 
4. Transição. 
❖ INICIAÇÃO 
• Visão Inicial do Sistema: 
✓ A fase de iniciação é também denominada de concepção. 
✓ O engenheiro de software deve ter uma visão inicial e geral do sistema a ser desenvolvido. 
✓ É possível o uso de modelos de estado ou atividades no desenho dos processos de negócio. 
✓ A modelagem inicial assegura que todas as partes interessadas compreendam o domínio do 
problema. 
• Obtenção de Requisitos: 
✓ A partir dessa compreensão do negócio, pode-se determinar os requisitos funcionais e não 
funcionais. 
✓ São modelados os casos de uso mais críticos. 
✓ São modelados os diagramas de classes para entender a estrutura de dados. 
• Estabelecimento do Escopo do Projeto: 
✓ A identificação dos principais requisitos, junto aos modelos de casos de uso e classes, permite o 
estabelecimento do escopo do projeto. 
✓ Arquitetura do sistema limitada a um esquema provisório. 
• Desafios: 
✓ Verificação da viabilidade técnica e financeira do projeto. 
✓ Garantia de financiamento. 
✓ Inclusão da análise de riscos. 
• Decisão de Avanço ou não com o projeto: 
✓ Caso positivo: Deve-se realizar o planejamento detalhado demais fases (elaboração, 
construção e transição). 
✓ Caso negativo: Encerramento das atividades. 
 
❖ ELABORAÇÃO 
• Início da Fase de Elaboração: 
✓ Inicia após aprovação do projeto de software. 
✓ Realizada de forma iterativa e incremental. 
✓ O nível de abstração é reduzido nos modelos de casos de uso e de classes, o que finaliza a atividade 
de análise do processo de desenvolvimento software. 
• Atividade de Projeto: 
✓ Ocorre o refinamento de alguns modelos da análise. 
✓ Criação de novos modelos, incluindo o modelo de interação (aspectos dinâmicos do sistema). 
✓ Construçãode um protótipo da interface com o usuário. 
• A Representação Arquitetural é expandida em cinco visões de software: Onde cada visão inclui um 
conjunto de modelos com respectivos diagramas. 
✓ Modelo de casos de uso 
✓ Modelo de análise 
✓ Modelo de projeto 
✓ Modelo de implementação 
✓ Modelo de implantação 
• Minimização de Riscos: 
✓ Nesta etapa também ocorre a identificação e mitigação de riscos associados ao projeto e o 
Planejamento da fase de construção. 
 
❖ CONSTRUÇÃO 
• Segue o Modelo de Arquitetura: 
✓ A fase de construção segue o modelo de arquitetura gerando os componentes. 
✓ Aplica-se o reuso, que tornam os casos de uso operacionais para os usuários. 
✓ Os modelos gerados na fase de elaboração são concluídos para refletir a versão final do 
incremento de software. 
✓ Com o avanço da codificação, são realizados os testes (testes unitários, os testes de integração 
entre os componentes e os testes de validação, até o teste beta - ambiente controlado). 
 
❖ TRANSIÇÃO 
• A fase de transição tem como objetivo realizar a implantação do software no ambiente de 
produção. 
• Inicialmente, o software é disponibilizado aos usuários para realização do teste beta (ambiente 
não controlado), tendo como foco a correção de defeitos e mudanças necessárias em função 
dos feedbacks dos usuários. 
• Nessa fase, podem ocorrer: 
✓ A elaboração dos manuais do usuário. 
✓ Treinamento dos usuários. 
✓ Procedimentos de instalação. 
✓ Montagem de estrutura de suporte ou definição do processo de manufatura. 
• Na conclusão dessa fase, o incremento torna-se uma versão de produção utilizável pela 
comunidade de usuários. 
 
FLUXO DE TRABALHO 
• Atividades Transversais: Compreendem atividades genéricas um processo de desenvolvimento 
de software, que compõem o denominado fluxo de trabalho, sendo as atividades distribuídas 
em todas as fases. 
• Relacionamento Fases do Projeto x Fluxos de Projeto: 
✓ Cada atividade do fluxo de trabalho se desenvolve de forma mais intensa em determinada 
fase. 
Por exemplo: A modelagem de negócio e requisitos possui um fluxo de trabalho intenso na fase de concepção. 
• Por que ocorre a implementação na fase de elaboração: Porque ocorre a validação de 
requisitos por meio da prototipação, que inclui a codificação. A implementação na fase de 
elaboração ocorre para validar requisitos por meio da prototipação. 
• O RUP define três grupos de atividades de apoio ao desenvolvimento: 
✓ Ambiente: Inclui a configuração de processos e ferramentas de suporte à equipe de 
desenvolvimento. 
✓ Gerenciamento de Configuração e Mudança: Permite a estruturação e controle de versão dos 
artefatos. 
✓ Gerência de Projeto: Enfatiza a importância do gerenciamento de projetos, recomendando práticas 
do PMBOK. 
 
Módulo 3: Explicar o processo de desenvolvimento ágil Extreme Programming (XP) 
DESENVOLVIMENTO ÁGIL DE SOFTWARE 
Contexto Histórico: 
✓ Até os anos 1990, processos prescritivos dominavam o desenvolvimento de software. 
✓ Eles exigiam detalhado planejamento, garantia de qualidade, métodos de análise e projeto, 
apoiados por ferramentas CASE. 
✓ Assim, os sistemas de software possuíam alto grau de complexidade, o que exigiam um esforço 
significativo de planejamento, projeto e documentação de sistema. 
Justificativa para Mudança: 
✓ Complexidade desses processos não se justificava para sistemas de menor complexidade. 
✓ Em 2001, um grupo de 17 metodologistas propuseram uma alternativa ao modelo prescritivo. 
✓ Foram criadas as bases para o novo conceito de processo de software, registradas no documento 
denominado Manifesto para o Desenvolvimento Ágil de Software. 
➢ O Manifesto para o Desenvolvimento Ágil de Software possui quatro valores: 
1. Indivíduos e interações mais do que processos e ferramentas. 
2. Software em funcionamento mais do que documentação abrangente. 
3. Colaboração com o cliente mais do que negociação de contratos. 
4. Resposta a mudanças mais do que seguir um plano. 
 
Características dos Métodos Ágeis: 
✓ Possui foco no software em vez de projeto e documentação. 
✓ Possui fluxo de processo iterativo e incremental. 
✓ Adequado para aplicações com alta volatilidade de requisitos. 
Um projeto de software ágil busca a capacidade de implantar uma nova versão a cada incremento, 
enfatizando o software funcional como uma medida primária de progresso. 
 
Objetivos do Desenvolvimento Ágil: 
✓ Implantação de novas versões a cada incremento. 
✓ Software funcional como medida primária de progresso. 
✓ Validação rápida pelo cliente para identificar erros e alterações de requisitos. 
✓ Comunicação em tempo real entre a equipe de desenvolvimento e clientes. 
 
EXTREME PROGRAMMING – XP 
• Extreme Programming (XP): 
✓ Proposto por Kent Beck em 1999. 
✓ É considerado um processo de desenvolvimento de software ágil. 
• Valores da Extreme Programming (XP): 
1. Comunicação: Promove entendimento dos requisitos com mínima documentação e máxima 
interação. 
2. Simplicidade: Adota soluções simples para reduzir custos futuros de mudanças. 
3. Feedback: Permite a obtenção de um feedback contínuo dos testes e da validação funcional dos 
clientes, permitindo a correção de erros e alterações nos requisitos. 
4. Coragem: Encoraja a aceitação de riscos e a confiança nos mecanismos de prevenção. 
5. Respeito: Base para todos os demais valores, fundamental para o sucesso do projeto. 
• Princípios da XP: 
1. Feedback rápido 
2. Assumir simplicidade 
3. Mudança incremental 
4. Abraçar mudanças 
5. Trabalho de qualidade 
• Práticas da XP: 
1. Jogo de Planejamento: Requisitos são registrados como "histórias de usuários", priorizados pelos clientes. A 
equipe estima a duração das releases. 
2. Pequenas Releases: Releases frequentes contendo os requisitos mais importantes. Permitem feedback rápido 
para clientes e equipe, facilitando aprendizado e correção de defeitos. 
3. Metáfora: Usa analogias compreensíveis para o cliente, como "Estoque 4.0", para facilitar a comunicação e 
entendimento do sistema. 
4. Projeto Simples: Foca apenas em funcionalidades definidas e soluções simples e bem estruturadas, 
minimizando complexidade. 
5. Cliente no Local de Trabalho: Um representante do cliente integra a equipe para esclarecer dúvidas e garantir 
que as necessidades do negócio sejam atendidas. 
6. Semana de 40 Horas: Estabelece um ritmo sustentável de trabalho, com horas extras limitadas a períodos 
específicos para evitar sobrecarga. 
7. Programação Pareada: Dois programadores trabalham juntos em um único computador para revisar 
constantemente o código, melhorando qualidade e reduzindo defeitos. 
8. Propriedade Coletiva: Todos os membros da equipe podem modificar qualquer parte do código, promovendo 
conhecimento compartilhado e estabilidade com testes rigorosos. 
9. Padronização do Código: Define regras comuns para programação, facilitando a manutenção e compreensão 
do código por toda a equipe. 
10. Desenvolvimento Orientado a Testes (TDD): Testes automatizados são escritos antes da implementação da 
funcionalidade, garantindo que o código seja robusto desde o início. 
11. Testes de Integração e Validação: Testes de integração são realizados sistematicamente para garantir que 
todos os componentes funcionem juntos. Testes de validação são baseados nas histórias de usuários. 
12. Refatoração: É um processo de modificar a estrutura interna do software sem alterar o seu comportamento 
externo, mantendo a qualidade e reduzindo erros. 
13. Integração Contínua: Cada nova funcionalidade é integrada ao sistema imediatamente, detectando erros de 
integração rapidamente e garantindo compatibilidade contínua. 
PROCESSO XP 
• Processo Extreme Programming (XP): 
✓ Adota o paradigma orientado a objetos. 
✓ Aplica seus valores, princípios e práticas em 
quatro atividades metodológicas: 
1. Planejamento 
2. Projeto 
3. Codificação 
4. Testes. 
 
O PROCESSO ÁGIL EXTREME PROGRAMMING– XP 
❖ Planejamento: O planejamento está fundamentado nas histórias de usuários. 
✓ Levantamento de Requisitos e Definição de escopo: 
o Ouvir o cliente para entender o escopo do problema. 
o Gerar histórias de usuários (cartões) priorizadas pelos clientes. 
✓ Avaliação e Estimativa: 
o Equipe de desenvolvimento avalia e divide as histórias em tarefas. 
o Estima o esforço e recursos necessários. 
✓ Seleção de Histórias: 
o Conjunta entre equipe e clientes, priorizando maior risco e de maior valor para o negócio. 
o Calcula-se a velocidade do projeto após a primeira versão para futuras estimativas. 
o Essa velocidade serve para avaliar se o compromisso firmado está compatível e auxiliar na 
estimativa de prazos das versões seguintes. 
❖ Projeto: O projeto tem um mínimo de formalismo em função de gerar um único tipo de artefato, os 
cartões CRC, sendo sugeridas a prototipação e refatoração nessa etapa. 
✓ Princípio de Simplicidade: 
o Modelagem com cartões CRC (Classe-Responsabilidade-Colaborador), que permitem identificar 
as classes orientadas a objetos relevantes para a iteração corrente do software. Os cartões CRC 
são os únicos artefatos de projeto gerados durante o processo XP. 
o A prototipação é usada para validar requisitos complexos. 
o Promove uso da refatoração contínua para melhorar a organização do código. 
❖ Codificação: A codificação sugere o trabalho em par de programadores alocados em um único 
computador, permitindo uma revisão de código em tempo real. 
✓ Programação em Par: 
o Dois programadores trabalham juntos em um computador. 
o A fim de garantir a qualidade e revisão imediata do código. 
o Ambos os desenvolvedores têm papéis distintos: uma pessoa implementa o código, o outro 
verifica os padrões de codificação. 
✓ Integração Contínua: Integração contínua do código permite identificação precoce de erros. 
❖ Teste: Os testes têm uma característica peculiar, são escritos antes da codificação e aplicados de 
forma sistemática em ambiente automatizado (incluindo testes unitários, de integração e aceitação). 
✓ A equipe de desenvolvimento avalia cada história e a divide em tarefas, que representa uma 
característica discreta do sistema. 
✓ Testes de Unidade: Elaborados antes da codificação e é fortemente recomendada a automação 
desses testes, o que estimula a realização dos testes de regressão toda vez que o código for 
alterado. 
Teste de Regressão é a reexecução de algum subconjunto de testes que já foram conduzidos para garantir 
que as modificações não propagaram efeitos colaterais indesejáveis. 
✓ Testes de Integração: Realizados sistematicamente a cada novo código gerado a ser integrado, 
o que permite lançar alertas logo no início, evitando propagações indesejadas. 
✓ Testes de Aceitação: São elaborados pelos clientes, com base nas histórias de usuários. O foco 
está nas funcionalidades externas visíveis aos clientes. Verificação se o sistema atende às 
necessidades dos usuários. 
 
Módulo 4: Explicar o processo de desenvolvimento ágil SCRUM e o processo unificado ágil 
(AUP) 
METODOLOGIA ÁGIL SCRUM 
• Origem do Termo “Scrum” 
✓ Derivado de um método de reinício de jogada no rugby. 
✓ O termo foi concebido fora da indústria de software como um estilo de gerenciamento 
de produtos. 
✓ A partir de conceitos relacionados com este termo, Jeffrey Sutherland e Ken Schwaber, 
no início dos anos 1990, desenvolveram o Processo de Desenvolvimento SCRUM, 
publicado em 1995. 
✓ Desde então, esse processo passou a ser aplicado no desenvolvimento de software em 
todo o mundo. 
• Desenvolvimento e Aplicação 
✓ A metodologia Scrum evoluiu para abranger o gerenciamento de projetos além do 
desenvolvimento de software. 
✓ Utiliza valores e princípios do manifesto ágil em seu framework. 
✓ Recomendado para projetos complexos onde não é possível definir todos os requisitos 
no início. 
• Três Pilares Fundamentais da Metodologia Scrum: 
1. Transparência: A equipe deve ter um entendimento comum dos aspectos do processo 
usando uma linguagem padrão. 
2. Inspeção: Deve haver inspeção constante de todos os artefatos e progresso para detectar 
não conformidades, sem atrapalhar a execução das tarefas. 
3. Adaptação: Inclui a adaptação rápida a mudanças nos requisitos, tecnologia ou processo 
para evitar a propagação de desvios. 
 
PAPÉIS NO SCRUM 
• Uma equipe Scrum é composta pelo Product Owner (Dono de Produto), Scrum 
Master e Scrum team. 
1. Product Owner (Dono de Produto) 
✓ Atua como cliente. 
✓ Determina os requisitos e funcionalidades. 
✓ Comunica a visão do projeto às partes interessadas. 
✓ Está disponível para esclarecer dúvidas e gerenciar mudanças. 
2. Scrum Master 
✓ Garante que as regras e procedimentos do Scrum sejam seguidas durante a execução do projeto. 
✓ Facilita a resolução de problemas e de interferências externas. 
✓ Ajuda a equipe a entender seus papéis no processo. 
3. Scrum Team (Equipe Scrum) 
✓ Equipe multidisciplinar e autossuficiente. 
✓ Inclui todos os especialistas necessários para desenvolver o produto de forma a não depender de 
membros externos, tais como programadores, administradores de banco de dados, web designers 
etc. 
 
ARTEFATOS SCRUM 
• Finalidade dos Artefatos Scrum: Os Artefatos Scrum são concebidos com a finalidade de 
garantir que as equipes Scrum sejam bem-sucedidas na geração de um incremento. 
 
• Principais Artefatos Scrum: 
1. Product Backlog 
✓ Lista de todos os requisitos ou funcionalidades do produto. 
✓ Gerido pelo Product Owner. 
✓ Inicialmente inclui os requisitos conhecidos e compreendidos. 
✓ Evolui dinamicamente conforme o produto e seu ambiente evoluem, ou seja, o product 
backlog é dinâmico. 
2. Sprint Backlog 
✓ É um subconjunto de requisitos do Product Backlog. 
✓ Esse subconjunto de requisitos são selecionados para uma iteração específica 
(denominada de Sprint). 
✓ Sprint backlog é uma lista de atividades que precisam ser feitas durante uma sprint. 
✓ Inclui o plano para entregar um incremento do produto e atingir a meta da Sprint. 
✓ Define as funcionalidades da próxima versão e o trabalho necessário para a entrega, 
denominada de “Done”. 
✓ A equipe de desenvolvimento pode modificar o Sprint Backlog conforme necessário. 
✓ Somente o product owner tem a autoridade para cancelar um Sprint antes do prazo 
estabelecido, embora o possa fazer sob influência das partes interessadas 
 
EVENTOS SCRUM 
• Objetivo dos Eventos Scrum: 
✓ Otimizar a organização das inspeções e iterações. 
✓ Implementar os conceitos ágeis de forma produtiva. 
✓ Minimizar reuniões não previstas no Scrum. 
✓ Possuem um tempo máximo definido (timebox) para garantir um planejamento eficiente. 
 
• Eventos Scrum: 
1. Sprint 
✓ O Sprint corresponde a uma unidade de iteração com duração de até um mês. 
✓ Gera um incremento de produto em condições de uso pelos usuários finais. 
✓ Possui duração consistente durante todo o desenvolvimento. 
✓ Cada Sprint inclui todas as atividades típicas de desenvolvimento de software (levantamento de 
requisitos, análise, projeto etc). 
2. Reunião de Planejamento do Sprint 
✓ Permite planejar o trabalho a ser realizado em um Sprint. 
✓ Resulta de trabalho colaborativo da equipe Scrum. 
✓ Limitada a 8h para um Sprint de um mês. 
✓ É dividida em duas partes, que buscam respostas às seguintes perguntas: 
o O que será entregue no incremento do Sprint? 
o Como será alcançado o trabalho necessário? 
3. Reunião Diária do Sprint (Daily Scrum) 
✓ É um evento diário de 15 minutos. 
✓ Objetivo: ajustar as atividades e criar um plano para as próximas 24h. 
✓ Inspeciona o trabalho desde a última reunião e prevê o próximo. 
4. Revisão do Sprint 
✓ Realizada no final do Sprint para inspecionar o incremento. 
✓ Adapta o Product Backlog se necessário. 
✓ É uma reunião informal para obter feedback e fomentar colaboração. 
✓ Não deve ultrapassar 4h para Sprints de um mês. 
5. Retrospectiva do Sprint✓ É uma oportunidade formal para a equipe Scrum inspecionar e planejar melhorias, a ser seguida 
durante o próximo Sprint. 
✓ Limitada a 3h para Sprints de um mês. 
✓ Objetivos da retrospectiva do sprint: 
o Verificar o último Sprint em termos de pessoas, relações, processos e ferramentas. 
o Identificar e ordenar itens que correram bem e possíveis ajustes. 
o Criar um plano para implementar melhorias. 
 
FLUXO DE PROCESSO DO SCRUM 
 
Figura – Fluxo de Processo Scrum 
O PROCESSO DE DESENVOLVIMENTO ÁGIL SCRUM 
• O fluxo de processo Scrum está ilustrado na Figura acima. 
1. Product Backlog 
o Lista os requisitos que definem as funcionalidades a serem entregues. 
o É mantido e priorizado pelo Product Owner. 
2. Reunião de Planejamento de Sprint 
o Realizada no início de cada Sprint. 
o Participantes: Product Owner, Scrum Master, e Scrum Team. 
o Objetivo: Priorizar e selecionar requisitos do Product Backlog para o Sprint. 
o Os requisitos são decompostos em tarefas. 
o Cada tarefa é alocada a um responsável que realiza a sua estimativa. 
o Ao final da reunião, essas tarefas compõem o Sprint Backlog. 
3. Desenvolvimento do Sprint 
o Scrum Team Inicia o desenvolvimento do sprint de acordo com o planejamento. 
o No início de cada dia do sprint, a daily scrum permite o compartilhamento, entre os membros da 
equipe, do que foi concluído no dia anterior e quais as prioridades do dia atual. 
o O scrum master conduz essa reunião. 
4. Reunião de Revisão de Sprint 
o Realizada ao final do Sprint. 
o Permite a revisão do Product Backlog. 
o São definidas as exigências para o próximo Sprint. 
o Podem ocorrer o ajuste de requisitos conforme volatilidade ou novas tecnologias. 
o Participantes: Product Owner, Scrum Master, e Scrum Team. 
5. Reunião de Retrospectiva do Sprint 
o Última atividade da iteração Sprint. 
o Objetivo: Levantar lições aprendidas nesta iteração, incluindo pontos positivos e melhorias 
necessárias para futuras Sprints. 
 
PROCESSO UNIFICADO ÁGIL – AUP 
• Processo Unificado Ágil (Agile Unified Process - AUP), é uma versão simplificada do Rational 
Unified Process (RUP). 
• O AUP baseia-se nos seguintes princípios: 
✓ Equipe experiente: AUP fornece links para documentação detalhada para interessados. 
✓ Simplicidade: Descrições concisas para maximizar a simplicidade. 
✓ Agilidade: Conformidade com valores e princípios ágeis. 
✓ Foco em atividades de alto valor: Concentração nas atividades que agregam valor ao 
cliente. 
✓ Independência de ferramenta: Utilização das ferramentas mais adequadas, 
frequentemente simples. 
✓ Customização: Fácil adaptação às necessidades dos usuários. 
• Natureza do AUP: O AUP adota uma natureza serial para o que é (amplo), e iterativo para o que 
é particular, ou seja, segue uma abordagem serial para fases amplas e iterativa para detalhes 
específicos. 
• Fases do projeto: As fases do projeto permanecem as mesmas do RUP, como: concepção, 
elaboração, construção e transição. 
• As mudanças significativas estão nas atividades iterativas compostas de modelagem, 
implementação, testes, implantação, gerenciamento de configurações, gestão de projetos 
e ambiente. 
• Fases do AUP: 
✓ Concepção: Busca a identificação do escopo do projeto, arquitetura potencial do sistema e 
viabilidade do projeto. 
✓ Elaboração: Possui foco na comprovação da arquitetura do sistema. 
✓ Construção: Visa desenvolver um software funcional de forma iterativa e incremental, atendendo 
às necessidades das partes interessadas. 
✓ Transição: Busca validar e implantar do sistema em ambiente de produção. 
• Natureza iterativa da AUP: As atividades que são realizadas de forma iterativa pelos 
membros da equipe de desenvolvimento para construir, validar e entregar software 
operacional. 
• Atividades iterativa da AUP: 
1. Modelagem 
o Inclui o entendimento do negócio e do problema a ser resolvido. 
o Ocorre a identificação de uma solução. 
o Utiliza modelos UML adequados, com o mínimo de formalismo. 
2. Implementação 
o Transformação dos modelos em código executável. 
o Realização de testes básicos, como testes unitários. 
3. Testes 
o Busca a realização de uma avaliação objetiva para garantir a qualidade, a partir da: 
✓ Detecção de defeitos. 
✓ Validação funcional. 
✓ Verificação do cumprimento dos requisitos. 
4. Implantação 
o Planejamento e execução da entrega do software aos usuários finais. 
o Obtenção de feedback dos usuários. 
5. Gerenciamento de Configuração 
o Visa garantir o acesso aos artefatos do projeto. 
o Inclui o rastreamento das diversas versões. 
o Inclui o controle e gerenciamento de alterações. 
6. Gestão de Projetos 
o Planejamento, monitoramento e controle das atividades do projeto. 
o A fim de garantir a entrega no prazo, dentro do orçamento e atendendo as expectativas dos usuários. 
7. Ambiente 
o Atua em apoio às demais atividades. 
o Garantindo a infraestrutura do processo, incluindo padrões, ferramentas e tecnologias de suporte à 
equipe. 
Atenção: É importante destacar que a adoção do AUP requer a aceitação prévia dos conceitos, 
valores e princípios do desenvolvimento ágil. 
 
TEMA 5: QUALIDADE DE SOFTWARE 
Módulo 1. Descrever a qualidade de processo e de produto de software 
ENGENHARIA DE SOFTWARE X QUALIDADE 
• Crise do Software: A crise do software é atribuída ao aumento da complexidade dos 
programas, impulsionado pelo avanço tecnológico do hardware. 
• Impacto do Avanço Tecnológico: O aumento da potência computacional tornou os 
softwares mais complexos, exigindo metodologias eficazes para lidar com essa 
complexidade. 
• Paradigma Orientado a Objetos: A transição do paradigma estruturado para o orientado a 
objetos permitiu o desenvolvimento de softwares mais complexos com melhor reuso e 
manutenibilidade. 
• Exemplos Críticos: Softwares críticos, como sistemas embarcados em aeronaves ou sistemas 
de controle de tráfego aéreo, exemplificam a importância da qualidade de software devido 
às potenciais consequências catastróficas de falhas. 
• Camadas da Engenharia de Software: A engenharia de software é estratificada em camadas: 
qualidade, processo, métodos e ferramentas. 
✓ Qualidade: A camada qualidade garante que os requisitos que atendem às expectativas do 
usuário serão cumpridos. 
✓ Processo: A camada de processo determina as etapas de desenvolvimento do software. 
✓ Métodos: A camada de métodos define os artefatos gerados em função da técnica de modelagem 
adotada. 
✓ Ferramentas: A camada ferramentas estimula a utilização de ferramentas CASE. 
• Ferramentas CASE: Ferramentas CASE (Computer-Aided Software Engineering) são 
fundamentais para auxiliar nas atividades de desenvolvimento de software, desde a análise 
de requisitos até os testes, contribuindo para a qualidade final do produto. 
 
QUALIDADE DE SOFTWARE 
• Definição de Qualidade de Software: Qualidade de software é a aplicação efetiva de gestão 
de qualidade para criar um produto útil que agregue valor mensurável tanto para os 
desenvolvedores quanto para os usuários. 
✓ Gestão da Qualidade: Estabelece uma infraestrutura para suportar o desenvolvimento 
de software com alta qualidade. 
✓ Produto Útil: Inclui o atendimento às necessidades dos usuários e livre de defeitos. 
✓ Valor Mensurável: Agrega valor aos usuários e aos fabricantes, reduzindo a necessidade 
de manutenção e permitindo mais tempo para novos desenvolvimentos. 
 
• Atividades Principais de Gerenciamento de Qualidade: 
1. Garantia da Qualidade: Define procedimentos e padrões organizacionais para garantir a 
geração de software com qualidade. 
2. Planejamento da Qualidade: Ajusta os procedimentos e padrões para cada projeto 
específico de software. 
3. Controle da Qualidade: Define e aprova processos que asseguram que a equipe de 
desenvolvimento siga os procedimentos e padrões de qualidade do projeto. 
 
Figura – Gerenciamento da qualidade. 
 
• Relacionamento entre Gerenciamentode Qualidade e Desenvolvimento de Software: 
✓ A figura abaixo ilustra o relacionamento entre o processo de gerenciamento da qualidade 
e o processo de desenvolvimento de software. 
o O processo de gerenciamento da qualidade permite uma verificação independente. 
o O processo de desenvolvimento de software, verifica as entregas de artefatos do projeto. 
✓ Uma melhor prática é que a equipe de garantia de qualidade seja independente da 
equipe de desenvolvimento, pois no caso de surgirem problemas, tal como atraso no 
projeto, poderia ocorrer um comprometimento da qualidade de modo a cumprir o 
cronograma. 
Figura 3 – Gerenciamento de qualidade versus processo de desenvolvimento. 
 
• A qualidade do software pode ser visualizada sob duas dimensões: 
✓ Processo: A qualidade deve ser garantida em todas as etapas do processo de 
desenvolvimento. A qualidade do processo exige a definição prévia de um processo de 
desenvolvimento de software que viabilize a sua aplicação. Nessa dimensão, são aplicados 
os testes de verificação nos artefatos gerados nas diversas etapas do processo de 
software, com o objetivo de impedir a propagação de defeitos nas etapas posteriores do 
referido processo. 
✓ Produto: A qualidade dever assegurar que o software final atenda aos requisitos e 
seja livre de defeitos. Softwares mal testados podem causar prejuízos significativos, 
como erros que geram decisões equivocadas, impactando negativamente a gestão 
empresarial e a tomada de decisões estratégicas, pois a qualidade das decisões está 
intimamente ligada à qualidade das informações disponibilizadas pelos softwares 
organizacionais. A qualidade do produto é aplicada ao software na etapa de 
codificação do processo de software. A partir de um plano de testes, são aplicados os 
testes de validação ou testes de software, que validam desde a estrutura interna de 
uma unidade de software até as funcionalidades por parte dos usuários. 
 
QUALIDADE DO PROCESSO 
• Definição de Processo: É uma sequência de etapas que permitem a geração de um produto 
(o software). 
• O processo permite melhor tratativa da complexidade para a obtenção de um produto 
(software), pois na maioria das vezes é um trabalho multidisciplinar. 
• Variedade de Modelos de Processo: A Engenharia de Software oferece uma diversidade de 
modelos de processos adaptados para diferentes complexidades e problemas, sendo crucial 
selecionar um processo adequado à complexidade do sistema. 
• Uma Metodologia Genérica de Processo compreende cinco atividades: 
✓ Comunicação: Compreende o entendimento do problema, definição de objetivos e identificação 
de requisitos. 
✓ Planejamento: Inclui o gerenciamento de projeto para estabelecer cronogramas e recursos. 
✓ Modelagem: Geração de modelos como diagramas de casos de uso para entender o sistema. 
✓ Construção: Inclui a codificação e teste do software conforme planejado. 
✓ Entrega: Disponibilização do produto de acordo com o planejamento. 
 
• Garantia da Qualidade de Software: Estabelece uma cultura de zero tolerância a erros e 
inclui mecanismos para detecção precoce de defeitos nos artefatos gerados ao longo do 
processo, evitando a propagação de problemas para fases subsequentes. 
• Testes no Processo de Desenvolvimento: 
✓ Podemos aplicar testes em todas as tarefas do processo de desenvolvimento de software, 
sendo esses denominados de testes de verificação, conhecidos também como testes 
estáticos. 
✓ Os objetivos dos testes de verificação são os artefatos gerados durante todo o processo 
de desenvolvimento do software, tal como o diagrama de classes ou o diagrama de casos 
de uso. 
• Importância do Processo de Desenvolvimento: A produção de software com qualidade 
depende da implementação de um processo estruturado, pois a qualidade não pode ser 
garantida em algo que não foi adequadamente planejado e controlado. 
 
QUALIDADE DO PRODUTO 
• Fatores de Qualidade de McCall: Propõe uma categorização dos fatores que impactam a 
qualidade do software em três etapas: revisão do produto, transição e operação. 
 
Figura – Fatores de qualidade de software de McCall. 
• Principais Fatores de Qualidade: 
ETAPAS FATORES 
Operação 1. Correção: Grau em que o programa satisfaz sua especificação e atende às necessidades do cliente. 
2. Confiabilidade: Capacidade do programa de executar suas funções com precisão. 
3. Eficiência: A quantidade de recursos computacionais e código exigidos por um programa para 
desempenhar sua função. 
4. Integridade: O quanto o acesso ao software/dados por pessoas não autorizadas pode ser controlado. 
5. Usabilidade: Facilidade para aprender, operar e interpretar a saída do programa. 
Revisão 1. Facilidade de Manutenção: Esforço necessário para localizar e corrigir erros. 
2. Flexibilidade: Esforço para modificar o programa em operação. 
3. Testabilidade: Esforço necessário para testar um programa de modo a garantir que ele desempenhe a 
sua função. 
Transição 1. Portabilidade: Esforço necessário para transferir o programa de um ambiente de hardware e/ou 
software para outro. 
2. Reusabilidade: O quanto um programa, ou partes do mesmo, pode ser reutilizado em outras aplicações. 
3. Interoperabilidade: Esforço para integrar o sistema a outros. 
 
• Garantia da Qualidade do Produto: 
✓ A qualidade do produto pode ser garantida através de um plano sistemático de testes 
durante a codificação do software, denominados testes de validação. 
✓ Teste de validações realizadas: 
1. Inicialmente ocorre a validação da estrutura interna da unidade de software e da aderência 
aos requisitos estabelecidos. 
2. Em seguida, ocorre a validação da integração com unidades de software previamente 
desenvolvidas (por exemplo, a validação de interface dos componentes de software). 
3. Por fim, ocorre a validação funcional e não funcional envolvendo os usuários. 
• Testes de Software: 
✓ Os procedimentos de testes aplicados diretamente em softwares são denominados de 
testes de software ou testes dinâmicos. 
✓ Testes de software, são essenciais para assegurar a qualidade do software. 
✓ Podem ser altamente automatizados para simular uma ampla variedade de cenários de 
uso, aumentando assim o nível de validação do produto. 
 
CUSTOS DA QUALIDADE 
• O custo da qualidade é composto pelo custo da 
conformidade e custo da não conformidade. 
 
❖ Custo da Conformidade 
✓ Prevenção de Defeitos: Inclui esforços para evitar a 
ocorrência de defeitos, tais como: 
o Detalhamento de metodologias 
o Treinamentos 
o Uso de ferramentas 
o Estabelecimento de procedimentos, e outros. 
✓ Detecção de Defeitos/Falhas (Custo de Avaliação): É composto pelos custos relacionados 
à avaliação, detecção ou inspeção da qualidade do processo ou produto, tais como: 
o Revisões de artefatos (requisitos, modelos, planos de testes) 
o Inspeções de código 
o Testes de software 
o Auditorias e outros. 
 
❖ Custo da Não Conformidade 
✓ Custo Proveniente da Falta de Qualidade: Custos que desapareceriam se não surgissem 
erros antes ou depois da entrega do produto ao cliente. 
✓ Inclui correções de defeitos originados no processo de desenvolvimento de software, 
retrabalhos, ações corretivas, atrasos nos cronogramas, perdas financeiras e operacionais, 
entre outros. 
✓ Tipos de Custos de Não Conformidade: 
o Custos de Falhas Internas: Erros identificados antes da entrega do software ao cliente. 
o Custos de Falhas Externas: Erros identificados após a entrega do software ao cliente. 
 
Quanto mais cedo ocorrer a identificação de um defeito, menor o custo. 
 
Módulo 2. Explicar o processo da garantia de qualidade de software 
PROCESSOS DE GARANTIA DA QUALIDADE 
• Um sistema de garantia da qualidade de software é denominado SQA (Software Quality 
Assurance). 
• Definição de SQA: é a estrutura organizacional com responsabilidades, procedimentos, 
processos e recursos para a gestão da qualidade. 
• Objetivo do SQA: garantir queprodutos e serviços satisfaçam às expectativas do cliente 
atendendo às suas especificações. 
• O processo de garantia de qualidade de software, inclui a definição e seleção de padrões que 
devem ser aplicados ao processo de desenvolvimento de software/produto de software, 
podendo ocorrer a seleção de ferramentas e métodos, como apoio a esses padrões. 
• A equipe de qualidade deve examinar o software sob o ponto de vista do cliente: “A qualidade 
é conformidade aos requisitos”, ou seja, o software deve atender às necessidades do cliente. 
• A garantia da qualidade de software é composta pelas atividades que se concentram na gestão 
da qualidade de software. 
• Componentes do Processo de Garantia de Qualidade: 
✓ Padrões: 
o Adoção de padrões, como os da ISO, pela equipe de Engenharia de Software ou determinados pelo cliente. 
o Cabe a equipe garantir de conformidade das entregas conforme esses padrões. 
✓ Revisões e Auditorias: 
o Permitem a identificação de erros nos artefatos gerados. 
o As auditorias são aplicadas na verificação da conformidade dos processos com os procedimentos, 
garantindo eficácia nas revisões. 
✓ Testes: Possui finalidade de descobrir de erros através de planos de testes implementados e executados pela 
equipe de qualidade. 
✓ Coleta e Análise de Erros/Defeitos: A equipe de qualidade deverá realizar a análise de erros e defeitos para 
propor melhorias de procedimentos. 
✓ Gerenciamento de Mudanças: Estabelecimento de procedimentos para gestão de mudanças devido à 
volatilidade de requisitos e evoluções tecnológicas. 
✓ Educação: A equipe de qualidade de realizar a gestão de programas educacionais para o aperfeiçoamento da 
equipe de desenvolvimento. 
✓ Gerência dos Fornecedores: Incorporação de exigências de qualidade nos contratos com fornecedores 
externos. 
✓ Administração da Segurança: Inclui a proteção de dados, implantação de firewalls e garantia de integridade 
do software. Cabe à equipe de qualidade o emprego de processos e tecnologias apropriadas. 
✓ Proteção: Avaliação do impacto de falhas de software e implementação de tratativas para redução de riscos. 
✓ Administração de Riscos: Garantia de que a gestão de riscos seja conduzida apropriadamente e que planos 
de contingência estejam estabelecidos. A gestão de riscos é responsabilidade da equipe de desenvolvimento 
 
PADRÕES DE SOFTWARE 
• Tipos de Padrões de Software que podem ser estabelecidos pela equipe de qualidade: 
✓ Padrões de Processo: Definem os processos a serem seguidos durante o desenvolvimento de 
software (ex.: processo de engenharia de requisitos) e descrevem os documentos a serem 
escritos ao longo dos processos. 
✓ Padrões de Produto: Inclui padrões de documentação (ex.: cabeçalho de comentário 
padronizado para classes) e padrões de codificação, que definem com uma linguagem de 
programação deve ser usada. 
• Relacionamento entre Padrões de Produto e Processo: 
✓ Padrões de processo incluem atividades que asseguram que os padrões de produto 
sejam seguidos. 
✓ Padrões de produto aplicam-se à saída do processo de software. 
 
 
• Aspectos Relacionados aos Padrões de Software: 
✓ Incluem melhores práticas, evitando a repetição de erros. 
✓ Proporcionam um framework para a implementação do processo de garantia de 
qualidade. 
✓ Asseguram a continuidade em caso de substituições na equipe. 
✓ Devem ter como base os modelos de padrões nacionais e internacionais. 
✓ Envolvem a equipe de desenvolvimento na criação e revisão sistemática dos padrões. 
✓ Devem ser apoiados por ferramentas CASE. 
• Aplicação de Processos de Desenvolvimento de Software: 
✓ Depende fortemente da complexidade do escopo do problema. 
✓ Diferentes tipos de processos podem ser utilizados em uma organização, o que pode 
impactar a o processo de garantia da qualidade. 
✓ A equipe de desenvolvimento tem autoridade para modificar os padrões de processo de 
acordo com as circunstâncias de cada projeto. 
✓ Portanto, há a possibilidade de alterações ou inclusão de novos padrões conforme 
necessário. 
 
PADRÕES ISO 9000 
• Definição e Aplicação: ISO 9000 é um conjunto internacional de padrões, aplicados a 
sistemas de gerenciamento de qualidade genéricos. 
• Aplicável a diversas indústrias, incluindo manufatura e serviços. 
• ISO 9001 não é especificamente voltado para o desenvolvimento de softwares, mas possui 
uma interpretação denominada, ISO 9000-3 , que estabelece princípios gerais que podem 
ser aplicadas ao desenvolvimento de software. 
• Necessidades Delineadas pelos Tópicos da ISO 9001: 
✓ Responsabilidade administrativa 
✓ Sistema de qualidade 
✓ Revisão contratada 
✓ Controle de projeto 
✓ Controle de dados e documentos 
✓ Identificação e rastreabilidade de produtos 
✓ Controle de processos 
✓ Inspeções e testes 
✓ Ações preventivas e corretivas 
✓ Registros de controle de qualidade 
✓ Auditorias de qualidade internas 
✓ Treinamento 
✓ Manutenção 
✓ Técnicas estatísticas 
 
• Adoção e Certificação ISO: 
✓ Empresas devem estabelecer e seguir políticas e procedimentos para cada umas das 
necessidades citadas, bem como ser capaz de demonstrar que tais políticas e 
procedimentos estão sendo seguidos. 
✓ A certificação é um indicador da seriedade de como uma organização trata a qualidade. 
 
• Relacionamentos entre ISO 9000, Manual de Qualidade e Planos de Qualidade de 
Projeto: 
✓ O Manual de qualidade (conhecido como Plano SQA) aplica os elementos básicos do 
padrão ISO 9000. 
✓ Cada projeto instancia um plano de qualidade a partir do manual e do processo de 
desenvolvimento de software adotado. 
✓ Manual determina o processo de qualidade da organização, adaptado para cada projeto, 
permitindo o gerenciamento de qualidade de cada projeto instanciado. 
 
Figura – ISO 9000 versus gerenciamento da qualidade. 
 
PADRÃO ISO 9126 
• Foi desenvolvido para identificar atributos fundamentais de qualidade para software. 
• Identifica seis atributos principais. 
• Atributos Fundamentais de Qualidade: 
1. Funcionalidade: O grau com que o software satisfaz às necessidades declaradas conforme indicado 
pelos subatributos adequabilidade, exatidão, interoperabilidade, conformidade e segurança. 
2. Confiabilidade: Quantidade de tempo que o software fica disponível para uso conforme indicado 
pelos subatributos maturidade, tolerância a falhas, facilidade de recuperação. 
3. Usabilidade: Grau de facilidade de utilização do software conforme indicado pelos subatributos 
facilidade de compreensão, facilidade de aprendizagem, operabilidade. 
4. Eficiência: O grau de otimização do uso, pelo software, dos recursos do sistema conforme indicado 
pelos subatributos comportamento em relação ao tempo, comportamento em relação aos recursos. 
5. Facilidade de manutenção: A facilidade com a qual uma correção pode ser realizada no software 
conforme indicado pelos subatributos facilidade de análise, facilidade de realização de mudanças, 
estabilidade, testabilidade. 
6. Portabilidade: A facilidade com a qual um software pode ser transposto de um ambiente a outro 
conforme indicado pelos subatributos adaptabilidade, facilidade de instalação, conformidade, 
facilidade de substituição. 
GERENCIAMENTO DA QUALIDADE DE ACORDO COM O PMBOK 
• O gerenciamento da qualidade do projeto faz parte de umas das dez áreas de 
conhecimento do PMBOK. 
O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na gestão de projetos 
organizado pelo instituto PMI e é considerado a base do conhecimento sobre gestão de projetos por 
profissionais da área. 
• Inclui processos para incorporar a política de qualidade da organização no planejamento, 
gerenciamento e controle dos requisitos de qualidade do projeto e do produto. 
• Possui foco em atender às expectativas dos clientes. 
 
Processos Principais: 
1. Planejamento (Gerenciar a Qualidade) 
o Identificação de requisitos e padrões de qualidade. 
o Documenta comoo projeto demonstrará conformidade. 
o Principal entrega: plano de gerenciamento da qualidade. 
2. Execução (Controlar a Qualidade) 
o Transformação do plano de gerenciamento da qualidade em atividades executáveis. 
o Incorporação das políticas de qualidade da organização no projeto. 
3. Monitoramento e Controle (Planejar ao Gerenciamento da Qualidade) 
o Monitoramento e registro dos resultados da execução das atividades de gerenciamento da 
qualidade. 
o Avaliação do desempenho e garantia de que as saídas do projeto sejam completas e corretas, 
atendendo às expectativas do cliente. 
 
Gerenciamento da Qualidade adota algumas Premissas e Abordagens: 
✓ Prevenção é preferível à inspeção. 
✓ Melhor obter qualidade nas entregas do que identificar não conformidades após a inspeção. 
✓ Custo de prevenção é geralmente menor que o custo de correção de erros. 
 
Níveis de Gerenciamento da Qualidade: 
1. Deixar que o cliente encontre os defeitos é uma abordagem que pode gerar problemas de 
garantia, recalls, retrabalho e outros, sendo em geral uma abordagem mais cara. 
2. Detectar e corrigir os defeitos antes que as entregas sejam enviadas para o cliente como parte do 
processo de controlar a qualidade, pois esse processo tem custos relacionados, que são 
principalmente os custos de avaliação e os custos internos de falhas. 
3. Usar a garantia da qualidade para examinar e corrigir o processo em si e não apenas defeitos 
especiais. 
4. Incorporar a qualidade no planejamento e design do projeto e do produto. 
5. Criar uma cultura na organização que esteja ciente e comprometida com a qualidade em 
processos e produtos. 
 
Módulo 3. Explicar o planejamento da qualidade e o controle da qualidade de software 
PLANEJAMENTO DA QUALIDADE 
• Atribuição da equipe de SQA (equipe de garantia da qualidade): Auxiliar a equipe de software 
a obter um produto final de alta qualidade. 
• Ações de garantia da qualidade recomendadas pelo SEI (Software Engineering Institute): 
✓ Planejamento da qualidade. 
✓ Supervisão da qualidade. 
✓ Manutenção de registros de qualidade. 
✓ Análise e relatórios relativos à garantia da qualidade. 
 
• As ações de garantia da qualidade devem ser realizadas por uma equipe de qualidade 
independente. 
• A equipe de qualidade prepara um plano de qualidade de software para cada projeto, que é 
revisado por todos os interessados. 
• A Equipe de qualidade é orientada pelo Plano de Qualidade, que: 
✓ Identifica as avaliações, auditorias e revisões a serem realizadas. 
✓ Define os padrões aplicados ao projeto. 
✓ Procedimentos para relatório e acompanhamento de erros. 
✓ Produtos resultantes produzidos pelo grupo de SQA. 
✓ Realiza o feedback fornecido à equipe de software. 
• O Plano de Qualidade fornece um roteiro para instituir a garantia da qualidade de software, 
que deve ser desenvolvido pela equipe SQA ou pela equipe de desenvolvimento na ausência da 
equipe SQA. 
• O Plano de Qualidade serve como um gabarito para as atividades de garantia da qualidade de 
software em cada projeto. 
• Planos de Qualidade para Cada Projeto: 
✓ Cada projeto de software tem um plano de qualidade instanciado (elaborado) a partir 
do manual de qualidade da organização. 
✓ O plano é adaptado à complexidade e ao processo de desenvolvimento do software em 
questão. 
 
• Estrutura Recomendada pelo IEEE para Planos de Qualidade de Software: 
1. Propósito e Escopo do Plano: Definição clara dos objetivos e abrangência do plano. 
2. Descrição dos Artefatos Resultantes: Modelos, documentos e código-fonte gerados pelo processo 
de engenharia de software. 
3. Padrões e Práticas Aplicados: Normas e práticas seguidas durante a gestão de qualidade. 
4. Ações e Tarefas de Garantia da Qualidade: Incluindo revisões e auditorias, e sua aplicação na gestão 
de qualidade. 
5. Ferramentas e Métodos de Suporte: Apoiam as ações e tarefas da garantia da qualidade. 
6. Procedimentos para Administração de Configurações de Software: Métodos para gestão e 
controle das configurações de software. 
7. Métodos para Montagem e Manutenção de Registros: Salvaguarda e manutenção de todos os 
registros relativos à garantia da qualidade. 
8. Papéis e Responsabilidades Relacionados à Qualidade do Software: Definição clara dos papéis e 
responsabilidades dentro da organização. 
 
PLANEJAMENTO DA QUALIDADE SEGUNDO O PMBOK 
• O PMBOK demonstra a importância da qualidade em todos os projetos por meio da definição 
de uma área de conhecimento denominada de Gerenciamento da Qualidade do Projeto. 
• O Gerenciamento da Qualidade do Projeto é composto de três processos em diferentes 
grupos de processos, ou etapas do ciclo de vida. 
• O processo Planejar o Gerenciamento da Qualidade (Grupo de Processo Planejamento), 
permite gerar o Plano de Gestão de Qualidade do Projeto como um todo. 
• O processo Planejar o Gerenciamento da Qualidade, é o processo de identificação dos 
requisitos e/ou padrões de qualidade do projeto e suas entregas, e de documentação de como 
o projeto demonstrará conformidade com os requisitos e/ou padrões de qualidade. 
• Benefícios do processo Planejar o Gerenciamento da Qualidade: Fornece orientação e 
direcionamento sobre como a qualidade será gerenciada e verificada ao longo do projeto. 
• Entrada, Técnicas/Ferramentas e Saídas: 
✓ Entradas: Informações iniciais que são processadas e convertidas em saídas. 
✓ Técnicas e Ferramentas: Aplicadas para transformar as entradas em saídas. 
✓ Saídas: Resultados do processo, destacando-se o Plano de Gerenciamento da Qualidade. 
Entradas Técnicas e Ferramentas Saídas 
Termo de abertura do projeto Opinião especializada Plano de gerenciamento da qualidade 
Plano de gerenciamento do 
projeto 
Coleta de dados Métricas da qualidade 
Documentos do projeto Análise de dados Atualizações do plano de gerenciamento do 
projeto 
Fatores ambientais da empresa Tomada de decisões Atualizações de documentos do projeto 
Ativos de processos 
organizacionais 
Representação de dados 
 
 
Planejamento de testes e 
inspeções 
 
 
Reuniões 
 
 
PLANEJAMENTO DE TESTES E REVISÕES 
• Teste é um processo sistemático e planejado que tem por finalidade única a identificação de 
erros. 
• Planejamento de testes e revisões: permite o planejamento da garantia da qualidade do 
processo e do produto. 
• O Processo de Qualidade de Software proposto está decomposto em fases que se organizam 
em um formato de "U". 
 
Figura – Processo de Garantia da Qualidade em “U”. 
• Testes de verificação (etapas à esquerda) estão relacionadas com a qualidade do processo de 
desenvolvimento de software. 
Foco: Garantir a qualidade do processo de engenharia do software. 
Objetivo: Verificar se o processo de desenvolvimento está sendo seguido corretamente. 
• Testes de validação (etapas à direita) estão relacionadas com a qualidade do produto software, 
sendo aplicados os denominados. 
Foco: Garantir a qualidade do produto de software. 
Objetivo: Validar se o software atende às expectativas e necessidades dos usuários finais. 
• Objetivo de ambos os grupos de testes: 
✓ Garantia de Produção: Asseguram que todos os produtos previstos na metodologia de 
desenvolvimento sejam produzidos. 
✓ Atendimento aos Requisitos: Asseguram que o software em construção atenda aos requisitos 
especificados. 
• Relação entre Testes de Verificação e Validação: 
✓ Complementaridade: Ambos os testes se complementam para assegurar a qualidade do 
software, atuando em diferentes aspectos do ciclo de desenvolvimento. 
 
❖ TESTES DE VERIFICAÇÃO 
• Objetivo Principal: 
✓ Avaliar a qualidade de todo o processo de desenvolvimento de software. 
✓ Validar se todas as documentações e atividades geradas estão de acordo com os padrões 
estabelecidos. 
✓ Reduzir os riscos de propagação de falhas ao longo do processo. 
• Os testes de verificação devem se concentrar em dois aspectos principais: 
1. Revisões: 
o São atividades deverificação com foco nas documentações. 
o A revisão é um processo de análise de determinado documento. 
2. Auditorias: 
o São as avaliações das atividades de desenvolvimento. 
o Verifica se a equipe de desenvolvimento segue o processo de desenvolvimento de software. 
o Inclui registro de defeitos encontrados, produção de documentos de análise e projeto. 
o Principais Objetivos das Auditorias de Qualidade: Avaliar se a equipe de desenvolvimento segue o 
processo de desenvolvimento de software (registrando os defeitos encontrados, produzindo os 
documentos de análise e projeto etc). 
Figura – Métodos Estruturados de Verificação. 
 
• As duas situações são consideradas métodos estruturados, pois possuem planejamento, 
regras de condução e necessitam de profissionais qualificados para desempenhar essas 
funções e acompanhar seu progresso. 
 
❖ TESTES DE VALIDAÇÃO 
• Objetivo Principal: Garantir a qualidade do produto de software. 
• Testes de Software (ou Testes Dinâmicos): 
✓ São aplicados diretamente em softwares. 
✓ Pode possuir alto nível de automação, o que possibilita a criação de ambientes de testes 
complexos para simular diversos cenários de utilização. 
Tipos de Testes de Validação: 
1. Validação da Unidade: 
Objetivo: Executar o software para exercitar toda a estrutura interna de um 
componente (como desvios condicionais, laços de processamento, etc.). 
2. Validação da Integração: 
Objetivo: Mantém a compatibilidade das novas unidades construídas ou 
modificadas com os componentes previamente existentes. 
3. Validação do Sistema: Conta com uma infraestrutura mais complexa de hardware. 
Objetivo: Visa a estar o mais próximo do ambiente real de produção, sendo 
realizados os testes funcionais (verificam se a versão corrente do sistema permite executar 
processos ou casos de uso completos do ponto de vista do usuário, obtendo os resultados esperados) e os testes 
não funcionais (testam o software em relação às características não funcionais como, desempenho, segurança, 
confidencialidade, recuperação de falhas etc). 
4. Aceite: Última oportunidade de detectar falhas no software. 
O aceite é empregado como uma estratégia para reduzir riscos de implantação. 
Estratégias de Aceite: 
✓ Teste Alpha: Usuários finais operam o software em um ambiente controlado, realizado na 
instalação do desenvolvedor. 
✓ Teste Beta: Usuários finais operam o produto utilizando suas próprias instalações físicas, em 
um ambiente não controlado pelo desenvolvedor. 
✓ Aceite Formal: É uma variação do Teste Beta. Clientes e usuários determinam o que deve ser 
testado e validam se os requisitos foram adequadamente implementados. 
 
❖ TESTE DE SISTEMA 
• Os testes de sistema consideram o contexto mais amplo da engenharia de sistemas de 
computadores, ou seja, extrapolam os limites da engenharia de software. 
• Após a validação do software, ele é combinado com outros elementos do sistema, como 
hardware e bases de dados. 
• Tipos de Testes de Sistema: 
• Teste de Recuperação: Avalia o comportamento do software após a ocorrência de erros ou 
condições anormais. 
Exemplo: Simular um saque com defeito no caixa eletrônico ou uma queda de energia durante a 
transação. 
• Teste de Segurança: Detecta falhas de segurança que possam comprometer o sigilo, 
fidelidade das informações, perdas de dados ou a interrupções de processamento. 
Exemplo: Avaliar se a senha do cartão é requisitada antes e depois da transação, ou se uma senha 
adicional é requisitada no início da operação. 
• Teste por Esforço: Simula condições atípicas de utilização do software, provocando 
aumentos e reduções sucessivas de transações. 
Exemplo: Simular 10.000 saques simultâneos para avaliar o comportamento do software e da 
infraestrutura. 
• Teste de Desempenho: Determina se o desempenho nas situações previstas de pico máximo 
de acesso e concorrência está consistente com os requisitos definidos. Define tempos de 
resposta aceitáveis para cada cenário. 
Exemplo: Garantir que a manipulação com dispositivos físicos durante um saque não ultrapasse 10 
segundos. 
• Teste de Disponibilização (Configuração): Executa o software em diversas configurações 
de software e hardware para garantir a compatibilidade com diferentes ambientes de 
produção. 
Exemplo: Simular um saque com impressoras de diferentes fornecedores (X, Y e Z). A ideia é garantir 
que a solução tecnológica seja executada adequadamente sobre os mais variados ambientes de 
produção previstos nas fases de levantamento dos requisitos 
 
CONTROLE DE QUALIDADE 
• Controlar a qualidade é o processo de monitorar e registrar resultados da execução das 
atividades de gerenciamento da qualidade verificando se as entregas e o trabalho do projeto 
cumprem os requisitos especificados. 
• O processo Controlar a Qualidade é realizado para medir a integridade, conformidade e 
adequação para uso de um produto ou serviço antes da aceitação do usuário e entrega final. 
• Isso é feito medindo todos os passos, atributos e variáveis usados para verificar a conformidade 
com ou o cumprimento das especificações definidas no planejamento. 
Entradas Técnicas e Ferramentas Saídas 
Plano de gerenciamento do projeto 
- Plano de gerenciamento da qualidade 
Coleta de dados 
- Listas de verificação 
- Folhas de verificação 
Medições de controle da qualidade 
- Amostragem estatística 
- Questionário e pesquisas 
Documentos do projeto 
- Registro das lições apreendidas 
- Métricas da qualidade 
- Documentos de teste e avaliação 
Análises de dados 
- Análises de desempenho 
- Análise de causa-raiz 
Entregas verificadas 
Solicitações de mudança aprovadas Inspeção Informações sobre o desempenho do trabalho 
Entregas Testes/avaliação de produtos Solicitações de mudança 
Dados de desempenho do trabalho Representação de dados 
- Diagramas de causa e efeito 
- Gráficos de controle 
- Histograma 
- Diagramas de dispersão 
Atualizações do plano de gerenciamento do projeto 
- Plano de gerenciamento da qualidade 
Fatores ambientais da empresa Reuniões Atualizações de documentos do projeto 
- Registro das questões 
- Registro das lições apreendidas 
- Registro dos riscos 
- Documentos de teste e Avaliação 
Ativos de processos organizacionais 
 
Tabela – Controlar a Qualidade. 
• Na tabela, “Documentos de testes e avaliação”, na coluna Entradas, incluem os testes aplicados 
na garantia do processo e do produto descritos anteriormente. 
• Na coluna Saídas, “Solicitações de mudança”, as solicitações de mudança resultam de não 
conformidades observadas e podem gerar atualizações no registro de mudanças do projeto. As 
modificações podem incluir reparos de defeitos, revisão dos métodos de trabalho e revisão dos 
cronogramas. 
 
Módulo 4. Descrever as medições e métricas do software 
MEDIÇÃO 
• Um elemento-chave de qualquer processo de engenharia é a medição. 
• Importância: 
✓ Essencial para o controle efetivo de processos de engenharia. 
✓ Baseada na máxima: “Não se controla o que não se mede”. 
• Conceitos: 
✓ Medição: É o ato de determinar uma medida. 
✓ Medida: É a indicação quantitativa da extensão, quantidade, capacidade ou tamanho de 
um atributo de um produto ou processo. 
Exemplo: Número de erros descobertos em um componente de software. A medição ocorre como 
resultado de um conjunto de revisões de componentes e testes de unidade investigados na coleta de 
medidas do número de erros para cada um. 
✓ Métrica: É a medida quantitativa do grau com o qual um sistema, componente ou processo 
possui determinado atributo. 
Exemplo: A métrica de software relaciona as medidas individuais, ou seja, o número médio de erros 
encontrados por revisão ou o número médio de erros encontrados por teste de unidade. 
• Medição de Software: 
✓ A medição de software está preocupada com a quantificação de algum atributo de um 
sistema de software, como a sua complexidade ou a sua confiabilidade. 
✓ Comparandodo software a partir dos modelos. 
✓ Os modelos determinam o comportamento do software. 
✓ Esta etapa inclui a codificação e testes de acordo com o planejamento. 
5. Entrega: 
✓ Objetivo final é a entrega do produto em produção conforme planejado. 
 
Atividades de Apoio complementares: 
1. Controle e Acompanhamento de Projeto: Verifica a conformidade da execução com o planejamento 
e implementa ações corretivas em caso de não conformidades. 
2. Administração de Riscos: Gerenciamento de riscos para tratar eventos positivos ou negativos que 
possam impactar o projeto. 
3. Garantia da Qualidade de Software: Assegurar que os requisitos do projeto sejam atendidos. 
4. Revisões Técnicas: Atividade inerente à qualidade que testa todos os artefatos, incluindo processos, 
modelos e código do software. 
5. Medição: Definição de métricas para avaliar as atividades durante o desenvolvimento do software. 
6. Gerenciamento da Configuração de Software: Trata do gerenciamento de versionamento e efeitos 
das mudanças, bem como da manutenção e propagação de correções entre versões. 
7. Gerenciamento da Capacidade de Reutilização: Objetiva a promoção do reuso de software, 
facilitado por paradigmas como a orientação a objetos. 
8. Preparo e Produção de Artefatos de Software: Diz respeito a documentação das atividades e 
geração de artefatos, como modelos de casos de uso. 
 
Responsabilidades do Engenheiro de Software: Documentar cada atividade no processo de 
desenvolvimento de software em função da complexidade do problema, das características da 
equipe e dos usuários envolvidos. 
 
Módulo 2. Descrever as etapas essenciais de um processo de desenvolvimento de software 
• O conceito de abstração é aplicado intensamente no desenvolvimento de software. 
Processo de desenvolvimento Software e Abstração: 
• O desenvolvimento de software inicia-se com especificações e modelos de alto nível de 
abstração. 
• Nível de abstração diminui conforme o desenvolvimento avança. 
• A codificação representa o nível mais baixo de abstração, com maior detalhamento na 
especificação do software. 
 
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
Definição do Processo de Desenvolvimento: 
• O engenheiro de software deve escolher o processo de desenvolvimento adequado para o 
projeto, como por exemplo a especificação de requisito não funcional. 
• Inicialmente deverá identificar as atividades que irão compor o processo. 
• Em seguida, deverá definir o sequenciamento dessas atividades, ou seja, o fluxo do processo. 
Atividades Típicas no Desenvolvimento de Software: 
• Existem atividades comuns que qualquer processo de desenvolvimento de software deve incluir, 
como : 
✓ Levantamento de requisitos 
✓ Análise 
✓ Projeto 
✓ Implementação 
✓ Testes 
✓ Implantação 
 
❖ LEVANTAMENTO DE REQUISITOS 
• Levantamento de requisitos é também denominada de elicitação de requisitos. 
• Constitui a primeira etapa no desenvolvimento de software. 
• Objetivo principal: entender o problema. 
• Engenheiro de software deve se comunicar com diferentes usuários, que geralmente 
compreendem apenas partes do problema. 
• Técnicas utilizadas: entrevistas, questionários, leitura de documentos, etnografia, entre outros. 
• Nesta etapa, são identificados os requisitos que serão implementados no software projetado. 
• O desafio do engenheiro de software é ter o mesmo entendimento do negócio que os usuários. 
Conceito de Requisitos: 
• São descrições dos serviços e restrições operacionais do sistema. 
• Os requisitos refletem as necessidades dos clientes para resolver um problema. 
Tipos de Requisitos: 
✓ Requisitos funcionais: São funcionalidades específicas que um sistema ou software deve executar, como 
ações, processos ou operações que o sistema deve ser capaz de realizar (ex. um e-commerce deve permitir 
que os usuários façam compras, adicione itens ao carrinho, façam pagamentos e visualizem seus históricos 
de compras). 
✓ Requisitos não funcionais: São requisitos relacionados ao uso da aplicação em termos de 
desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias 
envolvidas. 
✓ Requisitos de domínio: São regras de negócio que restringem requisitos funcionais (ex. cálculo de 
média para aprovação). 
Os requisitos podem ser classificados pelo Nível de Abstração como: 
• Requisitos de usuários: Apresentam alto nível de abstração. 
• Requisitos de sistema: Apresentam especificação mais detalhada, ou seja, com baixo nível de 
abstração. 
✓ Os requisitos de sistema podem ser funcionais, não funcionais e de domínio. 
Importância da compreensão do que são requisitos: Mau entendimento de um requisito pode 
se propagar e impactar negativamente o software. 
Quanto a especificação de requisitos: 
• O engenheiro firma um contrato com os usuários, definindo o produto de software a ser 
entregue. 
• A participação dos usuários é crucial para identificar defeitos na especificação e evitar sua 
propagação. 
Documento de Requisitos: 
• Durante o Processo de Desenvolvimento de Software é realizada uma especificação 
denominada documentos de requisitos. 
• O documento de requisitos define o escopo do projeto. 
• A partir desse documento, inicia-se a rastreabilidade dos requisitos, ou seja, a relação entre 
os produtos gerados nas diferentes etapas. 
Exemplos de rastreabilidade: Na etapa de análise (modelo de casos de uso e classes), etapa de Projeto (modelo 
de interação), etapa de Implementação (codificação). 
• A rastreabilidade de requisitos garante que as especificações geradas até a codificação estejam 
de acordo com a documentação de requisitos. 
• Na validação dos requisitos, a equipe deve estar atenta à rastreabilidade. 
• A rastreabilidade permite acompanhar a origem e o impacto das mudanças nos requisitos, 
garantindo que as alterações sejam bem compreendidas e verificadas. 
 
❖ ETAPA DE ANÁLISE 
Contexto e Requisitos Iniciais: 
• O documento de requisitos especifica características desejadas. 
Exemplo no contexto da construção de uma casa: sala, quartos, cozinha, piscina, área total. 
• O documento de requisitos serve como base inicial para o desenvolvimento. 
Criação de Modelos: 
• Engenheiro ou arquiteto traduz requisitos textuais em modelos (e.x., planta baixa da casa). 
• Os modelos ajudam a tratar a complexidade por meio de abstrações e facilitam a comunicação 
entre as partes interessadas (analistas, usuários, gerentes de projeto). 
Importância dos Modelos: 
• A criação de modelos permite a comunicação entre as partes interessadas no projeto. 
• A criação de modelos permite correção de erros nos modelos evita propagação de defeitos 
no código, economizando recursos. 
• A criação de modelos permite uma fácil manutenção no código, o que reduz os custos. 
• Modelos determinam a forma da solução do problema (e.x., se o diagrama de componentes 
estabelece três camadas de software, o software implantado deve refletir esta especificação). 
Conversão de Especificações em Modelos de Análise: 
• As especificações contidas no Documento de Requisitos são convertidas em modelos de 
análise, que incluem artefatos gráficos e textuais. 
Exemplo: Requisitos funcionais evoluem para uma especificação gráfica, como o Modelo de Casos de Uso 
(diagramas de casos de uso – artefatos gráficos e descrições de caso de uso – artefatos textuais). 
• A descrição dos casos de uso permite identificar os diferentes cenários de uso de acordo com 
o caso. 
• Na etapa de análise, o engenheiro aplica um alto nível de abstração de modo a definir “O 
QUE” o sistema deverá implementar e nenhum tipo de restrição tecnológica é considerado. 
• A entrega desta etapa, inclui os modelos denominados modelos de análise. 
• Para saber se o problema foi modelado corretamente, é necessário validar os modelos 
juntamente com os usuários. 
• A validação do usuário, garante ao engenheiro que a solução produzida para determinado 
problemaos valores medidos uns com os outros e com os padrões que se aplicam a uma 
organização, é possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia 
de processos de software, de ferramentas e de métodos. 
✓ O gerenciamento da qualidade pode contar com medições de atributos que afetam a 
qualidade do software. 
 
PROCESSOS DE MEDIÇÃO 
• O fluxo abaixo ilustra um processo de medição, que pode ser parte de um processo de avaliação 
da qualidade de software, no qual cada componente do sistema pode ser analisado 
separadamente usando uma variedade de métricas. 
• Os valores dessas métricas podem, então, ser comparados com diferentes componentes e, 
talvez, com dados de medição históricos, coletados em projetos anteriores. 
• Medições anômalas, que se desviam significativamente da norma, em geral indicam 
problemas com a qualidade desses componentes. 
 
• Passos do processo de medição de software: 
1. Escolher as Medições a Serem Feitas: 
✓ Inclui a formulação de questões para as quais as medidas irão responder. 
✓ Definição das medições necessárias para responder a essas questões. 
2. Selecionar os Componentes a Serem Avaliados: 
✓ Escolher um conjunto representativo de componentes para medição. 
✓ Para permitir uma avaliação geral da qualidade do sistema. 
3. Medir as Características dos Componentes: 
✓ Os componentes selecionados são medidos e são calculados os valores das métricas. 
✓ É sugerido o uso de ferramentas de coleta automática de dados. 
4. Identificar Medições Anômalas: 
✓ Após realizar as medições do componente, são comparadas as medições dos componentes entre si e 
com medições anteriores em um banco de dados de medição. 
✓ São procurados valores atipicamente altos ou baixos, que possam indicar problemas de qualidade. 
5. Analisar Componentes Anômalos: 
✓ É necessário examinar componentes com valores anômalos para decidir se a qualidade está 
comprometida. 
✓ Valores anormais, por exemplo para a complexidade, não necessariamente indicam má qualidade; 
pode haver outros motivos para esses valores altos. 
• Boas Práticas: 
✓ Manter dados coletados como um recurso organizacional. 
✓ Guardar registros históricos de todos os projetos. 
✓ Estabelecer um banco de dados de medição robusto permite a realização de comparações 
de qualidade de software em projetos e validação de relações entre atributos de 
componentes internos e características de qualidade. 
 
MÉTODO GQM 
O método GQM (Goal Question Metric) é uma abordagem de métrica de engenharia de software. 
• Objetivo do método GQM: 
✓ Deve ser específico para uma atividade do processo ou característica do produto a ser 
avaliada (deve ter uma meta). 
✓ Deve estar alinhado com os requisitos do software. 
✓ Exemplo: "Garantir que todos os requisitos funcionais deverão ser testados." 
• Questões: 
✓ Definição de um conjunto de questões quem deve ser respondidas para atingir o objetivo. 
✓ As questões estabelecem a ligação entre os objetivos e as métricas. 
✓ Exemplo: "Qual a cobertura dos testes?" 
• Métricas: 
✓ Devem ser formuladas com base nas respostas às questões elaboradas. 
✓ Exemplo: "Número de requisitos testados." 
 
MÉTRICAS 
• Definição de Métrica: Medida quantitativa do grau com o qual um sistema, componente ou 
processo possui determinado atributo. 
Exemplos: Número médio de erros encontrados por revisão ou por teste de unidade. 
• Importância na Engenharia de Software: 
✓ A Engenharia de Software é uma área de conhecimento quantitativa. 
✓ Portanto, a métrica de produto ajuda os engenheiros de software a visualizar o projeto e a 
construir o software por meio de atributos específicos e mensuráveis permitindo criar um 
software de alta qualidade. 
• Utilização das Métricas: 
✓ Definição e Coleta de Dados: 
o Após a definição das métricas, coletam-se os dados necessários para derivar as métricas formuladas 
✓ Análise e Interpretação: 
o As métricas formuladas são analisadas com base em diretrizes preestabelecidas e dados do passado. 
o Os resultados são interpretados para obter informações sobre a qualidade do software. 
✓ Ações a partir dos Resultados: 
o Os dados da interpretação podem gerar alterações nos requisitos, modelos de projeto, código-fonte 
ou processo de software. 
 
• Melhores Práticas para Definição de Métricas de Software 
✓ Métricas devem ser fáceis de derivar e calcular, sem demandar esforço computacional 
excessivo. 
✓ Devem refletir atributos desejáveis do produto de software, como coesão de módulo. 
✓ Resultados das métricas devem ser claros e não ambíguos. 
✓ Utilizar unidades de medida coerentes para evitar combinações incomuns. 
✓ Basear as métricas no contexto do software, como requisitos, modelo de projeto ou 
estrutura do programa. 
✓ Fornecer informações que possam contribuir para a melhoria da qualidade do produto 
final de software. 
 
• Definição de Métrica de Software: É uma característica de um sistema de software, 
documentação do sistema ou processo de desenvolvimento que pode ser medida 
objetivamente. 
 
• Tipos de Métricas de Software: 
1. Métricas de Controle ou de Processo 
o Objetivo: Apoiar o gerenciamento de processos. 
o Geralmente estão associadas aos processos de software, tais como o esforço médio ou o 
tempo necessário para reparar defeitos relatados. 
o Tipos de Métricas de Processo: Podem ser usados três tipos de métricas de processo: 
1. Tempo de conclusão de um processo. 
2. Recursos necessários para um processo (esforço total, custos de viagens, recursos de computador). 
3. Ocorrências de eventos específicos (defeitos detectados, alterações de requisitos, relatórios de 
defeitos, linhas de código modificadas). 
 
2. Métricas de Previsão ou de Produto 
o Objetivo: Estão associadas ao produto software, permitem quantificar atributos internos 
de um sistema (como o tamanho do sistema, medido em linhas de código, ou o número de 
métodos associados a cada classe.). 
o Tipos de Métricas: As métricas de produtos enquadram-se em duas classes: 
1. Dinâmicas: Medidas no software em execução durante testes ou operação. 
• As métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade de um sistema. 
2. Estáticas: Medidas a partir de representações do sistema (projeto, programa, 
documentação). 
• As métricas estáticas ajudam a avaliar a complexidade, a compreensibilidade e a 
manutenibilidade de um sistema ou de seus componentes. 
• Exemplos de Métricas Dinâmicas: 
Métrica Descrição 
Confiabilidade 
A confiabilidade é uma característica de 
qualidade de software a ser avaliada, pois, um 
software é confiável quando não falha. 
 
• Total de falhas relatadas durante o teste. 
• Número de falhas corrigidas. 
• Tempo médio entre falhas. 
• Porcentagem de falhas corrigidas. 
• Exemplos de Métricas Estáticas: 
Métrica Descrição 
Fan-in / fan-out • Fan-in: Número de funções ou métodos que chamam outra função ou método (por exemplo, x). 
• Fan-out: Número de funções que são chamadas pela função x. 
• Um valor elevado para o fan-in significa que x está fortemente acoplado ao resto do projeto e as 
mudanças em x terão um amplo efeito dominó. 
• Um valor elevado para fan-out sugere que a complexidade geral de x pode ser alta por causa da 
complexidade da lógica de controle necessária para coordenar os componentes chamados. 
Comprimento do 
código 
• Medida do tamanho de um programa. 
• Geralmente, quanto maior o tamanho do código de um componente, mais complexo e propenso 
a erros ele tende a ser. 
Complexidade 
ciclomática 
• Visa a analisar a estrutura do código-fonte. 
 
• Influência nas Decisões de Gerenciamento: As métricas de controle (processo) e de previsão 
(produto) podem influenciar a tomada de decisões de gerenciamento: 
✓ Métricas de controle ajudam a decidir alterações de processos. 
✓ Métricas de previsão ajudam a decidir se alterações no software são necessárias e se está 
pronto para produção.Figura – Medições de previsão e controle. 
 
TEMA 6: GERENCIAMENTO DE CONFIGURAÇÕES 
• Função do gerenciamento de mudanças: Permite que as alterações no sistema de uma maneira 
controlada. 
• Benefícios do gerenciamento de mudanças: 
✓ Garante que a evolução do sistema seja controlada. 
✓ Prioriza alterações urgentes e com bom custo-benefício. 
• Função do gerenciamento de versões: 
✓ Controlar as diferentes versões de componentes de software e sistemas. 
✓ Garantir que alterações feitas por diferentes desenvolvedores não interfiram umas com as 
outras. 
• O processo de construção de sistema executável, que ocorre por meio da compilação e da 
ligação dos componentes do sistema, das bibliotecas externas, dos arquivos de configuração e 
de outras informações necessárias ao referido processo é fundamental no contexto do 
gerenciamento de configurações. 
• Ferramentas CASE: permitem que as atividades principais de gerenciamento de configuração 
resultem em ganhos de produtividade no gerenciamento e controle de itens de configuração 
gerados ao longo do processo de desenvolvimento de software. 
 
Módulo 1: Descrever o planejamento de gerenciamento de configurações 
CONCEITO DE GERENCIAMENTO DE CONFIGURAÇÕES 
Exemplo: Uma equipe de engenheiros de software desenvolve uma aplicação para gestão de 
vendas cujo fluxo de processo é iterativo e incremental, onde são desenvolvidas as tarefas típicas 
de um processo de desenvolvimento de software, isto é, levantamento de requisitos, análise, projeto, 
implementação, testes e implantação. 
Ao final, após o aval da equipe de qualidade, é disponibilizada aos usuários uma versão em 
produção. Porém, durante a implementação da versão 2, foi detectada uma falha na versão 1. 
Cenários de Alteração: 
• Cenário 1: Finalizar a versão 2 com correções de defeitos. 
• Cenário 2: Corrigir a versão 1 em produção e replicar as alterações na versão 2. 
• Melhor solução: É o cenário 2 é a melhor solução técnica. 
A solução para este estudo de caso exige a implantação de um processo de Gerenciamento de 
Configurações de Software (GCS). 
• Importância do GCS: Essencial devido à constante mudança no software causada por: 
✓ Volatilidade dos requisitos. 
✓ Evolução tecnológica. 
✓ Defeitos detectados. 
✓ Atualizações de plataforma. 
✓ Novos recursos de hardware. 
✓ Adaptações a novos requisitos de negócio. 
✓ Restrições orçamentárias ou de cronograma. 
• Atividades do GCS: 
✓ Gerenciar alterações identificando artefatos a serem alterados. 
✓ Estabelecer relações entre artefatos. 
✓ Definir mecanismos para gerenciar diferentes versões de artefatos. 
✓ Controlar e auditar alterações feitas. 
• O GCS gerencia alterações através de todo o ciclo de vida de um software, podendo ser visto 
como uma atividade de garantia de qualidade do software aplicada através de todo o 
processo de desenvolvimento do software. 
• Responsabilidade do desenvolvimento das Atividades do GCS: Normalmente atribuída à 
equipe de qualidade ou a uma equipe específica designada para o GCS. 
 
Alterações não controladas podem impactar negativamente a qualidade do software. 
Dessa forma, pode-se afirmar que a gestão de alterações é essencial da gestão da qualidade. 
 
• Quatro Elementos do GCS: 
1. Elementos de componente: Conjunto de ferramentas acopladas em um sistema de gestão de 
arquivos que possibilita acesso à gestão de cada item de configuração de software. 
2. Elementos de processo: Coleção de ações e tarefas que definem uma abordagem eficaz da gestão 
de alterações para todas as partes envolvidas na gestão, engenharia e uso do software. 
3. Elementos de construção: Conjunto de ferramentas que automatizam a construção do software, 
assegurando que tenha sido montado o conjunto apropriado de componentes validados. 
4. Elementos humanos: Conjunto de ferramentas e características de processo usados pela equipe de 
software para implementar um GCS eficaz. 
 
PLANEJAMENTO DE GERENCIAMENTO DE CONFIGURAÇÕES 
• O Plano de Gerenciamento de Configurações descreve padrões e procedimentos adaptados 
aos requisitos e restrições de cada projeto específico. 
• O Plano de GCS deve incluir: 
1. Definição dos Itens de Configuração de Software (ICS) que serão gerenciados e o esquema 
que se deve usar para identificar essas entidades. 
2. Estabelecimento do responsável pelos procedimentos de gerenciamento de configuração 
e pela submissão de itens controlados para a equipe de gerenciamento de configurações. 
3. Definição das políticas de gerenciamento de configurações que todos os membros da 
equipe devem adotar para o controle de mudanças de gerenciamento de versões. 
4. Especificação das ferramentas aplicadas no gerenciamento de configurações e os processos 
para uso dessas ferramentas. 
5. Descrição da estrutura do banco de dados de configuração usada para registrar as 
informações de configuração e as informações que devem ser mantidas neste banco de 
dados, ou seja, os registros de configurações. 
 
• A inclusão de outros tópicos no plano GCS é possível, tais como: 
✓ Gerenciamento de software de fornecedores externos. 
✓ Procedimentos de auditoria dos processos de GCS. 
• A definição de Responsabilidades inclui quem é o: 
✓ Responsável pela entrega de cada documento ou componente de software. 
✓ Revisores de cada documento. 
 
GESTÃO DE ITEM DE CONFIGURAÇÃO DE SOFTWARE (ICS) 
• Alterações no Desenvolvimento de Software: Mudanças ocorrem devido à evolução do 
entendimento do problema durante o processo de desenvolvimento. 
✓ Clientes: Querem modificar requisitos, 
✓ Engenheiros de software e gerentes: Querem modificar seus métodos. 
• O entendimento do problema evolui durante o processo de desenvolvimento de software, 
gerando a necessidade de alterações. 
• Definição de Itens de Configuração de Software (ICS): Um ICS é uma informação criada no 
processo de engenharia de software, tal como única seção de uma grande especificação ou 
um caso de teste em um grande conjunto de testes. 
• Caso de teste é um conjunto de condições usadas para teste de software. 
• Exemplos de ICS: Um ICS é todo ou parte de um artefato, por exemplo, documentos, conjuntos de 
casos de teste, programas e componentes de software, incluindo ferramentas como editores e 
compiladores. 
• A identificação dos itens de configuração de software está prevista no plano de Gerenciamento 
de Configurações de Software (GCS). 
 
Figura – Objetos de configuração. 
 
• Organização como Objetos de Configuração: Os ICS são organizados como objetos de 
configuração em um banco de dados, cada um com nome, atributos e relações entre si. 
 
De acordo com a Figura 1, os objetos de 
configuração EspecificaçãoProjeto, ModeloDados, ComponenteN, CódigoFonte e EspecificaçãoTeste são definidos 
individualmente, estando relacionados entre si, como mostram as setas. As setas curvas são indicativas de 
relacionamento de composição, de modo que ModeloDados e ComponenteN são parte do objeto EspecificaçãoProjeto. 
 
• Conceito de Referência: Um conceito importante na Gestão de Configuração de Software é 
a referência, que é uma especificação ou produto que tenha sido formalmente revisado e 
acordado, que depois serve de base para mais desenvolvimento, e pode ser alterado somente 
por meio de procedimentos formais de controle de alteração. 
 
• Estabelecimento de um ICS como Referência: Uma vez estabelecido um ICS como uma 
referência, podem ser feitas alterações, mas deve ser aplicado um processo específico e formal 
para avaliar e verificar cada alteração. 
• No contexto de Engenharia de Software, uma referência é um marco no desenvolvimento de 
software. 
• Uma referência é marcada pelo fornecimento de um ou mais ICS que foram aprovados em 
consequência de uma revisão técnica. 
• Processo de Alteração: Alterações em ICS que foi estabelecido como referencia requerem 
procedimentos formais de avaliação e aprovação, garantindo que asmudanças sigam controles 
de versão e outros controles de Gestão de Configuração de Software (GCS). 
• Exemplo de Referência: Um modelo de projeto torna-se uma referência após ser 
documentado, revisado e aprovado, permitindo alterações adicionais apenas após nova 
avaliação e aprovação. 
 
Figura – ICS versus banco de dados de projeto. 
Exemplo na figura acima: Quando um engenheiro de software quer fazer uma alteração em um 
ICS que se tornou referencial, o mesmo é copiado do banco de dados de projeto para o ambiente 
de desenvolvimento do engenheiro. Porém, esse ICS somente poderá ser modificado se os controles 
de GCS, tal como o controle de versão, forem seguidos. 
 
Módulo 2: Descrever o gerenciamento de mudanças, versões e releases 
PROCESSO DE GERENCIAMENTO DE CONFIGURAÇÕES DE SOFTWARE 
• Objetivos Primários do Gerenciamento de Configuração de Software (GCS): 
✓ Identificar todos os itens que definem a configuração do software. 
✓ Gerenciar alterações em um ou mais desses itens. 
✓ Facilitar a construção de diferentes versões da aplicação. 
✓ Assegurar a manutenção da qualidade do software conforme a configuração evolui. 
 
• Tarefas do GCS: 
1. Identificação: Definir e identificar todos os itens de configuração de software (ICS). 
2. Controle de Alteração: Gerenciar e 
controlar mudanças nos ICS de forma 
formal. 
3. Controle de Versão: Gerenciar diferentes 
versões dos ICS ao longo do tempo. 
4. Auditoria de Configuração: Verificar e 
validar a integridade dos ICS e suas 
versões. 
5. Relatos: Fornecer informações relevantes 
sobre os ICS e suas mudanças para partes 
interessadas. 
Figura - Camadas do processo GCS. 
• Movimentação dos ICS entre Camadas: Os ICS transitam das camadas internas para as 
externas à medida que se tornam parte das configurações de software de diferentes versões da 
aplicação. 
• Registro e Auditoria dos ICS: Cada ICS é registrado com informações como nome, data de 
criação e versão para suportar auditorias de configuração e relatos para aqueles que precisam 
ter conhecimento. 
• A camada de controle de alterações é denominada de gerenciamento de mudanças. 
 
GERENCIAMENTO DE MUDANÇAS 
• Importância: Gerenciamento de mudanças é crucial para controlar alterações necessárias devido 
a novas necessidades organizacionais, requisitos ou correções de defeitos. 
• Processo Estruturado: Utiliza um processo formal para aplicar mudanças de maneira controlada, 
priorizando aquelas mais urgentes e com melhor custo-benefício. 
• Função do gerenciamento de mudanças: Permite que as alterações sejam aplicadas ao sistema 
de uma maneira controlada, ou seja, garante que a evolução do sistema seja controlada e que 
as alterações mais urgentes e com bom custo-benefício sejam priorizadas. 
• Processo Ilustrado: A Figura abaixo ilustra um processo de gerenciamento de mudanças que 
deve entrar em vigor quando o software for entregue para lançamento aos clientes ou para 
implantação dentro de uma organização, cabendo destacar que o formalismo depende da 
complexidade do software. 
• Ferramentas Utilizadas: Ferramentas como sistemas de rastreamento de defeitos ou pacotes 
integrados de gerenciamento de configuração, como o Rational Clear Case, são fundamentais 
para o gerenciamento eficaz das mudanças. 
Rational Clear Case: É uma família de ferramentas de software de computador que suporta gerenciamento de 
configuração de software (GCS) de código-fonte e outros ativos de desenvolvimento de software, sendo 
desenvolvido pela IBM. 
 
Figura – Gerenciamento de mudança. 
1. Origem da Solicitação de Mudança: O processo começa com uma parte interessada enviando um Formulário 
de Solicitação de Mudança (FSM), que pode descrever um relatório de defeitos ou um pedido de adição de 
funcionalidade ao sistema. 
2. Registro e Atualização do FSM: O FSM é atualizado em cada estágio do processo, incluindo informações como 
recomendações de alteração, custos estimados, datas de solicitação, aprovação, implementação e validação. 
3. Validação da Solicitação de Mudança: A validade da solicitação é verificada; se válida, é registrada como 
pendente para avaliação e cálculo de custos. O impacto da mudança é avaliado e os custos associados são 
estimados. 
4. Aprovação da Mudança: Um Comitê de Controle De Mudança (CCM) ou grupo de desenvolvimento analisa e 
aprova as solicitações, exceto por pequenas correções de erros que são tratadas diretamente pelo time de 
desenvolvimento. 
5. Decisão e Priorização: O CCM decide se a mudança é justificável economicamente e prioriza as mudanças 
aprovadas para implementação pelo grupo de desenvolvimento. 
• Fatores de Decisão: Considerações incluem consequências de não realizar a mudança, 
benefícios para os usuários, custos envolvidos e sincronização com novas versões de software. 
• Origem das Solicitações de Mudança: Podem vir de equipe de suporte ao cliente, marketing, 
desenvolvedores, refletindo feedback de clientes ou análises competitivas. 
• Durante o desenvolvimento, quando novas versões do sistema são criadas por meio de 
construções sistemáticas, não há necessidade de um processo formal de gerenciamento de 
mudanças, pois as mudanças que afetam os componentes individuais são passadas diretamente 
para o desenvolvedor do sistema, que pode aceitá-las ou indicar porque não são necessárias. 
• No entanto, uma autoridade independente, como um arquiteto do sistema, deve avaliar e 
priorizar as mudanças que afetam os módulos do sistema produzidos por diferentes times de 
desenvolvimento. 
• Gerenciamento em Desenvolvimento Ágil: Em métodos ágeis, clientes propõem mudanças 
nos requisitos, colaborando com a equipe de desenvolvimento na avaliação e implementação 
das mudanças. 
 
GERENCIAMENTO DE VERSÕES 
• Objetivo do Gerenciamento de Versões: 
✓ Controlar diferentes versões de componentes de software e sistemas. 
✓ Garantir que as alterações feitas por desenvolvedores não interfiram entre si. 
 
• Definição de Gerenciamento de Versões: É o processo de gerenciamento de codelines e 
baselines. 
1. Codeline: É uma sequência de versões do código-fonte. 
o São aplicadas a componentes de sistemas para criar versões diferentes de cada 
componente. 
2. Baseline: É uma definição de um sistema específico. 
o Especifica as versões dos componentes, bibliotecas utilizadas, arquivos de configuração e 
de outras informações do sistema. 
• Importância das Baselines: 
✓ Necessárias para recriar versões individuais de um sistema. 
✓ Facilitam a instanciação de software em versões específicas para clientes. 
✓ Permitem recriação de versões entregues a clientes para correção de defeitos. 
 
Diferentes baselines usam versões diferentes dos componentes de cada codeline, onde podemos destacar a 
mainline que incorpora uma sequência de baselines representando diferentes versões do sistema (conforme 
Figura abaixo) 
 
Figura – Codelines e baselines. 
• Tipos de Sistemas de Controle de Versão: 
1. Centralizados: Composto por um único repositório mestre que mantém todas as versões dos 
componentes. 
Exemplo: SVN (Subversion) - Desenvolvedores realizam check-out dos componentes para suas áreas 
de trabalho, fazem alterações e realizam check-in para atualizar o repositório mestre. 
Subversion é uma ferramenta de controle de versão centralizada. Isso significa que não é indicada para 
todas as equipes de TI, apenas para aquelas que são e estão reunidas em um mesmo espaço físico. 
2. Distribuídos: Composto por várias versões do repositório de componentes ao mesmo tempo. 
Exemplo: Git - Desenvolvedores clonam o repositório para seus computadores, fazem alterações 
localmente e enviam as atualizações para o repositório do projeto através de operações push. Quando 
terminam de fazer as alterações, realizam um commit nas mesmas, atualizando seu repositório. Pull: 
Atualiza o repositório local com todas as alterações feitas em outro repositório. 
GIT é uma ferramentade controle de versão distribuída, o que significa que é adequado para a utilização 
em grandes equipes, nas quais os desenvolvedores não estão localizados geograficamente no mesmo 
local. 
• Ambos os sistemas possuem funcionalidades semelhantes, mas as implementam de maneiras 
diferentes. 
 
• Principais Características dos Sistemas de Controle de Versão: 
1. Identificação de Versão e Lançamento: 
o Versões gerenciadas recebem identificadores únicos. 
o Permite gerenciar diferentes versões do mesmo componente sem alterar seu nome. 
javascript:void(0)
2. Registro do Histórico de Mudanças: 
o Mantém registros das mudanças feitas para criar uma nova versão de um componente a partir de uma versão 
anterior. 
3. Desenvolvimento Independente: 
o Permite que diferentes desenvolvedores trabalhem simultaneamente no mesmo componente. 
o Controla os componentes em que foi feito check-out para edição. 
o Assegura que mudanças feitas por desenvolvedores diferentes não interfiram entre si. 
4. Apoio a Projetos: 
o Suporta o desenvolvimento de vários projetos que compartilham componentes. 
5. Gerenciamento de Armazenamento: 
o Utiliza mecanismos eficientes para evitar cópias duplicadas de arquivos. 
o Armazena apenas as diferenças entre arquivos em vez de manter várias cópias. 
 
• Importância do Controle de Versão no Desenvolvimento de Software: Relevante pois vários 
desenvolvedores podem trabalhar simultaneamente no mesmo componente. 
 
GERENCIAMENTO DE RELEASES 
• Definição de Release: Uma release ou lançamento de sistema, é uma versão do software 
distribuída para clientes. 
 
• Tipos de Releases: 
1. Principais (Major Releases): Oferecem novas funcionalidades significativas. 
2. Secundários (Minor Releases): Consertam defeitos e solucionam problemas relatados por 
clientes (e.x., Na IDE 4.2, onde 4 é a versão principal e 2 é a secundária). 
Lançamentos secundários são comumente gratuitos. 
Entretanto, provavelmente o cliente terá que pagar pela versão 5.0. 
• Um Release de Software contém: 
1. Código executável do sistema. 
2. Arquivos de configuração: Definem como o lançamento deve ser configurado para 
instalações específicas. 
3. Arquivos de dados: Incluem arquivos de mensagens de erro em diferentes idiomas. 
4. Programa de instalação: Facilita a instalação do sistema no hardware de destino. 
5. Documentação: Pode ser eletrônica ou em papel, descrevendo o sistema. 
6. Embalagens e publicidade: Associadas ao lançamento. 
 
• Complexidade do Gerenciamento de Releases: 
✓ Depende do número de clientes e da necessidade de criar lançamentos específicos para diferentes 
hardwares. 
✓ Sistemas e processos de gerenciamento de configurações devem fornecer informações sobre: 
o Quais clientes têm quais versões do sistema. 
o Relação entre lançamentos e versões do sistema. 
✓ Em caso de problemas com um sistema entregua, o GCS deve ser capaz de recuperar todas as 
versões dos componentes utilizados nesse sistema específico. 
 
Módulo 3: Descrever a construção de sistemas 
CONSTRUÇÃO DE SISTEMAS 
• Definição de Construção de Sistemas (build): Processo de criar um sistema executável através 
da compilação e ligação dos componentes do sistema, bibliotecas externas, arquivos de 
configuração e outras informações. 
• Integração de Ferramentas: 
✓ As ferramentas de construção de sistema e de controle de versões devem ser integradas. 
✓ O processo de construção usa versões dos componentes armazenados no repositório 
gerenciado pelo sistema de controle de versões. 
• Ferramentas de Construção Automatizada: 
✓ É recomendado o uso de ferramentas de construção automatizadas para criar um build do 
sistema. 
✓ Construção de sistema envolve diversas informações sobre o software e seu ambiente 
operacional. 
 
• Elementos Incluídos no Build: 
✓ Arquivos de código-fonte. 
✓ Arquivos de dados. 
✓ Arquivos de configuração. 
✓ Bibliotecas vinculadas externamente. 
✓ Especificações das versões do 
compilador. 
✓ Ferramentas de software utilizadas. 
• Construção ideal: Deve ser 
possível construir um sistema 
completo com um único comando ou clique do mouse. 
 
• Funcionalidades disponíveis em Ferramentas para Integração e Construção: 
1. Geração do Script de Construção: 
o Analisa o programa em construção. 
o Identifica componentes dependentes. 
o Gera automaticamente um script de construção ou arquivo de configuração. 
2. Integração com o Sistema de Controle de Versão: 
o Realiza check-out das versões necessárias dos componentes no sistema de controle de versão. 
o Garante a integridade do build. 
3. Recompilação Mínima: 
o Analisa qual código-fonte precisa ser recompilado. 
o Realiza compilações essenciais. 
4. Criação do Sistema Executável: 
o Vincula arquivos objetos compilados entre si e com outros arquivos necessários, como bibliotecas e 
arquivos de configuração, para criar um sistema executável. 
5. Automação dos Testes: 
o Executa testes automaticamente usando ferramentas de automação de teste. 
o Verifica a correta integração dos componentes do build após mudanças. 
✓ Emissão de Relatórios: 
o Fornece relatórios sobre o sucesso ou falha da construção. 
o Inclui informações sobre os testes executados. 
✓ Geração da Documentação: 
o Gera notas de lançamento sobre o build. 
o Cria páginas de ajuda do sistema. 
 
• Script de Construção: 
✓ O script de construção (script de build) desempenha um papel crucial na definição do 
processo de construção do sistema de software. 
✓ Inclui informações sobre componentes, suas dependências e versões das ferramentas 
usadas para compilar e ligar o sistema. 
✓ É necessário que a linguagem de configuração descreva os componentes do sistema e suas 
dependências. 
✓ EM RESUMO: O script de construção não apenas automatiza o processo de compilação e construção de 
software, mas também define explicitamente como o sistema deve ser montado, quais partes devem ser 
incluídas e como elas se interrelacionam. É uma peça fundamental para garantir que o software seja construído 
de maneira consistente e confiável em diferentes ambientes de desenvolvimento e implantação. 
 
• Complexidade no Processo de Construção: As plataformas de sistema envolvidas, confere um 
grau de complexidade no processo de construção. 
• Plataformas Envolvidas 
1. Sistema de Desenvolvimento 
o Ferramentas: Inclui ferramentas de desenvolvimento como compiladores e editores de 
código-fonte. 
o Check-out: Os desenvolvedores fazem check-out do código do sistema de controle de 
versão, ou seja, transferem do repositório para uma área de trabalho particular antes de 
fazer alterações no sistema, sendo possível a criação de uma versão do sistema para teste 
em seu ambiente de desenvolvimento antes de efetivar as alterações feitas no sistema de 
controle de versão. 
o Check-in: Após alterações/testes, é realizado o check-in dos componentes modificados 
de volta ao repositório. 
o Ferramentas locais: O processo de check-in e check-out requer o uso de ferramentas de 
construção locais que utilizam versões de componentes na área de trabalho particular. 
2. Servidor de Construção 
o Servidor de Construção: Utilizado para construir versões definitivas e executáveis do 
sistema. 
o Check-in de código: Todos os desenvolvedores fazem check-in de código no sistema de 
controle de versão no servidor de construção, para construir o sistema. 
o Check-out de componentes: O servidor realiza o check-out de todos os componentes 
necessários para compor a versão do sistema. 
3. Ambiente de Destino 
o Execução do sistema: Este sistema inclui a plataforma na qual o sistema é executado, 
que pode ser semelhante ao hardware de desenvolvimento ou mais simples como 
sistemas embarcados e de tempo real. 
o Componentes adicionais: Em determinados sistemas, o ambiente de destino inclui 
bancos de dados e outros sistemas de aplicações que não podem ser instalados em 
máquinas de desenvolvimento.Figura – Plataformas de desenvolvimento, construção e destino. 
 
INTEGRAÇÃO CONTÍNUA 
• Práticas e Recomendações: 
✓ Os métodos ágeis recomendam a construção frequente do sistema com testes 
automatizados para identificar problemas de software. 
✓ As construções frequentes fazem parte de um processo de integração contínua. 
✓ As metodologias ágeis adotam as melhores práticas, o que possibilita o atendimento rápido 
às mudanças e a integração de forma sistemática. 
✓ Dessa forma, as metodologias ágeis requerem a reconstrução frequente da mainline para 
incorporar diferentes versões do sistema. 
 
Figura – Integração contínua. 
• Etapas da Integração Contínua: 
1. Extração do Sistema Mainline: 
o Extrair o sistema mainline do sistema de gerenciamento de versões para a área de trabalho do 
desenvolvedor. 
2. Construção e Testes Automatizados: 
o Construir o sistema e executar testes automatizados, para evitar falhas. 
o Caso falhem (construção quebrada), deve ser informado quem fez o último check-in, pois essa pessoa 
deverá reparar o problema. 
3. Realização de Mudanças: 
o Fazer as mudanças necessárias nos componentes do sistema. 
4. Nova Construção e Testes: 
o Construir o sistema na área de trabalho particular e executar os testes novamente. 
o Caso ocorra falha, continuar a edição. 
5. Devolução ao Servidor: 
o Após passar nos testes, devolver o sistema ao servidor de construção sem efetivar como novo 
baseline. 
6. Construção no Servidor e Testes: 
o Construir o sistema no servidor de construção e rodar os testes. 
o Caso haja falhas, fazer o check-out dos componentes que falharam e editá-los na área de trabalho 
particular, até que passem nos testes. 
7. Confirmação das Alterações: 
o Após aprovação nos testes no sistema de construção, confirmar as alterações feitas como um novo 
baseline no mainline do sistema. 
 
• Vantagens da integração continua: 
✓ Permite descobrir e corrigir imediatamente problemas causados por interações entre 
diferentes desenvolvedores. 
✓ Garante que o sistema mais recente no mainline seja o sistema funcional definitivo. 
 
• A integração contínua possui algumas restrições: 
✓ Tamanho do sistema: Se o sistema for muito grande, pode ser demorado construí-lo e testá-
lo repetidamente ao longo do dia, tornando a integração contínua inviável. 
✓ Diferenças de plataforma: Se a plataforma de desenvolvimento for diferente da plataforma 
de destino, pode ser difícil ou até impossível executar os testes na área de trabalho do 
desenvolvedor devido a diferenças de hardware, sistema operacional ou software instalado. 
Nos sistemas grandes ou naqueles cuja plataforma de execução não é a mesma da 
plataforma de desenvolvimento, a integração contínua costuma ser impossível. 
 
• Alternativa considerando um Sistema de Construção Diária: 
1. Estabelecimento de um horário regular para entrega de componentes pelo desenvolvedor. 
2. Construção do sistema por meio de compilação e ligação dos componentes, gerando um 
sistema completo. 
3. São realizados testes rigorosos pela equipe de testes. 
4. São documentados e corrigidos os defeitos identificados durante os testes. 
 
• Vantagem das Construções Frequentes: 
✓ Maior chance de detectar falhas nas interações entre componentes de forma precoce. 
✓ Incentiva o desenvolvimento de testes unitários completos para evitar falhas no sistema 
inteiro durante o check-in de novas versões. 
 
LIGAÇÃO DO CÓDIGO-FONTE AO CÓDIGO OBJETO 
• Processo de Compilação e Ligação: 
✓ A compilação é um processo computacionalmente intensiva, que é realizado por um 
determinado compilador. 
Um compilador traduz um programa de uma linguagem textual facilmente entendida por um ser humano para 
uma linguagem de máquina, específica para um processador e sistema operacional. 
✓ Ferramentas de construção minimizam a quantidade de compilação necessária ao verificar se 
há uma versão compilada disponível do componente, em caso positivo, não há necessidade 
de recompilar esse componente. 
• Como ocorre a ligação do código-Fonte de um componente ao código objeto equivalente? 
✓ Esta ligação é realizada por meio da designação de uma assinatura exclusiva a cada arquivo 
de componente de código-fonte armazenado 
✓ O código objeto correspondente, compilado a partir do código-fonte, possui uma assinatura 
relacionada. 
✓ Caso o código-fonte seja editado, esta assinatura é alterada. 
 
• Verificação e Decisão: A comparação das assinaturas entre os arquivos de código-fonte e 
código objeto determina se o componente de código-fonte foi usado para gerar o código 
objeto. 
 
Figura – Ligando código-fonte e código objeto. 
• Há dois tipos de assinaturas (conforme observado na figura acima): 
1. Timestamps de Modificação: 
o A assinatura é a data e hora de modificação (timestamps) do arquivo de código-fonte. 
o Sempre que ocorrer a modificação do arquivo de código-fonte de um componente, o sistema 
realiza a recompilação para criar um novo arquivo de código objeto correspondente. 
o Garante que versões mais recentes do código-fonte sejam sempre refletidas nos objetos 
compilados. 
Observemos a Figura acima, na qual os componentes Comp.java e Comp.class têm assinaturas de modificação de 
17:03:05:15:02:2018 e 16:58:43:15:02:2018, respectivamente. Isto significa que o código Java foi modificado às 17 horas, 3 
minutos e 5 segundos do dia 15 de fevereiro de 2018 e a versão compilada foi modificada às 16 horas, 58 minutos e 43 
segundos do dia 15 de fevereiro de 2018. Neste caso, o sistema recompilaria automaticamente Comp.java, porque a versão 
compilada tem uma data de modificação anterior à versão mais recente do componente. 
2. Somas de Verificação (Checksum) de Código-Fonte: 
o A assinatura no arquivo de código-fonte é uma soma de verificação (checksum) 
calculada a partir dos dados no arquivo. 
o Isso gera um número exclusivo a partir do texto de origem como entrada. 
o Onde, qualquer alteração no texto do código-fonte gera uma soma de verificação diferente. 
o A soma de verificação é atribuída ao código-fonte antes da compilação, para garantir 
integridade e identificação única. 
o Em seguida, o sistema de construção marca o arquivo de código objeto com a assinatura da 
soma de verificação. 
o Isso permite verificar se há um arquivo de código objeto correspondente ao código-fonte. 
o Se não houver um arquivo de código objeto com a mesma assinatura, o código-fonte precisa 
ser recompilado. 
 
• Principais diferenças entre assinaturas timestamps e checksum de código-fonte: 
✓ Timestamps de Modificação: 
o Definição: A assinatura é a data e hora em que o arquivo de código-fonte foi modificado. 
o Funcionamento: Sempre que há uma modificação no código-fonte, o sistema realiza a 
recompilação para criar um novo arquivo de código objeto. 
o Vantagens: Garante que a versão mais recente do código-fonte seja refletida no código 
objeto compilado. 
o Limitações: Armazena apenas a versão compilada mais recente no sistema, pois não 
mantém versões anteriores dos objetos compilados. 
✓ Somas de Verificação (Checksum): 
o Definição: A assinatura é uma soma de verificação calculada a partir dos dados no arquivo 
de código-fonte. 
o Funcionamento: Qualquer alteração no texto do código-fonte gera uma soma de verificação 
diferente. 
o Vantagens: Permite manter simultaneamente muitas versões diferentes do código 
objeto, pois identifica exclusivamente o arquivo de origem. 
o Implementação: O código objeto gerado é marcado com a assinatura da soma de 
verificação, facilitando a identificação de mudanças no código-fonte que exigem 
recompilação. 
o Vínculo entre Código-Fonte e Objeto: A assinatura da soma de verificação é o vínculo entre 
o código-fonte e o código objeto, independentemente do nome do arquivo. 
 
Módulo 4: Descrever as ferramentas CASE para gerenciamento de configurações 
AMBIENTE DE GERENCIAMENTO DE CONFIGURAÇÕES 
• Padronização dosProcessos: 
✓ Os processos de gerenciamento de configurações são padronizados. 
✓ Ou seja, incluem procedimentos predefinidos e requerem o gerenciamento de grande 
quantidade de dados. 
• Exemplo de Incidente: 
✓ Um engenheiro publica uma versão de um componente com conexão ao banco de dados X. 
✓ Há uma alteração de requisito não funcional para o banco de dados Y. 
✓ A versão do componente da camada de persistência não estava corretamente gerenciada. 
• Conclusão e Solução: 
✓ Incidentes como o citado demonstram a importância do apoio de uma ferramenta CASE. 
✓ Ferramentas CASE são essenciais para o gerenciamento de configuração. 
✓ Podem ser combinadas para criar uma área de trabalho que apoia todas as atividades de 
gerenciamento de configuração. 
• Ferramentas CASE: Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma 
classificação que abrange todas as ferramentas baseadas em computadores que auxiliam 
atividades de Engenharia de Software, desde análise de requisitos e modelagem até 
programação e testes. 
✓ Abrangência das Atividades Auxiliadas: 
o Análise de Requisitos: Ajuda na coleta e especificação de requisitos. 
o Modelagem: Facilita a criação de modelos para representar o sistema. 
o Programação: Suporta a escrita e manutenção do código-fonte. 
o Testes: Auxilia na verificação e validação do software. 
 
• Ambientes de Gerenciamento de Configurações: 
✓ Ambientes Abertos: 
o Utilizam ferramentas de código aberto para cada estágio do processo, que são integradas 
por meio de procedimentos organizacionais padronizados. 
o O gerenciamento de mudança, o gerenciamento de versões e a construção de 
sistemas possuem ferramentas específicas que devem ser integradas. 
✓ Ambientes Integrados: 
o Oferecem recursos integrados para: 
➢ Rastreamento de mudanças. 
➢ Controle de versões. 
➢ Construção de sistemas. 
o Proporcionam uma solução unificada para todas as etapas do ciclo de vida do 
desenvolvimento de software. 
 
• Destaca-se que sistemas complexos com equipes de desenvolvimento geograficamente 
distantes necessitam de ferramentas de gerenciamento de configuração que apoiem o trabalho 
em diferentes localidades com múltiplos repositórios de dados para itens de configuração. 
 
APOIO PARA GERENCIAMENTO DE MUDANÇAS 
• Modelo de Processo de Mudanças: 
✓ Deve ser projetado e integrado com um sistema de gerenciamento de versões. 
✓ Garante que documentos gerados nas atividades relacionadas às mudanças sejam enviados 
às pessoas certas no momento certo. 
• As ferramentas de Gerenciamento de Mudanças fornecem os seguintes recursos para dar 
suporte ao processo: 
✓ Editor de Formulários: Permite criar ou completar formulários com propostas de mudanças. 
✓ Sistema de Workflow: 
o Define quem deve processar a solicitação de mudança e a ordem de processamento. 
o Encaminha formulários automaticamente para as pessoas corretas no tempo certo. 
o Informa a equipe sobre o progresso da mudança. 
✓ Banco de Dados de Mudança: 
o Gerencia todas as propostas de mudança. 
o Pode estar ligado a um sistema de gerenciamento de versões. 
o Os recursos de consulta permitem encontrar propostas específicas de mudança. 
✓ Sistema de Relato de Mudanças: Gera relatórios gerenciais sobre o status das solicitações de 
mudança enviadas. 
 
APOIO PARA GERENCIAMENTO DE VERSÕES 
• Controle de Repositório: 
✓ As ferramentas de gerenciamento de versões controlam um repositório de itens de 
configuração no qual os conteúdos dos repositórios não podem ser alterados. 
• Como trabalhar em um, item de configuração: 
✓ Engenheiro de software realiza check-out do item de configuração do repositório e o 
armazena no diretório de trabalho. 
✓ Realiza mudanças no componente no diretório de trabalho. 
✓ Após as alterações, realiza check-in para devolver ao repositório. 
✓ Uma nova versão é automaticamente criada no repositório após o check-in. 
 
Os sistemas de gerenciamento de versões fornecem um conjunto básico de capacidades 
semelhantes, embora alguns recursos sejam mais sofisticados que outros. 
 
• Funcionalidades das Ferramentas de Gerenciamento de Versões: 
✓ Identificação de Versões e Releases: Versões gerenciadas recebem identificadores ao serem 
enviadas ao sistema. 
✓ Gerenciamento de Armazenamento: 
o O Sistema de Gerenciamento de Versões fornece recursos para descrever versões pelas suas 
diferenças em relação a uma versão mestre. 
o As diferenças entre versões, são representadas por um delta, que engloba instruções 
necessárias para recriar a versão associada. 
✓ Registro do Histórico de Mudanças: 
o Documenta todas as alterações feitas no código de um sistema ou componente. 
o Possui um desenvolvimento independente, pois permite o desenvolvimento paralelo de 
múltiplas versões de um sistema, permitindo modificações independentes. 
o O sistema de gerenciamento de versões mantém a rastreabilidade dos componentes retirados 
para edição por meio do check-out. 
✓ Suporte a Projetos: Possui suporte a múltiplos projetos. 
 
 
 
Figura – Versões baseadas em delta. 
 
SUPORTE PARA CONSTRUÇÃO DE SISTEMAS 
• Processo Computacional Intensivo: A construção de sistemas é um processo computacional 
intensivo, podendo incluir centenas de arquivos. 
• Ferramentas de Construção: 
✓ Automatizam o processo de construção para reduzir a possibilidade de ocorrência de erro 
humano . 
✓ Minimização do tempo necessário para a construção de sistemas, quando possível. 
• Recursos que podem estar presentes nas Ferramentas CASE para Construção de Sistemas: 
✓ Linguagem de Especificação de Dependências e Interpretador Associado, pois as 
dependências de componentes podem ser descritas e a recompilação minimizada. 
✓ Seleção de Ferramentas e Apoio a Instanciação, incluem compiladores e outras 
ferramentas de processamento para arquivos de código-fonte. 
✓ Suporte à Compilação Distribuída em Redes, de modo que antes da compilação ser 
executada, o desenvolvedor do sistema, busca por processadores ociosos na rede para alocar 
compilações paralelas, o que reduz significativamente do tempo de construção do sistema. 
✓ Gerenciamento de Objetos Derivados, liga os diferentes código-fontes, derivando 
novamente um objeto apenas quando necessário, devido a mudanças no código-fonte. 
 
• Dependência entre Objetos Derivados: 
✓ Exemplo com módulos e arquivos: 
o Compilador comp é criado a partir dos módulos objetos scan.o, syn.o, sem.o, e cgen.o. 
o Cada módulo objeto é criado de seus respectivos códigos-fonte (scan.c, syn.c, sem.c, cgen.c). 
o Arquivo de declarações defs.h é compartilhado por scan.c, syn.c, e sem.c. 
o Na Figura abaixo, as setas significam 'depende de', ou seja, a entidade na base da seta depende 
da entidade que está no topo, de modo que comp depende de scan.o, syn.o, sem.o e cgen.o; 
scan.o depende de scan.c, e assim, sucessivamente. 
 
Figura – Dependências entre componentes. 
• O que que ocorreria se scan.c fosse alterado? 
✓ A ferramenta de construção detectará a necessidade de recriar scan.o porque scan.c foi 
modificado. 
✓ O compilador C será chamado para compilar scan.c e gerar um novo scan.o. 
✓ A ferramenta reconstruirá o componente comp, que depende de scan.o, syn.o, sem.o e 
cgen.o, para refletir as mudanças feitas em scan.c e outras partes do sistema. 
✓ Portanto, a alteração em scan.c desencadeará uma série de eventos na ferramenta de 
construção de sistemas para garantir que todas as dependências sejam atualizadas 
corretamente e que o componente comp seja recriado para incorporar todas as mudanças 
feitas no código-fonte. 
A partir deste exemplo, pode-se verificar a complexidade de gerenciamento de 
diversos arquivos e respectivas dependências, portanto, a automação do 
gerenciamento de versões é fortemente recomendada. 
 
• Critério para Recompilação: 
✓ Muitas ferramentas de construção de sistemas usam a data de modificação do arquivo 
como atributo-chave paradecidir se a recompilação é necessária. 
✓ De modo que, o código objeto é recriado apenas se o código-fonte correspondente foi 
modificado após a última compilação. 
• Registro de Versões: 
✓ Algumas ferramentas mantêm o registro da última versão do código objeto correspondente 
ao código-fonte mais recente modificado. 
✓ Outras ferramentas sofisticadas, usam marcação nos objetos derivados com identificações 
dos códigos-fonte usados para gerá-los. 
o O que permite manter todos os objetos derivados, facilitando o gerenciamento de versões 
e recompilações. 
 
FERRAMENTAS CASE PARA GERENCIAMENTO DE CONFIGURAÇÃO 
• Benefícios das Ferramentas CASE para Gerenciamento de Configuração: 
✓ Promovem o aumento da produtividade no gerenciamento e controle de itens de 
configuração durante o desenvolvimento de software. 
• As ferramentas CASE podem ser divididas em três grupos principais: 
1. Ferramentas de suporte individual: Tratam o controle de versões, o controle de mudança 
e a integração contínua de itens. 
2. Ferramentas de suporte ao projeto: Suportam o projeto e apoiam a integração das 
atividades da gerência de configuração. 
3. Ferramentas de suporte completo à organização: Apoiam o processo da empresa e a 
gerência de configuração atrelada ao processo. 
 
Figura - Principais grupos de ferramentas. 
• Ferramentas de Suporte Individual: 
1. Controle de versões: Permite a identificação, armazenamento e gerenciamento dos itens de 
configuração. 
2. Controle de mudança: Foca nos procedimentos pelos quais as mudanças de um ou mais 
itens de configuração são propostas, avaliadas, aprovadas e implantadas. 
3. Integração contínua: Permite a identificação, empacotamento e preparação de uma 
baseline, garantindo que as mudanças sejam construídas, testadas e relatadas. 
 
A tabela a seguir apresenta algumas ferramentas, divididas pelos grupos: 
Tipo de ferramenta Ferramentas open source Ferramentas comerciais 
Controle de versão CVS 
Subversion (SVN) 
Aegis 
Arch 
JEDI 
PVC 
ClearCase 
StarTeam 
Perforce 
BitKeeper 
Synergy 
Serena 
Microsoft Visual Source Safe 
Controle de mudança Bugzilla 
Trac 
Mantis 
Scarab 
PVCS 
Jira 
FogBugz 
CaliberRM 
ClearQuest 
Perforce 
Synergy 
Serena 
Integração contínua Ant 
SCons 
Bitten 
Maven 
CruiseControl 
Gump 
TinderBox 
Build Forge 
Anthill Pro 
FinalBuilderestá correta e garante que está de acordo com os requisitos registrado no 
documento de requisitos. 
• A verificação (validação) permite a correção de cada modelo e o balanceamento entre eles. 
 
❖ ETAPA DE PROJETO 
Objetivo: 
• Permite refinar modelos gerados na análise e construir novos modelos com menor nível de 
abstração. 
• Permite definir “COMO” implementar a solução especificada. 
• Permite atingir um nível de detalhamento que permita a implementação da solução. 
Principais Atividades: 
✓ Refinamento do Modelo de Classes: Detalhamento adicional dos modelos de classes iniciados na 
análise. 
✓ Construção do Modelo de Interação: Identificação da comunicação entre objetos para implementar 
as funcionalidades especificadas pelos casos de uso. 
✓ Mapeamento Objeto-Relacional: Permite geração do modelo lógico do banco de dados, 
considerando requisitos não funcionais que determinem uma tecnologia relacional. 
✓ Desenho dos Componentes e Nós Computacionais: Permite a modelagem dos componentes do 
sistema e dos nós computacionais necessários para sua implantação, gerando modelos que 
determinam a arquitetura do sistema. 
 
❖ ETAPA DE IMPLEMENTAÇÃO 
• Implementação refere-se ao processo de desenvolver, codificar e configurar o software de 
acordo com os requisitos especificados 
• A implementação permite transformar o design e as especificações em código executável. 
• Nesta etapa, ocorre a codificação do software de acordo com os requisitos definidos na etapa 
de Projeto. 
• Os padrões de projeto devem ser considerados por representarem melhores práticas de 
implementação do software. 
Principais Atividades: 
✓ Codificação: Escrever o código-fonte do software utilizando uma linguagem de programação. 
✓ Testes: Realizar testes unitários, de integração e de sistema para garantir que o software funciona 
corretamente. 
✓ Depuração: Identificar e corrigir erros (bugs) no código. 
✓ Documentação: Criar documentação técnica e de usuário para o software. 
 
• Objetivo da Implementação: Criar e assegurar o funcionamento do software conforme os 
requisitos. 
• Foco da Implementação: Foca no desenvolvimento e testes do software. 
 
❖ ETAPA DE TESTES 
• Nesta etapa, são aplicados os denominados testes de software ou testes de validação. 
• Objetivo da Aplicação de Testes de Software/Validação: Verificar se o produto certo está 
sendo construído. 
• Os testes validam os componentes individualmente bem como a integração entre eles. 
Tipos de Testes: 
1. Testes Unitários: Validação de componentes individualmente. 
2. Testes de Integração: Verificação da integração entre componentes. 
3. Testes de Aceitação ou Homologação: Avaliação final antes da migração para produção. 
Por fim ocorre, a migração para o ambiente de produção: Ocorre após a conclusão dos testes de 
aceitação. 
Recomendações importantes: 
• Um plano de teste deve ser gerado a partir dos casos de teste. 
• Por sua vez, os casos de testes estão vinculados aos cenários na descrição de cada caso de uso. 
 
❖ ETAPA DE IMPLANTAÇÃO 
• Implantação é o processo de disponibilizar o software implementado para os usuários finais ou 
para o ambiente de produção. 
• Nesta etapa, o software é migrado para o ambiente de produção, de acordo com o aval da 
equipe de qualidade. 
• A etapa de implantação pode exigir: 
✓ A geração de manuais de utilização. 
✓ A migração de dados do ambiente de homologação para o de produção. 
✓ Treinamento de usuários. 
✓ Ou a implantação de um call-center em caso de sistemas complexos. 
 
• Objetivo da Implantação: Tornar o software disponível e funcional no ambiente de produção, 
pronto para uso pelos usuários finais. 
• Foco da Implantação: Foca na preparação do ambiente e disponibilização do software para os 
usuários finais. 
 
FLUXO DE PROCESSO 
• A especificação de um processo de desenvolvimento de software (que é um requisito não 
funcional), requer: 
✓ A definição de quais atividades irão compor o respectivo processo. 
✓ Como as referidas atividades serão encadeadas denominada de Fluxo de Processo ou Ciclo de Vida. 
Tipos de Fluxo de Processo: 
1. Fluxo de processo Linear: Atividades executadas em sequência, de modo que cada atividade é 
realizada uma única vez. 
 
2. Fluxo de processo Iterativo: Atividades ou conjuntos de atividades podem ser repetidos antes de 
prosseguir. 
 
3. Fluxo de processo Evolucionário: Onde o sequenciamento de cada fluxo inclui todas as atividades, 
sendo que cada iteração completa gera uma nova versão do software, ou seja, o software agrega 
valor às suas funcionalidades a cada ciclo completo. Fluxo de Processo Evolucionário permite o 
versionamento do software e o melhor trato da complexidade 
 
4. Fluxo de processo Paralelo: Permite a execução de uma ou mais atividades simultaneamente. 
 
5. Fluxo de processo Iterativo e Incremental: Cada iteração inclui todas as atividades e ocorre o 
versionamento do produto software gerado. Neste modelo, a cada novo ciclo, um subconjunto de 
requisitos é considerado. 
 
• Ressalta-se que: Não existe engenharia sem processo. 
 
Módulo 3. Relacionar as etapas de um processo de desenvolvimento de software com as 
etapas de gerenciamento de projeto 
GERENCIAMENTO DE PROJETO 
Objetivo: Aplicar sistematicamente uma metodologia para transformar a necessidade de um 
usuário em um produto software. 
PMI (Project Management Institute): 
• É uma organização que dissemina melhores práticas de Gerenciamento de Projetos 
globalmente. 
• Considera o gerenciamento de projetos uma profissão. 
• Certificação PMP: Certificação Profissional de Gerenciamento de Projetos do PMI é 
reconhecida como uma das mais importantes para a indústria, incluindo a de software. 
✓ Importância da Certificação: 
o Complementa a formação acadêmica. 
o Atualiza o profissional de TI. 
o Aumenta a empregabilidade e oportunidades de promoção. 
 
 
Guia PMBOK (Project Management Body of Knowledge): 
• O PMI é responsável por publicar um conjunto de melhores práticas para gerenciamento 
de projetos, denominado PMBOK (Project Management Body of Knowledge). 
• PMBOK (Project Management Body of Knowledge) - Guia de Conhecimento em 
Gerenciamento de Projetos 
• O PMBOK é uma base para criar metodologias de desenvolvimento de software. 
 
Conceitos Essenciais: 
• Conceito de Projeto: É um esforço temporário para criar um produto, serviço ou resultado 
único. 
✓ Todo projeto é temporário, logo possui início, meio e fim. 
✓ O projeto impulsiona mudanças nas organizações. 
• Conceito de Gerenciamento de Projetos: É a aplicação de conhecimentos, habilidades, 
ferramentas e técnicas para cumprir requisitos do projeto. 
✓ Envolve integração adequada dos processos de gerenciamento. 
✓ Permite a execução eficaz e eficiente de projetos. 
• Tanto a Engenharia de software, quanto o gerenciamento de projetos são baseados em 
processos. 
 
CICLO DE VIDA DO PROJETO x GRUPOS DE PROCESSO 
Ciclo de Vida do Projeto: 
• Inclui as fases genéricas: início do projeto, organização e preparação, execução do trabalho, 
e término do projeto. 
 
Figura – Ciclo de vida do projeto. 
• O ciclo de vida do projeto relaciona-se com os fluxos de processos (linear, iterativo, 
evolucionário, paralelo e iterativo e incremental). 
• A seleção do fluxo de processo determina as fases do projeto e suas entregas. 
 
Gerenciamento do Ciclo de Vida do Projeto: 
• Como o ciclo de vida do projeto é gerenciado? É gerenciado por meio da execução de 
processos de gerenciamento de projetos. 
• Cada processo de gerenciamento de projeto transforma entradas em saídas usando 
técnicas e ferramentas apropriadas. 
• As saídas podem ser uma entrega ou um resultado. 
 
Figura – Processo de Gerenciamento de Projeto. 
A gestão de um projeto possui cinco etapas: 
1. Iniciação 
2. Planejamento 
3. Execução 
4. Monitoramento e Controle 
5. Encerramento. 
 
• Cada etapa da gestão de um projetocontém um grupo de processos de Gerenciamento 
de Projetos. 
Exemplo: Na etapa de INICIAÇÃO, o gerente de projetos tem que considerar as etapas de gestão: 
1. Seleciona os processos que serão utilizados de acordo com a complexidade do projeto. 
2. Aloca responsáveis por cada processo de acordo com a área de conhecimento. 
3. Os responsáveis realizam os processos de acordo com o que preconiza o PMBOK. 
4. Os responsáveis geram seus respectivos resultados para cada processo. 
Em seguida, aplica os passos de 1 a 4 para cada etapa do ciclo de vida do projeto (Planejamento, Execução, 
Monitoramento e Controle e Encerramento). Em projetos complexos, as etapas podem ocorrer de forma iterativa. 
Existem cinco grupos de processos de Gerenciamento de Projetos: 
1. Grupo de Processo de Iniciação: 
✓ Inclui processos realizados no início de um projeto. 
✓ Termo de Abertura do Projeto autoriza a alocação de recursos. 
2. Grupo de Processo de Planejamento: 
✓ Envolve processos para planejar a execução do projeto. 
✓ A primeira atividade é o gerenciamento do escopo. 
✓ Principal entrega: Cronograma, que inclui datas de início e término das atividades. 
3. Grupo de Processo de Execução: 
✓ Nesta etapa é executado o projeto conforme o planejamento. 
✓ Logo este constitui um grande desafio para gerente de projeto (executar o que foi planejado). 
✓ Envolve integração de pessoas e conhecimentos distintos. 
4. Grupo de Processo de Monitoramento e Controle: 
Figura - Grupos de Processos 
✓ Inclui processos que permitem monitorar e controlar o progresso e desempenho do projeto. 
✓ Aplicação de ações corretivas para atividades não conformes, por meio de gerenciamento de mudanças. 
5. Grupo de Processo de Encerramento: 
✓ Conclusão ou encerramento formal do projeto. 
✓ Inclui entrega e aceitação do produto, dispensa da equipe e avaliação dos resultados. 
 
ÁREAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS 
• A complexidade é um fator determinante na definição de um processo de desenvolvimento 
software. 
• A complexidade também está relacionada com o Gerenciamento de Projeto, pois, quanto 
maior o problema, mais multidisciplinar este se torna. 
• Em função da complexidade de um projeto de software, o corpo técnico deve ser integrado 
com todas as áreas de conhecimento 
✓ Exemplo: A equipe técnica poderia ser composta por engenheiro de software, analistas, 
administrador de banco de dados, programadores, arquitetos de softwares e outros. 
✓ Porém essa equipe não seria capaz de realizar a gestão de projeto de software. 
✓ Uma equipe de gerenciamento de projeto deve ser composta por: especialistas em custos 
(realizam orçamentos realistas), especialistas em aquisições (responsável por contratações ou 
licitações), especialistas em recursos humanos (gerência os direitos trabalhistas da equipe) e 
outros. 
✓ Dessa forma o ideal é que o perfil da equipe deverá estar alinhado com as áreas de 
conhecimento. 
• O gerenciamento de projetos é uma atividade multidisciplinar. 
• Logo, o PMBOK divide essa complexidade em 10 (dez) áreas de conhecimento, onde cada 
área é composta por um grupo de processos: 
Tabela. Área de conhecimento e seu relacionamento com grupos de processos. 
Áreas de 
conhecimento 
Iniciação Planejamento Execução Monitoramento e 
controle 
Encerramento 
INTEGRAÇÃO 
Responsável: 
gerente de projeto 
1. Desenvolver o termo 
de abertura do projeto. 
2. Desenvolver o plano 
de gerenciamento do 
projeto. 
3. Orientar e 
gerenciar a 
execução do 
projeto. 
4. Monitorar e controlar o 
trabalho do projeto. 
5. Realizar o controle 
integrado de mudanças. 
6. Encerrar o projeto ou 
fase 1. 
ESCOPO 1. Coletar os requisitos 
2. Definir o escopo 
3. Criar a EAP (Estrutura 
Analítica do Projeto) 
 4. Verificar o escopo 
5. Controlar o escopo 
 
TEMPO 1. Definir as atividades 
2. Sequenciar as 
atividades 
3. Estimar os recursos 
das atividades 
4. Estimar as durações 
das atividades 
 5. Controlar o cronograma 
5. Desenvolver o 
cronograma 
CUSTOS 
Responsável: 
especialista em 
custos 
 1. Estimar os custos 
2. Determinar o 
orçamento 
 
 3. Controlar os custos 
QUALIDADE 
Responsável: 
gerente/engenheiro 
de qualidade 
 1. Planejar a qualidade 2. Realizar a 
garantia de 
qualidade 
3. Realizar o controle da 
qualidade 
 
RECURSOS 
HUMANOS 
Responsável: gestor 
de recursos 
humanos 
 1. Desenvolver o plano 
de recursos humanos 
2. Mobilizar a 
equipe do projeto 
3. Desenvolver a 
equipe do projeto 
4. Gerenciar a 
equipe do projeto 
 
COMUNICAÇÃO 1. Identificar as partes 
interessadas 
2. Planejar as 
comunicações 
3. Distribuir as 
informações 
4. Gerenciar as 
expectativas das 
partes interessadas 
5. Reportar o desempenho 
RISCOS 1. Planejar o 
gerenciamento dos 
riscos 
2. Identificar os riscos 
3. Realizar a análise 
qualitativa dos riscos 
4. Realizar a análise 
quantitativa dos riscos 
5. Planejar as respostas 
aos riscos 
 6. Monitorar e controlar os 
riscos 
 
AQUISIÇÃO 
Responsável: 
especialista em 
aquisições 
 1. Planejar as 
aquisições 
2. Conduzir as 
aquisições 
3. Administrar as 
aquisições 
4. Encerrar as 
aquisições 
 
Gerenciamento da Integração do Projeto: 
• Objetivo: Tratar dos processos que permitem a integração das diferentes áreas de 
conhecimento, estando sob controle direto do gerente de projetos. 
• Responsabilidades do gerente de projetos: 
✓ Gerente de projeto atua como maestro, coordenando todas as atividades, sem ter conhecimento 
específico de cada área do conhecimento. 
✓ O gerente de projetos combina os resultados de todas as outras áreas de conhecimento e tem a visão 
geral do projeto, pois é o único responsável pelo projeto como um todo. 
✓ O gerente de projetos está presente em todas as etapas de gestão (por isso conforme a tabela anterior, 
a integração é a única área com processos em todos os grupos de processos). 
✓ Termo de Abertura do Projeto autoriza a alocação de recursos ao projeto. 
 
Gerenciamento do Escopo do Projeto: 
• Objetivo: Assegurar que o projeto inclua todo o trabalho necessário para que termine com 
sucesso. 
• Atividades Principais: São realizados a especificação e detalhamento dos requisitos de 
software. 
• Principal técnica para a definição do escopo: É a confecção da Estrutura Analítica do 
Projeto (EAP) ou Work Breakdown Structure (WBS). 
• Estrutura Analítica do Projeto (EAP): 
✓ Cada elemento da EAP constitui uma entrega. 
✓ Entregas não decompostas são chamadas de pacotes de trabalho ou workpackages. 
✓ Pacotes de trabalho são conjuntos de tarefas ou ações a serem executadas no projeto. 
 
Figura – Exemplo de EAP. 
 
Gerenciamento do Cronograma do Projeto: 
• Objetivo: Gerenciar o término pontual do projeto. 
• Principal entrega: Cronograma físico do projeto. 
• O cronograma do projeto é gerado na etapa de planejamento do projeto. 
• Etapas do Cronograma: 
1. São identificadas as atividades, a partir dos pacotes de trabalho da EAP. 
2. Para cada atividade, são especificadas a duração e insumos necessários. 
3. É elaborado o diagrama de rede (do cronograma) para determinar as interdependências entre as 
atividades. 
4. É elaborado o cronograma do projeto. 
EAP
1. Infraestrutura
1.1 Projeto
1.2 Execução 
Atualização
2. Fornecedor 
EAP
3. Módulo 
compras 
3.1. Migração de 
dados 
3.2 Implantação
3.3 Treinamento
3.4 Homologação
4. Módulo 
vendas
4.1 Migração de 
dados
4.2 Implantação
4.3 Treinamento
4.4 Homologação
5. Módulo 
contabilidade/ 
Fiscal 
5.1 Migração de 
dados
5.2 Implantação
5.3 Treinamento
5.4 Homologação
6. Aceitação EAP 
6.1 Homologação 
integrada
6.2 Quitação do 
projeto
 
Figura – Diagrama de Rede do Cronograma do Projeto. 
 
Figura – Exemplo de Cronograma Detalhado do Projeto. 
• Gerenciamento dos Custos do Projeto: Inclui os processos envolvidos na gestão dos 
orçamentos para que o projeto terminedentro do orçamento aprovado. 
• Gerenciamento da Qualidade do Projeto: Inclui os processos que garantem o atendimento 
aos requisitos do projeto e às expectativas dos financiadores. 
• Gerenciamento dos Recursos do Projeto: Inclui os processos para identificar, adquirir e 
gerenciar os recursos necessários para concluir o projeto com sucesso. 
• Gerenciamento das Comunicações do Projeto: Inclui os processos necessários para 
assegurar a gestão oportuna e apropriada das informações do projeto. 
• Gerenciamento dos Riscos do Projeto: A área que inclui os processos de gestão dos riscos 
no projeto. 
• Gerenciamento das Aquisições do Projeto: Inclui os processos necessários para comprar 
ou adquirir produtos, serviços ou resultados externos à equipe do projeto. 
• Gerenciamento das Partes Interessadas do Projeto: Inclui os processos necessários para 
identificar partes interessadas e desenvolver estratégias para seu engajamento eficaz nas 
decisões e execução do projeto. 
 
Em resumo: 
• Relacionamento entre o Fluxo de Processo de Software e o Ciclo de Vida de Gerenciamento do 
Projeto: Ambos baseiam-se no conceito de processo. 
• O processo é a camada principal na Engenharia de Software. 
• Gerenciamento de projeto é orientado por grupos de processos. 
• O processo de Gerenciamento de Projetos possui 2 dimensões: 
✓ Parte de um grupo de processos. 
✓ Parte de uma das 10 áreas de conhecimento. 
• Como tratar a Complexidade em Projetos Multidisciplinares? 
✓ Áreas de conhecimento ajudam a gerenciar a complexidade. 
✓ Equipe de gerenciamento deve ser composta por especialistas em diversas áreas. 
 
Módulo 4. Descrever a importância do gerenciamento de risco no projeto de software 
RISCO 
• Definição de Risco: Evento ou condição incerta que pode afetar um ou mais objetivos do 
projeto, positivamente ou negativamente. 
• Importância da Avaliação de Riscos: Ajuda a prever problemas e a se preparar para eles, 
minimizando impactos negativos e potencializando oportunidades. 
Exemplos de Riscos em Viagens: 
✓ Problemas de Saúde: Acidentes ou doenças. 
✓ Cancelamento de Passagens: Companhia aérea pode cancelar voos. 
✓ Insuficiência de Dinheiro: Quantidade de dólares adquirida pode ser inadequada. 
 
• Incerteza: A avaliação de risco gera uma preocupação com o futuro, inserindo um grau de 
incerteza (podendo ou não ocorrer). 
• O risco pode levar a impactos negativos ou Impacto Positivos: Embora comumente 
associados a efeitos negativos, riscos podem também ter efeitos positivos. 
• Exemplo: Empresa Exportadora de Minério identificou o seguinte risco: Variação cambial do dólar. O 
planejamento inclui aplicar investimentos em novos projetos de prospecção de minas. O dólar atual 
custa 5,50 e a empresa realiza uma projeção de aumento do dólar em um ano: 
Cenários de Variação Cambial: 
✓ Cenário Negativo dólar a R$ 4,00 (prejuízo): Irá provocar a redução do portfólio de projetos devido à 
menor receita de exportação. Esse cenário é um obstáculo para a consecução dos resultados esperados. 
✓ Cenário Positivo dólar a R$ 7,00 (lucro): Irá provocar o aumento do capital de investimento devido à 
maior receita de exportação. Esse cenário é uma oportunidade para a consecução dos resultados 
esperados. 
Risco em Projetos: 
• A avaliação do risco permite planejar o futuro e evitar possíveis problemas. 
• O gerenciamento de risco permite a sistematização do tratamento do risco em forma de 
plano. 
• Fundamental considerar e avaliar riscos em qualquer planejamento. 
• Os grupos de processos de gerenciamento de projetos (iniciação, planejamento, execução, 
monitoramento e controle e encerramento) permitem a sistematização da identificação, da análise 
e das respostas aos riscos de um projeto. 
 
Identificação de Riscos 
• O risco possui três componentes: 
1. Evento: O que pode ocorrer. 
2. Probabilidade de Ocorrência: Grau de incerteza. 
3. Impacto: Consequência caso o evento ocorra, associado ao grau de perda. 
 
Plano de Gerenciamento de Riscos 
• O plano de gerenciamento de risco permite a elaboração da Estrutura Analítica de Risco (EAR). 
• Estrutura Analítica do Risco (EAR): Auxilia na definição, identificação e categorização de potenciais 
fontes de riscos. 
• O processo de identificação de riscos requer uma clara compreensão da missão, escopo e objetivos 
do projeto. 
 
Identificação das Categorias Genéricas de Riscos: 
• Tamanho do Produto: São riscos relacionados ao tamanho do software. 
• Impacto no Negócio: São riscos de restrições do cliente ou mercado. 
• Características dos Envolvidos: São riscos relacionados com a comunicação (ex.: entre engenheiros 
de software e clientes). 
• Definição do Processo: São riscos relacionados com a auditoria de processos pela equipe de 
qualidade. 
• Ambiente de Desenvolvimento: São riscos associados às ferramentas disponíveis para criação do 
software. 
• Tecnologia a ser Criada: São riscos relacionados com as inovações tecnológicas no desenvolvimento 
do software (ex.: um novo framework de persistência de dados). 
• Quantidade de Pessoas e Experiência: São riscos associados aos perfis e experiência da equipe de 
trabalho. 
 
Técnicas de Identificação de Riscos: 
• O processo de identificação de riscos é iterativo, pois novos riscos podem aparecer durante 
o projeto. 
• Técnicas utilizadas na identificação de risco: 
✓ Brainstorming: É uma reunião multidisciplinar de especialistas, que possui a finalidade de gerar 
uma lista abrangente de riscos sob a orientação de um facilitador. 
✓ Lista de Verificação (Check-List): Trata se de uma lista de riscos baseadas em informações 
históricas e conhecimentos acumulados de projetos semelhantes. Ajudam a identificar pontos 
fracos no projeto atual. 
✓ Entrevista: Os riscos podem ser identificados por meio de entrevistas com os participantes do 
projeto ou especialistas da área. Com a diversidade de experiência e especialidade de cada um 
consegue-se atingir um maior número de apontamentos no processo de identificação de riscos. 
Exemplo de perguntas a serem feitas: 
1. A alta gerência e o cliente estão comprometidos com o projeto? 
2. Os usuários estão comprometidos com o projeto e o sistema/produto? 
3. Os requisitos são bem entendidos pela equipe e clientes? 
4. Os clientes participaram na definição dos requisitos? 
5. As expectativas dos usuários são realistas? 
6. O escopo do projeto é estável? 
7. A equipe tem as aptidões adequadas? 
8. Os requisitos do projeto são estáveis? 
9. A equipe tem experiência com a tecnologia a ser implementada? 
10. O número de pessoas na equipe é adequado? 
11. Todos concordam com a importância do projeto e requisitos do sistema/produto? 
Respostas negativas indicam possíveis riscos a serem adicionados à lista de riscos. 
 
ANÁLISE QUALITATIVA DOS RISCOS 
• Devido as limitações de tempo e recursos, não é possível tratar todos os riscos com a 
mesma prioridade. 
• Definidos os riscos, surge a necessidade de priorização, pois a escolha dos riscos que serão 
tratados poderá impactar o orçamento final do projeto. 
• A análise qualitativa permite a priorização dos riscos. 
• A análise qualitativa dos riscos visa priorizar os riscos de um projeto, considerando: 
✓ A probabilidade de ocorrência. 
✓ O impacto desses riscos. 
• De acordo com a probabilidade de ocorrência e o impacto dos riscos é possível determinar 
o potencial de cada risco em influenciar os resultados do projeto. 
• A probabilidade determina a dimensão da incerteza e o impacto, sobre os objetivos do 
projeto. 
Exemplo 1: Analise qualitativa dos riscos em viagens: 
 
 
 
De acordo com a tabela, o evento mais crítico está relacionado com a saúde, seguido da, quantidade de dólar 
e com a passagem. 
 
Exemplo 2: A Força Aérea Americana determina em seus projetos de software os seguintes componentes de 
risco: desempenho, custo, suporte e cronograma. As categorias de impacto incluem: catastrófico,crítico, 
marginal e negligenciável. 
APLICAÇÃO 
Evento Probabilidade Impacto Probabilidade x Impacto 
1) Ocorrência de um problema de saúde, por causa de um 
acidente ou ter contraído alguma doença 
0,75 5 3,75 
1) Cancelamento da passagem pela companhia aérea 0,50 3 1,5 
3) A quantidade de dólar adquirida não ser suficiente 0,50 4 2,0 
GRAU DE IMPACTO PESO 
Muito grande 5 
Grande 4 
Moderado 3 
Pequeno 2 
Muito pequeno 1 
PROBABILIDADES 
Grande chance de ocorrer 0,95 
Provavelmente ocorrerá 0,75 
Igual chance de ocorrer ou não 0,50 
Baixa chance de ocorrer 0,25 
Pouca chance de ocorrer 0,10 
• Expertise Necessária: Especialistas em gerenciamento de risco são necessários para 
determinar os valores de probabilidade e impacto, principalmente devido a experiencias em 
projetos passados. 
• Papel do Gerente de Projetos: É um integrador de conhecimentos, e não precisa ter 
expertise em todas as áreas, mas deve entender os processos aplicados em diferentes áreas 
de conhecimento. 
 
ANÁLISE QUANTITATIVA DOS RISCOS 
• Definição: Processo que quantifica numericamente os efeitos dos riscos priorizados na Análise 
Qualitativa. 
• Objetivo: Determinar o impacto potencial e substancial dos riscos nos resultados do projeto. 
• Técnicas Aplicadas na análise quantitativa dos riscos : 
✓ Simulações: Método para prever o comportamento do sistema sob diferentes condições de risco. 
✓ Árvore de Decisão: Ferramenta utilizada para avaliar diferentes opções e suas consequências. 
Exemplo de Aplicação de técnicas na análise quantitativa dos riscos na Engenharia de Software: 
✓ Podemos aplicar a árvore de decisão, a fim de avaliar: 
o A contratação de uma fábrica de software para desenvolvimento de um determinado software. 
o Ou realizar o desenvolvimento na empresa. 
Exemplo 1: Analise quantitativa dos riscos em viagens: 
PRIORIDADE EVENTO CUSTO (R$) 
1 Ocorrência de um problema de saúde, por causa de um acidente ou ter contraído alguma doença 10.000,00 
2 A quantidade de dólar adquirida não ser suficiente 1.000,00 
3 Cancelamento da passagem pela companhia aérea 3.000,00 
 
PLANEJAMENTO DE RESPOSTAS AOS RISCOS 
• Definição: Processo de planejar ações para aumentar oportunidades e reduzir ameaças aos 
objetivos do projeto. 
• Objetivo: Gerenciar riscos conforme sua prioridade para melhorar o resultado do projeto. 
• Ações Planejadas visam: 
✓ Aumento das Oportunidades: Implementar ações para aproveitar os riscos positivos. 
✓ Redução das Ameaças: Implementar ações para minimizar os riscos negativos. 
 
• Entre os Tipos de Respostas aos Riscos, temos: 
✓ Mitigação: Reduzir o impacto negativo do risco no projeto. 
✓ Eliminação: Remover completamente o impacto do risco no projeto. 
• O planejamento é colocado em execução por meio do processo Implementar Respostas aos 
Riscos e pelo Monitoramento de Riscos. 
Exemplo 1: Resposta aos riscos em viagens: 
PRIORIDADE EVENTO TRATAMENTO RESPOSTA 
1 Ocorrência de um problema de saúde, por causa de 
um acidente ou ter contraído alguma doença 
Eliminação Contratar o seguro viagem 
2 A quantidade de dólar adquirida não ser suficiente Eliminação Atualizar o cartão de crédito para uso 
internacional 
3 Cancelamento da passagem pela companhia aérea Mitigação Confirmar a reserva em companhia 
aérea com boas alternativas de voos 
 
• Relevância para Projetos de Software: Projetos de software, devido à natureza dinâmica e à 
evolução rápida das tecnologias e requisitos, requerem práticas robustas de gerenciamento de 
riscos para garantir o sucesso do projeto. 
 
 TEMA 3: FASES DO DESENVOLVIMENTO DE SOFTWARE 
Módulo 1. Descrever as atividades da engenharia de requisitos 
• A complexidade do software reflete diretamente na composição da equipe (multidisciplinar). 
• O trato dessa complexidade requer a aplicação da Engenharia de Software. 
• A Engenharia de Software tem como base a camada de processos. 
• Podemos afirmar que não existe engenharia sem processo. 
• Portanto é importante compreender as principais atividades desenvolvidas nas etapas de um 
Processo de Desenvolvimento de Software (PDS). 
 
ENGENHARIA DE SOFTWARE 
• A Engenharia de Software, que tem como principal produto o software. 
• Podemos destacar uma característica comum no processo de desenvolvimento de software: 
a complexidade. 
• A melhor forma de tratar a complexidade é a aplicação de uma metodologia que permita 
a decomposição do problema em problemas menores. 
• A decomposição sistemática um problema complexo em partes menores e mais manejáveis, 
cabe à Engenharia de Software. 
• Entretanto, o software possui alta volatilidade, em função das constantes evoluções na 
tecnologia e nos requisitos, o que agrega uma complexidade adicional. 
• A Engenharia de Software é uma tecnologia em camadas: 
CAMADA DESCRIÇÃO 
Camada da qualidade Garante que os requisitos atendam às expectativas dos usuários. 
Camada de processo Define as etapas de desenvolvimento do software. 
Camada de métodos Determina as técnicas e os artefatos de software. 
Camada de ferramentas Estimula a utilização de ferramentas CASE. 
• Destaca-se que a base da Engenharia de Software é a camada de processo, que trata das 
etapas de desenvolvimento. 
 
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
Importância da Abstração: A abstração é intensamente aplicada no desenvolvimento de software 
para gerenciar a complexidade do sistema. 
Processo de Desenvolvimento: 
• Início com Alto Nível de Abstração: O desenvolvimento começa com especificações e 
modelos de alto nível, que fornecem uma visão geral e abrangente do sistema. 
• Redução Gradual da Abstração: À medida que o projeto avança, o nível de abstração 
diminui, levando a especificações mais detalhadas. 
Transição para a Codificação: 
• Menor Nível de Abstração: A codificação representa o nível mais baixo de abstração, onde 
os detalhes específicos são implementados. 
• Detalhamento Máximo: O código é a representação mais detalhada das especificações do 
software. 
Gerenciamento da Complexidade: 
• Uso de Modelos e Especificações: Utilizados para simplificar e comunicar conceitos 
complexos de forma acessível e compreensível. 
• Foco em Diferentes Aspectos: Em cada estágio, a abstração permite focar em diferentes 
aspectos do sistema sem sobrecarregar com detalhes desnecessários. 
 
• Os diferentes modelos de processos de desenvolvimento de software possuem as seguintes 
atividades típicas: 
✓ Levantamento de requisitos 
✓ Análise 
✓ Projeto 
✓ Implementação 
✓ Testes 
✓ Implantação 
ENGENHARIA DE REQUISITOS 
• As etapas de levantamento de requisitos e análise fazem parte da Engenharia de 
Requisitos, inserida no contexto da Engenharia de Software. 
 
Conceito de requisito: 
• Os requisitos de um sistema são descrições dos serviços que o sistema fornece. 
• Incluem as restrições operacionais do sistema. 
• Os requisitos refletem as necessidades dos clientes. 
• Objetivo é ajudar a resolver algum problema enfrentado pelos clientes. 
 
• A Engenharia de Requisitos envolve as seguintes atividades de Descobrir (Identificar os serviços e 
restrições operacionais do sistema), Analisar (Examinar e entender as necessidades e limitações dos requisitos), 
Documentar (Registrar de forma clara e detalhada os requisitos identificados), Verificar (Confirmar que os requisitos 
estão corretos e completos) os serviços fornecidos pelo sistema e suas restrições operacionais. 
• A Engenharia de Requisitos possui um processo próprio dentro da Engenharia de Software. 
• Destaca-se a existência de outras propostas de processos: 
✓ Concepção (Compreensão do domínio do problema). 
✓ Levantamento (Permite definir o escopo do projeto). 
✓ Elaboração (Construção de modelos). 
✓ Negociação (Acordo sobre os requisitos com as partes interessadas). 
✓ Especificação (Documentação formal das especificações dos 
requisitos). 
✓ Validação (Verificação da conformidade dos requisitos comas 
necessidades dos usuários). 
✓ Gestão (Permite controlar as alterações dos requisitos da evolução do 
projeto). 
 
❖ CONCEPÇÃO: 
• Nesta etapa, é estabelecido o entendimento inicial do problema. 
• É identificado partes interessadas atendidas pelo software. 
• É definido a natureza da solução desejada. 
• É promovida uma eficiente comunicação e colaboração entre clientes, usuários e equipe de 
projeto. 
• Destaca-se que durante o desenvolvimento de um software há diferentes tipos de usuários 
com necessidades variadas (e.x., diferentes níveis gerenciais de uma empresa). 
❖ LEVANTAMENTO: 
• Permite definir o escopo do projeto, ou “tamanho do problema”. 
• Possibilita que usuários e desenvolvedores tenham a mesma visão do problema a ser 
resolvido. 
• Nesta etapa, é gerada uma especificação de requisitos que serve como um contrato entre 
clientes e equipe de projeto, esclarecendo aos clientes o que será entregue como produto. 
• Técnicas de Elaboração de Requisitos: 
✓ Observação (Etnografia): Permite ao engenheiro de software emergir no ambiente de trabalho onde a 
solução será usada, observando o trabalho rotineiro e tomando notas das tarefas em execução nas quais 
as partes interessadas estão envolvidas. 
✓ Entrevista: É uma forma de diálogo, formal ou informal, onde o entrevistador busca respostas para um 
conjunto de questões previamente definidas e os entrevistados se apresentam como fontes de informação. 
✓ Pesquisa: Consiste na aplicação de um questionário às partes interessadas e posterior análise das 
respostas. Essa técnica permite a rápida obtenção de informações quantitativas e qualitativas de um 
público-alvo numeroso, particularmente quando não estão em um único local físico. 
✓ Joint Application Design (JAD): É um método de projeto interativo que substitui as entrevistas individuais 
por reuniões de grupo, onde participam representantes dos usuários e dos desenvolvedores. 
✓ Brainstorming: São reuniões na qual participam todos os envolvidos na idealização do produto, como os 
engenheiros de software, clientes e usuários finais. Todos os envolvidos devem expor suas ideias e 
necessidades em relação ao produto. 
• Na etapa de levantamento, temos a entrega do documento de requisitos, 
• Objetivo do documento de requisitos: 
✓ Documentar fiel e completamente as necessidades dos clientes. 
✓ Obter aceitação sobre a proposta de entrega do produto. 
• O documento de requisitos permite: 
✓ Garantir a rastreabilidade dos requisitos. 
✓ Assegurar que as especificações até a codificação estejam alinhadas com a documentação inicial. 
❖ ELABORAÇÃO: 
• Nesta etapa, os engenheiros de software realizam um estudo detalhado dos requisitos 
levantados 
• A partir desse estudo detalhado dos requisitos, são construídos modelos para representar o 
sistema a ser construído. 
• Na etapa de elaboração, a modelagem é orientada pela criação e refinamento de cenários 
identificados a partir dos requisitos funcionais, descrevendo como os usuários interagem com 
o sistema. 
• A modelagem de casos de uso da UML representa esses cenários por meio de diagramas de 
casos de uso (artefatos gráficos) e descrições de casos de uso (artefatos textuais). 
• A partir dos casos de uso, podemos identificar as classes de análise que representam os 
objetos do negócio ou do domínio do problema. 
• Na modelagem de análise, podemos considerar a construção do modelo de atividades e do 
modelo de estados. 
• O modelo de atividades possui diagramas que podem ser utilizados no mapeamento de 
processos de negócios, na descrição gráfica de um caso de uso ou na definição do algoritmo 
de um método. 
• O modelo de estados permite representar mudanças de estados significativas e respectivos 
eventos que causam a mudança de estado. 
❖ NEGOCIAÇÃO: 
• Nesta etapa, ocorre a priorização e a resolução de conflitos entre os requisitos definidos 
nas etapas anteriores. 
• Tanto a equipe de projeto quanto os usuários participam da avaliação de custos, riscos e 
conflitos. 
• O objetivo é eliminar, combinar ou modificar requisitos e priorizá-los de acordo com as 
necessidades e restrições. 
❖ ESPECIFICAÇÃO: 
• O engenheiro de software deverá gerar um documento de especificação incluindo todos os 
requisitos e modelos gerados nas etapas anteriores. 
❖ VALIDAÇÃO: 
• Na validação, o engenheiro de software verifica se os modelos criados refletem as 
necessidades dos usuários em relação ao sistema a ser desenvolvido. 
• A validação é crucial para evitar que defeitos não detectados levem à construção de um 
sistema que não atenda às expectativas do usuário. 
❖ GESTÃO: 
• A etapa de gestão permite controlar as mudanças dos requisitos à medida que o projeto 
evolui. 
 
• Gerenciamento do escopo: O engenheiro de software deve gerenciar o escopo do projeto, 
a partir de uma matriz de rastreabilidade de requisitos. 
• Matriz de rastreabilidade de requisitos: É uma tabela que liga os requisitos dos produtos 
desde suas origens até a entrega. 
• Importância da matriz de rastreabilidade: Essa matriz possibilita monitorar a estabilidade 
dos requisitos ao longo do tempo, garantindo que as entregas do projeto atendam às 
necessidades iniciais dos clientes. 
• Importância da rastreabilidade: A rastreabilidade permite gerenciar mudanças dos 
requisitos durante o processo de desenvolvimento de software. 
 
Módulo 2. Reconhecer as atividades do projeto de software 
PROJETO DE SOFTWARE 
• Os principais modelos da etapa de análise do processo de desenvolvimento de software: 
✓ Modelo de casos de uso 
✓ Modelo de classes de análise 
✓ Modelo de atividades 
✓ Modelo de estados. 
• O conceito de abstração é fundamental no processo de desenvolvimento de software, pois 
ele é iniciado com especificações e modelos com alto nível de abstração. 
• A etapa projeto de software diminui o nível de abstração dos diagramas de análise por meio 
de refinamentos sucessivos, como também exige a criação de novos modelos. 
• As principais atividades realizadas na fase de projeto são: 
✓ Refinamento dos aspectos 
estáticos e estruturais do sistema 
✓ Detalhamento dos aspectos 
dinâmicos do sistema 
✓ Detalhamento da arquitetura do 
sistema 
✓ Mapeamento objeto-relacional 
 
REFINAMENTO DOS ASPECTOS ESTÁTICOS E ESTRUTURAIS DO SISTEMA 
 
• O modelo de classes representa os aspectos 
estáticos e estruturais do sistema. 
• A partir do modelo de classes, são inseridos 
novos elementos que permitirão a 
implementação das classes. 
• Esses refinamentos possibilitam reduzir o grau 
de abstração, tornando a especificação da classe 
pronta para a codificação. 
Figura - Exemplo de refinamentos em uma classe. 
Exemplo: Vamos analisar os refinamentos: 
1. Indica uma classe e o respectivo nome. 
2. Inclui os atributos. 
3. Adiciona os métodos ou funções das classes 
4. Detalha os atributos e métodos. 
 
• No projeto é fundamental definir os tipos de dados, pois essa especificação garante a 
implementação, ou seja, a codificação da classe. 
• Na análise, não é importante definirmos os tipos de dados. 
• Novos elementos podem ser adicionados devido a associações entre classes, heranças ou 
criação de novas classes. 
• Padrões de projeto (design patterns), como o Factory Method, podem ser aplicados no 
modelo de classes para resolver problemas comuns de forma mais eficiente. 
 
DETALHAMENTO DOS ASPECTOS DINÂMICOS DO SISTEMA 
Aspectos da Orientação a Objetos: 
• Definição de orientação a objetos: É a representação do mundo real por meio de objetos 
que se comunicam através de mensagens. 
• A comunicação entre objetos reflete a dinâmica do sistema. 
• Para representar a comunicação temos o modelo de interação, que inclui os diagramas de: 
✓ Diagrama de comunicação 
✓ Diagrama de sequência 
• Ambos os diagramas representam a dinâmica das interações entre objetos de maneira 
abstrata e complementar. 
Relação entre Modelo deClasses e Modelo de Interação: 
• O modelo de interação é desenvolvido simultaneamente ao modelo de classes de projeto. 
• Os métodos implementados nas classes são identificados a partir das mensagens definidas 
no modelo de interação. 
 
DETALHAMENTO DA ARQUITETURA DO SISTEMA 
• Uma atividade muito aplicada na Engenharia de Software é a fatoração. 
• Fatoração: A fatoração é a decomposição da solução de um problema em partes menores, 
facilitando o tratamento da complexidade. 
• Projeto de Arquitetura: O projeto de arquitetura identifica os subsistemas do sistema de 
software e estabelece um framework para controle e comunicação entre eles. 
• A arquitetura é definida por duas abstrações: 
✓ Lógica 
✓ Física. 
• Exemplo: A figura ao lado ilustra uma divisão lógica em camadas: apresentação, aplicação, 
domínio e serviços técnicos. 
• As camadas superiores são dependentes das inferiores. 
• Essa fatoração permite melhor trato da complexidade, ou seja, decomposição do sistema 
em partes menores. 
• Outra vantagem é o reúso, pois as camadas inferiores são independentes das camadas 
superiores. 
• A arquitetura em camadas permite baixo acoplamento (mínimo de dependências entre os 
subsistemas) e alta coesão (deve haver mais associações entre as classes internamente do 
que externamente). 
• Componentes das Camadas: 
✓ Camada de Apresentação: inclui classes de fronteira para interação com usuários. 
✓ Camada de Aplicação: inclui classes de controle que atuam como intermediários da camada de apresentação 
e domínio. 
✓ Camada de Domínio: composta por classes de domínio, que permitem a instanciação dos objetos do domínio 
do problema, esses objetos podem conter métodos que alteram o próprio estado 
✓ Camada de Serviços Técnicos: Inclui serviços genéricos, como persistência de dados. 
 
Padrões aplicados à Arquitetura: 
• Temos também padrões aplicados à arquitetura, como 
por exemplo o padrão MVC (Model-View-Controller). 
• O padrão MVC é focado no reúso de código e na 
separação de conceitos em três camadas 
interconectadas. 
✓ Controlador (controller): Responsável por atualizar o estado do modelo (ex.:uma nota fiscal, ou 
alterar a apresentação da visão do modelo). 
✓ Modelo (model): Mantém os dados, notificando visões e controladores quando ocorre uma 
mudança em seu estado. 
✓ Visão (view): Permite a exibição dos dados. 
 
• Arquitetura Física: Após a definição lógica, define-se a arquitetura física através do modelo 
de implantação. 
• Modelo de Implantação: Projeta a 
infraestrutura de hardware 
necessária. 
• O projeto deve definir os nós 
computacionais necessários para a 
implantação do software, mas a 
especificação detalhada do hardware fica a cargo da equipe de infraestrutura. 
• A forma de representar a componentização do software é definida no modelo de 
implementação. 
• O modelo de implementação, mostra como os componentes são alocados nos nós 
computacionais. 
 
MAPEAMENTO OBJETO-RELACIONAL 
Padrão da indústria de software: 
• Atualmente, o padrão da indústria de software, é o paradigma orientado a objetos. 
• Dessa forma, os objetos podem ter estruturas de dados complexas. 
• Essa complexidade gera a necessidade de persistência. 
Padrão das tecnologias de banco de dados: 
• É predominantemente, é o modelo relacional. 
• O modelo relacional possui uma estrutura de armazenamento bidimensional (tabela). 
Como integrar o padrão de software orientado a objetos com o padrão das tecnologias de 
bancos de dados relacionais? 
• Para integrar os dois padrões utiliza-se: 
✓ Utiliza-se o diagrama de classes como modelo conceitual do banco de dados. 
✓ Gerar o modelo lógico de banco de dados a partir do modelo conceitual. 
✓ São criadas as tabelas necessárias às persistências exigidas pelos objetos. 
• Este processo é conhecido como mapeamento objeto-relacional (ORM), que permite a 
integração entre a orientação a objetos e os bancos de dados relacionais. 
 
 
Realização do projeto da interface gráfica com o usuário: 
• O diagrama de casos de uso define as funcionalidades do sistema. 
• Cada caso de uso representa uma interação completa entre o sistema e um agente externo 
denominado ator. 
• Nessa interação, é definida uma interface como meio de comunicação homem-máquina. 
• Nesse ponto, o requisito-chave não funcional é usabilidade, portanto é fundamental a 
participação do usuário no processo de definição das interfaces. 
• Possíveis questões relativas à interface que podem surgir: 
✓ Tempo de resposta (ex.: Em sistemas de venda online, um alto tempo de resposta pode levar à desistência 
e migração para concorrentes.) 
✓ Recursos de ajuda: Disponíveis sem necessidade de abandonar a interface. 
✓ Tratamento de erros: Utilização de linguagem inteligível para o usuário. 
✓ Acessibilidade da aplicação: Foco em atender usuários com necessidades especiais. 
 
Módulo 3. Reconhecer as etapas de implementação e testes 
IMPLEMENTAÇÃO 
• Quais as entregas da Etapa de Projeto? São os modelos, ou seja diagramas e especificações 
textuais que permitem a implementação, ou codificação do software. 
• Etapa de Implementação: A etapa de implementação permite realizar a tradução dos modelos 
de projeto em código executável por meio do uso de uma ou mais linguagens de programação 
• Como não conhecemos todos os detalhes dos algoritmos necessários para resolver o problema; 
para solucioná-lo, entram em cena os programadores. 
• Na etapa de implantação destaca-se os requisitos não funcionais, tais como: 
✓ Linguagens de programação. 
✓ Frameworks para mapeamento objeto-relacional (ex: Hibernate escrito em Java). 
✓ Sistemas de gerenciamento de banco de dados. 
✓ Requisitos de qualidade, confiabilidade e usabilidade. 
✓ Reutilização de componentes e outros. 
• Crise do Software: 
✓ A causa principal da crise é o aumento significativo da potência das máquinas. 
✓ Programação era um problema menor com computadores fracos, mas se tornou gigantesco com 
computadores potentes. 
• Desenvolvimento Tecnológico e Paradigmas: 
✓ Avanços no hardware permitiram o desenvolvimento de softwares mais complexos. 
✓ Esses avanços permitiram a mudança do paradigma estruturado para o paradigma orientado 
a objetos. 
✓ A programação orientada a objetos facilita reúso intensivo de especificações, melhora 
manutenção e consequentemente resulta no desenvolvimento de softwares mais 
complexos e de maior qualidade. 
 
QUALIDADE DE SOFTWARE 
• Impacto negativo da complexidade: 
✓ A complexidade exerce um efeito negativo pois está associada ao tamanho das 
especificações. 
✓ A complexidade é maior em programas de computador devido às interações entre diversos 
componentes do sistema. 
✓ Outro quesito que deve ser abordado, além dos problemas de software e sua complexidade, 
é a questão da qualidade. 
• Qualidade de Software: Qualidade é estar em conformidade com os requisitos. 
• Objetivo da qualidade: É satisfazer o cliente, por meio da aplicação da Engenharia de Software. 
• A norma ISO 9126, identifica seis atributos fundamentais de qualidade para o software: 
1. Funcionalidade: Satisfação dos requisitos funcionais. 
2. Confiabilidade: Tempo de Disponibilidade do software. 
3. Usabilidade: Facilidade de uso. 
4. Eficiência: Otimização dos recursos do sistema. 
5. Facilidade de manutenção: Realização de correção no software. 
6. Portabilidade: Adequação a diferentes ambientes. 
• A qualidade possui duas dimensões fundamentais aplicáveis ao software: 
✓ Dimensão da qualidade do processo 
✓ Dimensão da qualidade do produto (são testes que garantem a qualidade do produto 
software). 
 
TESTE DE SOFTWARE 
• A qualidade do software é garantida pela aplicação de testes sistemáticos em múltiplos 
estágios do desenvolvimento. 
• Os testes de software permitem: 
✓ Validação da estrutura interna do software. 
✓ Garantir sua conformidade com os requisitos. 
✓ Avaliam a integração dos subsistemas(especialmente as interfaces de comunicação entre 
componentes). 
• Definição de Teste: É o processo sistemático e planejado que tem a finalidade de identificar 
erros no software. 
• Em softwares complexos, o teste revela a presença de erros, mas não pode garantir a ausência 
completa deles. 
• Impacto de Softwares Mal Testados: Softwares mal testados podem gerar prejuízos às 
empresas. 
✓ Decisões gerenciais são afetadas pela qualidade das informações fornecidas pelo software. 
✓ Defeitos podem causar prejuízos, como compras inadequadas e resultados financeiros incorretos. 
• Testes de Software (também conhecido como teste dinâmico): São procedimentos de testes 
aplicados diretamente em softwares. 
✓ A maioria destes testes sofrem alto nível de automação. 
✓ A automação permite a criação de ambientes complexos de testes, simulando diversos cenários de 
uso. 
• Importância da Simulação de Cenários: 
✓ Quanto mais cenários são simulados, maior é o nível de validação do produto. 
✓ Isso caracteriza um maior nível de qualidade do software desenvolvido. 
• Objetivos dos Testes de Software: Avaliar a qualidade do produto em diversas dimensões: 
✓ Estrutura interna do software. 
✓ Aderência às regras de negócios estabelecidas. 
✓ Parâmetros de performance esperados. 
Exemplo de estratégia de Testes: 
• A estratégia é representada como uma espiral percorrida 
do interior para o exterior, aumentando o nível de 
abstração a cada volta 
• Existem quatro estratégias de testes disponíveis: 
1. Teste de unidade 
2. Teste de integração 
3. Teste de validação 
4. Teste de sistema 
• Cada etapa dessa estratégia é descrita para guiar o 
desenvolvimento do software de forma progressiva e estruturada. 
 
❖ TESTE DE UNIDADE: 
• Primeira etapa da estratégia de testes. 
• Objetivo do teste unitário: validar componentes individuais do software. 
• Nesta estratégia é testado toda a estrutura interna de um componente, como desvios 
condicionais e laços de processamento. 
❖ TESTE DE INTEGRAÇÃO: 
• Objetivo do teste de integração: manter a compatibilidade das novas unidades desenvolvidas 
com os componentes previamente existentes. 
• Alterações ou exclusões de rotinas ou propriedades públicas podem quebrar a 
compatibilidade de um componente. 
• Quando a compatibilidade é quebrada, são gerados erros durante a execução do software. 
• Isso porque todos os outros componentes que empregam essas rotinas ou propriedades estão 
automaticamente incompatíveis com o componente modificado. 
• São exatamente esses erros que devem ser identificados nesse estágio dos testes de software. 
❖ TESTE DE VALIDAÇÃO: 
• É a etapa final dos testes. 
• Nesse estágio, a maior parte das falhas de funcionalidade deve ter sido detectada nos testes 
unitários e nos testes de integração 
• Objetivo do teste de validação: validar a solução como um todo. 
• Os testes de validação utilizam uma infraestrutura complexa de hardware, como o objetivo de 
simular o ambiente real de produção. 
• Tipos de Testes Realizados: 
✓ Testes Funcionais: visam verificar se o sistema executa processos ou casos de uso completos 
conforme esperado pelo usuário. 
✓ Testes Não Funcionais: visam avaliar as características não funcionais como desempenho, segurança, 
confidencialidade e recuperação a falhas. 
• Planejamento de Testes: 
✓ O planejamento de testes deve ser baseado nos cenários descritos nos casos de uso durante 
a análise do processo de software. 
✓ Os cenários são inicialmente definidos com alto nível de abstração pelo engenheiro de 
software. 
✓ Analista de teste detalha esses cenários em casos de testes específicos. 
• Exemplos de Cenários e Casos de Teste: 
✓ Exemplo: Caso de uso "Realizar saque de conta" pode incluir cenários como saldo suficiente, 
saldo insuficiente, saque com juros, entre outros. 
✓ Detalhamento dos casos de teste permite identificar falhas e comportamentos alternativos 
do software. 
• Procedimentos de Aceite: 
✓ São realizados a cada ciclo de implementação para detectar falhas antecipadamente. 
✓ É considerada a última oportunidade efetiva para detectar falhas antes da implantação. 
✓ O aceite é uma estratégia para reduzir riscos durante a fase de implantação. 
✓ Os procedimentos de aceite são divididos em: Teste Alpha, Teste Beta e Aceite Formal. 
 
 
• Tipos de Aceite: 
✓ Aceite Teste Alpha: Usuários finais testam o software em um ambiente controlado, dentro da 
instalação do desenvolvedor. 
✓ Aceite Teste Beta: Usuários finais testam o produto em suas próprias instalações, ambiente não 
controlado pelo desenvolvedor. 
✓ Aceite Formal: É uma variação do Teste Beta, onde os clientes e usuários determinam o que testar 
e validam se os requisitos foram implementados corretamente. 
• Sucesso da validação: é determinado quando o software atende aos requisitos e funciona 
conforme esperado pelo usuário. 
 
TESTE DE SISTEMA 
• É a última etapa na espiral. 
• O teste de sistema extrapola os limites da engenharia de software ao considerar o contexto mais 
amplo da engenharia de sistemas de computadores. 
• Assim, a validação do software ocorre dentro do contexto do sistema completo. 
• Após ser validado, o software é combinado com outros elementos do sistema, tais como 
hardware, base de dados etc. 
• Testes de sistema que podem ser realizados: 
1. Teste de Recuperação: 
• Objetivo: Avaliar o comportamento do software após erros ou condições anormais. 
• O teste de recuperação inclui procedimentos para restaurar o estado inicial da transação interrompida, 
impedindo que determinados processamentos sejam realizados pela metade e sejam futuramente 
interpretados como completos. 
• Exemplos: Simular saque com defeito no caixa eletrônico (não concluído), simular saque com queda de 
energia. 
2. Teste de Segurança: 
• Objetivo: Detectar falhas que comprometam sigilo e fidelidade das informações. 
• Avalia a segurança da infraestrutura diante de ataques internos e externos. 
• Simula situações que provocam a quebra de protocolos de segurança. 
• Exemplos: Verificar requisitos de senha antes e depois de transações, validar senhas adicionais. 
3. Teste por Esforço: 
• Objetivo: Simular condições atípicas de uso, aumentando e reduzindo drasticamente o volume de 
transações. 
• Testa como o software e a infraestrutura lidam com picos de demanda. 
• Exemplo: Simular 10.000 saques simultâneos. 
4. Teste de Desempenho: 
• Objetivo: Verificar se o desempenho do software atende aos requisitos durante situações de pico 
máximo de acesso e concorrência. 
• Define tempos de resposta aceitáveis para cada cenário. 
• Exemplo: Garantir que operações físicas de saque não ultrapassem 10 segundos. 
5. Teste de Disponibilização: 
• Também chamado de teste de configuração. 
• Objetivo: Executar o software em diversas configurações de software e hardware. 
• Garante que o software funcione corretamente em diferentes ambientes de produção. 
• Também examina todos os procedimentos de instalação e instaladores a serem utilizados pelos clientes, 
bem como a documentação que será utilizada pelos usuários finais. 
• Exemplo: Simular saque com impressoras de diferentes fornecedores. 
 
Módulo 4. Descrever as etapas de implantação em manutenção 
IMPLANTAÇÃO 
• Definição: Implantação é a etapa relacionada com a transferência do sistema da equipe de 
desenvolvimento para os usuários finais, ou seja, o sistema entra em produção no ambiente real. 
• Objetivo: Produzir com sucesso a entrega do software para os usuários finais. 
• A implantação desenvolve diversas atividades tais como: 
1. Produção de Releases Externos: 
o Inclui o lançamento de novas versões ou atualizações do software. 
o São exigidas decisões sobre distribuição do produto pelos desenvolvedores e usuários. 
2. Embalagem do Software: 
o Quando o software será comercializado por meio de determinada mídia como DVD. 
3. Distribuição do Software: 
o É a entrega do