tds-as
Análise de Sistemas - Aula 04 - Processos de Software
Análise de Sistemas – Aula 04: Processos de Software
Professor: Mauro Borges França
Versão acessível: este arquivo apresenta o conteúdo do slide em texto corrido e listas, facilitando a leitura por leitores de tela.
Sumário
- Slide 1: Análise de Sistemas
- Slide 2: Programas de computador; Documentação associada; Configurações.
- Slide 3: Camadas da Engenharia de Software
- Slide 4: Camadas da Engenharia de Software
- Slide 5: Processo é o conjunto de passos, etapas e tarefas que se usa para construir um software.
- Slide 6: Existem diversos modelos de processos de software; Não existe um processo ideal; Existem atividades comuns aos processos de software; Um Processo não é uma prescrição rígida de como desenvolver software, deve ser adaptável conforme as características do projeto.
- Slide 7: Padroniza o desenvolvimento de software; Padronização dos artefatos de software; Melhora a comunicação da equipe; Consequentemente, agrega qualidade ao software.
- Slide 8: O que é um modelo de processo ?
- Slide 9: Processo de Software
- Slide 10: Modelo Cascata (Waterfall)
- Slide 11: Modelo Cascata (Waterfall)
- Slide 12: Modelo Cascata (Waterfall) – Etapas
- Slide 13: Modelo Cascata (Waterfall)
- Slide 14: Modelo Cascata (Waterfall)
- Slide 15: Modelo Cascata (Waterfall)
- Slide 16: Slide 16
- Slide 17: O que é um artefato ?
- Slide 18: Atividades comuns em qualquer modelo
- Slide 19: Levantamento de Requisitos
- Slide 20: Levantamento de Requisitos
- Slide 21: Análise de Requisitos
- Slide 22: Análise de Requisitos
- Slide 23: Análise de Requisitos
- Slide 24: Projeto
- Slide 25: Projeto
- Slide 26: Implementação
- Slide 27: Implementação
- Slide 28: Testes
- Slide 29: Testes
- Slide 30: Implantação
- Slide 31: Implantação
- Slide 32: Slide 32
Slide 1
Análise de Sistemas
- Aula - Processos de Software
- Prof.: Mauro Borges França
Slide 2
Programas de computador; Documentação associada; Configurações.
Revisão – O que é Software
Slide 3
Camadas da Engenharia de Software
FERRAMENTAS MÉTODOS PROCESSO FOCO NA QUALIDADE
Slide 4
Camadas da Engenharia de Software
Processo – Define os passos gerais para o desenvolvimento e manutenção do software – Serve como uma estrutura de encadeamento de métodos e ferramentas; Métodos – São os “how to’s” de como fazer um passo específico do processo; Ferramentas – Automatizam o processo e os métodos.
Slide 5
Processo é o conjunto de passos, etapas e tarefas que se usa para construir um software.
- Definindo Processo de Software
- Valente, Marco Tulio
- Toda projeto usa um processo para desenvolver seus softwares, o qual pode ser ágil ou tradicional (waterfall), por exemplo.
Slide 6
Existem diversos modelos de processos de software; Não existe um processo ideal; Existem atividades comuns aos processos de software; Um Processo não é uma prescrição rígida de como desenvolver software, deve ser adaptável conforme as características do projeto.
Processo de Software
Slide 7
Padroniza o desenvolvimento de software; Padronização dos artefatos de software; Melhora a comunicação da equipe; Consequentemente, agrega qualidade ao software.
Por quê utilizar um modelo de processo de software??
Slide 8
O que é um modelo de processo ?
Um modelo de processo fornece um guia específico para o trabalho de engenharia de software. Define o fluxo de todas as atividades, ações e tarefas, o grau de iteração, os artefatos e a organização do trabalho a ser feito. As vezes chamado de ciclo de vida do desenvolvimento de software.
Slide 9
Processo de Software
O desenvolvimento ágil vem crescendo na preferência de várias empresas no setor de gerenciamento de projetos, por outro lado, há alguns projetos que só podem ser desenvolvidos pelo método cascata.
Slide 10
Modelo Cascata (Waterfall)
- O Método Cascata (modelo Waterfall), conhecido também como método tradicional, é uma forma de gerenciamento de projetos que utiliza fases sequenciais.
- O primeiro modelo de processo de desenvolvimento de software a ser publicado (década de 1970). É derivado de modelos utilizados em outras engenharias.
Slide 11
Modelo Cascata (Waterfall)
- Implementa uma abordagem sistemática e sequencial e linear, isto é, uma nova atividade só pode ser iniciada quando a anterior estiver totalmente concluída.
- Também conhecido com Ciclo de Vida Clássico, é ideal para problemas nos quais os requisitos são bem definidos,
Slide 12
Modelo Cascata (Waterfall) – Etapas
- Comunicação: Iniciação do projeto; Levantamento de requisitos.
- Planejamento: Estimativas; Cronogramação; Monitoração.
- Modelagem: Análise; Projeto.
- Construção: Codificação; Teste.
- Implantação: Entrega; Manutenção; Feedback.
Slide 13
Modelo Cascata (Waterfall)
- Quando usar ?
- Requisitos do problema são bem claros e entendidos, definidos e estáveis;; Quando há pouca chance dos requisitos mudarem;; Sistemas críticos
Slide 14
Modelo Cascata (Waterfall)
- Vantagens
- Paradigma +antigo, estável e testado;; Documentação robusta em cada atividade;; Pode ser combinado com outros modelos;; Simples e suas atividades são claras e bem definidas
Slide 15
Modelo Cascata (Waterfall)
- Desvantagem
- Grande rigidez à execução do projeto;; Difícil para o cliente definir todos os requisitos antes;; Clientes devem esperar (versão do produto somente pronta no final do projeto);; Difícil para lidar com mudanças inevitáveis de requisitos;; Atrasos em uma fase reflete nas demais
Slide 16
Slide 16
Slide de transição ou sem texto adicional.
Slide 17
O que é um artefato ?
Do ponto de vista de um engenheiro de software, os artefatos são os programas, os documentos e os dados produzidos pelas atividades e tarefas definidas pelo processo.
Slide 18
Atividades comuns em qualquer modelo
Levantamento de Requisitos Análise de Requisitos Projeto Implementação Testes Implantação
Slide 19
Levantamento de Requisitos
Compreender o Problema/Demanda; Objetivos comuns; Mesma visão.
Slide 20
Levantamento de Requisitos
Esta atividade tem como objetivo, compreender o problema, dando aos desenvolvedores e usuários, a mesma visão do que deve ser construído para resolução do problema – Objetivo Comum Vários projetos são abandonados pelo baixo levantamento de requisitos, ou seja, membros da equipe não disponibilizaram tempo suficiente para essa fase do projeto, em compreender as necessidades dos clientes em relação ao sistema a ser desenvolvido. O entendimento amplo dos processos de negócios permite que as demais atividades do processo de desenvolvimento flua bem e com qualidade.
Slide 21
Análise de Requisitos
Slide de transição ou sem texto adicional.
Slide 22
Análise de Requisitos
Esta etapa, também chamada de especificação de requisitos, é onde os desenvolvedores fazem um estudo detalhado dos dados levantados na atividade anterior. De onde são construídos modelos a fim de representar o sistema de software a ser desenvolvido. O interesse nessa atividade é criar uma estratégia de solução, sem se preocupar como essa estratégia será realizada, ou seja, utilizar as necessidades dos clientes, depois de compreendido o problema, para resolução do problema solicitado. Assim é necessário definir o que o sistema deve fazer, antes de definir como o sistema irá fazer.
Slide 23
Análise de Requisitos
O que acontece com frequência, é quando as equipes de desenvolvimento partem para a solução do problema do software, sem antes ter definido completamente o problema em questão. Nesta fase deve-se então realizar a validação e verificação dos modelos construídos, antes de partir para solução do problema. Validação: tem por objetivo, assegurar que o sistema de software está atendendo às reais necessidades do cliente; Verificação: verifica se os modelos construídos na análise estão em conformidade com os requisitos do cliente.
Slide 24
Projeto
Slide de transição ou sem texto adicional.
Slide 25
Projeto
Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser considerados nessa fase de projeto do sistema, como: arquitetura do sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, entre outros. O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e projeto detalhado (ou projeto de baixo nível).
Slide 26
Implementação
Slide de transição ou sem texto adicional.
Slide 27
Implementação
Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código-executável para o desenvolvimento software. Em um processo de desenvolvimento orientado a objetos, a implementação se dá, definindo as classes de objetos do sistema em questão, fazendo uso de linguagens de programação.
Slide 28
Testes
Slide de transição ou sem texto adicional.
Slide 29
Testes
Diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto. Onde o principal resultado é o relatório de testes, que contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento em vários aspectos. Ao final dessa atividade, os diversos módulos do sistema são integrados, resultando no produto de software.
Slide 30
Implantação
Slide de transição ou sem texto adicional.
Slide 31
Implantação
Por fim a implantação compreende a instalação do software no ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de um software anterior, também é realizada a migração de dados anteriores desse software.
Slide 32
Slide 32
Slide de transição ou sem texto adicional.
Arquivo convertido para formato textual acessível a partir da apresentação enviada pelo usuário.