Docsity
EntrarCadastre-se
Docsity
Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity

Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium

Guias e Dicas
Guias e Dicas
Venda na Docsity
Venda na Docsity
EntrarCadastre-se

Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity

Encontrar documentos

Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity

Pesquisar documentos Store

Os melhores documentos à venda: Trabalhos de alunos formados

Videoaulas

Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade

Quiz

Responda perguntas de provas passadas e avalie sua preparação.

Pesquise entre todos os recursos de estudo
Docsity AINEW

Resuma seus documentos, faça perguntas, converta-os em questionários e mapas conceituais

TCC e ENEM 2025

Estude com provas passadas, TCCs e dicas úteis

Explorar perguntas

Tire suas dúvidas lendo as respostas dadas por outros alunos como você.

Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium

Compartilhe documentos
download point icon20 Pontos

Por cada documento compartilhado

Responda às perguntas
download point icon5 Pontos

por cada resposta enviada (máx. 1 por dia)

Todas as maneiras de obter pontos grátis
Ganhe pontos imediatamente

Escolha um Plano Premium com todos os pontos que precisa

Oportunidades de estudo

Escolha seu próximo programa de estudos

Entre em contato direto com as melhores Universidades do mundo. Pesquise entre milhares de Universidades e parceiros oficiais

Comunidade

Pergunte à comunidade

Peça ajuda à comunidade e tire suas dúvidas relacionadas ao estudo

Ranking universidades

Descubra as melhores universidades em seu país de acordo com os usuários da Docsity

Guias grátis

Os eBooks que salvam estudantes!

Baixe gratuitamente nossos guias de estudo, métodos para diminuir a ansiedade, dicas de TCC preparadas pelos professores da Docsity

Do blog

Vá para o blog

Resumo de Engenharia de Software I, Resumos de Engenharia de Software

Centro Universitário Eurípedes de Marília (UNIVEM)Engenharia de Software

Resumo de Engenharia de Software I

Tipologia: Resumos

2023

Compartilhado em 17/09/2023

danielle-bassetto
danielle-bassetto 🇧🇷

1 documento

1 / 13

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
Engenharia de Software
AULA 01
- Há uma transformação em como
os softwares são vistos,
construídos e utilizados…
- Antigamente:
Sistema Local;
Versões diferentes para
cada usuário;
- Atualmente:
Cloud;
Web;
Integrado
- O que era antigamente...
Um software -> Uma pessoa:
Compra;
É proprietário;
Responsável pelo
gerenciamento;
- Como é hoje...
Distribuído pela internet;
Pervasivo (???);
Está em servidores
distintos.
Velocidade para o
desenvolvimento
- O mercado atualmente exige:
Velocidade no
desenvolvimento;
Pela volatilidade das coisas;
Pelas mudanças no
mercado;
- Consequência:
Desenvolvimento Ágil
Engenharia de Software é
fundamental para que possamos
aplicar as metodologias ágeis,
fazendo softwares de qualidade.
Onde estão presente os
softwares?
Cresceu a quantidade, e
proporcionalmente a importância.
Duplo papel do Software
- Produto: Por meio de um
hardware, permite a realização de
tarefas, de produção e
transformação de informações
- Veículo para distribuir o produto;
Base para o controle do
computador (SO), comunicação de
informações (redes), criação e
controle de outros programas
(ambientes de desenvolvimento).
- Produto mais valioso da nossa
era = INFORMAÇÃO
- Software distribui as informações,
transforma dados pessoais em
informações valiosas para as
empresas.
Questões que nos guiam
Por que concluir um software leva
tanto tempo?
Por que os custos de
desenvolvimento são tão altos?
Por que não conseguimos
encontrar todos os erros antes de
entregar para nosso cliente?
Por que gastamos tanto tempo e
esforço mantendo programas
existentes?
A Engenharia de Software vai
permitir com que o
desenvolvimento seja melhor e
tenha mais qualidade.
Software
pf3
pf4
pf5
pf8
pf9
pfa
pfd

