0% acharam este documento útil (0 voto)
35 visualizações13 páginas

Guia Completo de Engenharia de Software

Este documento descreve vários conceitos e métodos relacionados à engenharia de software, incluindo definições de engenharia de software, modelos de desenvolvimento como cascata, espiral e RUP, metodologias ágeis, Scrum, engenharia de requisitos e técnicas de elicitação de requisitos.

Enviado por

Eduardo Antônio
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
35 visualizações13 páginas

Guia Completo de Engenharia de Software

Este documento descreve vários conceitos e métodos relacionados à engenharia de software, incluindo definições de engenharia de software, modelos de desenvolvimento como cascata, espiral e RUP, metodologias ágeis, Scrum, engenharia de requisitos e técnicas de elicitação de requisitos.

Enviado por

Eduardo Antônio
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd

O que é Engenharia de Software: Se trata da aplicação/criação de métodos e

técnicas que visam tornar mais eficientes os processos de desenvolvimento de

software, além de outras áreas da ciência da computação

● Engenharia:

○ Métodos de análise, planejamento, concepção/prototipação,

implementação, codificação e manutenção (testes);

○ Criam uma série de atividades (técnicas) para verificar a

qualidade para o lançamento do produto final;

● Software:

○ Por serem produtos imateriais e abstratos, não se desgastam

(fisicamente) e não podem ser perceptíveis até que tenham uma

forma (ou protótipo);

○ Seus custos de produção não estão envolvidos em matéria

prima, mas sim em desenvolvimento e planejamento;

Quais são as etapas do desenvolvimento de um Software ?:

● 1° Projeto: Planejamento e Organização;

● 2° Desenvolvimento: Criação do Software;

● 3° Teste: Validação da funcionalidade do Software;

● 4° Manutenção: Correção e aprimoramento das funcionalidades;

Modelos de Desenvolvimento de Software: São “técnicas” ou “metodologias” que

visam tornar mais eficiente a criação de softwares,

Modelo Cascata: Cada etapa deve estar completa antes de avançar para a próxima,

engessando o desenvolvimento, e também acaba dificultando a comunicação entre

desenvolvedores e clientes e podendo resultar em insatisfação do cliente com o

produto final.
● 1° Análise de requisitos e especificação;

● 2° Arquitetura do projeto;

● 3° Implementação e Integração;

● 4° Verificação;

● 5° Operação e Manutenção;

Modelo Espiral: O diferencial desse método é que os requisitos são documentados,

são avaliadas possíveis alternativas e partir daí um protótipo é desenvolvido, onde

esse ciclo se repete…

● Prós: O cliente é bastante envolvido no processo, os riscos são reduzidos,

projetos são monitorados mais fácilmente e seus prazos ficam mais

realísticos;

● Contras: As interações com o cliente são distantes, muitas modificações na

documentação, é um processo burocrático e caro;

Modelo Rational Unified Process (RUP):

● Indicação: definições de negócio, cronograma e riscos;

● Elaboração: casos de uso, arquitetura e protótipos;

● Construção: codificação e testagem dos protótipos;

● Transição: leva o produto final para o ambiente real;


● Disciplinas do modelo: Modelagem de negócios, requisitos, análise e projeto,

implementação, teste e implementação (deploy).

● Prós: É uma ferramenta que possui práticas de negócio amarradas ao

desenvolvimento e ferramentas que ajudam a melhorar o projeto

gradualmente.

● Contras: São ferramentas caras, para projetos de grande porte e que

possuem condições “específicas” para ajustar a RUP a cada empresa, que às

vezes impede o uso de uma ferramenta.

Metodologia do Planeje-e-Documente (P-e-D): Antes de começar a programação,

o gerente do projeto descrevia detalhadamente as fases de funcionamento do

software em um documento, com toda e qualquer alteração sendo registrada no

documento principal.

● Gerente de Projeto: Elaboram contratos, recrutam equipes, avaliam

desempenho e salários, estimam custos, mantêm cronogramas, avaliam

riscos, documentam planos de projeto e são responsáveis pelo sucesso ou

falhas, como atrasos ou estouro do orçamento.


