Desenvolvimento de Projetos Aula 1.3 Modelos de Processo Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br
Tipos de Modelos Modelo em Cascata; Prototipação; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento Espiral; Baseado em Componentes; 2
Modelo Incremental Divide o desenvolvimento em partes (incrementos); As funcionalidades do sistema são desenvolvidas de acordo com as prioridades; Cada incremento passa por um processo de confirmação de requisitos; Depois da confirmação dos requisitos, o incremento é desenvolvido como no processo em cascata: Análise, projeto, implementação, teste e operação. 3
Modelo Incremental Visão geral: O cliente identifica as funcionalidades a serem desenvolvidas e determina as prioridades; Define-se um número de incrementos a serem entregues; Cada incremento fornece os serviços estabelecidos na ordem de prioridade. 4
Modelo Incremental A análise de requisitos sempre é realizada para os próximos incrementos; Não são aceitas mudanças de requisitos para o incremento corrente; Depois que o incremento é concluído e entregue, o cliente pode colocá-lo em operação; Ou seja, parte do sistema é entregue com antecedência. 5
Modelo Incremental O cliente experimenta o sistema com os incrementos entregues Isso ajuda a conhecer os requisitos dos incrementos posteriores; A medida que novos incrementos do sistema são concluídos, eles são integrados aos incrementos já existentes A funcionalidade geral do sistema é aprimorada a cada incremento. 6
Modelo Incremental Vantagens Os clientes não precisam esperar o sistema inteiro; Os requisitos mais críticos são satisfeitos no primeiro incremento; Risco menor de falhas; Desvantagem Os incrementos devem ser relativamente pequenos e devem entregar alguma funcionalidade do sistema É difícil fazer esse mapeamento. 7
Tipos de Modelos Modelo em Cascata; Prototipação; RAD; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento Espiral; Baseado em Componentes; 8
Evolucionário É feita uma implementação inicial e apresentada ao cliente/usuário Baseado nessa apresentação, o projeto é refinado para passos posteriores; As atividades de desenvolvimento, especificação e validação são intercaladas; 9
Evolucionário Vantagens A especificação de requisitos pode ser feita de forma incremental; A medida que usuários compreendem melhor seu sistema, que contribuem mais Feedback rápido; É flexível quanto às alterações do cliente; 10
Evolucionário Desvantagens O processo não é visível para os gerentes Como o sistema é desenvolvido rapidamente, não é viável produzir documentos que refletem cada versão A documentação é o meio que gerente mede o desenvolvimento; Os sistemas são frequentemente mal estruturados A mudança contínua tende a corromper a estrutura do software; A incorporação de mudanças torna-se cada vez mais onerosa. 11
Evolucionário Definição do esboço Especificação Versão inicial Desenvolvimento Versões Versões Versões intermediárias intermediárias intermediárias Validação Versão final 12
Tipos de Modelos Modelo em Cascata; Prototipação; RAD; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento Espiral; Baseado em Componentes; 13
Espiral O processo é representado como uma espiral; Cada loop da espiral representa uma fase do processo. Por exemplo: 1o loop: viabilidade do sistema (mais interno); 2o loop: definição de requisitos; 3o loop: projeto do sistema; Dentro do desenvolvimento em espiral, pode-se adotar outro processo Por isso, ele é considerado um metamodelo; 14
Espiral Fonte: Sommerville, 8a edição 15
Espiral Setores da espiral Fonte: Sommerville, 8a edição 16
Espiral Os objetivos da fase de projeto são definidos As restrições sobre o processo e o produto são identificadas É elaborado um plano detalhado de gerenciamento Fonte: Sommerville, 8a edição 17
Espiral Para cada risco identificado, uma ação é analisada Providências são tomadas para reduzir o risco Por exemplo, se houver risco de que os requisitos não sejam apropriados, um prototipo do sistema poderá ser desenvolvido Fonte: Sommerville, 8a edição 18
Espiral Para cada risco identificado, uma ação é analisada Providências são tomadas para reduzir o risco Essa é a principal vantagem do desenvolvimento em espiral Fonte: Sommerville, 8a edição 19
Espiral Após a avaliação do risco, um modelo de desenvolvimento é selecionado Por exemplo, se os riscos da interface com o usuário forem dominantes, pode-se adotar a prototipação evolucionária Por exemplo, se o principal risco for a integração de sistemas, pode-se adotar o modelo cascata. Fonte: Sommerville, 8a edição 20
Espiral O projeto é revisado e uma decisão é tomada para prosseguimento ao próximo loop da espiral Se a decisão for pelo prosseguimento, serão elaborados planos para a próxima fase do projeto Fonte: Sommerville, 8a edição 21
Tipos de Modelos Modelo em Cascata; Prototipação; RAD; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento Espiral; Baseado em Componentes; 22
Baseado em Componentes Se baseia na divisão do sistema em unidades menores Mini-sistemas; Isso é feito para diminuir sua complexidade; O modelo baseia-se na seleção de componentes e no desenvolvimento de partes não atendidas por esses componentes Com o objetivo de readaptá-los; 23
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema 24
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema Estes estágios são comparáveis aos de outros processos. 25
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema É feita uma busca por componentes capazes de implementar a especificação de requisitos 26
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema Requisitos são modificados para corresponder a componentes disponíveis. 27
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema Quando as modificações são impossíveis, a atividade de análise de componentes pode ser novamente realizada para procurar soluções disponíveis. 28
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema O framework é projetado ou é reutilizado um framework existente. 29
Baseado em Componentes É inerente ao reuso Depende de uma grande base de componentes e de algum framework capaz de integrá-los Especificação de requisitos Análise de Componentes Projeto de sistema com reuso Modificação de Requisitos Desenvolvimento e Integração Validação de Sistema O software é então desenvolvido com os componentes sendo integrados 30
Baseado em Componentes Vantagens Reduz a quantidade de software a ser desenvolvido Reduz custos e riscos Entrega mais rápida Desvantagens Alguns requisitos podem não ser cobertos 31
Problemas com Processos Independentemente do processo utilizados, problemas de gerência podem existir; Existem diversas abordagens de se resolver esses problemas Adoção de boas práticas de gerenciamento; Adoção de processos ágeis Na aula que vem estudaremos processos ágeis!!! 32
Problemas com Processos Modelos de processos foram criados com o objetivo de sistematizar o desenvolvimento de softwares complexos Produto de larga escala Muitas pessoas trabalhando (e geograficamente distribuídas); A engenharia convencional pode nos ensinar técnicas, métricas, padrões e metodologias, mas, aplicadas na íntegras, não tiveram o sucesso esperado na indústria de software Embora na indústria de hardware seja positivo. 33
Curva de Falhas do HW Curva de desgaste de um hardware Curva da banheira 34
Curva de Falhas do SW Curva de desgaste de um software 35
Características dos SW A maioria é feita sob medida em vez de ser montada a partir de componentes existentes 36
Características dos SW Fazem uso de sistemas legados: sem documentação e nem planejamento. 37
Características dos SW Possui diferentes níveis de complexidade: Software básico: coleção de programas escritos para dar apoio a outros programas; Software em tempo real: monitora, analisa e controla eventos do mundo real; Software científico e de engenharia: caracterizado por algoritmos de processamento de números Software comercial ou empresarial: permite tomadas de decisões administrativas 38
Características dos SW Possui diferentes níveis de complexidade: Software embarcado: usado para controlar produtos e sistemas para os mercados industriais e de consumo Software de computador pessoal: envolve processamento de textos, planilhas eletrônicas, diversões, etc Software de inteligência artificial: faz uso de algoritmos complexos que são capazes de aprender com o contexto 39
Características dos SW É maleável Permite que o software seja modificável; Um software pode, e muitas vezes precisa, ser modificado Ao contrário de um prédio, uma ponte ou um avião; 40
Características dos SW Criatividade humana Pessoas constroem software; Sem a criatividade, sem pensamento de pessoas, não se faz software; Portanto é importante criar um ambiente onde as pessoas sejam produtivas. 41
Características dos SW Difícil acompanhamento do desenvolvimento 42
Características dos SW A Engenharia de Software tem o objetivo de desenvolver softwares respeitando essas características. O termo surgiu a partir de um momento histórico em que observou-se a necessidade de criação de técnicas, métodos e ferramentas para indústria de SW. 43
Evolução do Software Atual 1995 1975 1965 1950 44
Evolução do Software Atual 1995 1975 1965 1950 O hardware sofreu contínuas mudanças; O software era uma arte "secundária" Poucos métodos sistemáticos; O hardware era de propósito geral; O software era específico para cada aplicação; Não havia documentação; 45
Evolução do Software Atual Cresce o número de sistemas baseados em computador 1995 1975 1965 1950 Multiprogramação e sistemas multiusuários; Técnicas interativas; Sistemas de tempo real 1a geração de SGBD s; Bibliotecas de Software 46
Evolução do Software Atual Cresce o número de sistemas baseados em computador 1995 Crise do software! 1975 1965 1950 Multiprogramação e sistemas multiusuários; Técnicas interativas; Sistemas de tempo real 1a geração de SGBD s; Bibliotecas de Software 47
A Crise do Software Projetos importantes tinham anos de atraso; Custo dos softwares superavam previsões e ainda assim softwares não eram confiáveis; Softwares eram de difícil manutenabilidade; Desempenho dos softwares era insatisfatório; Os custos de hardware caíam enquanto os de software aumentavam rapidamente 48
A Crise do Software [1968] Conferência da OTAN sobre Engenharia de Software em 1968 Nascimento da Engenharia de Software 49
A Crise do Software Refere-se a um conjunto de problemas encontrados no desenvolvimento de software e na etapa de Manutenção 50
A Crise do Software 51
A Crise do Software Problema 1: estimativas de prazo e custos imprecisas; Problema 2: insatisfação do cliente; Problema 3: qualidade baixa do produto entregue; Problema 4: produto resultante é de difícil manutenção. 52
Motivação Novas técnicas eram necessárias Sistemas mais complexos; Hardwares cada vez mais potentes; Novas tecnologias de comunicação; Complexas interfaces com usuário. 53
Resultado Não existe uma abordagem ideal de ES; Precisamos da essência da Engenharia de Software: Definir noções fundamentais de processo e de organização de sistemas Processos de software; Métodos de ES; Ferramentas de ES. 54
A aplicação de uma abordagem sistemática, disciplinada e possível de ser medida para o desenvolvimento, operação e manutenção do software (IEEE) 55
ATENÇÃO Prova na semana que vem: 20/10; Conteúdo da prova: Introdução a Engenharia de Software; Modelos de Processo; Crise do Software; 56