Mais uma coisa legal que li no forum UML-BR. Segue na íntegra o post do membro:

“ Pessoal,

Gostaria de compartilhar com vocês um desabafo sobre como tenho visto a implantação de RUP aqui no Brasil o que tem feito dele um pequeno monstruinho, presumo que na maioria das empresas...

Alguns dos malentendidos classicos:

** Processo prescritivo vs. consultivo **

O malentendido vem da ideia vem de que um processo em outras engenharias, em processos fabris, tem que ser usado ipsis literis, passo a passo, e no desejo dos executivos e gerentes de tornar "desenvolvimento" em uma atividade menos riscosa, onde processos fossem o centro, ferramentas fissesem a transformação da matéria prima, e trabalhadores especializados operassem essas ferramentas que transformam a materia prima em produtos terminados... o paradigma da "Fabrica"...

Quanto será que esta custando este pequeno erro conceitual para as empresas...?

Já vi o Jacobson falando que maior e melhor *quando* vc tem mais informação para consultar e não mais processo para seguir... no RUP tem guidelines sobre unit testing e outras centenas de asuntos excelentes, tem checklists que tiram muitas duvidas, tem descrição de atividades com profundidade muito detalhadas... mais o espirito é fazer software não documentos... e a ideia era ter um corpo de conhecimento que pudesse ser consultado e não seguido...

** As 4 Fases do RUP = 4 etapas do Waterfall **

Outro malentendido, 10% das pessoas leem os livros os outros 90% so olham as figurinhas e não passam do primeiro capitulo, e ainda tiam conclusões dos titulos dos outros capitulos o que devem ser os conceitos la definidos.

RUP que usa modelo waterfall é uma abominação, e iterações que não entregam software so poderiam existir na primeira fase de Inception, mais eu prefiro que não existam para não descambar em processos de desenvolvimento de documentos e não de software.

** Iteratividade vs.. Waterfall **

Se o pessoal parte de que as 4 fases se asemelham ao modelo waterfall, então iteratividade é completamente abolida do projeto, ou fica como milestone de entregas de "artefatos" e não de software.

Uma insanidade!!!!

** Fase de Construção vs. Etapa Construção do Waterfall**

Lamentavelmente quem ve nas fases as etapas do modelo waterfall (analise, projeto, construção, teste) ve nesta fase a programação e na anterior o projeto. Em software o codigo é um tipo de projeto de baixo nivel (low level design), UML pode ser usado para projeto de alto nivel (high level design), enquanto que a construção (build) como em

outras engenharias não equivale a programação e sim a compilação + linkedição, que já é automatizada a muito tempo.

Ahi esta fase se confunde e o nome ajuda com a etapa waterfall de construção, ou seja o pessoal acha que a programação = construção e não programação = low level design, e ahi tenta que o a elaboração seja a etapa de projeto, onde em outras engenharias existe o conceito de "Projetar sem construir" e na seguinte etapa "Construir sem

projetar" ou "Construir seguindo o projeto".

Se procurar nos "principios do RUP" fala em software executavel é essencial desde o inicio na primeira fase incluida, probas de conceito, com mais enfase para a etapa de elaboração, protótipo arquitetural executavel e evolutivo, onde apartir de ahi cada iteração entrega software executavel que vai evoluindo, jamais documentos....

** Gestão de Projetos **

Sobre gestão de projetos simplesmente passa a bola para o pessoal do PMI, fala para dar uma olhada no PMBOK, mais com as "suposições" acima sobre Waterfall e a pressão por manter o investimento sobre controle e "custos fixos" + "escopo fixo" + "tempo fixo" so resta mesmo inflar o triangulo ate o ponto que exploda, e fique totalmente descontrolado em algum dos lados dele e tambem como "qualidade" é uma coisa para inglês ver, ou no minimo um condimento que se coloca no final na maioria das organizações o projeto acaba se ajustando por la...

Para gerenciar projetos RUP sempre usei processos como Scrum para fazer a gestão de projeto, incrivelmente simples, mais incrivelmente anti-intuitivo para quem espera gerenciar "escopo fixo definido no inicio", "tarefas definidas", "custo fixo", novamente o problema do paradigma...

** Papeis vs. Cargos **

A ultima desgraça foram os papeis, que foram interpretados como cargos funcionais, separados em estruturas funcionais, quando dentro do RUP claramente fala dos problemas que isso pode criar, tem um guideline sobre como alocar os papeis aos cargos funcionais da sua organização, e claramente aconselha que devem ser criardas equipes multifuncionais e pessoas devem adotar varios papeis, como "developer" + "use case specifier" ou como "system analist" + "architect"..

Bom a ideia do Jacobsom era boa... ter muita informação para que mentes bem informadas pudessem consultar, adequar a sua realidade, eliminar aquilo que não agregasse valor e criar processos sob medida para suas organizações.. acho que nunca entendeu mesmo da realidade das empresas onde a força dos paradigmas dominantes torçem qualquer ideia boa, mais diferente, para se adequar aos modelos conhecidos. Bom acho que se tocou porque agora saiu com EssUP (Essential UP) que é uma versão minimalista do RUP.

