O documento fornece uma introdução sobre engenharia de software, definindo o termo, por que o desenvolvimento é complexo, o que a área estuda e classificação de sistemas. Aborda 12 áreas de conhecimento como requisitos, arquitetura, design, testes, manutenção, configuração, projetos, processos, modelos, qualidade, ética e aspectos econômicos.

1. ENGENHARIA DE SOFTWARE MODERNA(CAP. 1)

2. O que é a Engenharia de software?
“Our civilization runs on software.” – Bjarne Stroustrup
Termo criado no final da década de 60 durante uma conferência da OTAN que definia a
padronização de princípios práticos e teóricos na área desenvolvimento de Software
A Engenharia de Software auxilia para que o desenvolvimento seja de forma produtiva e com
qualidade

3. Por que o desenvolvimento é tão
complexo?
No ensaio No Silver Bullet, Frederick Brooks ilustra a grande particularidade da Engenharia de
Software em Relação às outras Engenharias. São elas: dificuldades Essenciais e dificuldades
Acidentais

4. Dificuldades Essenciais
Complexidade(Muito mais complexos que construções físicas)
Invisibilidade(Dificuldade de visualização por ser abstrato)
Facilidade de Mudanças(Necessidade de evoluir sempre)
Conformidade(A fácil adaptação a um novo ambiente)

5. Dificuldades Acidentais
Bugs
Travamentos
Interfaces não responsivas
Ausência de um design de Software amigável

6. O que a Engenharia de Software estuda?
O livro SWEBOK(Guide to the Software Engineering Body of Knowledge) define 12 áreas de
conhecimento em Engenharia de Software, as quais serão abordadas a seguir

7. 1-Engenharia de Requitos
Um requisito de Software, na sua forma mais simplificada, é o que define os objetivos e as
funções de um software. Eles podem ser:
Funcionais
Não-funcionais

8. Requisitos Funcionais
São os requisitos que definem o que o sistema deve fazer, ou seja, quais são as suas
funcionalidades.
Podemos citar o exemplo de um sistema de gerenciamento de conta bancária. Nesse caso, os
requisitos funcionais são: exibir extrato, verificar o saldo, exibir as contas pendentes, etc.

9. Requisitos Não-funcionais
Os requisitos não funcionais são os que definem o modo de operação de um sistema.
Voltando ao exemplo do sistema de gerenciamento de contas, alguns requisitos não-funcionais
são: Segurança(se o sistema é seguro), desempenho(poucos segundos para exibir os resultados),
privacidade(não exibir os dados para terceiros), etc.

10. 2-Arquitetura de Software
A arquitetura de Software define a estrutura interna de um código, ou seja, sua “planta”. Ela
define a base de um projeto de forma complexa e organizada
Alguns padrões de arquitetura mais comuns são o MVC(Model-View-Controller),
Layres(camadas) e Client-Server(cliente-servidor)

11. 3- Design de Software
Enquanto a Arquitetura de Software se preocupa em definir como os componentes de um
sistema interagem entre si, o Design de Software define em como será realizada a
implementação desses componentes.
Um exemplo de práticas para uma boa implementação são: Clean code(código limpo),
minimizing complexity(minimizando a complexidade) e os Design Patterns(Padrões de projeto).
As duas primeiras práticas são autoexplicativas, já o termo Design Patterns é utilizado para
definir soluções elegantes para problemas comuns no desenvolvimento de software

12. 4-Testes de Software
Os testes são utilizados para verificar se um Software está exibindo o comportamento esperado
em um número finito de casos. Para isso, existem diversos tipos de testes, como: Testes de
unidade(em que uma pequena parte do código é testada, como uma classe), Testes de
integração(são realizados em ambientes mais complexos, como um conjunto de classes),Testes
de Performance(quando se submete o sistema a uma carga de processamento para verificar seu
desempenho) testes de usabilidade (quando o objetivo é verificar a usabilidade da interface do
sistema), etc.

13. Validação e Verificação
Os testes de software podem ser utilizados tanto para a verificação quanto para a validação de
um software
Verificação: garantir se o sistema atinge seus objetivos, ou seja, se está sendo implementado de
forma correta
Validação: garantir se o sistema atinge as necessidades dos seus clientes, ou seja, se ele atinge
os anseios da demanda e do mercado

