Metodologia de Desenvolvimento de Software – RUP Apresentação & Introdução

Processo de Desenvolvimento de Software – RUP

Apresentação & Introdução

Márcio Aurélio Ribeiro Moreira

[email protected]://si.lopesgazzani.com.br/docentes/marcio/

Márcio Moreira Apresentação & Introdução – slide 2Processo de Desenvolvimento de Software - RUP

Apresentação da Disciplina


Apresentação da disciplina

Objetivos da disciplina:Introduzir os conceitos relacionados ao RUPApresentar as Fases, Iterações e Disciplinas do

RUPApresentar práticas relacionadas ao RUPApresentar o material disponível do RUPRelacionar os fatores críticos de sucesso da

Engenharia de SoftwareDiscutir as habilidades e competências do

Engenheiro de Software


Ementa da disciplina

Apresentação e Introdução 1. Modelagem de Negócios 2. Requisitos 3. Análise & Projeto 4. Implementação 5. Testes 6. Distribuição 7. Gestão de Configuração e Mudança 8. Gestão de Projetos 9. Ambiente


Bibliografia

Fundamental:IBM Rational. RUP – Rational Unified Process – 7.5 –

For Large and Small Projects. 2008. IBM Rational.

Suplementar:Ivar Jacobson, Grady Booch, and James Rumbaugh.

The Unified Software Development Process. 1998. Addison Wesley Longman.

Per Kroll e Philippe Kruchten 2003. The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman.

Ian Sommerville. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.


Sistema de avaliação

50% Teórico:Média de “n” simulados

50% Prático:Média de “n” exercícios


Plano de aulas

Data Aulas Simulados Exercícios

1) 02/12/2014 Apresentação & Introdução Simulado 1

2) 03/12/20141.Modelagem de Negócios2. Requisitos

Simulado 2Simulado 3

Exercício 1

3) 04/12/2014 3. Análise & Projeto Simulado 4

4) 09/12/20144. Implementação5. Testes


Exercício 2

5) 10/12/20146. Distribuição7. Gestão de Configuração e Mudança


Exercício 3

6) 11/12/2014 8. Gestão de Projetos Simulado 9 Exercício 4

7) 16/12/20149. AmbienteCertificação

Simulado 10 Exercício 5


Introdução à Engenharia de Software


Problemas clássicos da ESOF1 •Desacoplamento das necessidades dos usuários e do negócio

2 •Mudanças de requisitos

3 •Os módulos não se integram

4 •Dificuldades de manutenção

5 •Descoberta tardia de falhas

6 •Baixa qualidade e experiência ruim do usuário

7 •Baixa performance para carga efetiva

8 •Dificuldades de gestão da equipe do projeto

9 •Construção e liberação de problemas

Fonte: KRO03


Dúvidas da engenharia de software

Qual a melhor forma de obter requisitos? Informal, Fluxos de Dados, DER ou Casos de Uso

O que é mais importante para o cliente?Saber logo se o projeto é viável e factível ouComeçar a ver telas do software funcionando

O que é mais fácil gerenciar?6 projetos de 30 dias ou1 projeto de 6 meses

Qual construção suportará mais mudanças?Uma feita com base na expertise de um mestre de obras

especialista ouUma feita pelo mesmo mestre de obras, mas com um projeto

estrutural considerando as necessidades atuais e futuras do prédio


Até 1969 Década de 70 Década de 80 Década de 90 Atualmente

Evolução dos softwares

Análise Clássica

A. Estruturada

A. Essencial

Modelagem O. Objeto

Programação ProceduralP. Estruturada

Orientada a Eventos O. Objetos

Testes: DepuraçãoProfissionalização

Qualidade Total

AutomaçãoCiclo Cascata Incremental Evolutivo e Espiral Iterativo & Incremental

Fontes: BEI90, CAR98, DEM89, GIL88, JAC98, KRU98, MSP91, MYE79, PRE95, SUM07 e YOU92

Engenharia de Software

Programa Monolítico

Modularização

Client-Server

Arquitetura MVC (Web)


Visão de Negócio (direção, gestão, administração)

Qualidade

Fatores críticos de sucesso da fabricação de software

Pessoas(CHA)

Infra-estruturaTI/comunicação

Gestão deProjetos

Processos

Clientes Clientes

Fonte

s: JA

C9

8,

KR

O0

3,

PR

E9

5 e

SU

M0

7


Pessoas(CHA)

Gestão de pessoas

CHA: Conhecimentos: Expertise em TI Habilidades: Trabalho em equipe, comunicação, foco, ... Atitudes: Assertividade, pró-atividade, ...

Desenvolver pessoas desenvolver a organização:Busca de propósitos comunsBusca da felicidade:

Harmonia entre pensamentos, expressão e ações

Capacitação e certificações Metas Tensão Criativa Superação Motivação Resultados Motivação Atração e retenção de talentos


Processos de engenhariade software Cascata – Uma disciplina só após a outra MSF – Microsoft Solutions Framework

Fases: visão, planejamento, estabilização e instalaçãoDisciplinas: projeto, riscos e competênciaMais ágil e menos formal que o RUP

RUP – Rational Unified ProcessDesenvolvido pela Rational (hoje da IBM)Processo mais utilizado atualmente

XP – Extreme ProgrammingAtividades: planejamento, projeto, codificação e testeGera sensação de produtividade constante

Processos

http://www.microsoft.com/technet/itsolutions/tandp/innsol/msfrl/default.asp


Comparativo de disciplinas

Disciplinas x Metodologias Cascata MSF RUP XP

Modelagem do Negócio

Requisitos

Análise

Projeto

Implementação

Testes

Distribuição (Instalação )

Gestão de Configuração e Mudanças

Gestão de Projeto

Ambiente


Maturidade e níveis de processos

Mat

urid

ade

de

TI

Alta

Baixa Fonte: ITIL – Planning to Implement Service Management

0 - Inexistente Não há procedimentosDesconhecimento do domínio

5 – Otimizado Processo de Melhoria Automação

4 - Gerenciado Processo de Medição Mudanças tecnológicas

3 – Definido InstitucionalizadoProcessos de métricas e análise

2 – Repetível Dependência de indivíduosPadronização, treinamento e teste

1 – Inicial Caótico (Tentativa e Erro)Planejamento e Gestão de projetos

Nível CaracterísticaÁrea Foco

(com problema)

Grupos de processos

Processos

Atividades

TarefasInstruções de Trabalho


Levantamento

Análise

Projeto

Implementação

Testes

O modelo cascata

Principais problemas:

O cliente participa do projeto somente no início e no final

Os riscos são mitigados no final do projeto Tem descoberta tardia de erros de projeto


O modelo iterativo

Iteração 1 Iteração 2 Iteração 3Levantamento

Análise

Projeto

Testes

Levantamento

Análise

Projeto

Testes

Levantamento

Análise

Projeto

Testes

Módulo 1 Módulo 2 Módulo 3


O modelo iterativo e incremental

Iteração 1 Iteração 2 Iteração 3Levantamento

Análise

Projeto

Testes

Levantamento

Análise

Projeto

Testes

Levantamento

Análise

Projeto

Testes

Módulo 1 Módulo 1 Módulo 2 Módulo 1Módulo 2M

ódulo

3


Nível de risco dos modelosRisco

Tempo

Cascata

Iterativo e

Incremental

Redução de Riscos

Fonte: KRO03


Progresso do projeto dos modelos

% d

e C

od

ific

ação

Co

mp

leto

do

Pro

jeto

Tempo

Protótipos Arquitetura Funcionalidades Produto

Processo Ite

rativo &

Incremental

Casca

ta Síndrome dos 90%

Fonte: KRO03


Custo das mudanças

Softwares atuais são complexos requisitos inexatos mudanças são necessárias (e devem ser estimuladas)

As mudanças devem ser detectadas e tratadas o mais cedo possível menor custo

Fonte: KRO03


Gestão de projetos (GP)

PMI – Project Management Institute:Project Management Body of Knowledge (PMBOK)Metodologia mais utilizada atualmente

Prince2 – Metodologia do governo inglês:Adotada em vários países europeus

TenSetpProcesso de uma multinacional americana que é

representante do PMI Agile

Resultante de um manifesto feito por 17 especialistas em Fevereiro de 2001 em Utah – USA

ISO 10006:A International Standards Organization tomou o PMI como

base e fez uma simplificação

Gestão de

Projetos


PMBOK do PMI – 47 Processos

Disciplinas Grupos de Processos

6

6 7

4 3

4

3

6

4

4

242

811

2


Verificação da qualidade

Projeto de Desenvolvimento

Requisitos Análise Projeto Testes

XQualidade


Qualidade

Fazer certo na primeira vezA qualidade deve ser meta e resultado em

todas as etapas do processo, não somente no final

É preciso garantir a qualidade do:Produto (resultante do projeto)Processo aplicado ao projetoE consequentemente:

do Projeto e das Pessoas.


Introdução ao RUP


Resumo do Histórico

RUP 5.5 & UML 1.3

RUP 5.0 & UML 1.2

ROP 4.1 & UML 1.1

ROP 4.0 & UML 1.0

Rational

Approach

(Booch)

OMT:

Objetory Process 3.8 (Rumbaugh)

1999

1998

1997

1996

1995

Fonte: RAT98 e IBM03