É uma pena... mais é a realidade das empresas... tambem já vi empresas que chamabam de XP a codificar como macacos loucos sem se preocupar com qualidade, nem refactoring, nem porcaria nenhuma... essa ideia de pegar 1 ideia, tiara-la do contexto e depois justificar para fazer o que realmente se queria fazer no inicio é lamentavel... e depois ver como "não funciona" e se queixar de que o RUP é muito burocratico... enorme.. ou o XP gera codigo sem documentação e com baixa qualidade...etc.

Acho que poucos viram o artigo onde compara RUP como um self-service.. la tem muita comida, mais do que uma pessoa pode consumir e muita mais variedade do que sensatamente pode se combinar numa unica refeição... a ideia no self-service é que tem que pegar um pratinho e escolher aquilo que esta dentro da sua dieta na variedade e quantidade certas... ou vai dar uma bela de uma indigestão...

É so realmente tentar olhar la dentro... mais o pessoal gosta de ver so as figurinhas.. e não lee as letrinhas... Just scale it down!!! Acho que RUP lamentavelmente tenta falar para um publico responsavel e maduro, que vai realmente decidir de forma responsavel, despois de ter conhecimento completo sobre o assunto, bom é so dar uma olhada no

Dilbert para ver como a maior parte das empresas são...

Abordagens ágeis já vem com um pouco de este aprendizado, uma abordagem minimalista, a idea de scale it up, um conjunto minimo e quem souber acrescenta, mais da trabalho acrescentar... assim não há problema.. antes daba trabalho tirar.. agora vai dar trabalho para acrescentar... ou seja que vai ter menos incentivos para criar monstruinhos.. mais que havera não tenho duvida disso... a mediocridade é muito criativa e se expressa usando todos os tipos de

artes e ciencias conhecidas e ainda inventa outras novas...

Se me ocorrem algumas peguntas nesta hora:

Você esta usando RUP? e WUP? (Waterfall Unified Process) Esta tendo alguns daqueles probleminhas sitados acima? Vocês estão criando castelos de papel? Que custo de oportunidades esta criando para sua empresa? Melhorou? Piorou? Vai melhorar? O GP já contratou uma empresa de segurança para os guardacostas fazer a escolta da equipe de projeto proximo da data da entrega? Cansaram ou ainda vão continuar tentado?

Voce gostaria de conhecer alguma alternativa mas razoavel?

Então pode dar uma olhada no OpenUP:

http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

Para gestão de projetos é bom dar uma olhada em Scrum é simples e

funciona muito bem com OpenUP, XP ou mesmo com RUP:

http://www.controlchaos.com/about/

Abraços,

Juan.

NOTA: Ainda não consegui me desvensilhar do habito de escrever longas

mensagens... quem não gostar, please me perdõe.. espero melhorar no

futuro...

--

Juan Esteban Bernabó

Tel: (11) 7685-5259

TeamWare do Brasil

Especialistas em Processos Ágeis e

Engenharia de Software

MPS.BR

O MPS.BR ou Melhoria do Processo de Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias de desenvolvimento de software no Brasil. Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. Um dos objetivos do projeto é replicar o modelo na América Latina, incluindo o Chile, Argentina, Costa Rica, Peru e Uruguai. O projeto tem apoio do Ministério de Ciência e Tecnologia, do FINEP e do Banco Interamericano de Desenvolvimento. No Brasil o projeto é desenvolvido pelo Softex, pelo governo e por universidades.

Motivação

O Brasil é um país cujo desenvolvimento de produtos de software está entre os maiores do mundo, e a cada dia, aumenta o nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos. A partir deste ponto, podemos observar que as empresas estão buscando cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para a sobrevivência no mercado de TI. Porém, o custo de uma certificação para uma empresa pode ser de até US$ 400 mil, o que se torna inviável para empresas de micro, pequeno e médio porte. Então, em uma parceria entre a Softex, Governo e Universidades, surgiu o projeto MPS.Br (melhoria de processo de software brasileiro), que é a solução brasileira compatível com o modelo CMMI, está em conformidade com as normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira.

O Modelo

O MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS.

MR-MPS: Modelo de Referência para melhoria do Processo de Software

O MPS.BR apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são:

* A - Em Otimização;

* B - Gerenciado quantitativamente;

* C - Definido;

* D - Largamente Definido;

* E - Parcialmente Definido;

* F - Gerenciado;

* G - Parcialmente Gerenciado;

Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento).

Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistos.

* AP 1.1 - O processo é executado;

* AP 1.2 - O processo é gerenciado;

* AP 2.2 - Os produtos de trabalho do processo são gerenciados;

* AP 3.1 - O processo é definido;

* AP 3.2 - O processo está implementado.

MA-MPS – Método de Avaliação para melhoria do Processo de Software.

Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresa e organizações que implementaram o MR-MPS. Avaliação MA-MPS:

* Equipe de avaliação: 3 a 8 pessoas, sendo:

1 avaliador líder

no mínimo 1 avaliador adjunto

no mínimo 1 técnico da empresa

* Duração: 2 a 4 dias;

* Validade: 2 anos;

Estruturação da Avaliação:

* Planejar e preparar avaliação

* Conduzir Avaliação

* Relatar resultados

* Registrar e publicar resultados

Banco de dados Softex (Ver portal MPS.BR nas 'Ligações Externas')

MN-MPS – Modelo de Negócio para melhoria do Processo de Software.

Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica.