ARA0097 – ENGENHARIA DE SOFTWARE

Prof. Ms. Pedro Gabriel Calíope Dantas Pinheiro

1. Fundamentos de Software e Gerenciamento de Projetos.

Situação-problema: Imagine que você tem um terreno e deseja construir uma casa. Qual o primeiro

passo? Você iniciará pelas paredes, pela fundação ou pelo projeto? E quando você tem um problema e deseja
construir um software para solucioná-lo, por onde você deve começar?

Engenharia de Software:
Há 20 anos, menos de 1% do público poderia descrever de forma inteligível o que significa "software
de computador". Hoje, a maioria dos profissionais bem como a maior parte do público, acham que
entendem o que é software. Será que entendem?

• É uma derivação da Engenharia de Sistemas e de Hardware.

• Compreende um conjunto de etapas (Paradigmas da Engenharia de Software) que envolve
métodos, ferramentas e os procedimentos.
• É um elemento de sistema lógico, e não físico.
• Possui características que difere do hardware.
• Pode ser aplicado a qualquer situação, em que um conjunto de passos procedimentais (um
algoritmo) tiver sido previamente especificado.
Exemplo:
✓ Não se desgasta.
✓ É feito sob medida em vez de ser montada a partir de componentes existentes.

Aplicações do Software:
• Software de Sistema: Finalidade de atender às necessidades de outros programas;
• Software de Aplicação: Finalidade de solucionar necessidades específicas de negócio;
• Software Científico/Engenharia: Finalidade em diversas áreas de pesquisa e simulações;
• Software Embutido: Residem em um produto ou sistema com finalidade de controlar as
atividades de equipamentos como por exemplo um ar-condicionado digital.
 • Software Generalistas/Prateleira: Finalidade de suprir as necessidades de diversos clientes,
por exemplo, na criação de planilhas eletrônicas, editores de textos, entre outros para linhas
de produtos;
• Aplicações para a web (WebApps): Executados em um servidor conectado à rede e que pode
ser acessado e utilizado por diferentes usuários, desde que possuam acesso;
• Software de Inteligência Artificial: Utilizados na resolução de problemas complexos, com
aplicações em redes neurais artificiais, robótica, jogos, entre outras.

Problemas do Software:
A “Crise do Software” é o conjunto de problemas associados ao software que atingem seu
desenvolvimento, alguns desse problemas podem ser descritos como:
1. Estimativas de Prazos e Custos que são frequentemente imprecisos;
2. Produtividade dos profissionais;
3. A qualidade do software;

Importância do Software:
1. Avanços da Microeletrônica
2. Integração de informações
3. Praticidade e agilidade
4. Mensuração de resultados descomplicada

O Processo de Software:
É o conjunto de atividades executadas com o objetivo de criar um produto (software). Pressman
(2011) define cinco atividades para o processo de software são elas:

✓ Comunicação: Visa a compreensão dos objetivos dos interessados, definindo os requisitos

para o desenvolvimento do produto;
o Levantamento de Requisitos: Levantar conhecimento sobre o negócio do cliente,
identificando suas necessidades;
o Análise: Detalhamento dos requisitos e definição lógica dos procedimentos;
✓ Planejamento: Tem como objetivo a criação de um mapa (também conhecido como plano de
projeto de software) que contém a descrição das tarefas, possíveis riscos, cronograma de
execução, os recursos demandados e o resultado esperado;
o Gerência de Projeto: Planejamento das funções a serem executadas;
 ✓ Modelagem: Criação de modelos (esboços) para representar o produto que deseja
desenvolver, fazendo assim com que as necessidades do projeto possam ser definidas antes
do início do desenvolvimento, reduzindo assim os custos de mudanças.
o Projeto: Definição física dos procedimentos, recursos tecnológicos necessários;

✓ Construção: Desenvolvimento e Testes do Software;

o Implementação: Construção do sistema (códigos);
o Teste: Validação do sistema, verificando se os requisitos levantados foram
devidamente desenvolvidos, se atendem às expectativas do cliente e se o sistema
funciona sem erros;

✓ Emprego: Entrega do produto ao cliente, de maneira Integral ou Parcial.

o Implantação: Disponibilizar o produto ao cliente (usuário), inclusive treinamentos e
carga de dados;
o Manutenção: Efetuar os ajustes necessários em caso de erros no programa, no
levantamento de requisitos ou no desenvolvimento de novas funcionalidades,
conforme necessidade do cliente;
o Qualidade: efetuar medidas para a verificação e busca pela excelência do sistema.

