Introdução à Engenharia de
Software
2. O Processo de Engenharia de Software
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Guias e Dicas
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Encontrar documentos
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Encontra documentos específicos para os exames da tua universidade
Videoaulas
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Quiz
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
apsiv - t02 - paradigmas, Notas de estudo de Informática
Engenahria de Software
Tipologia: Notas de estudo
2012
1 / 34
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Documentos relacionados
Pré-visualização parcial do texto
Baixe apsiv - t02 - paradigmas e outras Notas de estudo em PDF para Informática, somente na Docsity!
Introdução à Engenharia de
Software
2. O Processo de Engenharia de Software
2. O Processo de Engenharia de
Software
O Processo de Engenharia de Software envolve todas as
atividades relacionadas ao desenvolvimento de um
software, desde a análise de requisitos, administração e
gerenciamento de projetos até as técnicas de teste e
manutenção de software.
Essas atividades podem ser executadas em diferentes
seqüências e agrupadas em diferentes etapas. Os
conjuntos de regras que definem essas etapas e
seqüências são chamados de paradigmas da
engenharia de software.
Para se escolher entre um ou outro paradigma deve- se levar em consideração diversos fatores:
Processo de desenvolvimento a ser adotado
Tipo de aplicação a ser desenvolvida
Métodos e ferramentas a serem utilizados
Controles e produtos que precisam ser entregues
Expectativas do cliente
2.1.1 Ciclo de vida clássico
Também conhecido como modelo cascata ou
modelo waterfall.
Modelo mais antigo e mais utilizado
Foi desenvolvido com base no ciclo da
engenharia tradicional
É caracterizado por uma abordagem seqüencial
para o desenvolvimento do software
Cada atividade é uma fase distinta. Só após o seu
total término é que a próxima atividade começa.
FASES 1 e 2 - ENGENHARIA DE SISTEMAS EFASES 1 e 2 - ENGENHARIA DE SISTEMAS E
ANÁLISE DE REQUISITOS ANÁLISE DE REQUISITOS
Envolve a coleta dos requisitos para todos os elementos do sistema (^) Análise em alto nível. Pouco projeto. (^) Visão global do sistema: tarefas, interface com o usuário, interface com hardware, interface com banco de dados, etc. A análise envolve diversas tarefas: (^) Identificar as necessidades dos usuários (^) Realizar a análise dos custos envolvidos (^) Realizar a análise dos recursos necessários tanto de ferramentas quanto de pessoal (^) Estabelecer restrições de prazo e custo (^) Realizar um projeto inicial e global do sistema, incluindo sua divisão em módulos
Como realizar a análise:
(^) Entrevistas entre o analista e o cliente Questionários O analista deve saber fazer as perguntas certas, orientar, esclarecer e dar conselhos (^) O cliente deve ser capaz de esclarecer suas expectativas e metas de projeto. Técnicas: análise estruturada, análise orientada a objeto, métodos formais Resultado: Especificação dos Requisitos
FASE 4 – CODIFICAÇÃO (ou implementação)FASE 4 – CODIFICAÇÃO (ou implementação)
Consiste simplesmente em implementar o que foi
definido no projeto.
Quando o projeto é bem feito e os desenvolvedores
são experientes e/ou competentes, esta etapa é
relativamente simples
Em outras palavras, esta etapa consiste da tradução
do projeto para uma linguagem artificial, resultando
em instruções executáveis pelo computador.
Falando de maneira ainda mais simples: codificação
significa escrever o programa.
FASE 5 – TESTEFASE 5 – TESTE
Consiste em testar o software, o que pode ser
realizado de diversas formas:
(^) Teste caixa preta – consiste em testar o software ignorando o processamento interno. Apenas verifica se, para um conjunto de dados de entrada, o conjunto de dados de saída é o esperado. (^) Teste caixa branca – consiste em testar internamente o software, garantindo que todas as instruções teham sido testadas Outros tipos…
PROBLEMAS DO CICLO DE VIDA CLÁSSICO PROBLEMAS DO CICLO DE VIDA CLÁSSICO:
Dificilmente projetos reais seguem um fluxo seqüencial
Nem sempre é possível estabelecer, inicialmente, todos
os requisitos necessários, devido a incertezas tanto do
cliente quanto do desenvolvedor.
O cliente deve esperar até o final de todas as etapas para
saber como será o produto. Nem sempre ele consegue
visualizar exatamente como será o produto final.
Resultado:
Clientes instatisfeitos Modificações no sistema Aumento dos custos Possibilidade de introdução de erros
2.1.2 Prototipação
Foi criado para evitar que o produto final não
corresponda às expectativas do cliente.
Caracteriza-se por criar, logo no início, uma versão
simplificada do software (protótipo).
O protótipo pode ser:
(^) Um protótipo em papel (^) Um programa executável, mas que executa parte ou toda a função desejada, mas que deverá sofrer melhoras na interface ou na performance Um programa executável, mas que apenas demonstra a “cara” do programa e sua interface com o usuário.
1 – OBTENÇÃO DOS REQUISITOS 1 – OBTENÇÃO DOS REQUISITOS Semelhante à fase de análise do modelo clássico. Desenvolvedor e cliente definem os objetivos do software. 2 – PROJETO RÁPIDO 2 – PROJETO RÁPIDO Realiza-se um projeto simplificado do sistema final Geralmente concetra-se nas partes visíveis ao usuário, ou seja, as interfaces de diálogo e interfaces para entrada e saída de dados.
3 – CONSTRUÇÃO DO PROTÓTIPO 3 – CONSTRUÇÃO DO PROTÓTIPO Implementação do projeto rápido 4 – AVALIAÇÃO DO PROTÓTIPO PELO 4 – AVALIAÇÃO DO PROTÓTIPO PELO CLIENTE CLIENTE O cliente utiliza o protótipo para avaliar se o que está sendo desenvolvido é o que ele espera. O protótipo, portanto, serve para refinar os requisitos iniciais estabelecidos. Esse primeiro sistema deve servir apenas para avaliação e ser posteriormente descartado.
Vantagens deste modelo Vantagens deste modelo: É apropriado quando o cliente define um conjunto de objetivos gerais, mas não identificou claramente requisitos de entrada, saída e processamento. É apropriado quando o desenvolvedor não tem certeza da melhor abordagem de implementação, algoritmo ou interface e decide testar antes de implementar o produto final.
PROBLEMAS DA PROTOTIPAÇÃO PROBLEMAS DA PROTOTIPAÇÃO
O Cliente pensa que o protótipo já está bom o suficiente
e tenta forçar o seu uso como final, ou diminuir prazos.
O desenvolvedor tenta gerar o software final a partir do
protótipo, com o objetivo de acelerar o processo.
(^) Introduzir erros (^) Gerar conflitos internos
O desenvolvedor “esquece” que as escolhas tomadas na
prototipação não são as mais apropriadas e utiliza
estruturas de dados inadequadas ou não tão eficientes.
Solução:
(^) Deixar claro para o cliente, logo de início, o objetivo do protótipo