MODELOS DE PROCESSOS (PARTE 2) Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Recordando nossas Datas Provas (novas datas): 3ª Prova (1ª chamada): 03/07 2ª Prova (2ª chamada): 05/07 3ª Prova (2ª chamada): 07/07 Trabalhos (continuam as mesmas): Dia 1: 12/07 Dia 2: 14/07 1
Na aula passada... Modelos de Processo Prescritivos: Modelo Cascata Desenvolvimento em Fases Desenvolvimento Incremental Desenvolvimento Iterativo Modelos Evolucionários Prototipação Modelo em Espiral Na aula de hoje Outros Modelos: RAD (Rapid Application Development) Modelos de Processos Especializados: Modelo orientado a Reuso Linhas de Produto de Software Modelo de Métodos Formais Modelo Codificar e Consertar ( Codifica-Remenda ) 2
RAD (Rapid Application Development) Definição: Adaptação do modelo clássico. Modelo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento bastante curto, de 60 a 90 dias. Desenvolvimento por equipes e modular. Fases: 1. Modelagem do Negócio, 2. Modelagem dos Dados, 3. Modelagem do Processo, 4. Geração da Aplicação, 5. Teste e Implantação. RAD (Rapid Application Development) 1. Modelagem do Negócio: São levantados os processos suportados pelo sistema. 2. Modelagem dos Dados: São extraídos os principais objetos de dados a serem processados pelo sistema. 3. Modelagem do Processo: Os objetos de dados são transformados para conseguir o fluxo necessário que implemente uma função do negócio. 4. Geração da Aplicação: Através de reuso de componentes de programa existentes ou criando componentes reusáveis. 5. Teste e Implantação Componentes e interfaces devem ser testados. 3
RAD (Rapid Application Development) RAD (Rapid Application Development) Desvantagens: Para projetos grandes, exige um grande quantidade de recursos humanos para criar um número adequado de equipes. Se desenvolvedores e clientes não estiverem comprometidos com as atividades, os projetos RAD falharão. Se o sistema não puder ser adequadamente modularizado, a construção dos componentes será problemática. O RAD pode não ser adequado quando os riscos técnicos são altos. 4
Apresentam muitas características dos modelos apresentados anteriormente. São utilizados quando uma abordagem de software específica é escolhida. Modelos: Orientado ao Reuso Linhas de Produto de Software Métodos formais Modelo Orientado a Reuso Dependem de uma ampla base de componentes reusáveis de software. Faz amplo uso de sistemas de prateleira (COTS = Commercial off-the-shelf) Sistema de software que pode ser ajustado às necessidades do cliente Código-fonte não é alterável, mas o sistema é configurável Projetado para uso geral: muitos recursos e funções Geralmente, requisitos devem ser adaptados para comportar os COTS Atualizações e manutenções por conta do fornecedor Exemplos: processamento de texto, planilha, SGBD 5
Modelo Orientado a Reuso Estágios intermediários: Etapa 1: Análise de Componentes Etapa 2: Modificação de Requisitos Etapa 3: Projeto do Sistema com Reuso Etapa 4: Desenvolvimento e Integração Modelo Orientado a Reuso Vantagens: Reduz a quantidade de software a ser desenvolvido Reduz custo e riscos Entrega mais rápida do software Desvantagens: Alteração dos requisitos: pode levar à não satisfação dos usuários Controle sobre a evolução é perdido: novas versões dos componentes não estão sob controle da organização. 6
Linhas de Produto de Software Conjunto de aplicações com arquitetura comum e componentes compartilhados. Cada aplicação é especializada de acordo com a necessidade. Alto grau de reuso: código, testes e conhecimento. Núcleo do sistema é projetado para ser configurado e adaptado. Cada novo sistema surge de sistemas já existentes. Pode haver a criação de linha de produtos a partir de uma aplicação base. Exemplo de Linhas de Produto de Software Sistema de Alocação de Recursos: Veículos 7
Linhas de Produto de Software Etapas para criar um novo produto em uma Linha de Produtos: Elicitar requisitos Selecionar o sistema mais próximo dos requisitos Renegociar requisitos Adaptar sistema existente Entregar novo membro da família Modelo de Métodos Formais Engloba atividades que levam à especificação matemática formal do software. Notação matemática rigorosa: Ambiguidade, incompletude e inconsistência podem ser descobertas e facilmente corrigidas. Promessa: software sem defeitos Ideal para softwares críticos: tráfego aéreo, meteorologia, dispositivos médicos etc. 8
Modelo de Métodos Formais A especificação de requisitos é redefinida em um modelo formal detalhado, que é expresso em notação matemática. O processo de desenvolvimento de projeto, implementação e teste são substituídos por um processo de desenvolvimento transformacional, em que a especificação é refinada, por meio de uma série de transformações, em um programa. Modelo de Métodos Formais Mas, é aplicável a tudo? Consome muito tempo e dinheiro. Treinamento extensivo: poucos possuem a formação e a experiência necessária. Modelos não podem ser utilizados para comunicação com os clientes: são muito técnicos. 9
Outros Modelos Modelo Codificar e Consertar (Code-Fix) Também chamado de Codifica-Remenda. Ciclos de codificação e conserto de código: Não exige gerência complexa Nenhuma documentação Muito usado! Qual Modelo eu escolho? Um Modelo de Processo deve ser escolhido com base: 1. Na natureza do projeto e da aplicação 2. Nos métodos e ferramentas a serem utilizados 3. No produto que precisa ser entregue 10
Bibliografia Esta aula foi retirada dos seguintes livros/artigos: PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo, SP: Pearson/ Prentice Hall, 2007. SOMMERVILLE, Ian; OLIVEIRA, Kalinka; BOSNIC, Ivan. Engenharia de Software. 9. ed. São Paulo, SP: Pearson/ Prentice Hall, 2011. PRESSMAN, Roger S. Engenharia de software. 7. ed. São Paulo: McGraw-Hill, 2011. 11