Aula2 paradigmas
- 1. ENGENHARIA DE SOFTWARE RESUMO DA AULA ANTERIOR
- 2. Definicao de Engenharia de software estabelecimento e uso de sólidos princípios de engenharia para: Minimizar custos de desenvolvimento de software; Software confiável; Software eficientemente; Organizacao; Produtividade; e Software de qualidade
- 3. Etapas da Eng. Software Métodos Como fazer Ferramentas Apoio automatizado –CASE Tools Procedimentos Definem a sequência em que os métodos são aplicados.
- 4. Ciclo de Vida clássico da ES Definição de Requisitos Análise Desenho Implementação Teste Manutenção
- 5. Processo de Desenvolvimento Definição (O quê?)- Analise e Planeamento: o que será desenvolvido Desenvolvimento (Como?)- Desenho, Codificacao e Teste: como será desenvolvido Manutenção (Mudanças?)- Correcao, adaptacao e perfeicao: que mudanças ocorrerão depois
- 6. PARADIGMAS DA ENG. DE SOFTWARE Definição, Caracterização, Vantagens e Desvantagens.
- 7. Paradigmas de Eng. de Software Incremental RAD Iterativo Formal Estruturado Modelos de Ciclo de Lógico Vida de Software Espiral Evolutivo OO Combinação de Paradigmas Técnicas de Quarta Geração
- 8. Paradigmas de Eng. de Software: Escolha da Estrategia de deve considerar: Natureza do projecto; Tipo da aplicação; Métodos e ferramentas que serão usados; Métodos de controle; Prazo de entrega; Produtos que serão entregues.
- 9. Incremental Requisitos Projecto Requisitos em da superficiais incrementos arquitetura Desenvolv. Validação Integração Validação incremento incremento incremento do Sistema sistema completo Sistema incompleto
- 10. Incremental Desenvolvimento através de incrementos sucessivas do âmbito do sistema; O sistema é alargado progressivamente; Ao invés de entregar o sistema completo, divide-se o sistema em partes de tal forma a cada entrega corresponder a alguma funcionalidade do sistema; Requisitos do usuário são priorizados e quanto maior a prioridade, mais cedo tal funcionalidade deve ser entregue; Uma vez que o desenvolvimento de um incremento seja iniciado, esses requisitos são fixados enquanto que os posteriores são deixados serem modificados;
- 11. Incremental - Vantagens Esta abordagem é útil para Problemas complexos; Recursos humanos insuficientes; Datas de entrega inflexíveis.
- 12. Incremental - Vantagens Solicitações dos clientes são entregues a cada incremento. Assim, as funcionalidades são entregues o mais cedo possível Incrementos iniciais servem de protótipo para obter requisitos para incrementos posteriores Diminuição do risco de falha de todo o projeto Serviços de maior prioridade tendem a receber maior ênfase em testes
- 13. Rapid Application Development (RAD) É um modelo de processo de desenvolvimento de software iterativo e incremental; O ciclo de desenvolvimento é curto (entre 60 e 90 dias).
- 14. Rapid Application Development (RAD) Equipa 1 Equipa 2 Equipa 3 Modelado Modelado Modelado Modelado Modelado Modelado Da gestão Da gestão Da gestão Da gestão Da gestão Da gestão Modelado Modelado Modelado Modelado Modelado Dos dados Dos dados Modelado Dos dados Dos dados Dos dados Dos dados Modelado Modelado Dos Dos Modelado Modelado processos Modelado Modelado processos Dos Dos Dos Dos processos processos Geração de Geração de processos processos Aplicações Aplicações Geração de Geração de Geração de Geração de Aplicações Aplicações Testes e Testes e Aplicações Aplicações entrega entrega Testes e Testes e Testes e Testes e entrega entrega entrega entrega
- 15. RAD - Vantagens Permite o desenvolvimento rápido e/ou a prototipagem de aplicações; Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias); Cada função principal pode ser direcionada para uma equipe RAD separada e então integrada a formar um todo; Criação e reutilização de componentes; Visibilidade mais cedo (protótipos) Maior flexibilidade (desenvolvedores podem experimentar praticamente a vontade) Grande redução de codificação manual (wizards...); Envolvimento maior do usuário; Provável custo reduzido (tempo é dinheiro e também devido ao reuso);
- 16. RAD - Desvantagens Se uma aplicação não puder ser modularizada de modo que cada função principal seja completada em menos de 3 meses, não é aconselhável o uso do RAD; Para projectos grandes (mas escaláveis) o RAD exige recursos humanos suficientes para criar o número correcto de equipes, isso implica em um alto custo com a equipe; O envolvimento com o usuário tem que ser activo; Comprometimento da equipe do projecto;
- 17. RAD - Desvantagens O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada quando se está testando novas tecnologias; Menos eficientes; Perda de precisão científica (falta de métodos formais); Funções reduzidas (reuso, "timeboxing"); Problemas legais; Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes) Sucessos anteriores são difíceis de se reproduzir.
- 18. O RAD é apropriado quando A aplicação é do tipo "standalone"; A performance não é o mais importante; A distribuição do produto é pequena; O escopo do projecto é restrito; O sistema pode ser dividido em vários módulos independentes; A tecnologia necessária tem mais de um ano de existência.
- 19. O RAD deve ser evitado quando A aplicação precisa interagir com outros programas; Performance é essencial; O desenvolvimento não pode tirar vantagem de ferramentas de alto nível; A distribuição do produto será em grande escala; Para se construir sistemas operacionais (confiabilidade exigida alta demais) Jogos de computador (performance exigida muito alta) Riscos tecnológicos muito altos devido a tecnologia ter sido recém lançada; O sistema não pode ser modularizado.
- 20. Iterativo Aplicação do modelo cascata iterativamente; As iterações iniciais atacam os maiores riscos;
- 21. Iterativo Os requisitos do sistema SEMPRE mudam durante o desenvolvimento Iteração pode ser aplicado a qualquer um dos processos de desenvolvimento Duas abordagens são destacadas: Desenvolvimento incremental Desenvolvimento em espiral.
- 22. Iterativo Desenvolvimento iterativo antecipa a redução de riscos; Testes e integração são realizados desde o início, de forma contínua; Riscos críticos são resolvidos antes que grandes investimentos sejam realizados; Permite feedback dos usuários desde cedo; Pequenos objectivos, foco em curto- prazo; Progresso é medido de forma mais concreta; Implementações parciais podem ser implantadas;
- 23. Formal Definição de Especificação requisitos formal Transformação formal Integração e testes
- 24. Formal Métodos formais Especificação matemática Exacta e rigorosa Detecta e corrige requisitos incompletos, ambíguos e inconsistentes
- 25. Formal Desvantagens Necessita de profissionais altamente qualificados para aplicar a técnica Alguns aspectos ainda são difíceis de especificar (GUI) Vantagens Garantia de segurança e confiabilidade Aplicações Sistemas críticos e complexos
- 26. Cascata Várias actividades executadas de forma sistemática e sequencial
- 27. Cascata Um dos mais antigos, e ainda um dos mais usados! Várias actividades executadas deforma sistemática e sequencial; Fixa pontos específicos para a entrega de artefactos; É simples e fácil de aplicar, facilitando o planeamento; Na prática, existe uma interacção entre as atividades e cada atividade pode levar a modificações nas anteriores; Pressupõe que os requisitos ficarão estáveis; Atrasa a redução de riscos.
- 28. Cascata - Vantagens Padroniza os métodos para análise, projecto, codificação, testes e manutenção. Etapas semelhantes às etapas genéricas aplicáveis a todos os paradigmas; Orientado a documentação; Manutenção é mais simples.
- 29. Cascata - Desvantagens Projectos reais raramente seguem o fluxo sequencial que esse modelo propõe. Sempre ocorre alguma interacção e/ou superposição; Dificilmente os clientes são capazes de relacionar todos os requisitos de uma só vez no início do projecto; Maioria dos programas só estará disponível quando o cronograma já está bastante adiantado; Dificuldades para se introduzir alterações quando o processo está avançado; Dificuldade para lidar com as mudanças nos requisitos do sistema Não gere riscos
- 30. Espiral
- 31. Espiral Análise de riscos como ferramenta; Essencial para o planeamento e gestão do projecto; Dificuldades para fechar o contrato; Complexo e requer experiência na avaliação de riscos!
- 32. Espiral - Vantagens Modelo evolutivo possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do sistema. Permite que o projectista e cliente possa entender e reagir aos riscos em cada etapa evolutiva. Fácil de decidir o quando testar
- 33. Espiral - Desvantagens Avaliação dos riscos exige muita experiência; O modelo é relativamente novo e não tem sido amplamente utilizado; Bem aplicado somente a sistemas de larga escala; Sistemas devem ser produtos internos da empresa.
- 34. 4ª Geração Ferramentas de 4ª Geração Suporte automatizado à especificação de requisitos. A ferramenta gera codigo-fonte, na base da especificação do desenvolvedor;
- 35. Combinação de Paradigmas Os paradigmas para a Engenharia de Software alcancam melhores resultados quando combinadas. Exemplo: Espiral resulta da combinacao entre a Prototipacao e cascata numa abordagem revolucionaria.
- 36. Evolutivo Atividades concorrentes Versão Especificação inicial Descrição Versões Desenvolvimento intermediárias superficial Versão Validação final
- 37. Evolutivo Desenvolvimento exploratório (Protótipo evolucionário) Construa, avalie e evolua para produto Trabalhar com os clientes até se obter o produto final a partir de uma especificação bem-definida e completa do sistema. Protótipo descartável Construa, use e descarte Obter requisitos do cliente. Inicia-se com uma especificação incompleta e simples do sistema
- 38. Estruturado
- 39. Orientado a Objectos Métodos OO são voltados principalmente para sistemas complexos, que devem ser divididos para a distribuição dos trabalhos pela equipe; A abordagem OO se baseia em um desenvolvimento onde fases teoricamente já completadas são revistas continuamente, e alteradas se preciso; Iterativo e incremental.
- 40. Orientado a Objectos paralelo (reutilização de componentes) Análise de Riscos Identificar classes candidatas Engenharia buscar classes na biblioteca e Construção extrair classes, se existem desenvolver novas classes, se não existem adicionar novas classes recursivo à biblioteca (modelo evolutivo) construir n-ésima iteração do sistema Baseado em componentes Unified Development Process Utiliza UML
- 41. Selecção do Modelo Projectos pequenos: ciclo clássico Limites severos de tempo: RAD Data entrega muito próxima: modelo incremental. Sistemas Complexos com muitas mudanças de Requisitos: Orientadas a Objectos;
- 42. BIBLIOGRAFIA Gerry Coleman and Renaat Verbruggen. A quality software process for rapid application development, Software Quality Journal 7, pp. 107-122, 1998. Software Engineering. I.Sommerville; Engenharia de Software, Roger S. Pressman, 3.ª Edição. A Discipline for Software Engineering. W.S.Humphrey; http://pt.wikipedia.org/wiki/Engenharia_de_software, de 9/Fev/2007
- 43. TPC 1. Faca um estudo comparativo dos seguintes paradigmas: a. Evolutivo e Espiral; b. Incremental e Iterativo; c. Estruturada e OO; 2. Para cada uma das situacoes que modelo usaria para desenvolvimento de Software: a. Tempo reduzido (60 dias); b. Sistema complexo, com muitos riscos; c. Sistema com uma dimensão muito reduzida; d. Sistema critico com alta precisão de processamento (logico ou matemático); e. Implementação de um jogo de entretenimento; 3. Para o desenvolvimento de um software para gestao de registos academicos da UST, que com binacao de modelos usaria? Justifique a sua escolha.