Requisitos

Modelagem de Negócio

Análise & Projeto

OOSE(Jacobson)

Gestão de Projetos

Testes

GC&M

Web D. R.Time

Booch Jacobson Rumbaugh


Histórico do RUP & do UML1994 •Em outubro James Rumbaugh se juntou Grady Booch (cientista chefe da Rational), eles resolveram criar um Método Unificado de Análise Orientada a Objetos unindo o método do Booch com o OMT (Object Modeling Technology) de Rumbaugh

1995 •Em outubro a versão 0.8 do UP (Unified Process) foi lançada e Ivar Jacobson entrou na Rational•A Rational comprou da Ericsson a Objectory AB (que havia sido Jacobson) com o OOSE (Object-Oriented Software Engineering)

1996 •Em junho, “os três amigos” lançaram a versão 4.0 do ROP (Rational Objetory Process) e a 1.0 do UML (Unified Modeling Language)•O ROP nasceu com as disciplinas de Análise & Projeto

1997 •O UML 1.0 é aprovado como padrão pelo OMG (Object Management Group) e o UML 1.1 é lançado•O ROP 4.1 é lançado com as disciplinas de Requisitos e Testes

1998 •“Os três amigos” publicaram o livro “The Unified Software Development Process” e o UML 1.2•O RUP 5.0 é lançado com as disciplinas de Modelagem de Negócios e Gestão de Configuração e Mudanças

1999 •O RUP 5.5 preparado para desenvolvimento web e/ou tempo real é lançado com a disciplina de Gestão de Projetos•O UML 1.3 é lançado

2002 •Em 6/Dez a IBM anunciou a compra da Rational que foi concluída em 21/2/2003


Estrutura do RUP

RUP 7.5:Projetos:

GrandesPequenos

Apresentar:IdiomasRUP 7.5Links para

download


Pilares estratégicos do RUP

Dirigido por Casos de UsoCentrado em ArquiteturaIterativo e Incremental

Fases e Iterações

Casos de Uso

Guia

Arquitetura

Dirige


As fases do RUP e seus objetivos

Iniciação (concepção):Definir o macro escopoVerificar a viabilidade econômica

Elaboração:Verificar a viabilidade técnicaDefinir a arquitetura básica (versão α)

ConstruçãoDesenvolver o software (versão β)

TransiçãoFazer testes de aceitação e entregar o produto


As iterações do RUP

São mini-projetos com objetivos de:Integração de middleware, versão-alfa, casos de uso ...

versão-beta e produto

Vantagens:Redução de riscosPercepção antecipadaQuebra da complexidadeFacilitação do gerenciamentoTrabalho com parte dos requisitosConstrução de builds executáveisEvolução incremental do sistema pelos componentes


•Compreensão da Engenharia do Negócio (por que)Modelagem de Negócios:

•Explicitação e coleta de requisitos (escopo: o que)Requisitos:•Transformação dos requisitos em especificação do software (como)Análise & Projeto:

•Desenvolve, organiza, testa a unidade e integra os componentes do softwareImplementação:

•Testa a qualidade do softwareTestes:•Distribui (instala) o software aos usuários (entrega), não é um projeto de implantação completoDistribuição:•Cuida do controle e sincronização dos componentes do softwareGestão de Configuração & Mudanças:

•Foca em planejamento, gestão de riscos e gestão do progresso do projetoGestão do Projeto:

•Cria e mantém o ambiente (processos e ferramentas) de desenvolvimento interno do softwareAmbiente:

Disciplinas do RUP

Esforço x Disciplina x Tempo


Problema clássico Mapeando o território

Do problema do clienteà solução do usuário

Necessidades

Funcionalidades

Requisitos doSoftware

Casos de Testes

Rastreabilidade

Projeto Docum.Usuário

Espaço doProblema

Espaço daSolução

Produtoa serfeito

Problema

Fonte: KRO03


X X XXX

Versões pré-definidas Grandes Projetos

Pequenos Projetos

Rational Method composer

Processo adaptável ao projeto

Artefatos

Tarefas

Atividades

Disciplinas

Fases

X

X

X X

X

X X

X X


Elementos essenciais do RUP

1. Visão:Desenvolva uma visão

2. Processo: Adote um processo para o projeto

3. Plano: Crie e gerencie o plano

4. Riscos:Mitigue riscos e rastreie problemas

5. Caso de Negócios: Examine o caso de negócios

6. Arquitetura: Projete arquitetura de componente

7. Protótipo: Construa e teste progressivamente

8. Avaliação: Avalie regularmente os resultados

9. Controle de Mudanças: Gerencie e controle as alterações

10. Suporte ao Usuário: Implemente um produto utilizável


Outros princípios chaves do RUP