Os modelos de processos, também conhecidos como ciclos de vida de software mais utilizados são:
✓ O modelo cascata: Também conhecido como ciclo de vida clássico, possui suas atividades
sendo executadas de forma linear.
✓ O modelo evolucionário;
o Prototipagem: Utilizada como ferramenta para a descoberta de requisitos de forma
interativa, pondera-se a necessidade de reavaliação dos requisitos, fazendo assim com
que todas as etapas sejam revistas e ao final, um novo protótipo seja entregue ao
cliente.

o Espiral - BOEHM (1988): Seu ciclo não necessariamente termina quando o software é
entregue, ele pode ser adaptado para perdurar por toda a vida do software. A análise
de riscos é feita na etapa de planejamento e a cada volta em torno do eixo do espiral
pode ser utilizada para o desenvolvimento de um protótipo.
✓ O modelo incremental (Ciclo Interativo): Visa combinar as vantagens do modelo cascata com
as vantagens do modelo espiral. Os serviços a serem fornecidos pelo software a ser produzido
são devidamente identificados e desenvolvidos independentemente. Sendo assim, logo na
primeira entrega, o sistema já pode ser utilizado.
2. Gerenciamento de Projetos

Situação-problema: Você deseja aprender um novo idioma e de vez em quando assiste algumas aulas na
internet, ou faz algumas leituras esporádicas, isso pode ser considerado um projeto pessoal? Suponha agora
que você tenha planejado estudar duas horas por dia, três vezes na semana durante 18 meses, e após esse
período irá fazer uma viagem de 30 dias para exercitar a conversação. Isso pode ser considerado um projeto
pessoal?

Project Management Body of Knowledge (PMBOK):

O Guia PMBOK® é uma publicação do Project Management Institute (PMI) que traz um conjunto de
conhecimentos e boas práticas reconhecidas em gerenciamento de projetos.

Projeto:
✓ É um empreendimento único, com início e fim definidos, visando atingir metas e objetivos
pré-definidos e estabelecidos dentro de parâmetros de prazo, custo e qualidade (PMI 2008).
✓ Exige atividades de gerenciamento e conjuntos de habilidades.
✓ Realizados por pessoas, restringidos por recursos limitados, planejados, executados e
controlados.

Operações:
✓ São esforços contínuos que geram saídas repetitivas, com recursos designados para realizar
basicamente o mesmo conjunto de tarefas
✓ Exigem gerenciamento de processos de negócios.
✓ O gerenciamento de operações é responsável pela supervisão, orientação e controle das
operações de negócios.
✓ Realizados por pessoas, restringidos por recursos limitados, planejados, executados e
controlados.
Programa:
✓ É um grupo de projetos relacionados e gerenciados de modo coordenado para a obtenção de
benefícios e controle.
✓ Envolve empreendimento repetitivo ou cíclico e geralmente, maior tempo de duração.

Áreas de conhecimento do PMBOK®:

1. Gerenciamento de Integração: Significa unificação, consolidação e articulação das partes de

qualquer projeto. Requer escolhas sobre alocação de recursos, concessões entre objetivos e
alternativas conflitantes. É papel do gerente de projetos fazer com que os componentes do
projeto trabalhem juntos. habilidades gerenciamento, negociação, comunicação,
organização, familiaridade técnica com o produto etc.

2. Gerenciamento do Escopo: Através de processos o objetivo é definir e controlar o que faz

parte do projeto. O escopo/âmbito é o foco do projeto e difere-se do escopo do produto na
medida em que define o trabalho necessário para concluir o produto, e o escopo do produto
define os recursos (atributos e comportamentos).

3. Gerenciamento do Cronograma: Também chamado de gerenciamento de tempo em edições

anteriores, visa manter uma sequência de eventos precisa e atualizada, incluindo processos
necessários para estimar as tarefas, seus recursos e durações, de modo a gerenciar o projeto
para o término pontual.

4. Gerenciamento de Custos: Inclui processos envolvidos em estimativas, orçamentos e controle

dos custos, de modo que o projeto possa ser terminado dentro do orçamento aprovado. Os
processos incluem: Planejar o gerenciamento dos custos, estimar os custos, determinar o
orçamento, controlar os custos.
 5. Gerenciamento da Qualidade: Inclui processos e atividades da organização executora que
