Processos de Desenvolvimento de Software. Prof. Hélio Engholm Jr

Transcrição

1 Processos de Desenvolvimento de Software

2 Objetivos Descrever o processo de desenvolvimento de software Orientado a Objetos (Object Oriented Software Development - OOSD) Descrever como a modelagem suporta o processo OOSD Explicar o propósito, atividades e artefatos do OOSD

3

4 Processo de desenvolvimento de sistemas Orientado a Objetos

5 Processo de desenvolvimento de sistemas Orientado a Objetos

6 Workflows do processo OOSD Levantamento de requisitos Análise dos requisitos Arquitetura Design Implementação/Codificação Testes Implantação

7 Comparação entre paradigmas Habilidade para modificar código Reuso de código Configuração para casos especiais Separação de funcionalidades Procedural e OO Paradigma procedural Softwares difíceis de implementar mudanças Reusabilidade através de copy and past Utilização de if ou switch com muita freqüência Dificuldade de separar funcionalidades Paradigma OO Softwares robustos com facilidade para se implementar mudanças Reusabilidade através de extensão de classes e instanciação de objetos Comportamento polimórfico facilita configuração Código modular facilita a separação de blocos funcionais

8 Envolvidos no OOSD Cliente Desenvolvimento Dono do negócio Gerente do projeto Gerentes Analista de negócios Usuários Arquiteto de software Designer de software Programador Analista de qualidade

9 Levantamento de requisitos

10 Análise

11 Arquitetura

12 Design

13 Construção

14 OOSD como transformação de modelos Desenvolvimento de software pode ser visto como uma série de transformações do modelo mental dos StakeHolders para o sistema

15 Workflow do OOSD

16 Processos de Desenvolvimento de Sistemas

17 Processo Cascata

18 Cascata Requisitos Análise Tempo Design Implementação Testes Sistema completo

19 Características do método Cascata Processo tradicional Uma fase só iniciada quando aanterior estiver 100% completa O processo de desenvolvimento é realizado de uma só vez passando por todas as fases de desenvolvimento Cada fase deve estar completa, documentada antes de se mover para a fase seguinte Se problemas são detectados em fases futuras, é difícil de se retornar para fases anteriores É gasto muito tempo e esforço pela equipe para garantir que as fases estão sendo executadas com 100% de conformidades

20 Fase de Análise O que deve ser feito Requisitos Análise Design Implementação Testes Estabelecer uma visão clara do problema de negócio Verificar as tarefas que o sistema deve contemplar Entender o vocabulário do cliente Levantar os recursos existentes no cliente (plataforma,...) Verificar a melhor solução para o problema de negócio Definir tarefas

21 Fase de Design Como será feito Requisitos Análise Design Implementação Testes Resolver o problema de negócio Verificar elementos de suporte que farão o sistema funcionar Definir uma estratégia para implementação do sistema Produzir todas as especificações do sistema Produzir os casos de teste

22 Processo Unificado Rational Rational Unified Process (RUP)

23 Processos de desenvolvimento de sistemas RUP - Rational Unified Process Iteração 1 Iteração 2 Iteração 3 R D C R D C R D C * * * * * Sistema completo com módulos integrados T T T Módulo 1 Módulo 2 Módulo 3 R - Análise de requisitos D - Projeto C - Código, teste de unidade T - Integração Tempo Procedimentos: Define-se quais funcionalidades serão implementadas em cada iteração Procura-se contemplar as de maior risco primeiro Possibilidade de entrega modular ao cliente

24 Características do processo RUP Grandes projetos são quebrados em vários mini-projetos que possuem seus próprios ciclos de vida Projetos são iterativos e incrementais Incremento Parte do processo de desenvolvimento destinado a contemplar um conjunto de Casos de Uso Iteração Processo executado para contemplar um incremento Cada incremento é construído a partir de resultados anteriores e atualiza e corrige entregas anteriores

25 Características do processo RUP Desenvolver software interativamente Gerenciar os requisitos Usar arquitetura baseada em componentes Modelar visualmente o software Verificar continuamente a qualidade do software Controlar mudanças do software

26 Ciclo de vida Incremental e Iterativo de projetos Em todas as fases de construção devemos: Selecionar e analisar os Casos de Uso relevantes Criar o design utilizando a arquitetura selecioada Implementar o design dos componentes Verificar que os componentes atendem aos Casos de Uso Prosseguir para a próxima iteração quando a atual atender seus objetivos, caso contrário, rever decisões anteriores e tentar outras aproximações

27 Modelagem de Software

28 Benefícios da modelagem de software O início de qualquer sistema começa na idéia de alguém Para realizar uma idéia a equipe de desenvolvimento deve criar uma série de modelos conceituais que transformam a idéia em um sistema

29 O que é um modelo? Modelo é um conceito abstrato de uma entidade ou de um sistema Diferentes vistas mostram um modelo de diferentes perspectivas

30 Por que modelar software? Modelar permite: Visualizar novos sistemas e sistemas existentes Comunicar decisões para Stakeholders do projeto Documentar decisões das fases do workflow OOSD Especificar a estrutura e o comportamento do sistema Gerar código