Upload
dangnhi
View
215
Download
0
Embed Size (px)
Citation preview
Processo de SoftwareIntrodução
Processo de SoftwareIntrodução
http://www.labes.ufpa.br2
OrganizaçãoParte I
Processo de SoftwareMotivação e Definições IniciaisCMM e mpsBrDefinições
Modelos de Processo de SoftwareModelo Sequencial LinearModelo de PrototipagemModelo RADModelos Evolucionários: EspiralDesenvolvimento baseado em componentes
Parte IIProcesso Unificado
Motivação e Definições Iniciais
Processo de Software
http://www.labes.ufpa.br4
Processo de SoftwareDefinições (Sommerville)
Processo de SoftwareConjuntos de atividades para especificação, projeto, implementação e teste de sistemas de software
Modelo de Processo de SoftwareUm modelo de processo de software é umarepresentação abstrata de um processo. Apresenta a descrição de um processo a partir de uma perspectiva particular.
http://www.labes.ufpa.br5
Motivação Adicional
Processos vem sendo propostos pela indústria, países e academia
Análise Estruturada (Yourdon, Gane)Objectory (Jacobson)V-Model (Alemanha)Rational Unified Process - RUPXP - eXtreme Programming
http://www.labes.ufpa.br6
Motivação Adicional
Processos vem sendo propostos pela indústria, países e academia
NetBeans Release Management(in OPEN SOURCE SOFTWARE DEVELOPMENT PROCESS MODELING, Lonchamp, 2005)
RationalUnifiedProcess(A&D Workflow)
http://www.labes.ufpa.br7
Processo de SoftwareProcesso de construção de um prédio
Atividades
Problema Solução
http://www.labes.ufpa.br8
Processo de Software
Atividades
Problema Solução
dadosrelatórios
restriçõesprocedimentos
Software
Modelo deProcesso de Software
http://www.labes.ufpa.br9
Processo de SoftwareParadoxo:
Para todos os programas construídos há a necessidade de se entender os requisitos e o processo de negócio do contratanteNa grande maioria das situações não hádocumentação de como a organização de desenvolvimento de software vai agir para atender a requisiçãoSe a organização não sabe nem como trabalha, como vai descrever soluções para terceiros?
http://www.labes.ufpa.br10
Processo de Software
Modelo e Processo de Software
Processo de Sw:o que acontece na realidade
Modelo de Processo de Sw:representação abstrata daquilo de comoproceder ou do que ocorreu em um processo
http://www.labes.ufpa.br11
Processo de Software
2ª definição para Processo de Software“Todos os elementos do mundo real envolvidos no desenvolvimento e manutenção de um produto de software”Inclui os recursos, ferramentas, atividades, artefatos e organização (Derniame, 1998 apud GDPA)
http://www.labes.ufpa.br12
Processo de SoftwareFases Genéricas do Processo de Sw
Fase de Definição: o quêEngenheiro de Software tenta identificar: que informação deve ser processada, que função e desempenho são desejados, que comportamento deve ser esperado do sistema, que interfaces devem ser estabelecidas, quais restrições de projeto, quais critérios de validaçãoOs requisitos-chave do sistema e do software são identificados
http://www.labes.ufpa.br13
Processo de SoftwareFases Genéricas do Processo de Sw
Fase de Desenvolvimento: comoDefinição de como os dados devem ser estruturados, como a função deve ser implementada dentro da arquitetura do software, como os detalhes procedimentais devem ser implementados, como as interfaces devem ser caracterizadas, como o projeto deve ser traduzido em linguagem de programação, e como o teste deve ser realizado
http://www.labes.ufpa.br14
Processo de Software
Fases Genéricas do Processo de SwFase de Manutenção: modificações
Tipos: Corretiva, Adaptativa, Perfectiva e PreventivaReengenharia é um tipo de manutenção que normalmente implica ou deriva da reengenharia dos processos de negócios da organização usuária
http://www.labes.ufpa.br15
Motivação
Crise do Software30% dos projetos de software são cancelados antes de sua conclusãoDo restante, 70% não atendem as expectativasEm média, os projetos ultrapassam em 189% seus orçamentos e em 220% seus cronogramas (The Standish Group, numa análise de 8000
projetos em 352 empresas)
http://www.labes.ufpa.br16
MotivaçãoCausas para a Crise do Software
Freqüentemente o problema não é tecnológicoAs ferramentas disponíveis são boas e bem documentadasOs profissionais são bem treinados, estão disponíveis em boa quantidade e definitivamente sabem utilizar as ferramentas disponíveis
Problemas nos profissionaisBaixa capacidade de comunicação e dificuldade para trabalho em grupoGerente incapaz de obter feedback acerca do andamento
Na maioria das situações, o processo de software éinexistente
http://www.labes.ufpa.br17
MotivaçãoEvolução do desenvolvimento de software (Antigamente)
Atividade solitária, onde o sucesso era determinado por bons analistas/programadores com domínio da tecnologia envolvidaO cliente possuía pouco domínio da tecnologia envolvidaO software desenvolvido normalmente estava relacionado com as atividades-meio do cliente
Exemplos: Folha de pagamento, Controle de PatrimônioDistribuição de dados e aplicações era limitada ao domínio físico de redes locaisDesenvolvimento de software - “um tipo de Arte”
http://www.labes.ufpa.br18
MotivaçãoEvolução do desenvolvimento de software (Hoje)
Grande quantidade e variedade de profissionaisEx: Designers, DBA, Especialistas em web, Programação de sistemas distribuídos
O cliente possui domínio acerca da tecnologiaSoftware desenvolvido para atividades-fim
Aplicações críticas para o negócio do clienteExemplo: e-business
Distribuição de dados e aplicações: InternetDesenvolvimento de software
Exigência de abordagem metodológica por parte do clienteEmpresas espalhadas em diferentes regiões
http://www.labes.ufpa.br19
MotivaçãoCrescente importância de métodos para avaliação da qualidade de software baseados no processo
Capability Maturity Model (SEI-CMM) e SPICE (ISO)Avalia uma organização segundo:
capacidade de produzir resultados planejadosmaturidade, a qual indica o crescimento contínuo dacapacidade;
Qualidade na definição do processo é um dos elementos-chave para que uma organização possa atingir melhores níveis de maturidade;Utilizado por governos e empresas para a contratação de serviços
CMMCMM-SW, CMMi
Processo de Software
http://www.labes.ufpa.br21
MotivaçãoCMM – Capability Maturity Model for Software
Desenvolvido em 1987 pelo SEI - Software Engineering Institute, filiado à Universidade Carnegie Mellon.Avalia uma organização pela sua capacidade de produzir resultados planejados e pela suamaturidade, a qual indica o crescimento contínuodesta capacidade.1991, segunda versão: Modelo de Capacidade daMaturidade do ProcessoUm dos requisitos para se obter maturidade no modelo SEI é o amplo suporte à gerência do processo.
http://www.labes.ufpa.br22
Capability Maturity ModelCapability Maturity Model
http://www.labes.ufpa.br23
CMM – Nível InicialProcesso de desenvolvimento caótico;Falta de integração;Sucesso dos projetos se deve a esforços heróicos;Diante de uma crise, a organização abandona os procedimentos definidos e reverte à codificação e testes.
Chega desse negócio de projeto!Estamos atrasados!
Vamos COMEÇAR A PROGRAMAR!!!
http://www.labes.ufpa.br24
CMM – Nível RepetívelGerência do projeto, segurança do produto e controle de mudanças já estabelecidos;A organização cumpre seus prazos e orçamentos;Sucesso através de administração de projetosbásica, convencional;Se o gerente de projetos deixar essaorganização, os projetos poderão “cair porterra”.
http://www.labes.ufpa.br25
CMM – Nível DefinidoEstabelecimento de um Grupo de Processo de Engenharia de Software responsável por:
focalizar e cobrir os esforços de melhoria do processo;manter a gerência informada do estado desses esforçosfacilitar a introdução de métodos e técnicas de engenharia de software.
O processo foi codificado e institucionalizadoExiste um processo formal definido que todos seguemConstante possibilidade de melhoria do processo;Falta de avaliação da eficiência
http://www.labes.ufpa.br26
CMM – Nível GerenciadoConjunto de métricas de qualidade e produtividade foiestabelecido;Banco de dados do processocom análises de recursos e experiências disponíveis paraconsulta;Ênfase na coleta de métricaspara melhorar a qualidadetanto do processo quanto do produto
http://www.labes.ufpa.br27
CMM – Nível OtimizadoA organização possui Know-how para identificar seuselementos de processo mais fracos e reforçá-los;Disponibilidade de dados para justificativa da aplicaçãoda tecnologia;Coleta de dados automatizada (ou parcialmente);A gerência preocupa-se com a melhoria do processo aoinvés de com os reparos nos produtos;Análise rigorosa da causa dos defeitos e prevenção de falhas.
http://www.labes.ufpa.br28
CMMConsiderações
Cada nível forma uma plataforma necessária para o próximo;Brasil: crescente número de organizações nos níveis2 e 3;Para alcançar níveis elevados de maturidade, a organização deve preocupar-se com a gerência e o controle do processo;Compradores:
Avaliação dos fornecedoresRequisitos para exportação de software para governo EUA
http://www.labes.ufpa.br29
Processo de Software
Evolução damaturidade
http://www.labes.ufpa.br30
CMM
Certificação
http://www.labes.ufpa.br31
CMM
Papéis e responsabilidadesbem definidos
Processo improvisado
Existe base histórica Não existe base histórica
A qualidade dos produtos eprocessos é monitorada
Qualidade e funcionalidade doproduto sacrificadas
O processo pode ser atualizado Não há rigor no processo aser seguido
Existe comunicação entre ogerente e seu grupo
Resolução de crises imediatas
Organizações maduras Organizações imaturas
Construir software consiste naaplicação de técnicas
Construir software é “arte”
http://www.labes.ufpa.br32
CMMNível CMM Foco Áreas-chave de processo
Inicial Pessoas competentes e heróis
RepetívelProcessos degerenciamento
de projetos
- Gerenciamento de requisitos- Planejamento do projeto- Visão geral e acompanhamento do projeto- Gerenciamento de subcontratados- Garantia da qualidade do software- Gerenciamento de configuração
Definido Processos de engenhariae apoio
- Definição do processo organização- Programa de treinamento- Gerenciamento de software integrado- Engenharia de produto de software- Coordenação intergrupos- Revisão conjunta
Gerenciado Qualidade do produto edo processo
- Gerenciamento quantitativo dos processos- Gerenciamento da qualidade de software
Otimizado Melhoramento contínuodo processo
- Prevenção de defeitos- Gerenciamento de mudanças tecnológicas- Gerenciamento de mudanças no processo
mpsBr
Processo de Software
http://www.labes.ufpa.br34
mpsBr“O mpsBr é um projeto estruturante que vai promover a qualificação de um grupo amplo de empresas compatível com os padrões de qualidade aceitos internacionalmente pela comunidade de software, a custos acessíveis para a grande maioria das empresas brasileiras, sendo adequado ao perfil e cultura das empresas de software do país.”
Página do Softex
http://www.labes.ufpa.br35
mpsBr
http://www.labes.ufpa.br36
mpsBr
A divisão em estágios, embora baseada nos níveis de maturidade do CMMISE/SWSMtem uma graduação diferente, com o objetivo de possibilitar uma implementação eavaliação mais gradual e adequada às pequenas e médias empresas. A possibilidadede se realizar avaliações considerando mais níveis permite uma visibilidade dosresultados de melhoria de processos com prazos mais curtos.
Definições
Processo de Software
http://www.labes.ufpa.br38
Definições“Conjunto de todas as atividades realizadas no contexto de um projeto de desenvolvimento de software”[GRUHN04]
O conjunto de atividades necessárias para transformar os requisitos do usuário em software. [HUM89d]
O uso de um processo de software bem definido (automatizado ou não) leva à redução dos custos de produção, bem como à melhoria da qualidade e integridade do software [GIM94].
http://www.labes.ufpa.br39
Processo de SoftwareAcompanhamento do progresso de projetos
Você entende meu problema e minhas necessidades?Você pode projetar um sistema que resolverá meu problema ou satisfará minhas necessidades?Quanto tempo você levará para desenvolver meu sistema?Quanto irá custar o desenvolvimento desse sistema?
http://www.labes.ufpa.br40
Processo de SoftwareEntretanto... A definição de um processo não é bala de prata!
A existência prática com processos bem definidos énecessária para a maturidade das organizações
Porém, processos rigorosamente definidos mas não alinhados com os objetivos da organização são entraves burocráticos, e não fatores de produção
http://www.labes.ufpa.br41
DefiniçõesAtividades guarda-chuva: transversais às demais etapas
Acompanhamento e controle do projeto de softwareRevisões técnicas formaisGarantia de qualidade de softwareGestão de configuração de softwarePreparação e produção de documentosGestão de reutilizaçãoMediçãoGestão de Risco
http://www.labes.ufpa.br42
Definições
Caracterização
Estrutura comum de processo
Tarefas
Marcos, produtos finais ouintermediários sujeitos a entrega
Pontos de garantia deQualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
http://www.labes.ufpa.br43
DefiniçõesEstrutura Comum de Processo
É estabelecida definindo um pequeno número de atividades que são aplicáveis a todos os projetos de software, independente de seu tamanho ou complexidade
Estrutura comum de processo
Tarefas
Marcos, produtos finais ouintermediários sujeitos a entrega
Pontos de garantia deQualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
http://www.labes.ufpa.br44
Definições
Conjuntos de TarefasPermite que as atividades da estrutura sejam adaptadas às características do projeto e às necessidades da equipe de projeto
Estrutura comum de processo
Tarefas
Marcos, produtos finais ouintermediários sujeitos a entrega
Pontos de garantia deQualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
http://www.labes.ufpa.br45
Definições
Atividades guarda-chuva
Garantia de qualidadeGestão de configuração de softwareMedição
Estrutura comum de processo
Tarefas
Marcos, produtos finais ouintermediários sujeitos a entrega
Pontos de garantia deQualidade de software
Conjuntos de Tarefas
Atividades guarda-chuva
Modelos de Processo de Software
http://www.labes.ufpa.br47
Modelos de Processo de SoftwareRegistro histórico da prática passada e roteiro para o futuroTodo processo pode ser caracterizado como um ciclo:
Situação atual: o estado atual das “coisas”Definição do problema: identifica o problema específico a ser resolvidoDesenvolvimento Técnico: resolve o problemaIntegração da solução: entrega os resultados
statusquo
problemdefinition
technicaldevelopment
solutionintegration
Definiçãodo
Problema
DesenvolvimentoTécnico
Integração
SituaçãoAtual
http://www.labes.ufpa.br48
Modelos de Processo de SoftwareModelos Genéricos
Modelo Cascata (ou Modelo Sequencial Linear)Etapas separadas e distintas para especificação e desenvolvimento
PrototipagemModelo RADDesenvolvimento formal de sistemas
Um modelo de sistema matemático é transformado ou orienta a implementação
Desenvolvimento orientado a reusoO sistema é construído a partir de componentes existentes
Processos baseados em IteraçãoIncrementalEspiral
http://www.labes.ufpa.br49
Modelo de Processo vs Projetoshttp://www.phruby.com/publications/EuroPLoP2001.pdf
http://www.labes.ufpa.br50
Diferentes níveis de detalhe
Organização
Definição de Atividades
Definição de Artefatos
Definição de metasExemplos:“diminuir a taxa de defeitos”“lucro maior que X”
COMO
COMO Com ainda+ detalhe!
Modelo Cascata
Modelos de Processo de Software
http://www.labes.ufpa.br52
Cascata
http://www.labes.ufpa.br53
Cascata
O processo Cascata está associado às metodologias propostas nas décadas de 1970-1980
Notadamente as metodologias EstruturadasYourdonConstantineChris GanePage-Jones
http://www.labes.ufpa.br54
CascataPrincipais problemas
Projetos reais raramente seguem o fluxo seqüencialDificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicasO cliente precisa ter paciência
Indicado somente quando os requisitos são bem conhecidosPode ser usado em trabalhos acadêmicos com etapas bem definidasde “levantamento bibliográfico”
Raramente é usado na prática, apenas quandos os requisitos sãomuito bem definidos
Prototipagem
Modelos de Processo de Software
http://www.labes.ufpa.br56
Prototipagem
PressupostosO Cliente normalmente:
define um conjunto de objetivos gerais para o software,mas não identifica detalhadamente os requisitos de entrada, processamento ou saída
http://www.labes.ufpa.br57
Prototipagem
Ouvir ocliente
Construir e/ouRevisar oprotótipo
Clienteavalia oprotótipo
http://www.labes.ufpa.br58
PrototipagemVantagens
O progresso é visível e rápido nas primeiras iteraçõesÉ um método indicado para validar requisitos de interação com o usuário
ProblemasO cliente vê o que parecer ser uma versão executável do software, ignorando que o protótipo funciona de maneira precáriaO desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável
RAD
Modelos de Processo de Software
http://www.labes.ufpa.br60
RADDesenvolvimento rápido de aplicação
Incremental, com ciclo curtoÉ uma adaptação “de alta velocidade” do modelo seqüencial linear, no qual a rapidez é obtida com componentesFases
Modelagem do negócioModelagem dos dadosModelagem do processoGeração da aplicaçãoTeste e entrega
http://www.labes.ufpa.br61
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
team #1
team #2team #3
60 - 90 days
Uma seqüênciapara cada módulopor equipe
http://www.labes.ufpa.br62
RADPrincipais desvantagens
Nem todos os tipos de aplicação são apropriados para o RAD.
Se o sistema não puder ser adequadamente modularizado, a construção e seleção de componentes será problemática
Não é adequado quando são enfrentados riscos técnicos elevados
Por exemplo, adoção profunda de uma nova tecnologia
Desenvolvimento EvolucionárioModelo IncrementalModelo EspiralModelos de Processo de Software
http://www.labes.ufpa.br64
Desenvolvimento EvolucionárioPara a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema
Abordagem híbridaIteração
repetir partes do processo à medida que os requisitos do sistema evoluemPor exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitosCada ciclo desenvolve uma versão mais completa
http://www.labes.ufpa.br65
Desenvolvimento Evolucionário
Validation Finalversion
Development Intermediateversions
Specification Initialversion
Outlinedescription
Concurrentactivities
Sommerville:Descrição geral
Rascunhoinicial
Especificação
Desenvolvimento
Validação
Versãoinicial
Versõesintermediárias
Versãofinal
AtividadesConcorrentes
http://www.labes.ufpa.br66
Desenvolvimento Evolucionário -Incremental
Modelo IncrementalCombina Cascata com PrototipagemCada seqüência produz um incrementoExemplo: Processador de Texto
1o release: gestão básica de arquivos, edição e produção de documentos (núcleo do produto)2o: capacidades mais sofisticadas de edição3o: verificação sintática e gramatical4o: capacidade avançada de disposição de página
http://www.labes.ufpa.br67
Desenvolvimento Evolucionárioanalysis design code test
System/informationengineering
analysis design code test
analysis design code test
analysis design code test
increment 2
increment 3
increment 4
increment 1
delivery of1st increment
delivery of2nd increment
delivery of3rd increment
delivery of4th increment
calendar time
http://www.labes.ufpa.br68
Desenvolvimento Evolucionário -Incremental
VantagensOs clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele.
O primeiro estágio deve satisfazer os requisitos mais importantes e, assim, o software pode ser imediatamente usado
Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posterioresExiste um risco menor de fracasso completo do sistema
http://www.labes.ufpa.br69
Desenvolvimento Evolucionário -Incremental
ProblemasPode ser difícil mapear os requisitos para incrementos específicosÉ difícil identificar facilidades comuns que todos os incrementos exijam
http://www.labes.ufpa.br70
Desenvolvimento Evolucionário - Espiral
EspiralProposto Boehm (1988)O processo não é descrito como uma seqüência de atividades (com eventuais retornos)O processo é representado como uma espiral, onde cada loop representa uma fase do processo.
http://www.labes.ufpa.br71
Desenvolvimento Evolucionário - Espiral
O Processo Espiral é similar ao Incremental mas
Cada ciclo produz algo a ser avaliadonão necessariamente código
Gerência de Riscos embutida no processsoAo final de cada loop é perguntado “Devemos continuar?”
http://www.labes.ufpa.br72
Desenvolvimento Evolucionário - Espiral
Visão geral do processo
http://www.labes.ufpa.br73
Desenvolvimento Evolucionário - Espiral
http://www.labes.ufpa.br74
Desenvolvimento Evolucionário - Espiral
Setores da EspiralDefinição de objetivos
Especificação de objetivos para a faseIdentificação e Redução dos Riscos
Riscos são identificados e as atividades são levantadas para tratá-los
Desenvolvimento e ValidaçãoUm modelo de desenvolvimento para o sistema é escolhidaPode ser qualquer um dos modelos genéricos
PlanejamentoO projeto é revisadoSe a decisão for continuar, um novo loop da espiral é planejado
Desenvolvimento orientado a reuso
http://www.labes.ufpa.br76
Desenvolvimento orientado a reuso
Baseia-se na reutilização sistemática ondesistemas são integrados a partir de
Componentes existentes (in-house)Componentes de prateleira [COTS (Commercial-off-the-shelf)]
Estágios do processoAnálise dos componentesProjeto de sistema com reusoDesenvolvimento e integração
Processo promissor, mas existe poucaexperiência
http://www.labes.ufpa.br77
Desenvolvimento orientado a reuso
Especificaçãode Requisitos
Análise deComponentes
Modificação deRequisitos
Modificação deRequisitos
Projeto do Sistemacom Reuso
Desenvolvimentoe Integração
Validaçãohttp://www.labes.ufpa.br
78
Desenvolvimento orientado a reuso
Catalysis: Reuso baseado em componentes
SolutionBiz Problem
Req
uire
men
ts
Ana
lysis
Des
ign
Impl
emen
tatio
n
New
New
New
New
Ass
embl
e
Ass
embl
e
Ass
embl
e
Ass
embl
e
Reuse Process
http://www.labes.ufpa.br79
Desenvolvimento orientado a reuso
Catalysis: Reuso baseado em componentes
http://www.labes.ufpa.br80
Desenvolvimento orientado a reuso
Catalysis: Reuso baseado em componentesBusiness context, problem definition, solution constraints
Analyze, design, build, test cycles
Deliver solutions
Processo UnificadoIntrodução e VariaçõesProcesso Unificado
Introdução e Variações
http://www.labes.ufpa.br82
AgendaProcesso Unificado (USDP)
DefiniçõesRUP x USDPCaracterísticas do Processo Unificado
Descrição detalhada do Processo UnificadoProcessos DerivadosConclusões
Processo Unificado
Histórico e DefiniçõesRUP x USDPCaracterísticas do Processo
Unificadohttp://www.labes.ufpa.br
84
Processo Unificado
Definição principalO processo “oficial” definido para apoiar o uso da UMLNecessidade a partir do sucesso da UML como padrão de fato para especificação de software
http://www.labes.ufpa.br85
Processo Unificado
Histórico: UMLUnified Modeling Language (UML)
Linguagem visual para sistemas orientados a objetosUnified Method 0.8: 1995Padrão de fato e de direitoUML foi proposta somente como uma linguagem, sem orientação de uso (i.e., sem um processo)
http://www.labes.ufpa.br86
Processo Unificado
Histórico: Processo UnificadoBases históricas do Processo Unificado
Processo EspiralIteratividadeGerência de riscos
http://www.labes.ufpa.br87
Processo Unificado
Histórico: Processo Unificado
Bases históricas do Processo Unificado
Processo ObjectoryProposto por Jacobson et alProcesso direcionado pelos Casos de Uso
http://www.labes.ufpa.br88
Processo Unificado
O que é o Processo Unificado?Pode ter 2 respostas:
Modelo de Processo PadrãoProduto comercial da IBM/Rational
http://www.labes.ufpa.br89
Processo Unificado: Introdução
Definições: o que é Processo Unificado
...Modelo de Processo PadrãoDescrição de atividades que compõem um processo que adota UMLMais simples que a proposta da Rational
http://www.labes.ufpa.br90
Processo Unificado: IntroduçãoDefinições: O que é Processo Unificado
...Produto comercialDesenvolvido e mantido pela RationalIntegrado a suite de produtosDisponível em CD-ROM / InternetConhecido como Rational Unified ProcessE-coach: treinamento a distância
http://www.rational.com/rupPara o treinamento online, clicar em “Trials & Betas”
http://www.labes.ufpa.br91
http://www.labes.ufpa.br92
RUP em PortuguêsVersão não-oficial
disponível emhttp://www.wthreex.com/rup/index.htm
http://www.labes.ufpa.br93
Descrição do artefatoVision
http://www.labes.ufpa.br94
1
http://www.labes.ufpa.br95
2
http://www.labes.ufpa.br96
3
http://www.labes.ufpa.br97
4
http://www.labes.ufpa.br98
Gabarito do artefato de Visão(projetos pequenos)
Estrutura do Processo Unificado
http://www.labes.ufpa.br100
Processo Unificado
Estrutura do Processo UnificadoProcesso Iterativo, baseado no modelo Espiral
Iterativo: baseado em sucessivas versõesEspiral: inclui análise de riscos
http://www.labes.ufpa.br101
Processo Unificado
O que é um processo iterativo na prática?Produção de sucessivas versões de artefatosRepetição de um ciclo, onde em cada “volta”são avaliados novos requisitos
http://www.labes.ufpa.br102
Processo Unificado
Processo Centrado em Casos de Uso
1. ok 2. ok
3. falha4. ok
Modelo de TestesModelo de Componentes
Modelo de Dados
Modelo Temporal
http://www.labes.ufpa.br103
Processo Unificado
Estrutura do Processo Unificado
tempo
componentesdo processoagrupadoslogicamenteem workflows
http://www.labes.ufpa.br104
Processo Unificado
Estrutura do Processo Unificado
Uma iteração
http://www.labes.ufpa.br105
Milestones
Fases/Etapas
http://www.labes.ufpa.br107
Inic
iaçã
o
http://www.labes.ufpa.br108
Inic
iaçã
o
http://www.labes.ufpa.br109
Ela
bora
ção
http://www.labes.ufpa.br110Construção
http://www.labes.ufpa.br111
Tran
siçã
o
Workflows
http://www.labes.ufpa.br113
Workflowde Requisitos
http://www.labes.ufpa.br114
Workflow de Análise e Projeto
http://www.labes.ufpa.br115
Workflow de Implementação
http://www.labes.ufpa.br116
Workflow de Testes
http://www.labes.ufpa.br117
Workflow de Implantação
Descrição de Atividades
http://www.labes.ufpa.br119
Realizar síntese arquitetural
http://www.labes.ufpa.br120
Analisar o Problema
Processo Unificado: detalhamento das etapas
http://www.labes.ufpa.br122
Processo Unificado: detalhamento das fases
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br123
Processo Unificado: detalhamento das fases
IniciaçãoObjetivos
Estabelecer escopo do projeto e condições de fronteiraDescrever os casos de uso críticos do sistemaDescrever pelo menos uma arquitetura candidata para os principais casos de usoEstimar o custo e cronograma para a ElaboraçãoEstimar riscos (fontes de incerteza)
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br124
Processo Unificado: detalhamento das fases
IniciaçãoAtividades
Descrever o escopo do projetoCapturar o contexto na forma de requisitos e restrições para determinar um critério de aceitação do produto final
Planejar e preparar o Plano de NegóciosAvaliação de riscos, staff, plano de projeto e relações entre custo, cronograma e lucro
Preparar uma arquitetura candidadaAvaliar alternativas de projeto (atividade pode ser suprimida se o sistema não possui novidades ou possui uma arquitetura bem conhecida)
Preparar o ambiente de projeto (environment)Escolha de recursos físicos e humanos, e ferramentas de software
Obs: Geralmente a concepção é completada em dois dias ou menos para sistemas pequenos
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br125
Processo Unificado: detalhamento das fases
IniciaçãoArtefatos produzidos
O documento de Visão, isto é, a visão geral dos requisitos principais do sistema, incluindo funcionalidades principais e restriçõesO modelo de caso de uso, listando todos os casos de uso e atoresque podem ser identificados neste início (10% a 20% do total)Um glossário inicial do projetoUm plano de negócios inicial, contendo:
Contexto do negócio, Critério de sucesso (projeção de lucro, reconhecimento do mercado, etc), Provisionamento Financeiro
Análise de Riscos InicialUm plano de projeto (para etapa de Elaboração)Um ou mais protótipos
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br126
Processo Unificado: detalhamento das fases
IniciaçãoMilestone: Objetivos do ciclo de vida
Acordo com stakeholder acerca da definição de escopo, e estimativas de custo e cronogramaEntendimento dos requisitos (evidenciado pelos principais casos de uso)Estimativas reais de custo e cronograma, prioridades, riscos e processoProtótipo de Arquitetura do software
Iniciação Elaboração Construção Transição
Objetivos dociclo de vida
http://www.labes.ufpa.br127
Processo Unificado: detalhamento das fases
ElaboraçãoObjetivos
Definir e validar uma arquitetura baselineBaseline - release estável que serve como ponto de partida e referência no desenvolvimento futuro
Gerar uma Visão baselineGerar um plano detalhado para a fase de construçãoDemonstrar que a arquitetura baseline irá atender a revisão no custo e tempo estimados
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br128
Processo Unificado: detalhamento das fases
ElaboraçãoAtividades
Elaborar a visão: entendimento sólido dos casos de uso mais críticos (que determinam as decisões arquiteturais e de planejamento)A arquitetura é elaborada e componentes de software são selecionados
Componentes potenciais são avaliados segundo decisões make/buy/reuse para determinar custo e estimativaLições obtidas podem servir para gerar o novo projeto da arquitetura do sistema
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br129
Processo Unificado: detalhamento das fases
ElaboraçãoArtefatos produzidos
Um modelo de caso de uso (pelo menos 80% dos casos de uso)Requisitos suplementares que capturem requisitos não-funcionais e requisitos que não estão associados com um caso de uso específicoUma descrição da arquitetura de softwareUm protótipo arquitetural executávelUma lista revisada dos riscos e plano de negóciosUm plano para as próximas iteraçõesUm manual do usuário preliminar
Iniciação Elaboração Construção Transição
http://www.labes.ufpa.br130
Processo Unificado: detalhamento das fases
ElaboraçãoMilestone: Arquitetura
Perguntas:A visão do produto é estável?A arquitetura é estável?O plano para Construção está suficientemente detalhado e correto?
Iterações x ReleasesO cliente está de acordo com a visão?A alocação de recusos está de acordo com o previsto?
Iniciação Elaboração Construção Transição
Arquitetura
http://www.labes.ufpa.br131
Processo Unificado: detalhamento das fases
ConstruçãoAtividades:
Gerenciamento de recursosDesenvolver e testar os componentesAvaliar e, eventualmente, prosseguir para a próxima iteração
ArtefatosProduto de software integrado na plataforma de hardwareManuais de usuárioDescrição dos releases
Concepção Elaboração Construção Transição
http://www.labes.ufpa.br132
Processo Unificado: detalhamento das fases
ConstruçãoMilestone: Início da Capacidade Operacional
O release está maduro e estável para ser usado?Todos os stakeholders estão prontos para a transição?O consumo de recursos é aceitável?
Início da capacidade operacional
Concepção Elaboração Construção Transição
http://www.labes.ufpa.br133
Processo Unificado: detalhamento das fases
TransiçãoObjetivo geral:
Garantir que o software estjea disponível para usuários finaisAtividades
Finalizar o material de apoio ao usuário finalTestar o produto entregue
Simular o ambiente do cliente (se possível) ou instalar o software no cliente
Realizar um ajuste fino do produto com base no feedbackEntregar o produto final para o usuário
Concepção Elaboração Construção Transição
http://www.labes.ufpa.br134
Processo Unificado: detalhamento das fases
TransiçãoArtefatos
Release NotesÉ raro o produto que não possui instruções e modificações de “último-minuto”
Material de treinamento e documentação
Concepção Elaboração Construção Transição
http://www.labes.ufpa.br135
Processo Unificado: Como Aplicar em Pequenos Projetos
Idéias principaisIteratividadeAndamento do projeto ao redor dos casos de usoAnálise de riscos
Processos Derivados
http://www.labes.ufpa.br137
Processos Derivados
Grande número de processos surgiram para customizar ou estender o Processo UnificadoExperiências na indústria e academiaHá uma verdadeira coqueluche em adaptações de RUP para empresas específicas
http://www.labes.ufpa.br138
Processos Derivados
PraxisProcesso Acadêmico, desenvolvido na UFMGhttp://www.wppf.uaivip.com.br/praxis/
RUP-SmallGary Pollice et al
Unified Process for Education (UPEDU)Robillard & Kruchten
http://www.labes.ufpa.br139
Processos Derivados
Diversos textos e ferramentas são voltadas à adaptação do RUP para contextos especializados:
OrganizacionalTecnológicoMetodológico
O que falta?
http://www.labes.ufpa.br141
Estado da Arte
Tecnologia do Processo de SoftwareEdição, simulação, reutilização e execução automatizada de processos de softwareAspectos de implementação de ambientes e ferramentas para gestão de processosLinguagens de Modelagem de Processos