● Tamanho do Projeto: Adicionar membros a um projeto atrasado pode piorar

o atraso. Isso ocorre porque novos desenvolvedores precisam de tempo para

aprender o projeto, aumentando o tempo de comunicação e reduzindo o

tempo de desenvolvimento. Recomenda-se grupos de 4 a 9 pessoas,

organizados de forma hierárquica para melhorar a eficiência do projeto.

O que são Metodologias Ágeis:

● Abordagem iterativa e incremental para desenvolvimento de software.

● Valoriza indivíduos e interações sobre processos e ferramentas.

● Foco na entrega contínua de software funcional e de qualidade.

Manifesto Ágil: Valorizamos mais indivíduos e interações, software funcional,

colaboração com o cliente e resposta a mudanças do que processos, documentação

extensa, negociação de contratos e seguir um plano, conforme a evolução no

desenvolvimento de software.

● Ciclo de Vida Ágil: Foca na mudança/evolução contínuo, com o protótipo

sendo refinado constantemente, porém, mesmo estando incompleto ele será

funcional e sendo atualizado até que se adeque ao cliente, alguns métodos

que funcionam desta maneira são:

○ Test-Driven Development (TDD);

○ User Stories;

● Antes e Agora: Antigamente, ela era tratada como controversa, pois causaria

uma mudança muito brusca, até que em 2013, após uma pesquisa constatar

que 66 equipes usavam metodologias ágeis, que mesmo com times

distribuídos, conseguiram uma boa produtividade, que revolucionou a área.


Metodologia Scrum: Se trata de um estrutura de gerenciamento de projetos ágeis,

ela é baseada em iterações curtas chamadas de "sprints", com divisão dos papéis,

artefatos e eventos-chave.

● Papéis do Scrum:

○ Product Owner:

■ Representante dos stakeholders.

■ Responsável por maximizar o valor do produto.

○ Scrum Master:

■ Facilitador do time Scrum.

■ Remove obstáculos e promove a adoção de práticas ágeis.

○ Time de Desenvolvimento: Equipe multifuncional responsável por

desenvolver o produto.

● Artefatos do Scrum:

○ Product Backlog: Lista priorizada de requisitos do produto.

○ Sprint Backlog: Lista de tarefas a serem realizadas durante a sprint.

○ Incremento do Produto: Versão do produto que está pronta ao final

de cada sprint.

● Eventos em Scrum:

○ Sprint Planning: Reunião para planejar o trabalho da próxima sprint.

○ Daily Scrum: Reunião diária para sincronizar o time.

○ Sprint Review: Demonstrações do trabalho feito ao final da sprint.

○ Sprint Retrospective: Reflexão sobre o processo e identificação de

melhorias.

● Princípios Ágeis:

○ Colaboração com o cliente.

○ Entrega contínua de software funcional.

○ Adaptação às mudanças.
Engenharia de Requisitos: Identificação, documentação e gerenciamento dos

requisitos de um sistema. Esses requisitos são as necessidades e restrições que o

sistema deve atender para satisfazer os usuários, clientes e outras partes

interessadas.

● Requisitos Funcionais: Funcionalidades específicas de um sistema;

● Requisitos Não-Funcionais: Atributos e características do sistema;

● Importância: Ajuda a estabelecer as bases para desenvolver o projeto;

Processo de Engenharia de Requisitos:

● Elicitação de Requisitos: Coleta de informações sobre os requisitos do

sistema, usa técnicas como entrevistas, workshops, questionários e

observação dos usuários;

● Análise: Os requisitos coletados são analisados e refinados para garantir que

sejam claros, completos e consistentes;

● Especialização: Envolve a decomposição de requisitos de alto nível em

requisitos mais detalhados e específicos;

● Validação: Verifica se os requisitos capturados refletem as necessidades

reais dos usuários e se são alcançáveis e testáveis.

● Gerenciamento: Controle e manutenção dos requisitos ao longo do ciclo de

vida do projeto, lidando com mudanças, rastreando o status dos requisitos e

garantindo sua integridade.

Desafios na Engenharia de Requisitos:

● Compreensão de Domínio: Compreender o contexto do problema;

