Engenharia de Software I

Aula 3
Visão Geral da Engenharia de Software

l.bertholdo@ifsp.edu.br
Conteúdo
• Definição de Engenharia de Software
• Processo de Software
• Prática e Princípios da Engenharia de Software
• Mitos do Desenvolvimento de Software
• Aspectos Humanos
• Ética na Engenharia de Software

l.bertholdo@ifsp.edu.br
 Definição de Engenharia de Software
• Segundo o IEEE – Institute of Electrical and Electronics Engineers*,
(pronuncia-se “i3e”):

Engenharia de software refere-se ao estudo e a aplicação de

abordagens sistemáticas, disciplinadas e quantificáveis no
desenvolvimento, na operação e na manutenção de software.

* O IEEE é a maior sociedade profissional técnica do mundo. Seus membros são compostos por
engenheiros, cientistas e profissionais afins, que incluem cientistas da computação, desenvolvedores
de software, profissionais de tecnologia da informação, físicos, médicos e outros, além do núcleo de
engenharia elétrica e eletrônica do IEEE. (https://www.ieee.org/about/ieee-history.html)

l.bertholdo@ifsp.edu.br
 Definição de Engenharia de Software
• Mas por que a engenharia de software é necessária?
Atualmente, software é usado para lidar
com boa parte dos problemas de nossas
vidas. Logo, é preciso compreender um
problema antes de desenvolver uma
solução de software para tratá-lo.
Todo software
deve passar
por processos
de engenharia.
Os requisitos de tecnologia da
informação estão cada vez mais
complexos. Por isso, projetar o software
se tornou uma atividade essencial.
Aplicações valiosas tendem a aumentar
sua base de usuários com o tempo, o que
também amplia a demanda por
adaptações. Logo, dentro do possível, um
software deve ser de fácil manutenção.
Todos dependem cada vez mais de
software, tanto em operações cotidianas
como para tomada de decisões. Logo, um
software deve apresentar alta qualidade.
l.bertholdo@ifsp.edu.br
 Definição de Engenharia de Software
• Camadas da Engenharia de Software
As ferramentas fornecem suporte para o
processo e os métodos. Quando integradas, de
modo que as informações criadas por uma
ferramenta possam ser utilizadas por outra, é
Os métodos da O processo de engenharia
estabelecido um sistema chamado engenharia
engenharia de software software constitui a base
de software com o auxílio do computador.
fornecem as informações para o gerenciamento de
técnicas para desenvolver projetos e estabelece o
o software. Eles envolvem contexto no qual são
uma ampla variedade de aplicados métodos, são
tarefas: comunicação, produzidos artefatos, são
análise de requisitos, estabelecidos marcos, a
modelagem de projeto, qualidade é garantida e
construção do programa, mudanças são geridas de
testes e suporte. forma apropriada.
A gestão da qualidade é a pedra fundamental
que sustenta a engenharia de software. Ela
promove uma cultura de melhoria contínua
de processos, que leva ao desenvolvimento de
abordagens cada vez mais eficazes.
l.bertholdo@ifsp.edu.br
Processo de Software Artefato é um produto, objeto ou dispositivo
resultante de algum trabalho ou ação.

• Processo é um conjunto de atividades, ações e tarefas realizadas na

criação de algum artefato. Dentro de um processo de software:
• Uma atividade visa um objetivo amplo (por exemplo: comunicar-se
com os envolvidos) e independe do campo de aplicação, do tamanho
do projeto ou do rigor com que a engenharia de software será aplicada.
• Uma ação (por exemplo: especificar os requisitos) envolve um conjunto
de tarefas que resultam em um artefato de software fundamental (um
documento de especificação de requisitos, por exemplo).
• Uma tarefa se concentra em um objetivo pequeno, porém bem-
definido (por exemplo: definir os fluxos de um caso de uso).

Na engenharia de software, um processo não é uma prescrição rígida de como

desenvolver um software. Ao contrário, é uma abordagem adaptável que possibilita
à equipe de software selecionar e escolher o conjunto apropriado de ações e tarefas.
l.bertholdo@ifsp.edu.br
 Processo de Software
Essas cinco atividades podem
• A engenharia de software define um processo ser usadas para desenvolver
básico que inclui atividades metodológicas programas pequenos e simples
ou grandes e complexos. Os
aplicáveis a qualquer projeto, independente-
detalhes do processo de
mente de tamanho ou complexidade. software poderão ser bem
diferentes em cada caso, mas
• Uma metodologia de processo genérica para as atividades metodológicas
engenharia de software possui cinco atividades: básicas serão as mesmas.

Comunicação: Antes de iniciar os Planejamento: O plano de projeto Modelagem: Um engenheiro de

trabalhos técnicos, é essencial
entender os objetivos dos
envolvidos no projeto e reunir os
requisitos básicos que definirão os
recursos e funções do software.
de software descreve as tarefas
técnicas, os riscos, os recursos
materiais e humanos necessários,
os produtos resultantes e o
cronograma de trabalho.
software precisa criar modelos
para entender melhor as
necessidades do software e o
projeto que vai atender a estas
necessidades.

Construção: Essa atividade combina geração de Entrega: O software (completo ou um incremento

código (manual ou automatizada) e testes parcialmente concluído) é entregue ao cliente, que
necessários para revelar erros na codificação. avalia o produto recebido e fornece seu feedback.
l.bertholdo@ifsp.edu.br
 Processo de Software
• As atividades metodológicas são complementadas por diversas
atividades de apoio, que ajudam a equipe de software a gerenciar e
a controlar o andamento, a qualidade, as alterações e os riscos.
Atividade de Apoio Descrição
Controle e acompanhamento Possibilita que a equipe avalie o progresso em relação ao plano do projeto e tome
do projeto as medidas necessárias para cumprir o cronograma.
Administração de riscos Avalia riscos que possam afetar o resultado ou a qualidade do produto/projeto.
Garantia da qualidade de Define boas práticas e conduz atividades que garantem a qualidade do software.
software
Revisões técnicas Avaliam artefatos da engenharia de software, tentando identificar e eliminar erros
antes que se propaguem para a atividade seguinte.
Medição Define e coleta medidas do processo, do projeto e do produto), além de auxiliar na
entrega do software de acordo com os requisitos.
Gerenciamento da Gerencia os efeitos das mudanças ao longo do processo.
configuração de software
Gerenciamento da capacidade Define critérios para a reutilização de artefatos, sobretudo componentes de
de reutilização software, e estabelece mecanismos para a obtenção de componentes reutilizáveis.
Diretrizes para produção de Estabelece modelos e orientações para criação de artefatos como, por exemplo,
artefatos de software documentos, diagramas, protótipos, casos de teste. l.bertholdo@ifsp.edu.br
Prática e Princípios da Engenharia de Software
• O matemático húngaro George Polya descreveu em linhas gerais a
essência da solução de problemas em seu livro clássico How to
Solve It, escrito antes de os computadores modernos existirem.
• Como o desenvolvimento de um software também é um problema
a ser resolvido, podemos mapear as etapas da abordagem de Polya
para a prática de engenharia de software:
1. Compreender o problema (comunicação e análise);
2. Planejar uma solução (modelagem e projeto de software);
3. Executar o plano (geração de código);
4. Examinar o resultado para ter precisão (testes e garantia da
qualidade).

