Engenharia De Software

35,276 views

Published on

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

Published in: Technology
2 Comments
14 Likes
Statistics
Notes
No Downloads
Views
Total views
35,276
On SlideShare
0
From Embeds
0
Number of Embeds
152
Actions
Shares
0
Downloads
1,194
Comments
2
Likes
14
Embeds 0
No embeds

No notes for slide

Engenharia De Software

  1. 1. Engenharia de Software
  2. 2. Tópicos – Engenharia de Software <ul><li>O que é? </li></ul><ul><li>Camadas </li></ul><ul><li>Perguntas que devem ser respondidas </li></ul><ul><li>Fases genéricas da Engenharia de Software </li></ul><ul><li>Modelos de Processos de Engenharia de Software </li></ul><ul><li>Modelos de Processos de Desenvolvimento de Software </li></ul><ul><li>RUP - ( Rational Unified Process ) </li></ul>
  3. 3. O que é Engenharia de Software? <ul><li>É um conceito que está baseado em camadas: </li></ul><ul><li>Qualidade: Toda engenharia deve se fundamentar no comprometimento com a qualidade; </li></ul><ul><li>Processo: É a base da engenharia de software. É o processo que “cola” as ferramentas e os métodos; </li></ul><ul><li>Métodos: Fornecem a definição do “como fazer” o desenvolvimento de software; </li></ul><ul><li>Ferramentas: Realizam o suporte automatizado ou semi-automatizado para os processos e métodos (exemplo: ferramentas CASE); </li></ul>
  4. 4. Camadas de Engenharia de Software Foco em Qualidade Processos Métodos Ferramentas
  5. 5. Perguntas que devem ser respondidas <ul><li>Qual é o problema a ser resolvido? </li></ul><ul><li>Quais características do software a ser gerado resolvem o problema? </li></ul><ul><li>Como o software (a solução) serão concebidos? </li></ul><ul><li>Como o software será construído? </li></ul><ul><li>Qual a abordagem que será utilizada para cobrir erros feitos no projeto e construção do software? </li></ul><ul><li>Como o software será mantido a longo prazo, quando correções, adaptações e melhorias forem requeridas por usuários do software? </li></ul>
  6. 6. Fases Genéricas da Engenharia de Software
  7. 7. Modelos de Processos de Engenharia de Software <ul><li>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; </li></ul><ul><li>Esta estratégia é o modelo de processo ou paradigma de engenharia de software; </li></ul><ul><li>É escolhido baseado na natureza do projeto e aplicação, nos métodos e ferramentas a serem utilizados e nos controles e entregas requeridos; </li></ul><ul><li>Os modelos definem ordem para uma atividade inerentemente caótica ; </li></ul>
  8. 8. Modelos de Processos de Desenvolvimento de Software <ul><li>Modelo Linear Seqüencial </li></ul><ul><li>Modelo de Prototipação </li></ul><ul><li>Modelos Evolucionários </li></ul><ul><li>- Incremental </li></ul><ul><li>- Espiral </li></ul><ul><li>RUP – Rational Unified Process </li></ul><ul><li>Atividades de suporte : independentes do modelo de </li></ul><ul><li>processo </li></ul><ul><li>- Garantia de Qualidade de Software </li></ul><ul><li>- Gerenciamento da Configuração do Software </li></ul><ul><li>- Mensuração de Software </li></ul>
  9. 9. Modelo Linear Seqüencial <ul><li>Também chamado de “ciclo de vida clássico” e “modelo cascata”; </li></ul><ul><li>Sugere uma abordagem seqüencial para o desenvolvimento de software; </li></ul>Análise Projeto (Design) Codificação Testes Engenharia do Sistema / Informação
  10. 10. <ul><li>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; </li></ul><ul><li>Análise: Intensificação do levantamento de requisitos, agora focado no software. Define domínio de informação, funcionalidade, comportamento, performance e interface; </li></ul><ul><li>Projeto ( design ): Traduz os requerimentos para uma representação técnica; </li></ul><ul><li>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; </li></ul><ul><li>Teste: Teste do programa codificado. Pode ser da lógica interna do software ou focado nas funcionalidades externas; </li></ul><ul><li>Suporte: Corrige e adapta o software gerado. Reaplica as fases precedentes no programa existente. </li></ul>Modelo Linear Seqüencial
  11. 11. Modelo Linear Seqüencial <ul><li>É o mais antigo paradigma de engenharia de software; </li></ul><ul><li>Problemas do modelo linear seqüencial: </li></ul><ul><li>Projetos reais raramente seguem a ordem seqüencial proposta e mudanças nesta seqüência podem causar confusão na equipe de projeto; </li></ul><ul><li>É 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; </li></ul><ul><li>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; </li></ul>
  12. 12. Modelo de Prototipação <ul><li>Permite que o cliente “perceba” o software que está sendo gerado antes da finalização; </li></ul><ul><li>Atividades do modelo: </li></ul><ul><li>Definição de requisitos; </li></ul><ul><li>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 ; </li></ul><ul><li>Avaliação do Protótipo: o usuário avalia o protótipo e refina os requisitos; </li></ul><ul><li>Natureza iterativa: as atividades se repetem até que o software fique pronto; </li></ul>
  13. 13. Modelo de Prototipação
  14. 14. <ul><li>Problemas: </li></ul><ul><li>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; </li></ul><ul><li>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; </li></ul><ul><li>“ Software nunca está pronto”... </li></ul>Modelo de Prototipação
  15. 15. <ul><li>A natureza evolucionária do software não é considerada explicitamente nem no modelo linear seqüencial, nem no modelo de prototipação; </li></ul><ul><li>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; </li></ul><ul><li>Veremos dois tipos de modelos evolucionários: </li></ul><ul><li>- Incremental </li></ul><ul><li>- Espiral </li></ul>Modelos Evolucionários
  16. 16. <ul><li>O modelo incremental combina elementos do modelo linear seqüencial (aplicado repetidamente) com a filosofia iterativa da prototipação; </li></ul><ul><li>Cada seqüência linear produz um “incremento” entregável ( deliverable ) do software; </li></ul><ul><li>Exemplo de um processador de texto: </li></ul><ul><li>– Primeiro entregar funções básicas de manipulação de arquivo; </li></ul><ul><li>– Depois, entregar funcionalidades de edição e produção de documentos mais avançadas; </li></ul><ul><li>– No terceiro incremento, entregar verificação de grafia e gramática; </li></ul><ul><li>– ... </li></ul>Modelo Incremental
  17. 17. <ul><li>A cada incremento, o usuário pode utilizar o produto gerado ou fazer uma revisão detalhada; </li></ul><ul><li>O próximo incremento deve implementar as solicitações do usuário, mais as novas funcionalidades planejadas; </li></ul><ul><li>O processo é repetido até que o produto completo é entregue; </li></ul>Modelo Incremental
  18. 18. Modelo Incremental <ul><li>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; </li></ul>
  19. 19. <ul><li>É um modelo que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo linear seqüencial; </li></ul><ul><li>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; </li></ul>Modelo Espiral
  20. 20. Modelo Espiral <ul><li>O modelo espiral é dividido em um número de atividades, chamadas regiões de tarefas. Tipicamente, existem de 3 a 6 regiões; </li></ul>
  21. 21. <ul><li>Comunicação com cliente: tarefas requeridas para estabelecer comunicação efetiva entre desenvolvedor e cliente; </li></ul><ul><li>Planejamento: tarefas requeridas para definir recursos, tempos de tarefas e outras atividades de planejamento; </li></ul><ul><li>Análise de Risco: tarefas requeridas para avaliar riscos técnicos e de gerenciamento; </li></ul><ul><li>Engenharia: tarefas requeridas para construir um ou mais representações da aplicação; </li></ul><ul><li>Construção e Entrega: tarefas requeridas para construir, testar, instalar, e prover suporte ao usuário; </li></ul><ul><li>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; </li></ul>Modelo Espiral
  22. 22. <ul><li>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; </li></ul><ul><li>Quando o processo inicia, a equipe de desenvolvimento se move na espiral em sentido horário, iniciando no centro: </li></ul><ul><li>- O primeiro circuito resulta no desenvolvimento da especificação; </li></ul><ul><li>- O subseqüente, pode ser usado para desenvolvimento do protótipo; </li></ul><ul><li>- 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); </li></ul>Modelo Espiral
  23. 23. <ul><li>Não termina quando o software é entregue: pode ser adaptado a todo o ciclo de vida do software; </li></ul><ul><li>“ 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; </li></ul>Modelo Espiral
  24. 24. <ul><li>Projeto de Desenvolvimento de Conceito: inicia no centro da espiral e continua na espiral até que esteja completo (área mais escura); </li></ul><ul><li>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; </li></ul><ul><li>Em essência, se a espiral for vista dessa forma, ela continua até que o software é retirado de uso; </li></ul><ul><li>Problemas: </li></ul><ul><li>- Pode ser difícil convencer os clientes de que a abordagem evolucionária é controlável; </li></ul><ul><li>- 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; </li></ul>Modelo Espiral
  25. 25. <ul><li>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; </li></ul><ul><li>A comunidade de software precisava de um processo que: </li></ul><ul><li>- Provesse um guia para a ordem das atividades da equipe do projeto; </li></ul><ul><li>- Direcionasse as tarefas dos desenvolvedores e da equipe como um todo; </li></ul><ul><li>- Especificasse quais os artefatos que devem ser desenvolvidos; </li></ul><ul><li>- Oferecesse critérios para monitoramento e medida dos produtos </li></ul><ul><li>atividades de um projeto; </li></ul>RUP - ( Rational Unified Process )
  26. 26. <ul><li>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); </li></ul><ul><li>É baseado em componentes: o sistema de software sendo desenvolvido é feito de componentes de software interconectados via interfaces bem definidas; </li></ul><ul><li>Utiliza a UML ( Unified Modeling Language ) </li></ul>RUP - ( Rational Unified Process )
  27. 27. <ul><li>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; </li></ul><ul><li>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 ; </li></ul><ul><li>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; </li></ul>Características Fundamentais
  28. 28. <ul><li>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; </li></ul><ul><li>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; </li></ul>Iterações
  29. 29. <ul><li>A iteração controlada reduz o custo do risco às despesas de um único incremento, e não do produto pronto; </li></ul><ul><li>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; </li></ul><ul><li>Acelera o tempo de desenvolvimento porque trabalha com tarefas mais curtas e focadas; </li></ul><ul><li>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. </li></ul>Benefícios das Iterações
  30. 30. <ul><li>Segundo o RUP, um produto de software deve ter: </li></ul><ul><li>Um modelo de casos de uso com todos os casos de uso e seus relacionamentos com usuários; </li></ul><ul><li>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; </li></ul><ul><li>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; </li></ul><ul><li>Um modelo de implementação , que inclui componentes (representando código fonte), e mapeando as classes para os componentes; </li></ul><ul><li>Um modelo de implantação ( deployment ), que define os nós físicos dos computadores e os mapeamentos dos componentes para estes nós; </li></ul><ul><li>Um modelo de testes , que descreve os casos de teste e verifica os casos de uso; </li></ul><ul><li>E uma representação da arquitetura ; </li></ul>O Produto de Software do RUP
  31. 31. O Produto de Software do RUP
  32. 32. <ul><li>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; </li></ul><ul><li>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; </li></ul>O Ciclo de Vida do RUP
  33. 33. O Ciclo de Vida do RUP
  34. 34. <ul><li>Uma fase termina com um marco ( milestone ), que é definido pela disponibilidade de certos artefatos (modelos ou documentos) em um determinado estado; </li></ul><ul><li>Dentro de cada fase, são realizadas iterações . Uma iteração é equivalente a um “mini-projeto”; </li></ul>Fases e Iterações do RUP
  35. 35. <ul><li>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; </li></ul><ul><li>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; </li></ul><ul><li>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; </li></ul><ul><li>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. </li></ul>Fases
  36. 36. Fases
  37. 37. <ul><li>Os processos são procedimentos compostos de atividades logicamente seqüenciadas e têm objetivos específicos em relação ao projeto; </li></ul><ul><li>O RUP possui 6 processos de engenharia e 3 processos de suporte, também chamados de disciplinas ; </li></ul>As Disciplinas do RUP
  38. 38. <ul><li>Engenharia: </li></ul><ul><li>– Modelagem de Negócio : foca no entendimento do negócio ser automatizado pelo software; </li></ul><ul><li>– Requisitos : foca no entendimento dos requisitos do software; </li></ul><ul><li>– Análise e Design : análise dos requisitos e projeto ( design ) do software; </li></ul><ul><li>– Implementação : codificação dos componentes; </li></ul><ul><li>– Teste : avaliação do sistema em relação aos requisitos; </li></ul><ul><li>– Implantação : entrega do software; </li></ul><ul><li>Suporte: </li></ul><ul><li>– Gerenciamento de Projeto ; </li></ul><ul><li>– Gerenciamento de Configurações e Mudanças ; </li></ul><ul><li>– Ambiente : preparação do ambiente para desenvolvimento do projeto; </li></ul>As Disciplinas do RUP
  39. 39. <ul><li>Quando o projeto amadurece, a ênfase em certas atividades das disciplinas aumenta ou diminui; </li></ul><ul><li>As atividades podem ser executadas qualquer tempo durante o ciclo de vida do projeto; </li></ul>As Disciplinas do RUP
  40. 40. As Disciplinas do RUP
  41. 41. As Disciplinas do RUP

×