Introdução
Pressman, Roger S. Software Engineering: A
Practiotioner’s Approach. Editora: McGraw-Hill. Ano: 2001. Edição: 5
Sommerville, Ian. SW Engineering. Editora:
Addison Wesley. Ano: 2003. Edição: 6
2 Fernando Pedrosa Lopes
Disciplina gerencial e tecnológica
lida com a produção e manutenção de
produtos de software desenvolvidos dentro de estimativas de custo e tempo.
Trata aspectos relacionados a
Processos, Métodos, Técnicas,
Ferramentas e Ambientes de suporte
Desenvolver Software não é só
programação!
3 Fernando Pedrosa Lopes
Obter software de qualidade
Com produtividade no seu
desenvolvimento, operação e
manutenção
Dentro de custos, prazos e níveis de
qualidade controlados
Com o melhor custo-benefício entre
Qualidade e Produtividade
4 Fernando Pedrosa Lopes
Década de 60: a chamada “Crise do
Software”
Desenvolvimento fora de controle
Iniciou como um problema de Custo e
Produtividade.
Mais importante: era um problema de
Qualidade
Dé
cada de 70◦ Programação Estruturada
◦ Projeto Estruturado
5
Década de 80
Análise Estruturada (DFDs, Dicionário de
Dados, Diagrama ER, de Estados, etc.)
Ferramentas CASE
Década de 90
◦Análise e Projeto OO.
◦Modelagem de acordo com o mundo real.
Características e Comportamento de Objetos.
◦Processo Unificado
7 Fernando Pedrosa Lopes
Anos 2000
Metodologias Ágeis
Novos paradigmas: SOA, Aspectos,
Model-Driven Architecture, etc.
8 Fernando Pedrosa Lopes
Software
◦Programa de computador e documentação
associada.
◦Produtos de software podem ser
desenvolvidos para um cliente particular ou podem ser desenvolvidos para um mercado geral.
9 Fernando Pedrosa Lopes
Processo
◦Uma série conectada de ações, atividades,
mudanças, etc., realizada de forma bem definida por atores com a intenção de satisfazer um propósito ou objetivo.
◦Define quem está fazendo o quê, quando
e como para atingir um certo objetivo
10 Fernando Pedrosa Lopes
Entrada Processo (atividades e sub-processos) Saída
Processo de Software
◦Conjunto de atividades, métodos, práticas e transformações que guiam pessoas na construção de Software
“São uma representação abstrata e
simplificada do processo de
desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de software.”
Contêm:
◦“Esqueleto do processo”
◦Ordem de precedência das atividades
◦Artefatos e produtos gerados
13 Fernando Pedrosa Lopes
Seqüenciais
◦Cascata ou Clássico Modelos Evolucionários
◦Programação Exploratória ◦Prototipagem Descartável Específicos
◦Métodos formais Iterativos
◦Espiral ◦Incremental 14 Fernando Pedrosa Lopes
Modelo “Clássico”, derivado de
modelos existentes em outras
engenharias
Sua estrutura é composta por várias
etapas que são executadas de forma
sistemática e seqüencial
Na prática, existe uma interação entre
as etapas e cada etapa pode levar a
modificações nas etapas anteriores
15 Fernando Pedrosa Lopes
Análise Projeto Implementação Testes Operação e Manutenção 16 Fernando Pedrosa Lopes
Requisitos Análise Projeto Implementação Testes Operação e Manutenção 17 Fernando Pedrosa Lopes
Requisitos Comunicação Planejamento Modelagem Construção Implantação 18 Fernando Pedrosa Lopes
- Iniciação do projeto - Levantamento de Requisitos - Estimativas - Cronograma - Monitoramento - Análise - Projeto - Codificação - Teste - Entrega - Manutenção - Teste
É simples e fácil de aplicar, facilitando
o planejamento
Fixa pontos específicos para a entrega
de artefatos
Pressupõe que os requisitos ficarão
estáveis
Porém, atrasa a redução de riscos!
19
Fernando Pedrosa Lopes Fernando Pedrosa Lopes 20
Início da integração 100% Tempo P ro g re s s o d o p ro je to (% c o d if ic a d o ) Deadline original
Planejamento
◦Esboçar escopo e requisitos
◦Fazer estimativas razoáveis sobre
recursos, custos e prazos
Análise e Especificação de Requisitos
◦Refinar requisitos e escopo
◦Entender o domínio do problema, com
comportamento e funcionalidades esperados
21 Fernando Pedrosa Lopes
Projeto
Incorporar requisitos tecnológicos aos
requisitos essenciais do sistema
Fazer o projeto da arquitetura do sistema
e projeto detalhado do sistema
Implementação
Traduzir o projeto em uma forma passível
de execução pela máquina. Codificação.
22 Fernando Pedrosa Lopes
Testes
◦Realizar diversos níveis de teste, de forma
a fazer a verificação do software.
Implantação, Operação e Manutenção
◦Colocar o software em produção
◦Treinar pessoas
◦Manter o software
◦Gerenciar os serviços
Programação exploratória
Idéia geral:
◦Modificações sucessivas até que o sistema
seja considerado adequado
◦Desenvolvimento da primeira versão do
sistema o mais rápido possível
◦Após o desenvolvimento de cada uma das
versões do sistema ele é mostrado aos usuários para comentários
Programação exploratória
Adequado para o desenvolvimento de
sistemas onde é difícil ou impossível
se fazer uma especificação detalhada
do sistema
Principal diferença para os outros
modelos é a ausência da noção de
programa correto
25 Fernando Pedrosa Lopes
Prototipagem
Como na programação exploratória, a
primeira fase prevê o desenvolvimento
de um programa para o usuário
experimentar
◦No entanto, o objetivo aqui é estabelecer
os requisitos do sistema
◦O software deve ser reimplementado na
fase seguinte
26 Fernando Pedrosa Lopes
Prototipagem
27 Fernando Pedrosa Lopes
Prototipagem
É útil para sistemas grandes e
complicados
Ou quando não existe um sistema
anterior ou manual que ajude a
especificar os requisitos
28 Fernando Pedrosa Lopes
Métodos Formais
Idéia geral:
◦Uma especificação formal (definição
matemática, não ambígua) do software é desenvolvida e posteriormente
“transformada” em um programa através de regras que preservam a corretude da especificação
esp. 2
esp. 1 implement.
29 Fernando Pedrosa Lopes
Métodos Formais
O próprio processo de desenvolvimento
garante que o programa faz exatamente o que foi especificado
É possível gerar programas corretos e
completos por construção
Têm sido aplicados apenas ao
desenvolvimento de sistemas críticos (por questões de segurança!)
30 Fernando Pedrosa Lopes
Motivação: requisitos de sistema
sempre evoluem durante o projeto
Deve-se dividir para conquistar
Duas abordagens
◦Desenvolvimento Incremental
◦Desenvolvimento Espiral
31 Fernando Pedrosa Lopes
Desenvolvimento Incremental
A idéia é de desenvolver e entregar o software em
incrementos, com cada incremento entregando parte da funcionalidade requerida.
Requisitos são definidos antes do desenvolvimento
do incremento, sendo os mais críticos priorizados. Req A&P Imp I/T Imp Iteração 1 Req A&P Imp I/T Imp Iteração 2 Req A&P Imp I/T Imp Iteração 3 TEMPO 32 Fernando Pedrosa Lopes
Incremental: são adicionados “pedaços completos”
Iterativo: esboços ou pedaços incompletos do
produto são adicionados a cada iteração
33 Fernando Pedrosa Lopes
Desenvolvimento em Espiral
O processo é representado como uma
espiral em vez de uma seqüência de
atividades. Cada volta na espiral
representa uma fase no processo
Acrescenta aspectos gerenciais
Planejamento, tomada de decisão
Análise de Riscos
Porém, é complexo e requer
experiência na avaliação de riscos!
34 Fernando Pedrosa Lopes
Fernando Pedrosa Lopes 37 100% Tempo P ro g re s s o d o p ro je to (% c o d if ic a d o ) Ciclo de vida tradicional Ciclo de vida iterativo 38 Fernando Pedrosa Lopes
Início: década de 90
Reação contra métodos “pesados”, vistos como
lentos e burocráticos
Idéia central: tornar simples o que
dificultava o desenvolvimento de software
Geralmente aplicado em projetos onde os
Requisitos e Prioridades são instáveis
Hoje representa uma família de processos
de desenvolvimento.
39 Fernando Pedrosa Lopes
“Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que:
Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e detalhada.
Colaboração com o cliente é mais importante do que negociação de contratos.
Adaptação a mudanças é mais importante do que seguir o plano inicial.
Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “
40 Fernando Pedrosa Lopes
Errado - Metodologia Ágil não é o caos!
41 Fernando Pedrosa Lopes
eXtreme Programming
Scrum
FDD
Lean Software Development
Cristal Family
(...)
42 Fernando Pedrosa Lopes
Surgimento
Em meados de 1990, Kent Beck,
procurou formas mais simples e
eficientes de desenvolver Software.
Em Março de 1996, ele iniciou um
projeto com novos conceitos que
resultaram na metodologia XP
-eXtreme Programming
43 Fernando Pedrosa Lopes
“Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança”
44 Fernando Pedrosa Lopes
Levar todas as boas práticas ao
extremo
◦Se testar é bom, vamos testar toda hora!
◦Se projetar é bom, vamos fazer disso
parte do trabalho diário de cada pessoa!
◦Se integrar é bom, vamos integrar a maior
quantidade de vezes possível!
◦Se iterações curtas são boas, vamos deixar
as iterações realmente curtas!
45 Fernando Pedrosa Lopes
Metáfora
◦Procura facilitar a comunicação com o cliente,
entendendo a realidade dele.
Projeto simples
◦O código está, a qualquer momento, na forma
mais simples que passe todos os testes.
Pequenas versões
◦O software é entregue em pequenas versões para
que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos.
46 Fernando Pedrosa Lopes
Refatoração
◦A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos.
Programação em Pares
◦Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor.
Propriedade coletiva do código
◦A equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.
Padrão de codificação
◦Todo código é desenvolvido segundo um padrão.
40 horas por semana
◦Cada programador trabalha 40 horas por
semana, no máximo
Reuniões em pé
◦Reuniões rápidas e diárias com a equipe, para
discutir apenas o essencial
Cliente sempre presente
Testes de Aceitação
◦São definidos pelo usuário e são os critérios de aceitação do software.
Desenvolvimento Orientado a Testes
◦A criação de testes leva em conta não só o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema.
Integração Contínua
◦Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.
49 Fernando Pedrosa Lopes
Comunicação
◦Métodos para rapidamente construir e disseminar conhecimento
Simplicidade
◦XP encoraja que você comece, sempre, pela solução mais simples
Feedback
◦Do cliente, do sistema e da equipe
Coragem
◦Design simples, refatoração…
Respeito
◦Respeito da Equipe, do Cliente, dos Usuários…
50 Fernando Pedrosa Lopes
O nome é derivado de uma atividade que
ocorre durante um jogo de Rugby
Princípios:
◦Pequenas equipes de trabalho são organizadas de
modo a “maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal”.
◦O processo precisa ser adaptável tanto a
modificações técnicas como de negócio.
◦O processo produz frequentes incrementos de
software.
51 Fernando Pedrosa Lopes
Atividades do processo
◦ requisitos ◦ análise ◦ projeto ◦ evolução ◦ entrega. Principais papéis
◦ScrumMaster; Product Owner; Team
52 Fernando Pedrosa Lopes
Início: Jeff de Luca e Peter Coad em
1997-98
A FDD é focada na entrega regular de
funcionalidades valiosas para o cliente
Tem mais estrutura do que o XP,
porém é mais enxuto do que o RUP – é
um meio termo.
53 Fernando Pedrosa Lopes
Seis Papéis
◦Project Manager
◦Chief Architect
◦Development Manager
◦Chief Programmers
◦Class Owners (aka Developers)
◦Domain Experts
54 Fernando Pedrosa Lopes
Cinco processos
55
Fernando Pedrosa Lopes Fernando Pedrosa Lopes 56
Antes da década de 90 – “casa de
ferreiro, espeto de pau”
Hoje em dia as ferramentas CASE
ainda não são tão variadas nem
fornecem tudo aquilo que os
desenvolvedores queriam, mas são
um aparato essencial para o
engenheiro de software
57 Fernando Pedrosa Lopes
O que são?
◦São ferramentas que auxiliam o
engenheiro de SW em cada atividade associada ao desenvolvimento de SW
Quem usa?
◦Gerentes de projeto e engenheiros de SW
Por que são importantes?
◦Reduzem o esforço necessário para
produzir artefatos e alcançar metas
◦Aumentam a qualidade do software
58 Fernando Pedrosa Lopes
Quais são os passos?
◦Ferramentas CASE são usadas em
conjunto com o modelo de processo adotado. Se for escolhida uma ferramenta completa, pode passar por quase todos os passos do desenvolvimento de SW
Como são usadas?
◦Como complemento às boas práticas de
Engenharia de Software. Ferramentas CASE não substituem uma metodologia de desenvolvimento de software sólida
“Um tolo com ferramentas, ainda é apenas um tolo”
Horizontais
◦São utilizados durante todo o processo de
desenvolvimento de software
Verticais
◦São específicas para uma disciplina de software
Por funções [Pressman]
◦Processos de negócio, Planejamento de
projeto, Análise de Riscos, Rastreamento de Requisitos, IDEs, Gerenciamento de BDs, Análise Estática, Análise Dinâmica, ...
61 Fernando Pedrosa Lopes
Como não há um padrão para categorizar
ferramentas CASE, a seguinte proposta foi feita:
◦Front-end ou Upper CASE
apóiam as etapas iniciais da criação dos
sistemas: as fases de planejamento, análise e projeto da aplicação
◦Back-end ou Lower CASE
dão apoio à parte física, i.e, código, testes e
manutenção
◦I-CASE ou Integrated CASE
cobrem todo o ciclo de vida, do início ao fim
62 Fernando Pedrosa Lopes
