Engenharia de Software I – 2013.
Modelos de Processo
de Software
Ricardo Argenton Ramos
ricargentonramos@[Link]
A Engenharia de Software
Uma Tecnologia em Camadas
Gerenciamento da Qualidade Total e filosofias similares
produzem uma mudança cultural que permite o
desenvolvimento crescente de abordagens mais maduras para
a Engenharia de Software
2
ENGENHARIA DE SOFTWARE
pode ser vista como uma abordagem dedesenvolvimento
de software elaborada com disciplina e métodos bem
definidos.
.....“a construção por múltiplas pessoas de um
software com múltiplas versões” [Parnas 1987]
3
Modelos de Processo de
Software
Existem vários modelos de processo de
software (ou paradigmas de engenharia de
software)
Cada um representa uma tentativa de
colocar ordem em uma atividade
inerentemente caótica
4
Modelos de Processo de
Software
O Modelo Seqüencial Linear
(também chamado Ciclo de Vida Clássico ou
Modelo Cascata)
O Modelo O Modelo Espiral
Baseado em
Componentes
O Paradigma de
Prototipação
Processo Unificado
O Modelo Seqüencial Linear
(também chamado Ciclo de Vida
Clássico ou Modelo Cascata)
6
O Modelo Cascata
modelo mais antigo e o mais
amplamente usado da engenharia
de software
modelado em função do ciclo da
engenharia convencional
requer uma abordagem sistemática,
seqüencial ao desenvolvimento de
software
o resultado de uma fase se constitui
na entrada da outra 7
O Modelo em Cascata
Verificar Plano
Exploração de
conceitos Requisitos de V & V O quê
Requisitos
Projeto de V & V
Projeto
Implementação
Sistema de V & V Como
Tarefas de V & V
Testes
Evoluir Operação
Sistema
Instalação e de V & V
liberação
Operação
Manutenção e de V & V
Feedback operação
8
O Modelo em Cascata
Exploração de Conceitos / Informação e
Engenharia de
Sistemas Modelagem
Análise de
Envolve a elicitação
Requisitosde requisitos do sistema, com uma pequena
quantidade de projeto e Projeto
análise de alto nível;
Preocupa-se com aquilo que conhecemos
Codificação como engenharia
progressiva de produto de software;
Testes
Iniciar com um modelo conceitual de alto nível para um sistema e
Manutenção
prosseguir com o projeto, implementação e teste do modelo físico do
sistema.
9
O Modelo em Cascata
Análise de Requisitos de Software
o processo dede elicitação dos requisitos é
Engenharia
Sistemas
intensificado eAnálise
concentrado
de especificamente no
Requisitos
software Projeto
deve-se compreender o domínio Codificação da informação, a
função, desempenho e interfaces exigidos
Testes
os requisitos (para o sistema e para o Manutenção software) são
documentados e revistos com o cliente
10
O Modelo em Cascata
Projeto
tradução dos requisitos do software para um
conjunto de representações que podem ser
avaliadas quanto à qualidade, antes que a
codificação inicie
11
O Modelo em Cascata
Implementação
tradução das representações do projeto para uma
linguagem “artificial” resultando em instruções
executáveis pelo computador e implementado
num ambiente de trabalho.
12
O Modelo em Cascata
Testes
Concentra-se:
nos aspectos lógicos internos do software,
garantindo que todas as instruções tenham sido
testadas
nos aspectos funcionais externos, para descobrir
erros e garantir que a entrada definida produza
resultados que concordem com os esperados.
13
O Modelo em Cascata
Manutenção
provavelmente o software deverá sofrer
mudanças depois que for entregue ao cliente
causas das mudanças: erros, adaptação do
software para acomodar mudanças em seu
ambiente externo e exigência do cliente para
acréscimos funcionais e de desempenho
14
com o Modelo em
Cascata
Projetos reais raramente seguem o fluxo seqüencial
que o modelo propõe;
Logo no início é difícil estabelecer explicitamente
todos os requisitos. No começo dos projetos sempre
existe uma incerteza natural;
O cliente deve ter paciência. Uma versão executável
do software só fica disponível numa etapa avançada
do desenvolvimento (na instalação);
Difícil identificação de sistemas legados (não
acomoda a engenharia reversa). 15
Embora o Modelo em Cascata
tenha fragilidades, ele é
significativamente melhor do
que uma abordagem casual de
desenvolvimento de software.
16
O Modelo em Cascata
O Modelo de processo em Cascata trouxe
contribuições importantes para o processo de
desenvolvimento de software:
Imposição de disciplina, planejamento e
gerenciamento
a implementação do produto deve ser postergada até
que os objetivos tenham sido completamente entendidos;
Permite gerência do baseline, que identifica um conjunto
fixo de documentos produzidos ao longo do processo de
desenvolvimento;
17
O Paradigma de Prototipação
18
O Modelo de Prototipação
o objetivo é entender os requisitos do usuário
e, assim, obter uma melhor definição dos
requisitos do sistema.
possibilita que o desenvolvedor crie um
modelo (protótipo)do software que deve ser
construído
apropriado para quando o cliente não definiu
detalhadamente os requisitos.
19
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
Elaborar Projeto Rápido
Refinamento do Protótipo
Construir Protótipo
Avaliar Protótipo
20
O Paradigma de Prototipação
para obtenção dos requisitos
1- OBTENÇÃO DOS REQUISITOS:
Obter Requisitos
desenvolvedor e cliente definem os
objetivos gerais do software,
identificam quais requisitos são Projeto Rápido
Elaborar
conhecidos e as áreas que necessitam
Refinamento do Protótipo
de definições adicionais.
Construir Protótipo
Avaliar Protótipo
21
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
2- PROJETO RÁPIDO:
Elaborar Projeto Rápido
representação dos aspectos do
Refinamento do Protótipo
software que são visíveis ao usuário
(abordagens de entrada e formatos
de saída)
Construir Protótipo
Avaliar Protótipo
22
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
Elaborar Projeto Rápido
Refinamento do Protótipo
3- CONSTRUÇÃO DO PROTÓTIPO:
implementação rápida do
projeto Construir Protótipo
Avaliar Protótipo
23
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
Elaborar Projeto Rápido
Refinamento do Protótipo
4- AVALIAÇÃO DO PROTÓTIPO: cliente e
Construir Protótipo
desenvolvedor avaliam o protótipo
Avaliar Protótipo
24
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
Elaborar
5- REFINAMENTO DO PROTÓTIPO: Projeto
cliente e Rápido
Refinamento do Protótipo
desenvolvedor refinam
os requisitos do
software a ser desenvolvido.
Construir Protótipo
Avaliar Protótipo
25
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
Elaborar Projeto Rápido
CONSTRUÇÃO
Refinamento
DO PRODUTO do Protótipo
Construir Protótipo
Avaliar Protótipo
26
O Paradigma de Prototipação
para obtenção dos requisitos
Obter Requisitos
6- CONSTRUÇÃO PRODUTO:
identificados os requisitos, o
protótipo deve ser descartado Elaborar
e a Projeto Rápido
CONSTRUÇÃO
versão de do
Refinamento
DO PRODUTO produção
Protótipo deve ser
construída considerando os
critérios de qualidade.
Construir Protótipo
Avaliar Protótipo
27
Problemas com a Prototipação
cliente não sabe que o software que ele vê
não considerou, durante o desenvolvimento,
a qualidade global e a manutenibilidade a
longo prazo
desenvolvedor freqüentemente faz uma
implementação comprometida (utilizando o
que está disponível) com o objetivo de
produzir rapidamente um protótipo
28
Comentários sobre o
Paradigma de Prototipação
ainda que possam ocorrer problemas, a
prototipação é um ciclo de vida eficiente.
a chave é definir as regras do jogo logo no
começo.
o cliente e o desenvolvedor devem ambos
concordar que o protótipo seja construído
para servir como um mecanismo para definir
os requisitos
29
Exercício
Vamos refazer o exercício da primeira aula,
agora utilizando a Prototipação para construir
o Projeto.
Obter Requisitos
Elaborar Projeto
Refinamento do Rápido
Protótipo
Construir Protótipo
Avaliar Protótipo
30
O Modelo Espiral
31
O Modelo Espiral (Boehm, 1986)
O modelo espiral acopla a natureza iterativa da
prototipação com os aspectos controlados e
sistemáticos do modelo cascata.
O modelo espiral é dividido em uma série de
atividades de trabalho ou regiões de tarefa.
Existem tipicamente de 3 a 6 regiões de tarefa.
Combina as características positivas da gerência
baseline (documentos associados ao processo);
32
O Modelo Espiral (com 4 regiões)
DETERMINAR OBJETIVOS, AVALIAR ALTERNATIVAS
ALTERNATIVAS E IDENTIFICAR, RESOLVER RISCOS
RESTRIÇÕES Risk
analys is
Risk
analys is
Risk
analys is Opera-
Prot otyp e 3 ti onal
Prot otyp e 2 protoyp e
Risk
REVIEW analysis Prot o-
ty pe 1
Requirements plan Sim ul ati ons, m odels, b en ch marks
Life-cycle plan Concept o f
Operati on S/W
requi rement s Prod uct
desi gn Detail ed
Requi rement desi gn
Develop ment
plan valid ati on Code
Desi gn Uni t tes t
Integrati on
and test p lan V& V Integr ati on
Accep tance test
PLANEJAR PRÓXIMA FASE test
Serv ice DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
33
O Modelo Espiral (com 4 regiões)
DETERMINAR OBJETIVOS, AVALIAR ALTERNATIVAS
ALTERNATIVAS E IDENTIFICAR, RESOLVER RISCOS
RESTRIÇÕES Risk
analys is
Risk
analys is
cada ciclo na espiral Risk
analys is
Prot otyp e 3
Opera-
ti onal
representa uma Risk
Prot otyp e 2 protoyp e
REVIEW analysis Prot o-
fase do processo de
Requirements plan
ty pe 1
Sim ul ati ons, m odels, b en ch marks
software Life-cycle plan Concept o f
Operati on S/W
requi rement s Prod uct
desi gn Detail ed
Requi rement desi gn
Develop ment
plan valid ati on Code
Desi gn Uni t tes t
Integrati on
and test p lan V& V Integr ati on
Accep tance test
PLANEJAR PRÓXIMA FASE test
Serv ice DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
34
O Modelo Espiral de Processo
de Software
o ciclo mais interno
está concentrado
nas possibilidades
do sistema
Risk
REVIEW analysis Proto-
ty pe 1
Requirements plan
Life-cycle plan Concept o f
Operati on
35
O Modelo Espiral de Processo
de Software
o próximo ciclo está
concentrado na Risk
analys is
definição dos Prototype
requisitos do
Simul ati ons, models, benchmarks
sistema
SW
requi rements
Development Requi rement
plan validati on
36
O Modelo Espiral de Processo
de Software
Risk
analys is
prototype 3
o ciclo um pouco
mais externo está
si mul ati ons, models, benchmarks
concentrado no
projeto do sistema Product
desi gn
Integrati on Desi gn
and test plan V&V
37
O Modelo Espiral de Processo
de Software
Risk
nalys is
Opera-
ti onal
protoype
um ciclo ainda mais
externo está Simul ati ons, models, benchmarks
concentrado na
Detail ed
construção do desi gn
Code
sistema Uni t tes t
Integrati on
Acceptance test
Serv ice test
38
O Modelo Espiral (com 4 regiões)
DETERMINAR OBJETIVOS, AVALIAR ALTERNATIVAS
ALTERNATIVAS E IDENTIFICAR, RESOLVER RISCOS
RESTRIÇÕES Risk
analys is
não existem fases fixas no modelo Risk
analys is
Risk
as fases mostradas na figura são meramente analys is
Prot otyp e 3
Opera-
ti onal
Prot otyp e 2 protoyp e
exemplos REVIEW
Risk
analysis Prot o-
ty pe 1
a gerência decide como estruturar o projeto
Requirements plan
Life-cycle plan Concept o f
Sim ul ati ons, m odels, b en ch marks
Operati on S/W
em fases requi rement s Prod uct
desi gn Detail ed
Requi rement desi gn
Develop ment
plan valid ati on Code
Desi gn Uni t tes t
Integrati on
and test p lan V& V Integr ati on
Accep tance test
PLANEJAR PRÓXIMA FASE test
Serv ice DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
39
O Modelo
Cada “loop”Espiral
do espiral(com
é dividido
4 regiões)em 4
setores
DETERMINAR OBJETIVOS, AVALIAR ALTERNATIVAS
ALTERNATIVAS E IDENTIFICAR, RESOLVER RISCOS
RESTRIÇÕES Risk
analys is
Risk
AVALIAÇÃO E
ESTABELECIMENTO DE analys is REDUÇÃO DE
Risk
OBJETIVOS analys is RISCOS Opera-
Prot otyp e 3 ti onal
Prot otyp e 2 protoyp e
Risk
REVIEW analysis Prot o-
ty pe 1
Requirements plan Sim ul ati ons, m odels, b en ch marks
Life-cycle plan Concept o f
Operati on S/W
requi rement s Prod uct
desi gn Detail ed
PLANEJAMENTO
Develop ment Requi rement DESENVOLVIMENTO E desi gn
plan valid ati on
VALIDAÇÃO Code
Uni t tes t
Integrati on Desi gn
and test p lan V& V Integr ati on
Accep tance test
PLANEJAR PRÓXIMA FASE test
Serv ice DESENVOLVER, VERIFICAR O
PRODUTO NO PRÓXIMO NÍVEL
40
O Modelo Espiral de Processo
de Software são definidos objetivos
específicos para a fase do projeto
são identificadas restrições sobre
o processo e o produto
ESTABELECIMENTO DE é projetado um plano de
OBJETIVOS gerenciamento detalhado
são identificados riscos do
projeto
dependendo dos riscos,
estratégias alternativas podem
ser planejadas
41
O Modelo Espiral de Processo
de Software
para cada um dos riscos
identificados,
COLOCAÇÃO DEuma análise AVALIAÇÃO E
detalhada é executada.
OBJETIVOS REDUÇÃO DE
passos são tomados para reduzir o RISCOS
risco
42
O Modelo Espiral de Processo
de Software
AVALIAÇÃO E
ESTABELECIMENTO DE REDUÇÃO DE
OBJETIVOS RISCOS
depois da avaliação do risco, um
modelo de desenvolvimento é DESENVOLVIMENTO
escolhido para o sistema E VALIDAÇÃO
43
O Modelo Espiral de Processo
de Software
AVALIAÇÃO E
COLOCAÇÃO DE REDUÇÃO DE
OBJETIVOS RISCOS
o projeto é revisto e é tomada
uma decisão de continuidade
se é decidido continuar, são
projetados planos para a próxima
DESENVOLVIMENTO
PLANEJAMENTO
fase do projeto (próximo “loop” )
E VALIDAÇÃO
44
O Modelo Espiral
engloba as melhores características do ciclo de
vida Clássico e da Prototipação, adicionando um
novo elemento: a Análise de Risco
segue a abordagem de passos sistemáticos do
Ciclo de Vida Clássico incorporando-os numa
estrutura iterativa que reflete mais realisticamente
o mundo real
usa a Prototipação em todas as etapas da
evolução do produto, como mecanismo de redução
de riscos
45
Comentários sobre o Ciclo de
Vida em Espiral
usa uma abordagem que capacita o
desenvolvedor e o cliente a entender e
reagir aos riscos em cada etapa evolutiva
pode ser difícil convencer os clientes que
uma abordagem "evolutiva" é controlável
46
Comentários sobre o Ciclo de
Vida em Espiral
exige considerável experiência na
determinação de riscos e depende dessa
experiência para ter sucesso
o modelo é relativamente novo e não tem
sido amplamente usado. Demorará muitos
anos até que a eficácia desse modelo possa
ser determinada com certeza absoluta
47
O Modelo Espiral
adiciona um novo elemento: a Análise de Risco
usa a Prototipação, em qualquer etapa da
evolução do produto, como mecanismo de redução
de riscos
exige considerável experiência na determinação de
riscos e depende dessa experiência para ter
sucesso
48
O MODELO BASEADO EM
COMPONENTES
49
O Modelo Baseado em
Componentes
Utiliza tecnologias orientadas a objeto
Quando projetadas e implementadas
apropriadamente as classes orientadas a
objeto são reutilizáveis em diferentes
aplicações e arquiteturas de sistema
O modelo de montagem de componentes
incorpora muitas das características do
modelo espiral.
50
O Modelo de Montagem de
Componentes
Planejamento
Análise de Riscos
Comunicação
com Cliente
Avaliação do Cliente
Engenharia 51
Construção e Liberação
O Modeloidentificar
de Montagem de
Componentes
componentes
candidatas
Construir a na
procurar Planejamento
componentes iteração do
na biblioteca sistema Análise de Riscos
extrair
Comunicação colocar os
componentes
com Cliente novos
se disponíveis componentes
na biblioteca
construir os
componentes
não
Avaliação do Cliente
disponíveis
Engenharia 52
Construção e Liberação
O Modelo Baseado em
Componentes
O modelo baseado em componentes conduz ao
reuso do software
a reusabilidade fornece uma série de benefícios:
redução de até 70% no tempo de desenvolvimento
redução de até 84% no custo do projeto
índice de produtividade de até 26.2 (normal da indústria é de
16.9)
esses resultados dependem da robustez da biblioteca
de componentes
53
Processo Unificado da
Rational
54
O que é o RUP?
O nome é uma abreviação de Rational
Unified Process
mas na verdade é
Processo + Métodos + Linguagem (UML)
e os autores argumentam que é
Framework para gerar processos
O que é o RUP?
Conjunto de atividades
bem definidas
com responsáveis
com artefatos de entrada e saída
com dependências entre as mesmas e ordem de execução
com modelo de ciclo de vida
descrição sistemática de como devem ser realizadas
guias (de ferramentas ou não), templates
utilizando diagramas de UML
Características Principais do
RUP
O desenvolvimento de sistemas seguindo o
RUP é
Iterativo e incremental
Guiado por casos de uso (use cases)
Baseado na arquitetura do sistema
O RUP é iterativo e
incremental
O ciclo de vida de um sistema consiste de
quatro fases:
concepção elaboração construção transição
tempo
Concepção (define o escopo do projeto)
Elaboração (detalha os requisitos e a arquitetura)
Construção (desenvolve o sistema)
Transição (implanta o sistema)
O RUP é iterativo e
incremental
Cada fase é dividida em iterações:
Inception Elaboration Construction Transition
Preliminary Architect. Architect. Devel.. Devel.. Devel.. Transition Transition
iteration iteration iteration iteration iteration iteration iteration iteration
Minor Milestones: Releases
O RUP é iterativo e
incremental
Cada iteração
é planejada
realiza uma seqüência de atividades (de
elicitação de requisitos, análise e projeto,
implementação, etc.) distintas
geralmente resulta em uma versão executável do
sistema
é avaliada segundo critérios de sucesso
previamente definidos
O RUP é iterativo e incremental
Passos dentro de
uma iteração
Iteração e Workflow
Fases
Core Workflows Concepção Elaboração Construção Transição
Requisito
Uma iteração na
Análise fase de Elaboração
Desenho
Implemen-
tação
Teste
Iteração ite r. ite r. ite r. ite r. ite r. ite r. ite r.
Preliminar #1 #2 #n #n+1 #n+2 #m #m +1
O RUP é guiado por casos de
uso
Os casos de uso não servem apenas para
definir os requisitos do sistema
Várias atividades do RUP são guiadas pelos
casos de uso:
planejamento das iterações
criação e validação do modelo de projeto
planejamento da integração do sistema
definição dos casos de teste
O RUP é baseado na
arquitetura do sistema
Arquitetura
visão geral do sistema em termos dos seus
subsistemas e como estes se relacionam
A arquitetura é prototipada e definida logo
nas primeiras iterações
O desenvolvimento consiste em
complementar a arquitetura
A arquitetura serve para definir a
organização da equipe de desenvolvimento e
identificar oportunidades de reuso
Organização do RUP
Fluxos de atividades
Atividades
passos
entradas e saídas
guias (de ferramentas ou não), templates
Responsáveis (papel e perfil, não pessoa)
Artefatos
Exemplo de Fluxo:
Planejamento e Gerenciamento
Iniciar Aprovar Atestar
Projeto Projeto Conclusão
Contratante do Projeto
Identificar
Riscos Executar
Estudar Plano de
Viabilidade Iteração
Desenvolve Desenvolve Finalizar
Avaliar
r Plano de r Plano de Projeto
Iteração
Projeto Iteração
Gerente de Reavaliar
projeto Riscos
Priorizar
Arquiteto Casos de
Uso
Resumo
O RUP é:
iterativo e incremental
guiado por casos de uso
baseado na arquitetura do sistema
organizado em fases, iterações, fluxos,
atividades e passos
Vamos Navegar pelo RUP
Entre no site:
[Link]
68
Métodos Ágeis
69
Novos ventos no mundo do
Desenvolvimento de Software
Sociedade demanda
grande quantidade de sistemas/aplicações
software complexo, sistemas distribuídos,
heterogêneos
requisitos mutantes (todo ano, todo mês, todo dia)
Mas, infelizmente,
não há gente suficiente para
desenvolver tanto software com qualidade.
Problemas
Com metodologias de desenvolvimento
Supõem que é possível prever o futuro
Pouca interação com os clientes
Ênfase em burocracias (documentos, formulários,
processos, controles rígidos, etc.)
Avaliação do progresso baseado na evolução da
burocracia e não do código
Com software
Grande quantidade de erros
Falta de flexibilidade
Como resolver esse impasse?
Melhores Tecnologias
Padrões de Projeto (reutilização de idéias)
Componentes (reutilização de código)
Middleware (aumenta a abstração)
Melhores Metodologias
Métodos Ágeis
outras... (RUP, relacionadas a CMM, etc.)
Métodos Ágeis de
Desenvolvimento de Software
Movimento iniciado por programadores
experientes e consultores em desenvolvimento
de software.
Questionam e se opõe a uma série de
mitos/práticas adotadas em abordagens
tradicionais de Engenharia de Software e
Gerência de Projetos.
Manifesto Ágil:
• Assinado por 17 desenvolvedores em Utah em
fevereiro/2001.
O Manifesto do
Desenvolvimento Ágil de Software
1. Indivíduos e interações são mais importantes
que processos e ferramentas.
2. Software funcionando é mais importante do
que documentação completa e detalhada.
3. Colaboração com o cliente é mais importante
do que negociação de contratos.
4. Adaptação a mudanças é mais importante do
que seguir o plano inicial.
Princípios do Manifesto Ágil
Objetivo: satisfazer o cliente entregando,
rapidamente e com freqüência, sistemas com
algum valor.
Entregar versões funcionais em prazos curtos.
Estar preparado para requisitos mutantes.
Pessoal de negócios e desenvolvedores juntos.
Troca de informações através de conversas diretas.
75 / 69
Principais Métodos Ágeis
Crystal (uma família de métodos)
Scrum
Programação eXtrema (XP)
Adaptive Software Development
Feature Driven Development
etc.
A família Crystal de Métodos
Criada por Alistair Cockburn
[Link]
Editor da série Agile Software Development da
Addison-Wesley.
Scrum
Definição informal:
Estratégia em um jogo de rugby onde
jogadores colocam uma bola quase perdida
novamente em jogo através de trabalho em
equipe.
Scrum
Scrum é um esqueleto de processo que
contém grupos de práticas e papéis pré-
definidos. Os principais papéis são:
ScrumMaster, que mantém os processos
(normalmente no lugar de um gerente de projeto);
Proprietário do Produto, ou Product Owner, que
representa os stakeholders e o negócio;
a Equipe, ou Team, um grupo multifuncional com
cerca de 7 pessoas e que fazem a análise,
projeto, implementação, teste etc.
79
Programação eXtrema
XP
Metodologia de desenvolvimento de software
aperfeiçoada nos últimos 5 anos.
Ganhou notoriedade a partir da
OOPSLA’2000.
Nome principal: Kent Beck
Também importante: Ward Cunningham
A Quem se Destina os
Métodos Ágeis
Grupos de 2 a 10 programadores
Projetos de 1 a 36 meses (calendário)
De 1000 a 250 000 linhas de código
Características Comuns dos
Métodos Ágeis
Coloca o foco
Na entrega freqüente de sub-versões do software
[funcionando] para o cliente.
Nos seres humanos que desenvolvem o software.
Retira o foco de
Processos rígidos e burocratizados.
Documentações e contratos detalhados.
Ferramentas que são usadas pelos seres humanos.
Para escolha de um Modelo de
Processo de Software:
natureza do projeto e da aplicação
métodos e ferramentas a serem usados
controles e produtos que precisam ser
entregues
83
Exercício
Você e mais 4 sócios resolveram criar uma empresa de
desenvolvimento de Software e você ficou responsável por definir
algumas áreas da empresa. Cada questão abaixo será a sua parte
para a criação desta empresa.
1) Defina uma abordagem para o desenvolvimento de software que compreenda os
benefícios dos modelos de desenvolvimento clássicos (Cascata, prototipação e
Espiral). Inclua as características de outros modelos se achar necessários.
2) Defina uma abordagem para fazer a analise da viabilidade de sistemas a serem
desenvolvidos. Esta abordagem consiste de uma relação das atividades em ordem
cronológica para analisar a viabilidade de qualquer sistema que for desenvolvido
pela empresa.
3) O seu primeiro sistema a ser desenvolvido pela nova empresa de
desenvolvimento de software será para a Farmácia “Pague Pouco”. Eles querem
informatizar o sistema de vendas e controle de estoque, desejam armazenar a
seguinte informação: qual vendedor vendeu qual produto para qual cliente. Relate,
de acordo com o modelo de software criado na primeira questão e com a abordagem
de analise da segunda, quais a as atividades deverão ser realizadas para o
84
desenvolvimento do sistema da Farmácia “Pague Pouco”.