Priorização• Decidir pelas prioridades de

negócio• Promove o alinhamento da TI

aos negócios

Trabalho em equipe• Focar em motivação,

autogestão, colaboração, etc.• Desenvolve o senso de

propósito

Iteratividade• Entregar valor a cada iteração• Cliente e usuário “veem” o

andamento

Elevar a abstração (arquitetura)• Arquitetar e reutilizar para simplificar e

quebrar a complexidade• Reuso adaptabilidade reduz o

TCO

Qualidade• Focar continuamente na

qualidade do processo e do produto

• Melhora a experiência do usuário


Quando utilizar o RUP

Baixa Complexidade de Gestão Alta

Bai

xaC

omp

lexi

dade

Téc

nica

Alta

Informal

Nível de Formalidade

Formal

Criar x Documentar

XP, SCRUM e Adaptive

Development

Cascata

Nível de Integração

Iterativo

CMM

CMMI

RUP para pequenos projetos

RUP para projetos de médio porte

RUP para grande projetos

Adapta

ção liv

re d

e:

JAC

98

, K

ER

04

, K

RO

03

e R

UP0

8


PORTE EMPRESA

24%

17%59%

Pequena Média Grande

TI NA EMPRESA

50%

33%

18%

De TI TI EstratégicaUsuária de TI

Pesquisa: metodologia em Uberlândia feita com 177 profissionais

PERFIL DAS PESSOAS

6%14%

12%67%

Alto Executivo GerenteCoordenador Analista

Fonte: MOR13


USA METODOLOGIA

67%

33%

Sim Não

METODOLOGIA

36%

24%

12%

10%

10%

8% 1%

SCRUM RUP Outros Ágeis

Cascata Outros XP

Crystal

Relação da empresa com metodologia

FASES DO RUP

Viabilidade $

Arquitetura

Testes Desenv

Testes Aceite

0% 20% 40% 60% 80%

57%

46%

69%

67%

Fonte: MOR13


Disciplinas utilizadas nas empresasM

. de

Neg

ócio

s

Requ

isito

s

Anál

ise &

Pro

jeto

s

Test

es

Ges

tão

de P

roje

tos

Ges

tão

C &

Mud

...

Dist

ribui

ção

Ambi

ente

0%

10%

20%

30%

40%

50%

60%

70% 64%68%

47%

58% 60% 59%56%

59%

59% de Similaridade com o RUP

Fonte: MOR13


Conclusões sobre o RUP

Ele resolveu os problemas clássicos do desenvolvimento de software

Ele definiu o que é a Engenharia de Software

Ele serviu de base para as metodologias que estão surgindo

Ele pode ser utilizado para projetos de todos os portes


Fluxos de trabalho do RUP

Início do fluxo

Término do fluxo

AtividadeAtividade

Atividades em paralelo


Detalhamento de fluxos de trabalho

Seqüenciamento

Tarefa

TarefaFunção (papel)

Produto do trabalho (artefato)

Entradas

Saídas


ReferênciasSigla ReferênciaBEI90 BEIZER, Boris. Software testing techniques. Scottdale: Coriolis Group, 1990, 2 ed.

CAR98 CARZANIGAYZ, A., et. al. A Characterization Framework for Software Deployment Technologies. Technical Report CU-CS-857-98, University of Colorado, April 1998.

DEM89 DeMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989.GIL88 Tom Gilb. Principles of Software Engineering Management. 1988. Harlow, England: Addison Wesley LongmanJAC98 Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process. 1998. Addison Wesley Longman.

KER04 KERZNER, Harold PhD. Strategic Planning for Project Management Using a Project Management Maturity Model; John Wiley & Sons, Inc., New York, 2001.

KRO03 Per Kroll e Philippe Kruchten 2003. The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman.

KRU98 P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. IBM03 IBM. Rational Unified Process: A Best Practices Approach. IBM. 2003.MSP91 MCMENAMIN, Stephen & PALMER, John. Análise essencial de sistemas. São Paulo : McGraw-Hill, 1991.MOR13 MOREIRA, Márcio; OLIVEIRA, Rogério. Aplicabilidade do RUP para o desenvolvimento mobile. Pitágoras. 2013.MYE79 MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979. PMB08 PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. 4ª Ed. Guia PMBOK©. USA. 2008. PMI.PRE95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books. 1995.RAT98 Rational. Rational Unified Process: Best Practices for Software Development Teams. Rational Software. 1998.RUP08 IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects. 2008. IBM Rational.SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.YOU92 YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1992.

http://www.eecg.utoronto.ca/~jacobsen/courses/ece1770/slides/rup.pdf

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf





Documents

Metodologia de Desenvolvimento de Software – RUP Apresentação & Introdução