• Nenhum resultado encontrado

Aula03-Processos de Desenvolvimento de Software

N/A
N/A
Protected

Academic year: 2021

Share "Aula03-Processos de Desenvolvimento de Software"

Copied!
21
0
0

Texto

(1)

Engenharia de

Software

Juliana Paschoal Bueno

e-mail:

julianapb@gmail.com

site:

https://sites.google.com/site/engsoft2012/

PROCESSOS DE

DESENVOLVIMENTO DE

SOFTWARE

(2)

Tópicos

• Engenharia de Software

• Processos de Desenvolvimento Software: • Ciclo de Vida Clássico (ou Modelo Cascata) • Prototipação

• Espiral • Incremental

• Combinando Paradigmas

Engenharia de Software

• Os problemas do desenvolvimento de software estão longe de acabar.

• O caminho para ter software com mais

qualidade é identificar os problemas e descobrir as suas causas.

(3)

Engenharia de Software

• As soluções da engenharia de software devem dar assistência ao desenvolvedor, melhorar a qualidade do software e permitir que o software acompanhe a evolução do hardware.

• Não existe uma única solução para todos

casos de softwares!

• Existem várias soluções e elas podem ser somadas e adaptadas a cada problema.

Engenharia de Software

• Primeira definição de engenharia de software proposta por Fritz Bauer:

“O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter

economicamente um software que seja confiável e que funcione eficientemente em máquinas reais.”

• Os três pilares da engenharia de software são: métodos, procedimentos e ferramentas.

(4)

Engenharia de Software

• Métodos:

• São detalhes de “como fazer” para construir um software.

• Incluem tarefas de planejamento, estimativa, análise de requisitos, projeto de estrutura de dados, arquitetura do programa, algoritmo, codificação, teste e manutenção.

Engenharia de Software

• Ferramentas:

• Proporcionam apoio para execução das tarefas envolvidas nos métodos anteriores. • São chamadas de CASE (Computer Aided

Software Engineering) – Engenharia de Software Auxiliada por Computador. • Exemplos de CASE:

(5)

Engenharia de Software

• Procedimentos:

• Significa a união entre métodos e ferramentas.

• Definem a ordem que os métodos serão aplicados, os produtos (deliverables) que devem ser entregues, os controles de qualidade e os marcos de referência.

(6)

PROCESSOS DE SOFTWARE

Processos de Software

• Processo de desenvolvimento de software é um conjunto de tarefas e resultados que levam a produção de um software.

• Um processo de software pode ser aplicado ao desenvolvimento de um sistema desde o seu início ou para a expansão e modificação de um software já existente.

(7)

Processos de Software

• Algumas atividades são comuns a qualquer processo de software:

• Especificação de software

• Projeto e implementação de software • Validação de software

• Evolução de software

Ciclo de Vida Clássico

• Conhecido como clássico ou cascata.

Adaptado de Sommerville, 2004 Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

(8)

Ciclo de Vida Clássico

• Engenharia de Sistemas:

• É fase inicial de levantamento de requisitos. • Nesta fase também são determinadas as

interfaces do software com elementos de hardware, pessoas e bancos de dados. • Levantamento de alto nível.

Ciclo de Vida Clássico

• Análise de Requisitos:

• O processo de coleta de requisitos é itensificado.

• O engenheiro deve entender a função do software e analisar o seu desempenho.

• Os requisitos são documentados e revisados com o cliente.

(9)

Ciclo de Vida Clássico

• Projeto:

• Possui muitas etapas definição da estrutura de dados, arquitetura do software e

caracterização da interface.

• Traduz os requisitos em uma representação que permite que programa seja analisado antes de ser implementado.

Ciclo de Vida Clássico

• Codificação:

• O projeto deve ser traduzido através de uma linguagem de programação em um programa.

(10)

• Testes:

• Terminada a codificação começa a fase de testes.

• Esta fase tem o objetivo de testar todas as instruções.

• É importante nesta fase testar situações de erro e não só de sucesso.

Ciclo de Vida Clássico

• Manutenção:

• Todo software sofre mudanças depois de ser entregue ao cliente.

• Mudanças devido a erros.

• Mudanças exigidas pelo cliente (novas funcionalidades ou desempenho).

• Mudanças devido a diferenças entre o

Ciclo de Vida Clássico

(11)

• Problemas do modelo cascata: • Projetos raramente seguem o fluxo

sequencial.

• Alguma iteração sempre ocorre entre as etapas.

• O cliente tem dificuldade em expressar todas as suas nececidades em um primeiro momento e este modelo exige este tipo de atitude.

Ciclo de Vida Clássico

• Problemas do modelo cascata:

• Uma versão preliminar do programa só estará pronta tardiamente.

• O cliente na maioria das vezes fica insatisfeito com isso.

• Consequência: acúmulo de muitos erros. • Ainda é uma abordagem melhor do que

NADA.

(12)

• Para alguns problemas este modelo pode ser a solução:

• Cliente só definiu objetivos gerais do software.

• Equipe de desenvolvimento tem dúvidas sobre eficiência do algoritmo, ambiente de produção e interfaces.

Prototipação

• A prototipação permite que o cliente visualize o software antes que ele ganhe forma final:

• Através de um modelo em papel.

• Um protótipo que implementa algumas funcionalidades do software final.

• Um programa existente que será melhorado.

Prototipação

(13)

Prototipação