l.bertholdo@ifsp.edu.br
 Prática e Princípios da Engenharia de Software
Compreenda o problema: O elemento mais
importante para se entender um problema é escutar.
Quem são os envolvidos (interessados na solução do
problema)?
Que dados, funções e recursos são necessários para
resolver apropriadamente o problema?

Examine o resultado: É preciso garantir que um
número de testes suficiente foi realizado para revelar
o maior número de erros possível.
É possível testar cada parte componente da solução?
A solução produz resultados adequados aos dados,
às funções e às características necessários?
Planeje a solução: Antes de começar a codificar,
faça alguma perguntas.
Algum problema semelhante já foi resolvido? Se sim,
há elementos da solução que podem ser reutilizados?
É possível definir subproblemas? Em caso positivo,
existem soluções aparentes e imediatas para eles?

Execute o plano: O projeto elaborado é um mapa para

construir o sistema. Podem surgir desvios inesperados, mas
o planejamento permitirá que continuemos sem nos perder.
O código-fonte está compatível com o projeto?
Todas as partes componentes da solução estão corretas?

l.bertholdo@ifsp.edu.br
Prática e Princípios da Engenharia de Software
• O que é “princípio”?

Em uma área de conhecimento, conjunto de proposições fundamentais e diretivas que servem de