Pré-visualização parcial do texto

Baixe Resumo de Engenharia de Software I e outras Resumos em PDF para Engenharia de Software, somente na Docsity!

Engenharia de Software

AULA 01

  • Há uma transformação em como os softwares são vistos, construídos e utilizados…
  • Antigamente:  Sistema Local;  Versões diferentes para cada usuário;
  • Atualmente:  Cloud;  Web;  Integrado
  • O que era antigamente... Um software -> Uma pessoa:  Compra;  É proprietário;  Responsável pelo gerenciamento;
  • Como é hoje...  Distribuído pela internet;  Pervasivo (???);  Está em servidores distintos. Velocidade para o desenvolvimento
  • O mercado atualmente exige:  Velocidade no desenvolvimento;  Pela volatilidade das coisas;  Pelas mudanças no mercado;
  • Consequência:  Desenvolvimento Ágil Engenharia de Software é fundamental para que possamos aplicar as metodologias ágeis, fazendo softwares de qualidade. Onde estão presente os softwares? Cresceu a quantidade, e proporcionalmente a importância. Duplo papel do Software
    • Produto: Por meio de um hardware, permite a realização de tarefas, de produção e transformação de informações
    • Veículo para distribuir o produto; Base para o controle do computador (SO), comunicação de informações (redes), criação e controle de outros programas (ambientes de desenvolvimento).
    • Produto mais valioso da nossa era = INFORMAÇÃO
    • Software distribui as informações, transforma dados pessoais em informações valiosas para as empresas. Questões que nos guiam Por que concluir um software leva tanto tempo? Por que os custos de desenvolvimento são tão altos? Por que não conseguimos encontrar todos os erros antes de entregar para nosso cliente? Por que gastamos tanto tempo e esforço mantendo programas existentes? A Engenharia de Software vai permitir com que o desenvolvimento seja melhor e tenha mais qualidade. Software
  • Produto desenvolvido por profissionais de computação;
  • Suporte a longo prazo;
  • Abrange programas executáveis em um computador de qualquer porte ou arquitetura. Software - Construção X Desenvolvimento
  • Software é um processo de engenharia, NÃO É fabricação!
  • Não se deve gerir o desenvolvimento de um software como se fosse a construção de um hardware;
  • Aplicando processos constantes.
  • Hardware se desgasta, ao contrário do Software, que não se desgasta, se deteriora;
  • Software não, ou seja, não deveria aumentar os defeitos;
  • Por meio das alterações do software, ele se modifica, novos erros são inseridos. Como diminuir deterioração do software?
  • Basta fazer um projeto melhor!
  • Não há peças de reparação do software;
  • Defeito no software indica um erro no projeto ou no processo de desenvolvimento. AULA 02 - Software está em todos os aspectos da sociedade, e impactam a muitos em uma organização; - Esforço para compreender o problema antes de desenvolver - Complexidade dos requisitos, pode necessitar de equipes de desenvolvimento; - Projetar é uma atividade chave - Empresas dependem estrategicamente do Software, por isso deve ter QUALIDADE ELEVADA! - IEEE aponta que Engenharia de software é: (1) A aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento e na manutenção de software, isto é a aplicação de engenharia de software; (2) O estudo das abordagens como definido em (1) Os processos utilizados são importantes e permitem a manutenção das tecnologias e o desenvolvimento racional e dentro do prazo do software; - Define uma metodologia que deve ser estabelecida para a entrega. - Controle do gerenciamento e o contexto em que os métodos serão aplicados - Informações técnicas para desenvolver o software; Comunicação, análise de requisitos, modelagem, testes, suporte - Suporte automatizado ou semi- automatizado para os processos e os métodos; - Uso de ferramentais para a realização da engenharia: Astah, Trelo, outros.
  • Executar o Plano: Pode haver problemas durante a execução ou melhores formas de realizar o desenvolvimento.  A solução se adequa ao plano??  Cada uma das partes da solução está provavelmente correta
  • Examinar o Resultado: realizar testes para revelar a maior quantidade de erros possíveis.  É possível testar cada parte da solução?  A solução produz resultados de acordo com os requisitos? Princípios da Engenharia de Software
  • 7 Princípios da Engenharia de Software (David Hooker);
  • Prática Segura da Engenharia 1- A razão de existir: Um sistema existe por uma única razão:  GERAR VALOR A SEUS USUÁRIOS;  Antes de especificar, desenvolver uma funcionalidade, determinar que vai ser usado em um IWatch, pensar: Isso realmente agrega valor para meu usuário? 2- KISS: Keep It Simple, Stupid!  Faça de forma simples, tapado!  Todo o projeto deve ser o mais simples possível, mas não tão simples assim.  Buscar fazer um sistema mais fácil de compreender e manter 3- Mantenha a visão  Integridade conceitual. Uma visão clara do projeto;  Compreender a arquitetura do sistema 4- O que um produz outros consomem  Raramente, um sistema é construído de forma isolada;  Alguém irá usar, manter, documentar, ou depender de alguma forma do sistema desenvolvido;  Sempre, especifique, projete e implemente ciente de que alguém terá que entender o que foi feito 5- Esteja aberto para o futuro  Um sistema deve estar preparado para mudanças e adequações;  Jamais faça projetos limitados.  Sistema com valor devem ter uma vida útil grande.  Exemplo: SAP. 6- Planeje com antecedência, visando a reutilização  Reutilização economiza tempo e esforço;  Reutilizar código:  Orientação a Objetos contribui com isso;  Componentes e APIs estão ligados a isso. 7- Pense  Pensar bem e de forma clara antes de agir quase sempre produz melhores resultados  Refletir sobre o sistema e aplicar os princípios Mito em relação ao software - Crenças infundadas sobre o software e sobre o processo de criá-lo (atrapalha no gerenciamento e na criação de softwares) Mitos do GERENCIAMENTO  Livros com padrões resolvem o problema da equipe. Realidade: A equipe usa; Está