Pressman, 2005

• Coleta de requisitos: nesta etapa cliente e equipe de requisitos definem os objetivos globais do software.

• Projeto rápido: representação dos aspectos que serão visíveis ao usuário e definição de formatos de entrada e saída.

• Construção do protótipo: elaboração de protótipo para avaliação do cliente e posterior refinamento dos requisitos.

(14)

• Idealmente todo o protótipo deveria ser jogado fora.

• Nem mesmo o melhor planejamento é feito tão corretamente na primeira vez.

Prototipação

• Problemas da prototipação:

• O cliente acha que o produto já está quase pronto.

• O desenvolvedor tenta colocar um protótipo em execução rapidamente e utiliza uma

linguagem de programação ou S.O. imprórios. • O desenvolvedor tentando agilizar o

funcionamento do protótipo implementa um

Prototipação

(15)

• Para que seja alcançado o sucesso com este modelo deve-se definir as regras do jogo logo no começo.

• Protótipo só será utilizado para definição de requisitos.

• O protótipo será descartado.

• O software real será implementado considerando métricas de qualidade e manutenção.

Prototipação

• Reúne as melhores características do modelo cascata e da prototipação.

• Possui um novo elemento: análise de riscos (não existia nos anteriores).

• Define 4 principais atividades: planejamento, análise de riscos, engenharia e avaliação feita pelo cliente.

(16)

Modelo Espiral

Pressman, 2005

• Planejamento: determinação dos objetivos, alternativas e restrições.

• Análise dos riscos: análise de alternativas e identificação/resolução dos riscos.

• Engenharia: desenvolvimento do produto no nível seguinte.

• Avaliação feita pelo cliente: avaliação dos

Modelo Espiral

(17)

• O centro do espiral representa o início do projeto.

• Se a análise dos riscos mostrar incertezas nos requisitos a prototipação pode ser utilizada para auxiliar o entendimento do problema.

• Simulações e modelos também podem ser utilizados neste paradigma.

Modelo Espiral

• É uma abordagem muito realista para desenvolvimento de software.

• Não é perfeito:

• Exige muita experiência para avaliação de riscos.

• Complicado exibir diversos protótipos e não a versão final para o cliente.

(18)

Incremental

Incremento 1 Codificação Teste Projeto Análise Incremento 2 Codificação Teste Projeto Análise Incremento N Codificação Teste Projeto Análise . . .

• Primeiramente é realizado um levantamento de requisitos com o cliente/usuário.

• Depois o cliente identifica as prioridades das funcionalidades levantadas.

• As funcionalidades com mais prioridade vão para a entrega dos primeiros incrementos. • As funcionalidades com menos prioridade vão

(19)

• O desenvolvimento é realizado por incremento. • Um subconjunto de funcionalidades é

desenvolvida em cada incremento.

• As entregas para o cliente são realizadas por subconjunto de funcionalidades.

• Para cada subconjunto de requisitos é realizado: análise, projeto, codificação e testes.

Incremental

• Os incrementos são feitos em paralelo, ou seja, equipes trabalhando em paralelo.

• O subconjunto de funcionalidades a ser implementado em cada incremento deve ser independente.

• Antes de criar os subconjuntos de requisitos é importante ter a visão de todo o projeto.

(20)

• É um modelo iterativo.

• É uma boa estratégia para grandes projetos. • Cada incremento utiliza o processo de

desenvolvimento de software do cascata.

• Apresenta os mesmos problemas que o cascata, porém em escalas menores.

Incremental

• Os paradigmas podem ser combinados ou adaptados a cada situação.

• Podemos combinar o cascata com a prototipação e assim por diante.

• O importante é que a primeira etapa de

qualquer processo é sempre um levantamento prévio de requisitos.

(21)

Bibliografia

• “Engenharia de Software”

Autor: Roger S. Pressman

Editora: Pearson – Makron Books

• “Engenharia de Software”

Autor: Ian Sommerville

Editora: Pearson – Addison Wesley

• “Engenharia de Software – Os Paradigmas

Clássico e Orientado a Objetos”

Autor: Stephen R. Schach Editora: Mc Graw Hill

Bibliografia

• “Introdução ao RUP: Rational Unified Process”

Autor: Phillippe Kruchten Editora: Ciência Moderna

Referências

Documentos relacionados

• Gerar nos alunos de Análise e desenvolvimento de software a capacidade de analisa, documentar e especificar sistemas computacionais de informação.. Estes devem fazer uso

• O ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido

• Deve-se avaliar o conjunto de requisitos essenciais para a definição do Documento de Visão do software e este deve incluir o escopo do projeto e suas limitações, bem como

• Depois de determinar os custos e benefícios para uma possível solução, você pode realizar a análise de custo- benefício.. Estudo

• Requisitos são tipicamente utilizados como informações fundamentais para a fase de projeto de um produto ou serviço, especificando as propriedades e funções necessárias

Nesta reunião, o ScrumMaster trabalha junto com o Proprietário do Produto e a Equipe de Desenvolvimento para definir qual a carga de tempo que cada funcionalidade do Product

Esse conjunto de função consiste naquelas funções não diretamente relacionada à definição, ao gerenciamento, ao desenvolvimento e ao teste de software, mas que não

Processo de Desenvolvimento de Software: Analises iniciais, ciclo de vida de um processo, modelos de processos de desenvolvimento, padrões de processos, processo unificado;