Engenharia De Software
Upcoming SlideShare
Loading in...5
×
 

Engenharia De Software

on

  • 34,438 views

Apresentação sobre Introdução a Engenharia de Software

Apresentação sobre Introdução a Engenharia de Software

Statistics

Views

Total Views
34,438
Views on SlideShare
34,303
Embed Views
135

Actions

Likes
12
Downloads
896
Comments
2

2 Embeds 135

http://www.slideshare.net 127
http://www.moraga.com.br 8

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Achei muito importante estudar engenharia de software educacional, pois faço parte da turma de licenciatura em computação pela UFRA - Universidade Federal Rural da Amazônia- Estado do Pará.
    Are you sure you want to
    Your message goes here
    Processing…
  • Excelente trabalho.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Engenharia De Software Engenharia De Software Presentation Transcript

    • Engenharia de Software
    • Tópicos – Engenharia de Software
      • O que é?
      • Camadas
      • Perguntas que devem ser respondidas
      • Fases genéricas da Engenharia de Software
      • Modelos de Processos de Engenharia de Software
      • Modelos de Processos de Desenvolvimento de Software
      • RUP - ( Rational Unified Process )
    • O que é Engenharia de Software?
      • É um conceito que está baseado em camadas:
      • Qualidade: Toda engenharia deve se fundamentar no comprometimento com a qualidade;
      • Processo: É a base da engenharia de software. É o processo que “cola” as ferramentas e os métodos;
      • Métodos: Fornecem a definição do “como fazer” o desenvolvimento de software;
      • Ferramentas: Realizam o suporte automatizado ou semi-automatizado para os processos e métodos (exemplo: ferramentas CASE);
    • Camadas de Engenharia de Software Foco em Qualidade Processos Métodos Ferramentas
    • Perguntas que devem ser respondidas
      • Qual é o problema a ser resolvido?
      • Quais características do software a ser gerado resolvem o problema?
      • Como o software (a solução) serão concebidos?
      • Como o software será construído?
      • Qual a abordagem que será utilizada para cobrir erros feitos no projeto e construção do software?
      • Como o software será mantido a longo prazo, quando correções, adaptações e melhorias forem requeridas por usuários do software?
    • Fases Genéricas da Engenharia de Software
    • Modelos de Processos de Engenharia de Software
      • Para resolver problemas reais, o engenheiro de software deve aplicar uma estratégia de desenvolvimento que contemple as camadas de processos, métodos e ferramentas;
      • Esta estratégia é o modelo de processo ou paradigma de engenharia de software;
      • É escolhido baseado na natureza do projeto e aplicação, nos métodos e ferramentas a serem utilizados e nos controles e entregas requeridos;
      • Os modelos definem ordem para uma atividade inerentemente caótica ;
    • Modelos de Processos de Desenvolvimento de Software
      • Modelo Linear Seqüencial
      • Modelo de Prototipação
      • Modelos Evolucionários
      • - Incremental
      • - Espiral
      • RUP – Rational Unified Process
      • Atividades de suporte : independentes do modelo de
      • processo
      • - Garantia de Qualidade de Software
      • - Gerenciamento da Configuração do Software
      • - Mensuração de Software
    • Modelo Linear Seqüencial
      • Também chamado de “ciclo de vida clássico” e “modelo cascata”;
      • Sugere uma abordagem seqüencial para o desenvolvimento de software;
      Análise Projeto (Design) Codificação Testes Engenharia do Sistema / Informação
      • Engenharia do sistema/informação: O software é parte de um sistema maior. Por isso, o trabalho inicial com a definição dos elementos do sistema e do software, é realizada uma análise do projeto superficial;
      • Análise: Intensificação do levantamento de requisitos, agora focado no software. Define domínio de informação, funcionalidade, comportamento, performance e interface;
      • Projeto ( design ): Traduz os requerimentos para uma representação técnica;
      • Codificação: É a tradução do projeto em uma linguagem de programação. Se o projeto for detalhado, a codificação é um processo mecânico;
      • Teste: Teste do programa codificado. Pode ser da lógica interna do software ou focado nas funcionalidades externas;
      • Suporte: Corrige e adapta o software gerado. Reaplica as fases precedentes no programa existente.
      Modelo Linear Seqüencial
    • Modelo Linear Seqüencial
      • É o mais antigo paradigma de engenharia de software;
      • Problemas do modelo linear seqüencial:
      • Projetos reais raramente seguem a ordem seqüencial proposta e mudanças nesta seqüência podem causar confusão na equipe de projeto;
      • É difícil para os usuários definir todos os requisitos explicitamente. O modelo seqüencial requer esta definição e é difícil acomodar incertezas nos requisitos;
      • O cliente deve ter paciência. Uma versão “visível” do programa estará disponível somente no fim do projeto. Erros percebidos somente nesta fase podem ser tornar um desastre;
    • Modelo de Prototipação
      • Permite que o cliente “perceba” o software que está sendo gerado antes da finalização;
      • Atividades do modelo:
      • Definição de requisitos;
      • Projeto “Rápido”: foca em representar os aspectos do software que serão visíveis ao usuário. É a construção de um protótipo ;
      • Avaliação do Protótipo: o usuário avalia o protótipo e refina os requisitos;
      • Natureza iterativa: as atividades se repetem até que o software fique pronto;
    • Modelo de Prototipação
      • Problemas:
      • O cliente vê o que parece ser uma versão que funciona do software. Apesar das grandes mudanças que devem ser feitas para que o protótipo se torne um software completo e com qualidade, o cliente pode querer fazer “remendos” no protótipo para iniciar o uso;
      • Práticas não desejáveis de codificação podem ser utilizadas para construção do protótipo e depois “esquecidas”, tornando-se a solução definitiva;
      • “ Software nunca está pronto”...
      Modelo de Prototipação
      • A natureza evolucionária do software não é considerada explicitamente nem no modelo linear seqüencial, nem no modelo de prototipação;
      • Os modelos evolucionários são iterativos, ou seja, são caracterizados de maneira que permitem aos engenheiros de software, construções com versões cada vez mais completas do software;
      • Veremos dois tipos de modelos evolucionários:
      • - Incremental
      • - Espiral
      Modelos Evolucionários
      • O modelo incremental combina elementos do modelo linear seqüencial (aplicado repetidamente) com a filosofia iterativa da prototipação;
      • Cada seqüência linear produz um “incremento” entregável ( deliverable ) do software;
      • Exemplo de um processador de texto:
      • – Primeiro entregar funções básicas de manipulação de arquivo;
      • – Depois, entregar funcionalidades de edição e produção de documentos mais avançadas;
      • – No terceiro incremento, entregar verificação de grafia e gramática;
      • – ...
      Modelo Incremental
      • A cada incremento, o usuário pode utilizar o produto gerado ou fazer uma revisão detalhada;
      • O próximo incremento deve implementar as solicitações do usuário, mais as novas funcionalidades planejadas;
      • O processo é repetido até que o produto completo é entregue;
      Modelo Incremental
    • Modelo Incremental
      • O modelo incremental, como o de prototipação, é iterativo. Mas diferentemente do de prototipação, ele foca em entregar um produto operacional em cada incremento;
      • É um modelo que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo linear seqüencial;
      • O software é desenvolvido em uma série de “ releases ” incrementais: nas primeiras iterações podem apenas ser um modelo em papel ou um protótipo; nas últimas, versões cada vez mais completas do software são produzidas;
      Modelo Espiral
    • Modelo Espiral
      • O modelo espiral é dividido em um número de atividades, chamadas regiões de tarefas. Tipicamente, existem de 3 a 6 regiões;
      • Comunicação com cliente: tarefas requeridas para estabelecer comunicação efetiva entre desenvolvedor e cliente;
      • Planejamento: tarefas requeridas para definir recursos, tempos de tarefas e outras atividades de planejamento;
      • Análise de Risco: tarefas requeridas para avaliar riscos técnicos e de gerenciamento;
      • Engenharia: tarefas requeridas para construir um ou mais representações da aplicação;
      • Construção e Entrega: tarefas requeridas para construir, testar, instalar, e prover suporte ao usuário;
      • Avaliação do cliente: tarefas requeridas para obter feedback do cliente baseado na avaliação das representações do software criadas durante o estágio de engenharia;
      Modelo Espiral
      • Cada região possui um conjunto de tarefas, que são adaptadas às características do projeto a ser iniciado. Para pequenos projetos, poucas tarefas. Para grandes projetos, mais tarefas para garantir nível maior de formalidade;
      • Quando o processo inicia, a equipe de desenvolvimento se move na espiral em sentido horário, iniciando no centro:
      • - O primeiro circuito resulta no desenvolvimento da especificação;
      • - O subseqüente, pode ser usado para desenvolvimento do protótipo;
      • - Cada passagem na região de Planejamento resulta em ajustes no plano de projeto (inclusive o número de iterações necessárias para finalizar o projeto);
      Modelo Espiral
      • Não termina quando o software é entregue: pode ser adaptado a todo o ciclo de vida do software;
      • “ Eixos de Entrada de Projeto”: cada cubo localizado no eixo pode ser utilizado para representar o ponto de início de diferentes tipos de projetos;
      Modelo Espiral
      • Projeto de Desenvolvimento de Conceito: inicia no centro da espiral e continua na espiral até que esteja completo (área mais escura);
      • Se o conceito será desenvolvido na forma de um produto, o processo continua através do próximo cubo (ponto de entrada de desenvolvimento de novo produto). O novo produto evolui na espiral na área em cinza médio;
      • Em essência, se a espiral for vista dessa forma, ela continua até que o software é retirado de uso;
      • Problemas:
      • - Pode ser difícil convencer os clientes de que a abordagem evolucionária é controlável;
      • - O modelo não é usado na mesma extensão que o linear e o de prototipação, e, por isso, não foi “testado” o suficiente;
      Modelo Espiral
      • As demandas atuais para softwares poderosos e complexos não têm sido atendidas pela forma como softwares são desenvolvidos. Hoje em dia, muitas pessoas desenvolvem software usando modelos de 25 anos atrás;
      • A comunidade de software precisava de um processo que:
      • - Provesse um guia para a ordem das atividades da equipe do projeto;
      • - Direcionasse as tarefas dos desenvolvedores e da equipe como um todo;
      • - Especificasse quais os artefatos que devem ser desenvolvidos;
      • - Oferecesse critérios para monitoramento e medida dos produtos
      • atividades de um projeto;
      RUP - ( Rational Unified Process )
      • O RUP é um modelo de processo de desenvolvimento de software (dessa forma, ele descreve um conjunto de atividades para transformar os requisitos do usuários em um software);
      • É baseado em componentes: o sistema de software sendo desenvolvido é feito de componentes de software interconectados via interfaces bem definidas;
      • Utiliza a UML ( Unified Modeling Language )
      RUP - ( Rational Unified Process )
      • Direcionado a Caso de Uso: o processo de desenvolvimento segue um fluxo (procede) através de uma série de workflows que derivam dos casos de uso;
      • Centrado em Arquitetura: o processo do RUP ajuda o arquiteto a focar nos objetivos corretos, como entendimento, resiliência a mudanças futuras e reuso. Casos de uso e arquitetura se completam e devem evoluir em paralelo ;
      • Iterativo e incremental: divide o trabalho de engenharia do software em “mini-projetos” ou iterações. Cada iteração resulta em um incremento no produto;
      Características Fundamentais
      • Em cada iteração, os desenvolvedores identificam e especificam casos de uso relevantes, criam um projeto usando a arquitetura escolhida como um guia, implementam o projeto em componentes e verificam se os componentes satisfazem o caso de uso;
      • Se a iteração atinge seu objetivo, prossegue-se para a próxima iteração. Quando não, os desenvolvedores revisam suas decisões e tentam nova abordagem;
      Iterações
      • A iteração controlada reduz o custo do risco às despesas de um único incremento, e não do produto pronto;
      • A iteração controlada reduz o risco de não colocar o produto no mercado no tempo esperado, ou seja, os riscos são descobertos antes;
      • Acelera o tempo de desenvolvimento porque trabalha com tarefas mais curtas e focadas;
      • Reconhece uma realidade geralmente ignorada: necessidades dos usuários e requerimentos não podem ser definidos logo no início. São tipicamente refinados em iterações sucessivas.
      Benefícios das Iterações
      • Segundo o RUP, um produto de software deve ter:
      • Um modelo de casos de uso com todos os casos de uso e seus relacionamentos com usuários;
      • Um modelo de análise que tem dois propósitos: refinar os casos de uso em mais detalhes e fazer uma alocação inicial do comportamento do sistema em uma série de objetos que provêem o comportamento;
      • Um modelo de projeto ( design ) que define: a) a estrutura estática do sistema como subsistemas, classes e interfaces; e b) os casos de usos realizados como colaborações entre os subsistemas, classes e interfaces;
      • Um modelo de implementação , que inclui componentes (representando código fonte), e mapeando as classes para os componentes;
      • Um modelo de implantação ( deployment ), que define os nós físicos dos computadores e os mapeamentos dos componentes para estes nós;
      • Um modelo de testes , que descreve os casos de teste e verifica os casos de uso;
      • E uma representação da arquitetura ;
      O Produto de Software do RUP
    • O Produto de Software do RUP
      • O processo unificado repete uma série de ciclos que formam a vida de um sistema. Cada ciclo é concluído com uma release (entrega) aos clientes;
      • Cada ciclo consiste de 4 fases: inception (iniciação), elaboration (elaboração), c onstruction (construção), transition (transição) e cada fase é dividida em iterações;
      O Ciclo de Vida do RUP
    • O Ciclo de Vida do RUP
      • Uma fase termina com um marco ( milestone ), que é definido pela disponibilidade de certos artefatos (modelos ou documentos) em um determinado estado;
      • Dentro de cada fase, são realizadas iterações . Uma iteração é equivalente a um “mini-projeto”;
      Fases e Iterações do RUP
      • Iniciação : o foco é chegar a um acordo com os stakeholders quanto à visão do sistema e aos objetivos e estimativas das demais fases do ciclo/projeto;
      • Elaboração : esta fase é um processo de engenharia, onde o foco está em especificar uma arquitetura robusta e confiável para o sistema e fazer o planejamento para o restante do ciclo/projeto;
      • Construção : a fase de construção basicamente consiste num processo de manufatura, onde o foco está na construção do sistema e no gerenciamento dos recursos e otimização de tempo, custos e qualidade;
      • Transição : o objetivo desta fase é transferir o produto para a comunidade de usuários. Pode ser apenas uma release do produto, e não o produto final.
      Fases
    • Fases
      • Os processos são procedimentos compostos de atividades logicamente seqüenciadas e têm objetivos específicos em relação ao projeto;
      • O RUP possui 6 processos de engenharia e 3 processos de suporte, também chamados de disciplinas ;
      As Disciplinas do RUP
      • Engenharia:
      • – Modelagem de Negócio : foca no entendimento do negócio ser automatizado pelo software;
      • – Requisitos : foca no entendimento dos requisitos do software;
      • – Análise e Design : análise dos requisitos e projeto ( design ) do software;
      • – Implementação : codificação dos componentes;
      • – Teste : avaliação do sistema em relação aos requisitos;
      • – Implantação : entrega do software;
      • Suporte:
      • – Gerenciamento de Projeto ;
      • – Gerenciamento de Configurações e Mudanças ;
      • – Ambiente : preparação do ambiente para desenvolvimento do projeto;
      As Disciplinas do RUP
      • Quando o projeto amadurece, a ênfase em certas atividades das disciplinas aumenta ou diminui;
      • As atividades podem ser executadas qualquer tempo durante o ciclo de vida do projeto;
      As Disciplinas do RUP
    • As Disciplinas do RUP
    • As Disciplinas do RUP