● Comunicação Efetiva: Comunicação clara para evitar desentendimentos;

● Mudança Constante: Equipes devem ser ágeis para adaptação a mudanças;

● Escopo Mal Definido: Deve-se evitar requisitos vagos ou inconsistentes;


Técnicas de Elicitação de Requisitos:

● Entrevistas: Conversas diretas com os stakeholders para entender suas

necessidades e expectativas em relação ao sistema;

● Questionários: Formulários com perguntas específicas para coletar

informações sobre os requisitos dos usuários de forma mais ampla e

estruturada;

● Workshops: Reuniões em grupo com representantes de diferentes áreas

para discutir e identificar requisitos de forma colaborativa e intensiva;

● Prototipagem: Criação de versões simplificadas do sistema para permitir que

os usuários experimentem e forneçam feedback sobre o design e

funcionalidades desejadas;

● Brainstorming: Sessões de geração de ideias em grupo para explorar

criativamente possíveis requisitos e soluções para o sistema;

● Observações do Usuário: Observação direta das atividades dos usuários no

ambiente real de trabalho para identificar suas necessidades e problemas

enfrentados.

● Cenários e Histórias do Usuário: Descrições detalhadas de situações de uso

do sistema e dos objetivos que os usuários desejam alcançar.

Selecionando a Técnica Adequada: É importante considerar fatores como a

disponibilidade de tempo, recursos e o contexto do projeto. Algumas técnicas

podem ser mais apropriadas para determinados tipos de projetos ou para lidar com

certos tipos de stakeholders

Matriz Rastreabilidade: Trata-se de uma ferramenta que ajuda a acompanhar e

entender as relações entre diferentes partes de um projeto ou sistema. Ela mostra

como os requisitos, partes do sistema e outros elementos estão conectados. Além

de aspectos práticos como testes, componentes e etc…


Importância da Matriz Rastreabilidade:

● Rastreamento de Requisitos: Permite acompanhar como cada requisito é

atendido ao longo do projeto;

● Avaliação de Impacto: Ajuda a entender como as mudanças afetam outras

partes do sistema;

● Teste de Cobertura: Garante que todos os requisitos foram testados e

cobertos adequadamente;

● Compreensão do Sistema: Facilita a compreensão das relações e

dependências entre diferentes partes do sistema;

Elementos da Matriz Rastreabilidade:

● Requisitos: As necessidades ou funcionalidades que o sistema deve atender;

● Elementos Relacionados: inclui elementos como casos de uso, módulos de

software, testes, documentação, entre outros, que estão diretamente

relacionados aos requisitos;

Criação da Matriz Rastreabilidade:

● Identificação dos Elementos: Identificar e listar todos os requisitos e

elementos que estão relacionados;

● Construção da Matriz: Criar uma estrutura que mostre as relações entre

esses elementos;

● Preenchimento da Matriz: Preencher a matriz com informações sobre como

os requisitos estão conectados aos outros elementos;

● Atualização Contínua: Manter a matriz atualizada à medida que o projeto

evolui e novas informações são descobertas;


Benefícios da Matriz Rastreabilidade:

● Visibilidade: Torna as relações entre diferentes partes do projeto mais claras;

● Rastreabilidade: Permite rastrear mudanças e entender seu impacto;

● Gestão de Mudanças: Facilita a gestão de mudanças ao mostrar como elas

afetam outros elementos;

● Garantia de Qualidade: Ajuda a garantir que todos os requisitos sejam

atendidos e testados;

● Conclusão: Matriz de Rastreabilidade é uma ferramenta valiosa para garantir

que um projeto seja bem compreendido, gerenciado e entregue com

qualidade.

Exemplo de Matriz Rastreabilidade:

Conceitos de Orientação a Objetos: Com a popularização dos computadores e com

o crescimento da demanda por softwares nos anos de 1970, as técnicas de

desenvolvimento da época se provarem ineficientes, surgiu então a necessidade da

criação de novas técnicas.

● Primeiro, surge a programação estruturada com as etapas de abstrair,

formalizar, dividir e depois hierarquizar a solução dos problemas;

● Depois surge o conceito da Orientação a Objetos;


Origem da Programação Orientada a Objetos: Surgiu como uma evolução da