de acordo com as práticas atuais; É adaptável;  Se o cronograma atrasar, basta contratar mais programadores: Realidade: Processo não é mecânico. Colocar mais pessoas pode atrasar o projeto.  Se terceirizar o desenvolvimento, não preciso mais me preocupar com nada: Realidade: se não souber gerenciar, haverá problemas na terceirização Mitos dos CLIENTES  Definição geral dos objetivos é suficiente para iniciar o projeto: Realidade: necessário definir requisitos não ambíguos, pois, se não, será um desastre;  As mudanças nos requisitos podem ser facilmente assimiladas. Realidade: Mudanças nos requisitos impactam significativamente, de acordo com o momento que for solicitado. Mitos dos PROFISSIONAIS  Desenvolvi o sistema, não preciso mais fazer nada: Realidade: 60% a 80% do esforço será após a entrega para o cliente;  Só consigo avaliar a qualidade após o software entrar em funcionamento: Realidade: Foco na qualidade em todo o processo.  Único produto passível de entrega é o programa em funcionamento: Realidade: Modelos, planos, documentos são base para a engenharia bem-sucedida;  Engenharia de Software faz criar documentação volumosa e desnecessária: Realidade: Engenharia não se trata de criação de documento, mas sim, criar um produto de qualidade. Modelo Genérico

  • 5 Atividades
  • Comunicação;
  • Planejamento;
  • Modelagem;
  • Construção;
  • Emprego
  • Fluxo:  Linear;  Iterativo;  Evolucionário;  Paralelo AULA 04