determinam as políticas de qualidade, objetivos, requisitos e responsabilidades de modo que
o projeto satisfaça às necessidades para as quais foi empreendido.

6. Gerenciamento de Recursos: Também chamada de recursos humanos em algumas edições,

inclui processos que organizam e gerenciam a equipe do projeto. Faz parte desta área do
conhecimento descrever as necessidades de pessoal e suas respectivas capacidades e
habilidades.

7. Gerenciamento de Comunicações: Inclui os processos necessários para assegurar que as

informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e
organizadas de maneira oportuna e apropriada.

8. Gerenciamento de Riscos: Inclui processos de planejamento, identificação, análise,

estabelecendo um plano de resposta para tratar problemas que possam surgir, bem como o
monitoramento e controle de riscos de um projeto.

9. Gerenciamento de Aquisições: Inclui processos necessários para comprar ou adquirir

produtos, serviços ou resultados externos ao projeto e abrange o gerenciamento de
contratos. A organização pode ser tanto compradora como vendedora dos produtos, serviços
ou resultados de um projeto. Na ótica do PMI®, abordamos o gerenciamento das aquisições
do ponto de vista do comprador.

10. Gestão de Partes Interessadas (Stakeholders): Inclui processos de identificação,

planejamento, engajamento e gerenciamento das partes interessadas. Para isso, São
utilizadas estratégias para identificar e gerenciar as expectativas dos stakeholders para
aumentar o suporte e comprometimento ao projeto.
*Stakeholders: Pessoa ou Grupo envolvidos com o sistema, direta ou indiretamente.

Gerência de Projetos:

É a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do

projeto para atender aos seus requisitos. Os grupos de processos de gerenciamento de
projetos são:

Monitoramento e
Iniciação Planejamento Execução Encerramento
Controle
Os itens que integram um gerenciamento de projetos são:

✓ Escopo, cronograma, orçamento, qualidade, recursos e riscos.

✓ Levantamento das necessidades e expectativas dos clientes e das partes
interessadas.
✓ Estabelecimento de objetivos claros e alcançáveis.
✓ Adaptação das especificações, dos planos e da abordagem às diferentes
preocupações e expectativas das diversas partes interessadas.
✓ Balanceamento das demandas conflitantes de escopo, cronograma,
orçamento, qualidade, recursos e riscos.

Problemas - Causas x Soluções:

Problemas
Atrasos no cronograma
Custos acima do previsto.
Falta de recursos de pessoal.
Mudanças de requisitos e especificações.
Qualidade abaixo da esperada.
Produtos que não funcionam
Complexidade acima da capacidade.
Produtos mal projetados.
Projetos que são cancelados.
Causas
Cronogramas apertados ou mal estruturados.
Estimativas de orçamento fracas ou abaixo do Análise do escopo, cronograma e recursos para a correta
real.
Desenvolvimento inadequado da equipe dos
projetos.
Falta de um comando claro para o projeto.
Sistema de controle mal planejado.
Objetivos mal planejados ou não compreendidos
Falta de capacitação da equipe do projeto.
Expectativas dos clientes sem monitoramento.
Falha no levantamento dos requisitos ou
recursos financeiros insuficientes
Soluções
Tempo estimado considerando os recursos disponíveis.
estimativa de custos.
Controle do pool de recursos alocados nos projetos em
andamento e previstos.
Implementação de processo de controle de mudanças.
Validação do produto pela equipe do projeto e aceite do
cliente.
Reuniões semanais com o cliente para validação prévia dos
produtos.
Capacitar a equipe do projeto ou contratar especialistas
Ênfase no planejamento do projeto em conjunto com o
cliente.
Ajustar o escopo do projeto para atender as necessidades
do cliente.
3. Engenharia de Requisitos e Análise de Sistema
Situação-problema: Quando um cliente deseja um software, como nós sabemos quanto tempo

demorará para ser desenvolvido? Como nós descrevemos para os programadores todas as características que
devem ser implementadas? De que forma são listadas todas as funcionalidades que o software deve possuir?

Requisitos:
Existem dois tipos principais de requisitos:
✓ Funcionais: São declarações de como o sistema deve reagir a entradas específicas e como se
comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente.
Também podem explicitar o que o sistema não deve fazer.
✓ Não-Funcionais:
➢ Organizacionais: Políticas e procedimentos nas organizações do cliente e do desenvolvedor.
➢ Externos: Fatores externos ao sistema e ao seu processo de desenvolvimento;
o Interoperabilidade com outros sistemas;
o Requisitos éticos ou legais;
➢ De produto: Comportamento do produto
o Eficiência: Desempenho, Espaço, Rapidez, Memória;
o Confiabilidade;
o Portabilidade.