base e das quais todo desenvolvimento posterior deve ser subordinado. (Dicionário Michaelis)

• Na engenharia de software, os princípios ajudam a estabelecer uma

forma de pensar, de modo que possamos praticá-la com segurança.

• Em 1996, David Hooker propôs sete princípios para a prática da

engenharia de software:
1. A razão de existir: Um sistema existe por um motivo: agregar valor para seus
usuários. Todas as decisões devem ser tomadas com esse princípio em mente.
Antes de definir ou executar qualquer atividade técnica, pergunte a si mesmo:
“Isso agrega valor real ao sistema?”. Se a resposta for “não”, não o faça.

l.bertholdo@ifsp.edu.br
Prática e Princípios da Engenharia de Software
2. KISS (Keep It Simple, Stupid!, ou seja: não complique!): Todo projeto deve ser o
mais simples possível, mas não simplista (superficial). Esse princípio contribui para
um sistema mais fácil de compreender e manter. Porém, simples não significa
“gambiarra”. Na verdade, é necessário muita reflexão e trabalho para simplificar.

3. Mantenha a visão global: A falta de uma visão geral clara, pode transformar o
projeto em uma colcha de retalhos, com módulos incompatíveis unidos por
parafusos que não se encaixam. Ter um arquiteto responsável e capaz de manter a
visão clara e de reforçar a adequação ajuda a assegurar o êxito de um projeto.

4. O que um produz outros consomem: Muitas pessoas dependerão da capacidade

de entender seu sistema para usá-lo, documentá-lo e modificá-lo. Portanto,
sempre especifique, projete e implemente ciente de que mais alguém terá de
entender o que você está fazendo. Ao facilitar o trabalho futuro das pessoas, você
agrega maior valor ao sistema.

l.bertholdo@ifsp.edu.br
Prática e Princípios da Engenharia de Software
5. Esteja aberto para o futuro: Hoje, as especificações mudam a todo instante e as
tecnologias se tornam obsoletas rapidamente. Sistemas mais duráveis e de
sucesso são aqueles que foram projetados para se adaptar sem muitas
dificuldades às mudanças. Jamais faça projetos pensando apenas no presente.

6. Planeje com antecedência, visando a reutilização: O reuso de código economiza

tempo e esforço. Porém, aproveitar as possibilidades de reutilização oferecidas
pelas linguagens e técnicas de programação exige planejamento. Planejar com
antecedência o reuso reduz o custo e aumenta o valor dos componentes
reutilizáveis e dos sistemas aos quais eles serão incorporados.

7. Pense: Geralmente, este é o princípio mais menosprezado. Algo bem analisado,

provavelmente sairá da forma correta. Se você analisar algo e mesmo assim o fizer
errado, isso ainda será uma valiosa experiência. Um efeito da análise é aprender a
reconhecer quando não se sabe algo, e assim poder buscar o conhecimento.

l.bertholdo@ifsp.edu.br
Mitos do Desenvolvimento de Software
• Tratam-se de crenças infundadas sobre o software e o processo
utilizado para criá-lo e remontam aos primórdios da computação.

• Eles são traiçoeiros, pois parecem ser afirmações sensatas e

intuitivas (algumas vezes contendo elementos de verdade) e
frequentemente são propagados por profissionais experientes.

• Os mitos podem provocar sérios problemas tanto para gerentes