Devemos conciliar esses conflitos com a negociação. Uma forma é fazer iterações, que:  Priorize os requisitos,  Avalie os custos e os riscos;  Trate dos conflitos internos.  Assim, atinja um nível de satisfação. Especificação Documentos que especificam o software.

  • Pode ser de diversas formas: Documento escrito, Modelos gráficos, Modelo matemático, Conjunto de cenários uso, um protótipo
  • Existe um modelo padrão - (Software Requirements Specification - SRS); Mas pode ser diferente para cada caso:  Sistemas Grandes: documento escrito, com linguagem natural e modelos gráficos;  Sistemas Pequenos: talvez apenas cenários de uso.
  • SRS  Especificação de Requisitos de Software (SRS);  Documento que detalha todos os aspectos de um software;  Deve ser feito antes do software ser construído;  Não necessariamente precisa ser formal (Casos de software desenvolvido por terceiro pede um SRS formal) Validação
    • Realiza-se a validação dos requisitos (dos artefatos construídos, como o casos de uso e outros modelos);
    • Verificar se todos os requisitos do software foram declarados de forma não ambígua;
    • Uma forma é a Revisão Técnica: Uma equipe valida os requisitos, encontrando possíveis erros, problemas de interpretação, inconsistências, conflitos, entre outros.
    • Algumas perguntas:  O requisitos estão declarados de forma clara? Eles podem ser mal interpretados?  O requisito viola quaisquer restrições do domínio do sistema?  O requisito pode ser associado a qualquer modelo de sistema que tenha sido criado? Gestão
    • Os requisitos podem MUDAR ao longo da vida de um sistema;
    • Atividades para ajudar: a equipe de projeto a identificar, controlar e acompanhar as necessidades e suas mudanças a qualquer momento. Requisito Funcional
    • Descrevem explicitamente as funcionalidades e serviços do sistema;
    • Completude: devem ser completos;
    • Consistência: não podem ser contraditórios.
    • Especificação ou descrição de uma função, recurso ou comportamento que um sistema deve ser capaz de executar. Eles descrevem as principais funcionalidades que o sistema deve possuir, as operações que ele deve realizar, as restrições de tempo ou desempenho e

quaisquer outras características específicas do sistema

  • Geralmente escritos em linguagem clara e objetiva, descrevendo as ações que o sistema deve realizar em resposta a determinadas entradas ou eventos
  • Os requisitos funcionais são compostos de duas partes: função e comportamento. A função é o que o sistema faz (por exemplo, “calcular imposto sobre vendas”). O comportamento é como o sistema faz isso (por exemplo, “O sistema deve calcular o imposto sobre vendas multiplicando o preço de compra pela alíquota do imposto.”). Requisitos Não Funcionais
  • Requisitos que definem propriedades e restrições do sistema;
  • Críticos: Sistema PRECISA atender.
  • Os requisitos não funcionais podem ser divididos em duas categorias:  Atributos de qualidade: Estas são as características do sistema que determinam sua qualidade geral. Exemplos de atributos de qualidade incluem segurança, desempenho e usabilidade.  Restrições: Estas são as limitações impostas ao sistema. Exemplos de restrições incluem tempo, recursos e ambiente.
  • O sistema não pode funcionar sem satisfazer todos os requisitos funcionais. Por outro lado, o sistema fornecerá o resultado desejado mesmo quando não atender aos requisitos não funcionais.
  • Exemplos: ● Sistema será Web. Pode ser feito apenas uma aplicação Web; ● Usuários não poderão ver informações pessoais dos clientes; ● Sistema terá que estar em nuvem, pois cliente não tem servidor físico. Requisito Funcional x Requisito Não Funcional
    • Os requisitos funcionais descrevem as funções, comportamentos e operações específicas que o sistema deve realizar. Eles estão relacionados ao que o sistema deve fazer para atender às necessidades e expectativas dos usuários. Esses requisitos geralmente são descritos em termos de casos de uso, cenários ou fluxos de trabalho, e definem as interações entre os usuários e o sistema. Exemplos de requisitos funcionais incluem: "O sistema deve permitir que os usuários se cadastrem", "O sistema deve permitir que os usuários façam login" e "O sistema deve permitir que os usuários realizem compras online".
    • Os requisitos não funcionais são atributos ou qualidades do sistema que não estão relacionados diretamente com suas funcionalidades específicas, mas sim com suas características de desempenho, confiabilidade, usabilidade, segurança, entre outras. Esses requisitos se concentram em aspectos como desempenho, escalabilidade, disponibilidade, segurança, usabilidade, manutenibilidade e outros atributos do sistema. Exemplos de requisitos não funcionais incluem: "O sistema