programação estruturada, visando melhorar a organização e reutilização do código.

A POO visa modelar o mundo real de forma mais fiel, representando objetos e suas

interações, facilitando o desenvolvimento, manutenção e reutilização do código.

Programação Estruturada:

● Abstração: Representa elementos complexos do mundo real de forma

simplificada.

● Formalidade: Definir regras claras e precisas para a resolução de problemas.

● Dividir o Problema: Quebrar um problema complexo em partes menores e

mais gerenciáveis.

● Disposição Hierárquica: Organizar o código em uma estrutura lógica e

hierárquica.

Fundamentos da POO:

● Encapsulamento: Ocultar os detalhes de implementação e expor apenas

uma interface.

● Herança: Permite que uma classe herde atributos e métodos de outra.

● Polimorfismo: Capacidade de um objeto poder ser referenciado de várias

formas.

Classes: São como planos ou modelos para criar objetos. Elas definem atributos

(características) e métodos (ações) que os objetos podem ter.

● Atributos: São características que descrevem um objeto, como cor, tamanho,

e dentre outros fatores;

● Métodos: São ações que um objeto pode realizar dentro de uma classe, como

mover, calcular, etc;


Instâncias ou Instanciação: É o ato de criar um objeto a partir de uma classe.

Objetos: São instâncias de uma classe, ou seja, são as entidades reais com

características e comportamentos.

● Objetos e seus atributos: Cada objeto tem seus próprios valores para os

atributos definidos na classe;

● Objetos e seus Métodos: Os objetos podem executar os métodos definidos

na classe;

● Objetos e suas Mensagens: Os objetos se comunicam entre si enviando

mensagens, que são chamadas de métodos de outros objetos;

Vantagens da POO:

● 1° Facilita a organização e manutenção do código;

● 2° Promove a reutilização do código através de classes e objetos;

● 3° Permite uma modelagem mais próxima do mundo real;

Desvantagens da POO:

● 1° Pode aumentar a complexidade do código em certos casos;

● 2° Requer um pouco mais de tempo e planejamento para desenvolver;

● 3° Nem sempre é a melhor abordagem para todos os tipos de problemas.;

Generalização e Especialização: Generalização é o processo de definir uma classe

mais abstrata, enquanto especialização é o processo de criar classes mais

específicas com base na classe geral.

Herança: Permite que uma classe herde atributos e métodos de outra.

● Herança Múltipla: Uma classe pode caracteristicas herdar de outras classes;

● Herança x Uso: Herança é uma relação "é um", enquanto o uso é uma

relação "tem um".


Polimorfismo (Override): Permite que um método em uma classe filha substitua

um método na classe pai. Isso permite que objetos de diferentes classes respondam

ao mesmo método de maneiras diferentes.

Sobrecarga (Overload): Permite que uma classe tenha vários métodos com o

mesmo nome, mas com diferentes parâmetros. O método a ser chamado é

determinado pelo número e tipo de parâmetros passados.

Encapsulamento: Oculta os detalhes internos de implementação de uma classe,

expondo apenas uma interface pública. Isso ajuda a proteger os dados da classe e

garante que eles sejam acessados e modificados de forma controlada.

Abstração: Permite representar objetos do mundo real de forma simplificada,

destacando apenas os detalhes mais importantes para o problema em questão.

Diagrama de Classe de UML - Características:

● Multiplicidade: Define quantos objetos de uma classe podem se relacionar

com objetos de outra classe;

● Associação Unária: Uma classe se relaciona consigo mesma;

● Associação Binária: Relacionamento entre duas classes;

● Associação Ternária: Relacionamento entre três classes;

● Agregação: Uma classe é parte de outra classe, mas pode existir

independentemente;

● Composição: Uma classe é parte de outra classe e não pode existir

independentemente;

● Classe Associativa: Classe usada para representar uma associação entre

outras classes;

● Dependência: Uma classe depende de outra para realizar alguma tarefa;


● Realização: Uma classe implementa a interface definida por outra classe;

● Restrições: Limitações ou condições impostas aos relacionamentos entre

classes;

___________________________________________________________________________

Você também pode gostar