quanto para praticantes da área. Entretanto, antigos hábitos e
atitudes são difíceis de ser modificados, e resquícios de mitos de
software permanecem até hoje.

l.bertholdo@ifsp.edu.br
Mitos do Desenvolvimento de Software
• Mitos de Gerenciamento de Projetos de Software

Mito: Já temos um documento cheio de padrões e procedimentos para desenvolver software. Ele não
supriria meu pessoal com tudo que precisam saber?
Realidade: Esse documento é realmente utilizado? Os profissionais sabem que ele existe? Ele reflete a
prática moderna da engenharia de software? É completo? É adaptável? Está otimizado para melhorar
o tempo de entrega, mantendo a qualidade? Normalmente, a resposta para essas perguntas é “não”.

Mito: Se o cronograma atrasar, poderemos acrescentar mais programadores e ficar em dia.

Realidade: O desenvolvimento de software não é um processo mecânico como o de uma fábrica.
Quando novas pessoas entram, as que já estavam terão de gastar tempo situando os recém-
chegados, reduzindo assim o tempo destinado ao desenvolvimento produtivo. Pode-se adicionar
pessoas, mas somente de forma planejada e bem coordenada.

Mito: Se eu terceirizar parte do projeto, posso me despreocupar, pois a outra empresa irá realizá-la.
Realidade: Uma organização deve saber gerenciar e controlar seus projetos de software, mas quando
partes do projeto são terceirizadas, o acompanhamento das atividades deve ser ainda mais próximo.

l.bertholdo@ifsp.edu.br
Mitos do Desenvolvimento de Software
• Mitos dos Clientes

Mito: Uma definição geral dos objetivos é suficiente para começar a escrever os programas, podemos
preencher os detalhes posteriormente.
Realidade: Embora nem sempre seja possível uma definição ampla e estável dos requisitos, uma
definição de objetivos muito superficial é a receita para um desastre. Além disso, requisitos consistentes
e efetivos são obtidos somente pela comunicação contínua e eficaz entre cliente e desenvolvedor.

Mito: As mudanças nos requisitos de software, que ocorrem durante o projeto, podem ser facilmente
assimiladas, pois um software em construção é altamente flexível.
Realidade: O impacto de uma mudança de requisitos varia dependendo do momento em que foi
introduzida. Quando a mudança é solicitada cedo (antes de o projeto ou de a codificação terem
começado), o impacto sobre o custo é relativamente pequeno. Entretanto, conforme o tempo passa,
este custo começa a aumentar rapidamente.

l.bertholdo@ifsp.edu.br
Mitos do Desenvolvimento de Software
• Mitos dos Profissionais da Área
Mito: Uma vez que o programa foi feito e colocado em uso, nosso trabalho está terminado.
Realidade: Levantamentos indicam que entre 60 e 80% de todo o esforço de um projeto será despendido
após a entrega do software ao cliente pela primeira vez.

Mito: Até que o programa esteja “em execução”, não há como avaliar sua qualidade.
Realidade: Mecanismos de garantia da qualidade, como a revisão técnica, podem ser aplicados desde a
concepção do projeto de software. Os revisores técnicos são “filtros de qualidade”, considerados mais
eficientes do que os testes feitos para encontrar certos tipos de defeitos de software.

Mito: O único produto a ser entregue é o programa em funcionamento.

Realidade: Um programa funcionando é somente uma parte de uma configuração de software que inclui
muitos outros artefatos, como: modelos, documentos, manuais de usuário etc.

Mito: A engenharia de software nos fará criar documentação volumosa e desnecessária e,

invariavelmente, vai nos atrasar.
Realidade: O objetivo da engenharia de software não é criar documentos. É criar um produto de
qualidade. E qualidade melhor leva à redução do retrabalho, resultando em tempos de entrega menores.
l.bertholdo@ifsp.edu.br
Aspectos Humanos
• Software é desenvolvido por pessoas e equipes. Por isso, os
aspectos humanos da engenharia de software são tão importantes
para o sucesso de um projeto quanto a melhor das tecnologias.
• Um engenheiro de software precisa ter várias habilidades técnicas,
mas os aspectos humanos são igualmente importantes.
• Uma equipe de software só será bem-sucedida se sua dinâmica
estiver correta. Porém, às vezes, os engenheiros de software têm a
reputação de não trabalhar bem com outras pessoas.
• É fundamental que os engenheiros de software trabalhem bem com
seus colegas de equipe e com outros envolvidos no produto a ser
construído.

