1. Gerencia de projetos
1.1. A Lei de Brooks
1.2. stakeholder
1.2.1. São as partes interessadas no mesmo; ou seja, os stakeholders são aqueles que afetam ou que são afetados pelo projeto, podendo ser pessoas físicas ou organizações.
2. Processos de Desenvolvimento de Software
2.1. Processos Waterfall
2.1.1. Processos Waterfall — também chamados de processos dirigidos por planejamento (plan-driven) — propõem que a construção de um sistema deve ser feita em etapas sequenciais, como em uma cascata de água, na qual a água vai escorrendo de um nível para o outro
2.1.1.1. levantamento de requisitos, análise (ou projeto de alto nível), projeto detalhado, codificação e testes. Finalizado o pipeline, o sistema é liberado para produção.
2.2. Processos Ágeis
2.2.1. A ideia de processos ágeis é que um sistema deve ser construído de forma incremental e iterativa. Pequenos incrementos de funcionalidade são produzidos, em intervalos de cerca de um mês e, logo em seguida, validados pelos usuários. Uma vez que o incremento produzido seja aprovado, o ciclo se repete.
2.2.1.1. XP, Scrum, Kanban e Lean Development, testes automatizados, test-driven development (isto é, escrever os testes primeiro, antes do próprio código) e integração contínua (continuous integration).
3. Prática profissional
3.1. Responsabilidade ética
3.2. Código de Ética da Sociedade Brasileira de Computação (SBC)
4. Teste consiste na execução de um programa com um conjunto finito de casos, com o objetivo de verificar se ele possui o comportamento esperado
4.1. VERIFICAÇÃO
4.2. VALIDAÇÃO
4.3. ERRO, DEFEITO, FALHA
5. A presença de softwares está contida no cotidiano
5.1. devido a relevância, há a necessidade de uma área da Computação destinada a investigar e propor solucões que permitam desenvolver sistemas de software mais eficientes.
5.1.1. Engenharia de Software
5.1.1.1. Hoje, já se tem conhecimento de que software — na maioria das vezes — não deve ser construído em fases estritamente sequenciais, como ocorre com produtos tradicionais de engenharia, tais como Engenharia Civil, Engenharia Mecânica, Engenharia Eletrônica, etc.
6. desenvolver, operar, manter e evoluir.
6.1. Conferência OTAN, 10/1968
6.1.1. A conferência afirmava a necessidade de que software fosse construído com base em princípios práticos e teóricos, tal como ocorre em ramos tradicionais e bem estabelecidos da Engenharia. Para deixar essa proposta mais clara, decidiu-se cunhar o termo Engenharia de Software.
6.2. ACIDENTAIS
6.2.1. TECNOLOGIAS
6.2.2. RECURSOS
7. DIFICULDADES NO DESENVOLVIMENTO DE SOFTWARES
7.1. ESSENCIAIS
7.1.1. Complexidade
7.1.2. Conformidade
7.1.3. Facilidade de mudanças
7.1.4. Invisibilidade
8. OBJETO DE ESTUDO:
8.1. Guide to the Software Engineering Body of Knowledge (SWEBOK)
9. Engenharia de Requisitos
9.1. os requisitos podem ser funcionais ou não-funcionais
9.1.1. Interfaces providas são aqueles serviços que uma unidade de código torna público para uso pelo resto do sistema
10. PROJETO DE SOFTWARE
10.1. interfaces providas e interfaces requeridas
10.1.1. Interfaces requeridas são aquelas interfaces das quais uma unidade de código depende para funcionar.
10.2. arquitetura de software
10.2.1. trata da organização de um sistema em um nível de abstração mais alto do que aquele que envolve classes ou construções semelhantes.
10.3. CONSTRUÇÃO DE SOFTWARE
10.3.1. Construção trata da implementação, isto é, codificação do sistema
10.4. TESTE DE SOFTWARE
10.5. MANUTENÇÃO DE SOFTWARE
10.5.1. EVOLUTIVA
10.5.1.1. Manutenção evolutiva é aquela realizada para incluir uma nova funcionalidade ou introduzir aperfeiçoamentos importantes em funcionalidades existentes.
10.5.2. CORRETIVA
10.5.2.1. Manutenção adaptativa tem como objetivo adaptar um sistema a uma mudança em seu ambiente, incluindo tecnologia, legislação, regras de integração com outros sistemas ou demandas de novos clientes.
10.5.3. PREVENTIVA
10.5.3.1. Manutenção adaptativa tem como objetivo adaptar um sistema a uma mudança em seu ambiente, incluindo tecnologia, legislação, regras de integração com outros sistemas ou demandas de novos clientes.
10.5.4. ADAPTATIVA
10.5.4.1. Manutenção adaptativa tem como objetivo adaptar um sistema a uma mudança em seu ambiente, incluindo tecnologia, legislação, regras de integração com outros sistemas ou demandas de novos clientes.
11. Qualidade de Software
11.1. Qualidade externa
11.1.1. Qualidade externa considera fatores que podem ser aferidos sem analisar o código. Assim, a qualidade externa de um software pode ser avaliada mesmo por usuários comuns, que não são especialistas em Engenharia de Software.
11.2. Qualidade interna
11.2.1. Qualidade interna considera propriedades e características relacionadas com a implementação de um sistema. Portanto, a qualidade interna de um sistema somente pode ser avaliada por um especialista em Engenharia de Software e não por usuários leigos.
11.3. Revisões de código
11.3.1. O objetivo é detectar bugs antecipadamente, antes de o sistema entrar em produção. Além disso, revisões de código servem para garantir a qualidade interna do código — isto é, sua manutenibilidade, legibilidade, modularidade, etc.