Lista de Objetos  DVD’s dos filmes;  Totem de autoatendimento;  Servidor Web;  Veículo para entrega em domicilio; Lista de Serviços  Registrar a compra de DVD’s;  Cadastrar novos clientes;  Baixar DVD’s defeituosos;  Entregar DVD;  Devolver DVD;  Consultar acervo de filmes;  Reservar filme;  Alugar filme Lista de Restrições  A aplicação deve estar na nuvem (cloud computing);  O cliente deve ser avisado quando o filme reservado estiver disponível;  As campanhas devem estar integradas com as redes sociais (facebook, instagram) Miniespecificação

  • Pode criar uma pequena especificação de algum item da lista, que exige mais detalhes;
  • Por exemplo o totem de autoatendimento: O totem de autoatendimento permite que o cliente pesquise todo o acervo de filmes da loja, faça uma reserva caso o filme esteja alugado, alugue os filmes disponíveis e faça a retirada do balcão. Caso o cliente se interesse pelo filme, pode acessar a sinopse do mesmo e assistir o trailer do mesmo
    • Ao invés de miniespecificação pode-se fazer casos de uso específicos Diagrama de caso de uso Pontos de Debate
    • Nessa fase, os debates devem ser evitados, porque é uma fase inicial;
    • O facilitador deve intervir; Por exemplo, o marketing acha que o cliente pode alugar diretamente pelas redes sociais, e os desenvolvedores acham que a implementação é muito complexa;
    • Deve verificar se isso é mesmo necessário, e levar isso para uma discussão futura Disponibilização da Função de Qualidade
    • Quality Function Deployment (QFD);
    • Visa atender as necessidades dos clientes, traduzindo para requisitos técnicos do software;
    • 3 Tipos de Requisitos  Requisitos normais: o Objetivos e metas para um produto, obtidos durante as reuniões;

o Requisitos presentes → clientes satisfeitos; o Ex: desempenho satisfatório, aplicativo para android e iphone;  Requisitos Esperados: o Implícitos no produto, por serem fundamentais; o Na reunião pode não aparecer; o Ex: boa interação no IHC, confiabilidade;  Requisitos Fascinantes: o Além da expectativa dos clientes; o Muito satisfatórios quando estão presentes; o Clientes se deleitam; o Ex: Recomendação de filmes utilizando IA Cenários de Uso A partir do levantamento dos requisitos:  Tem-se uma visão mais clara do produto e das necessidades;  As funções serão utilizadas por diferentes classes de usuários; (Esse passo é o chamado casos de uso.) Sintetizando O processo para extrair os requisitos antes do caso de uso:  Identificar os interessados: saber quem vai trabalhar;  Realizar perguntas iniciais: começar a ter uma ideia do projeto;  Levantamento de Requisitos: coleta colaborativa e reuniões entre os interessado JAD (Joint Application Design)

  • Uma técnica popular para levantamento de requisitos;
  • Método de Projeto Interativo;
  • Funcionam por meio de reuniões estruturadas;
  • Trabalho em equipe, visando o consenso.
  • Princípios: ○ Realizar dinâmicas de grupo; ○ Usar recursos audiovisuais; ○ Manter processo organizado e racional; ○ Utilizar uma documentação padrão; ○ Planejamento; ○ Projeto Protótipo
  • Fazer um protótipo a partir das reuniões ou entrevistas iniciais;
  • Tentar apresentar alguma coisa palpável;
  • Para o cliente poder dar feedbacks e melhorar os requisitos que o cliente deseja