Publicité
Publicité

Contenu connexe

Publicité

Resumo capítulo 1 livro Engenharia de Software Moderna

  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
Publicité