Os requisitos ainda podem ser divididos em outras categorias:

✓ Inversos: Definem o que nunca deve ocorrer durante a execução do software;
✓ Estáveis: Não são alterados ou modificados com frequência, sua alteração é algo excepcional;
✓ Voláteis: Vivem em constante modificação, podem ser divididos em quatro categorias:
Compatíveis, Mutáveis, Emergentes e Consequentes.

Os requisitos ainda podem ser divididos em outra categoria, se vistos pelo aspecto da
implementação:
✓ Cliente ou Alto Nível: Expostos pelo cliente em linguagem natural, ou ainda em forma de
desenhos ou casos de uso, qualquer técnica que facilite o entendimento. Se caracterizam por
dizer apenas o que o usuário/cliente quer que o sistema faça, não há a preocupação de como
aquela funcionalidade será implementada;
✓ Sistema ou Baixo Nível: Relatam não só o que deve ser implementado, mas como deve ser
implementado, fazem restrições a aspectos de implementação e arquitetura, possuem detalhes
que geralmente são obscuros para o cliente, mas não para os desenvolvedores.

Engenharia de Requisitos:
O processo de Engenharia de Requisitos possui quatro subprocessos com finalidade de criação e
manutenção do documento de requisitos, com foco na qualidade do processo:

✓ Estudo de viabilidade: Consiste num conjunto preliminar de requisitos de negócio, um esboço

da descrição do sistema e como este pretende apoiar os processos de negócio. Através de uma
série de questões, como:
➢ O sistema contribui para os objetivos gerais da organização?
➢ O sistema pode ser implementado com tecnologia atual e dentro das restrições de
prazo e custo? O sistema pode ser integrado a outros sistemas existentes?
➢ Como a empresa se comportaria se esse sistema não fosse implementado?
➢ Quais são os problemas com os processos atuais e como o novo sistema ajudaria a
reduzir esses problemas?
Estas questões são respondidas através de conversas com: gerentes de departamento em que o
sistema será usado, engenheiros de software familiarizados com o tipo de sistema proposto,
especialistas em TI e usuários finais. Os resultados devem ser apresentados no relatório de
viabilidade, onde recomenda se vale a pena ou não prosseguir com o processo.

✓ Elicitação e Análise dos requisitos: Nessa atividade, os engenheiros de software trabalham com
os clientes e usuários finais do sistema para compreender sobre o domínio da aplicação, os
serviços do sistema, desempenho, restrições etc. Essa fase pode envolver vários stakeholders e
possui 4 atividades de processo:
➢ Obtenção de requisitos
➢ Classificação e organização de requisitos
➢ Priorização e negociação de requisitos
➢ Documentação de requisitos

✓ Obtenção de Requisitos: Obter informações sobre sistema através de fontes de informação

como: Documentação, Stakeholders de sistema e Especificações de sistemas similares.
Os requisitos podem ser obtidos através de:
➢ Pontos de vista: Organiza o processo de Elicitação de requisitos e os próprios requisitos
em pontos de vista. Um ponto forte dessa abordagem é que ela reconhece várias
perspectivas de um requisito, ou seja, várias visões diferentes de um requisito.
Existem 3 tipos de ponto de vista:
o Pontos de vista de interação
o Pontos de vista indiretos
o Pontos de vista de domínio

➢ Entrevista (Formais ou Informais): São formuladas perguntas Abertas ou Fechadas para

os stakeholders.
o Abertas: Indicadas quando deseja-se conhecer o escopo do entendimento do
entrevistado, não são seguidas por alternativas encorajando resposta livre,
podendo consumir muito tempo e resultar em pouca informação útil.
o Fechadas: Indicadas para avaliar características específicas do problema.
Fornecem escolha de alternativas ou níveis de resposta, impondo limites do tipo
Nível e Quantidade de informação fornecida pelo entrevistado.

Se utilizarmos apenas a entrevista como meio de obter requisitos, pode haver perda de
informações. Essa técnica deve ser utilizada em conjunto com outras técnicas de
Elicitação.