14. Defeitos, Bugs e Falhas
Um defeito é o termo utilizado quando um determinado código apresenta inconsistências, mas
ainda não executadas. Um bug é o termo informal utilizado com diversas intenções, mas muito
mais utilizado como sinônimo de defeito. Por fim, falha é a execução de um código com defeito,
o que exibe um resultado insesperado

15. 5-Manutenção e Evolução de Software
Softwares Precisam de manutenção para continuarem executando suas funções de forma
correta, elas podem ser: ]
Corretivas: correção de falhas notadas pelos desenvolvedores ou usuários.
Preventiva: Correção de defeitos no código, ou seja, podem se tornar falhas.
Adaptativa: adaptação a um novo ambiente, novas leis, novos clientes, etc.
Refactoring: modificações visando exclusivamente a melhoria do código(arquitetura, design,etc)
Evolutiva: Implementações de novas funcionalidades, aperfeiçoamentos, etc

16. 6-Gerência de configuração
A Gerência de Configuração é um conjunto de práticas e políticas para o controle das diversas
versões de um sistema, como a utilização do versionamento quântico ou o uso de softwares git

17. 7-Gerência de projetos
A Gerência de projetos nada mais é do que a supervisão dos prazos, contratos, riscos e outras
burocracias importantes do desenvolvimento de software.
A lei de Brooks é um termo comum nessa prática, pois ela define que a adição de novos
desenvolvedores pode atrasas ainda mais o andamento do projeto, pois eles precisam entender
desde o início a arquitetura, os requisitos e outras partes importantes do projeto.

18. 8-Processos de Desenvolvimento de
Software
Os Processos de Desenvolvimento de Software nada mais são que as atividades e etapas da
construção de um software. Os modelos mais comuns são o Waterfall e Agile.
O modelo Waterfall define as etapas do desenvolvimento de um software como algo sequencial
e em cascata, análogo a construção de prédios, pois esses são elaborados de forma
sequencial(fundação,alvenaria,encanamento, etc). O problema que fez esse modelo cair em
desuso é a lentidão que essas etapas promovem no desenvolvimento, fazendo com que o
lançamento seja profundamente atrasado e o software seja prejudicado
Já o Agile, é um modelo mais atual e que consiste em realizar pequenos incrementos e
funcionalidades em um curto intervalo de tempo. Modelos dessa prática são a Metodologia
Scrum, Kanbam, XP, etc.

19. 9-Modelos de Software
Os Modelos de software são práticas que ajudam os desenvolvedores a avaliar propriedades e
características essenciais de um sistema, um exemplo dessa prática são os diagramas UML

20. 10-Qualidade de Software
A qualidade de um software pode ser medida de forma Externa e Interna.
A forma externa é analisada não necessariamente por desenvolvedores, mas sim pelos clientes e
usuários, exemplos: correção(se existem bugs), eficiência(se o software age como prometido),
facilidade de uso, compatibilidade, etc
A forma interna, deve ser analisada por um profissional da área, pois ela avalia a modularidade,
legibilidade, manutenbilidade, etc.

21. 11-Prática Profissional
A prática profissional é nada mais que a necessidade dos desenvolvedores de agirem de forma
ética durante seu trabalho, para isso existem diversos códigos e leis que regem essa prática,
como o código de ética da ACM, código de ética da SBC(Sociedade Brasileira de Computação),
etc.

22. 12-Aspectos Econômicos
Todo projeto de desenvolvimento exige custos, não só monetários mas custos de oportunidade,
esses custos são a análise de prós e contras de uma decisão e como isso pode afetar o projeto.
Exemplo: Existe uma decisão X e uma Y, ao tomar a decisão X em detrimento da Y, é necessário
entender que as oportunidades que a Y poderia oferecer são perdidas e, dependendo da
decisão, pode acarretar tanto em perdas monetárias quanto no atraso do desnvolvimento.

23. Classificação de Sistemas de Software
Os sistemas de software podem ser classificados em A(acute), B(Business), C(Casuais)
Acute: São sistemas de missão crítica em que erros podem gerar falhas graves ou perda de
vidas, exemplo: sistema de gerenciamento de uma usina nuclear
Business: Sistemas direcionados para o mercado e suas aplicações, devem ter qualidade e boas
práticas de uso
Casuais: Sistemas com pouca exigência de qualidade, pois são definidos para fins não críticos em
que falhas não afetarão tanto o desempenho de alguma atividade