Engenharia de
Software
Juliana Paschoal Bueno
e-mail:
julianapb@gmail.com
site:
https://sites.google.com/site/engsoft2012/
PROCESSOS DE
DESENVOLVIMENTO DE
SOFTWARE
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.
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.
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:
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.
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.
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
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.
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.
• 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
• 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.
• 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
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.
• 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
• 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.
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
• 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.
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
• 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.
• É 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.
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