Your SlideShare is downloading. ×
0
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 2

470

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
470
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Introdução a Engenharia de Software CJR – Empresa Júnior de Computação
  • 2. 2 Processos
  • 3. 2 Relembrando 4 atividades fundamentais no desenvolvimento de software Especificação Desenvolvimento Validação Evolução (requisitos) (modelagem e implementação)Na CJR Diretoria de Diretoria de Tecnologia ? Finanças e Negócios + Equipes de Projetos
  • 4. ! Validação?Atender as especificações dadas pelo cliente! ≠ Verificação
  • 5. 2 E como fazemos na CJR? Especificação Desenvolvimento Validação Evolução (requisitos) (modelagem e implementação) Preparação do Documentação * Ambiente
  • 6. 2 Atividades de Processos Papéis Produtos Responsabilidades das pessoas Artefatos criados ao final da envolvidas. Ex: gerente, atividade. Ex: documento de desenvolvedor, testador requisitos ao fim da especificação Pré e Pós-Condições Como o projeto está antes e depois da atividade. Ex: antes de fazer a arquitetura temos que todos os requisitos foram validados pelo cliente, depois de fazê-la temos que os modelos UML foram revisados.
  • 7. ! Não existe modelo ideal Sistemas Críticos: sistemas os quais empresas são dependentes e uma falha pode gerar perdas econômicas significativas, danos físicos ou ameaças a vida humana. Para Sistemas Críticos é interessante utilizar modelos mais “engessados” que são bastante estruturados Para sistemas empresariais nos quais os requisitos podem mudar constantemente uma abordagem ágil pode ser mais interessante. Empresas normalmente tem um modelo próprio Ter um modelo é importante pois aumenta a produtividade da equipe, diminuindo assim o tempo gasto e consequentemente os custos. A padronização do processos e do código se faz importante pois melhora a possibilidade de reuso e evolução.
  • 8. Atividades do Processo de Software
  • 9. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Visa entender e definir os serviços necessários de um sistema e também os possíveis riscos e problemas do sistema e do desenvolvimento. Normalmente os requisitos se dividirão em duas visões: • Mais alto nível para que seja compreensível aos clientes • Mais baixo nível para que especifique bem o sistema para os desenvolvedores Os erros que ocorrem aqui se propagarão para o resto do projeto todo!
  • 10. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Elicitação e Estudo de análise de Viabilidade requisitos Especificação de requisitos Validação de Requisitos Relatório de Modelos de Viabilidade Sistema Requisitos de Usuário e de Sistema Documento de Requisitos
  • 11. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Elicitação e Estudo de análise de Viabilidade requisitos Especificação de requisitos Validação de Requisitos Relatório de Modelos de Viabilidade Sistema Requisitos de Usuário e de Sistema Documento de Requisitos Verifica se as necessidades do cliente podem ser atendidas com as tecnologias atuais considerando também se é possível fazê-lo dentro do orçamento dado.
  • 12. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Elicitação e Estudo de análise de Viabilidade requisitos Especificação de requisitos Validação de Requisitos Relatório de Modelos de Viabilidade Sistema Requisitos de Usuário e de Sistema Documento de Requisitos Coleta dos requisitos através da observação de sistemas existentes, discussões com usuários potenciais, análise de tarefas, etc...
  • 13. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Elicitação e Estudo de análise de Viabilidade requisitos Especificação de requisitos Validação de Requisitos Relatório de Modelos de Viabilidade Sistema Requisitos de Usuário e de Sistema Documento de Requisitos Traduz o que foi coletado na etapa anterior para um documento de requisitos. Divide os requisitos em de usuário e de sistema.
  • 14. 2 Atividades de Processo de SoftwareEngenharia de Requisitos (ou especificação de software) Elicitação e Estudo de análise de Viabilidade requisitos Especificação de requisitos Validação de Requisitos Relatório de Modelos de Viabilidade Sistema Requisitos de Usuário e de Sistema Documento de Requisitos Verifica os requisitos em reação ao realismos, consistência e abrangência.
  • 15. 2 Atividades de Processo de Software Arquitetura de Software e Implementação Especificação => Arquitetura => Executável
  • 16. 2 Atividades de Processo de Software Arquitetura de Software e Implementação
  • 17. 2 Atividades de Processo de Software Validação e Verificação Teste de Teste de sistema Teste de aceitação componente
  • 18. 2 Atividades de Processo de Software Validação e Verificação
  • 19. 2 Atividades de Processo de Software Evolução de Software Definir requisitos Avaliar sistemas Propor mudanças Modificar do sistema existentes de sistema sistemas Sistemas Novos Sistemas Existentes
  • 20. Mudança É inevitável Evitar mudanças Vai gerar custos e Tolerar mudanças Gera retrabalho
  • 21. Modelos de Processo de Software
  • 22. 2 Modelos Os modelos apresentados aqui são modelos gerais que acabam muitas vezes sendo chamados de Paradigmas de Processos ou Modelos de Ciclo de Vida de Projeto
  • 23. 2 Modelos Devem ser adaptados para o contexto real de uso • Características do projeto • Características da equipe • Características do cliente Exemplos Reuso Incremental Espiral Cascata Prototipação RAD
  • 24. 2 Cascata • Modelo mais antigo e o mais amplamente usado da engenharia de software • Modelado em função do ciclo da engenharia convencional • Requer uma abordagem sistemática, sequencial ao desenvolvimento de software Definição e Análise de Requisitos Projeto de Sistema e Software (Modelagem) Implementação e Teste de Unidade Integração e Teste de Sistema Manutenção
  • 25. 2 Cascata BOM RUIM• Útil quando se tem requisitos estáveis e bem definidos. • Projetos reais raramente seguem o fluxo sequencial que o modelo Ex.: Adicionar um novo dispositivo legal em um sistema de propõe contabilidade • Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural • Versão executável do software só fica disponível numa etapa X avançada do desenvolvimento
  • 26. RUP (Rational Unified Process)
  • 27. 2 RUP UML + Unified Software Development Process Boas práticas de especificação e arquitetura Mistura de vários outros modelos genéricos de software Suporte a prototipação e entrega incremental
  • 28. 2 RUP Baseado em três perspectivas (ao invés de uma visão apenas como nos outros modelos): 1 Dinâmica, fases do modelo ao passar do tempo 2 Estática, atividades de processo estabelecidas 3 Prática, boas práticas a serem utilizadas durante o processo
  • 29. 2 RUP Dividido em quatro fases que, ao contrário de outros modelos, se aproximam mais do negócio do cliente do que da parte técnica.
  • 30. 2 RUP: Dinâmica1. Concepção: construção de casos de uso para que seja possível analisar a viabilidade de projeto. Nesta etapa pode-se fazer também um protótipo para que aprovação do cliente.2. Elaboração: complementação de casos de uso e requisitos, identificação dos riscos. É a fase de elaboração do projeto do sistema (definição de atividades, etc...)3. Construção: desenho do sistema, programação de módulos, testes e integração.4. Transição: entrega do produto, instalação do produto e treinamento.
  • 31. 2 RUP: Estático São seis workflows (ou disciplinas) utilizadas no RUP e mais três delas que são de apoio. Modelagem de Análise e Projeto Requisitos Negócios (design) Implementação Teste Implantação Configuração e Gerência de Apoio Ambiente Gerência de Projeto Mudança
  • 32. 2 RUP: Práticas O RUP define seis boas práticas da engenharia de software: Uso de arquitetura Desenvolvimento de Gerenciamento de baseada em software iterativo requisitos componente Verificação Modelagem visual de Controle de alteração da qualidade do software no software software
  • 33. 2 Apresentação Desenvolvimento Incremental x Iterativo Apresentação (slides) – 20% Modelos cascata e baseado em componentes Apresentação (oral) – 30% Conteúdo – 50% Modelos em espiral e prototipação
  • 34. CJR Empresa Júnior de Computação da UnB Renato Leal contato@cjr.org.br renatodossantosleal@gmail.com renatoleal@cjr.org.brrenatodossantosleal@gmail.com

×