l.bertholdo@ifsp.edu.br
 Aspectos Humanos
• Erdogmus (2009) identifica sete características pessoais de um
engenheiro de software com comportamento “superprofissional”.
Senso de responsabilidade individual: Tem
determinação para cumprir suas promessas para
colegas, para os envolvidos e para a gerência.

Pragmatismo: Sabe que a engenharia

Perspicácia: Observa o ambiente em
de software não é uma religião na qual
que as pessoas trabalham e adapta seu
devem ser seguidas regras dogmáticas,
comportamento a ele e às próprias
mas sim uma disciplina que pode ser
pessoas.
adaptada conforme as circunstâncias.

Atenção aos detalhes: Considera Honestidade: Ao ver um projeto falho,

atentamente as decisões técnicas que aponta os defeitos de maneira
toma, levando em conta desempenho, construtiva, sem distorcer fatos sobre
custo, qualidade, sem apresentar cronogramas, recursos, desempenho
obsessão com a perfeição. ou outras características do projeto.

Lealdade: Compartilha os créditos com seus Resiliência sob pressão: É capaz de suportar a
colegas. Tenta evitar conflitos de interesse e nunca pressão de modo que seu desempenho não seja
age no sentido de sabotar o trabalho dos outros. prejudicado.
l.bertholdo@ifsp.edu.br
Ética na Engenharia de Software
• O trabalho de um engenheiro de software envolve responsabilidades
maiores do que simplesmente aplicar habilidades técnicas.
• Ele também deve se comportar de forma ética e moralmente
responsável se deseja ser respeitado como profissional.
Uma empresa é responsável por desenvolver um sistema bancário e, por causa da pressão pelos prazos,
ignora um erro muito específico encontrado em um teste de validação de segurança do sistema. O
engenheiro de software responsável deve manter a confidencialidade exigida pelo seu gestor, ou deve
alertar o cliente, de alguma forma, que o sistema pode não ser 100% seguro?
• Embora o sistema tenha apresentado o erro com base em critérios predefinidos, esses critérios podem
ser rígidos demais, e o sistema pode, de fato, operar com segurança durante todo seu ciclo de vida.
• Mesmo que o sistema não apresentasse o erro, não há como garantir totalmente que todos os testes
de validação de segurança foram previstos.
• A divulgação antecipada do erro pode causar prejuízo para a empresa de desenvolvimento, incluindo
seus funcionários.
• Por outro lado, não divulgar o erro pode resultar em prejuízo para o cliente.
Não existem manuais para situações assim, e é preciso refletir para tomar suas próprias decisões.
l.bertholdo@ifsp.edu.br
Ética na Engenharia de Software
• Segundo Pressman (2016), em nível pessoal, um engenheiro de
software também deve se guiar pelas seguintes regras:
• Nunca roubar dados para obter vantagens pessoais.
• Nunca distribuir ou vender informações proprietárias obtidas como parte
de seu trabalho em um projeto de software.
• Nunca destruir ou modificar programas, arquivos ou dados de outra
pessoa para prejudicá-la.
• Nunca violar a privacidade de um indivíduo, grupo ou organização.
• Nunca invadir um sistema, seja qual for a motivação.
• Nunca criar ou promover um vírus ou verme (worm) de computador.
• Nunca usar a tecnologia de informação para facilitar qualquer tipo de
discriminação ou assédio.
l.bertholdo@ifsp.edu.br
Referências
• PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.

• SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.

• ERGOMUS, H. The Seven Traits of Superprofessionals. IEEE Software, vol.

26, no. 4, July–August, 2009, pp. 4–6.

l.bertholdo@ifsp.edu.br