➢ Cenários: Geralmente as pessoas consideram mais fácil relatar exemplos da vida real do
que abstrair descrições. O cenário começa com um esboço da interação e, durante o
processo de Elicitação, os detalhes são adicionados para uma descrição completa dessa
interação.
➢ Casos de uso: Utiliza a linguagem de modelagem UML. É uma técnica baseada em
cenários para elicitação de requisitos. Os casos de uso identificam interações individuais
com o sistema.
✓ Validação: Finalidade de mostrar que os requisitos realmente definem o sistema que o usuário
deseja. Também está relacionada com a descoberta de problemas com os requisitos. Erros em
um documento de requisitos podem levar a custos excessivos. Devem ser realizadas verificações
nos requisitos do sistema:
➢ Verificação de validade
➢ Verificação de consistência
➢ Verificação de clareza
➢ Verificação de realismo
➢ Facilidade de verificação

Uma série de técnicas de validação pode ser utilizada:

➢ Revisão de requisitos
➢ Prototipação
➢ Geração de casos de teste

✓ Gerenciamento de Mudanças: Deve ser aplicado a todas as mudanças propostas. A principal

vantagem da utilização de um processo formal para tal tarefa é que todas as alterações de
requisitos propostas são tratadas consistentemente, e as mudanças no documento de requisitos
são realizadas de forma controlada. Existem 3 estágios principais no processo:
➢ Análise do problema e especificação da mudança
➢ Análise da mudança e estimativa do custo
➢ Implementação da mudança
4. Diagramas de Casos de Uso
Procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo
do sistema por qualquer pessoa, através da apresentação da visão externa geral das funções e
serviços que o sistema deverá oferecer aos usuários, sem se preocupar com o COMO;

Componentes Principais:

Atores: Tenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que
estes usuários irão assumir e quais funções serão requisitas por cada usuário específico;
• Pessoas (Normalmente)
• Hardware / software (Eventualmente)

Casos de Uso: Referem-se aos serviços, tarefas ou funções que podem ser utilizados pelos usuários
do sistema. Utilizados para expressar/documentar os comportamentos pretendidos para as funções
do sistema;

Documentação:
Associações:
➢ Atores e Casos De Uso
➢ Casos De Uso e Casos De Uso

Relacionamentos:
➢ Inclusão: Usada quando existe um serviço, situação ou rotina comum a mais de um Caso de
Uso, “Chamada de Sub-rotina”, representada por uma linha tracejada com texto
“<<Include>>”.

➢ Extensão: Descrever cenários opcionais de um Caso de Uso que somente ocorrerão em uma
situação específica – se uma determinada condição for satisfeita. Representada por:
“<<Extend>>”
➢ Generalização/Especialização: Associação entre Casos de Uso com características
semelhantes, onde a estrutura de um Caso de Uso generalizado é herdada pelos Casos de Usos
especializados.
5. Referências
✓ ANDRADE, Mayb. Qualidade de Software. 1ª Ed. Rio de Janeiro: SESES, 2015. Disponível em:
https://repositoriov2.azurewebsites.net/api/objetos/efetuaDownload/405d3e91-3eef-4471-9ead-702cee3d2861
✓ PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Porto Alegre: AGMH, 2016. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788580555349/
✓ SOMMERVILLE, Ian. Engenharia de Software. 10ª Ed. São Paulo: Pearson Prentice Hall, 2011. Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Loader/168127/pdf
✓ Amui, Saulo. Processos de Desenvolvimento de Software. 1ª Ed.. Rio de Janeiro: SESES, 2015.Disponível em:
https://repositoriov2.azurewebsites.net/api/objetos/efetuaDownload/faf38cab-2fb5-48d6-ac0b-a2685e2f5f48
✓ Braga, Pedro H. C. (Organizador). Testes de Software. 1ª Ed.. São Paulo: Pearson, 2016. Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Publicacao/150962/pdf/
✓ Galloti, Giocondo M. A. (Organizador). Qualidade de Software. 1ª Ed.. São Paulo: Pearson Education do Brasil, 2016.
Disponível em: https://plataforma.bvirtual.com.br/Acervo/Publicacao/124148
✓ PADUA FILHO, Wilson de Paula. Engenharia de Software. 3ª Ed.. Rio de Janeiro: LTC, 2009. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/978-85-216-1992-5/
✓ SCHACH, Stephen R. Engenharia de Software. 7ª Ed. Porto Alegre: ArtMed, 2010. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788563308443/