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.

Metodologia de Desenvolvimento de Sofware

Geralmente o desenvolvimento de software é caótico, principalmente em pequenas empresas, onde não existem projetos e o codigo simplesmente é escrito sem controle e com poucas visões da sua principal utilidade. Sempre utilizamos formas "caseiras" para a metodologia de desenvolvimento de software. A figura do lado representa um processo "exuto" do RUP. Quando começamos a olhara para estes artefatos a serem preenchidos a primeira idéia que vem a cabeça é que: "nossa, pra que isso?". Mas conforme vamos adotando a metodologia, percebemos o quanto ela torna a tarefa mais controlada e organizada gerando um produto com no mínimo mais qualidade e com o melhor esforço.
Uma das grandes vantagens do uso deste artefatos é que eles levam você a entender porque você esta desenvolvendo o software. isso reduz muitas falhas de projeto, como não saber se o que você esta fazendo é correto ou não.

CMM - Capability Maturity Model

Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos. O CMM prevê cinco níveis de maturidade: inicial, repetível, definido, gerenciado e otimizando. O modelo foi proposto por Watts S. Humphrey, a partir das propostas de Philip B. Crosby, e vem sendo aperfeiçoado pelo Software Engineering Institute - SEI da Carnegie Mellon University. A especificação do modelo compreende um instrumental para a averiguação do nível atual da organização e expõe os pontos de ação, ou áreas chave de processo, que servem como pontos de destaque para a promoção a um nível mais elevado de maturidade. A adoção do CMM se baseia em um processo gradual de aumento da maturidade da capacidade de desenvolvimento de software de uma organização. A maturidade desse processo pode ser traduzida como a probabilidade de entregar sistemas de software dentro do prazo, utilizando os recursos planejados e atendendo aos requerimentos para o qual foi projetado dentro dos padrões de qualidade desejados.

Li isso no fórum sobre UML e achei muito interessante. Resolvi pulicar. São as opniões de um dos membros sobre casos de uso. O nome do autor esta logo abaixo do texto.

1. Caso de uso de "cadastro" (CRUD): não é caso de uso, a não ser que teu sistema faça SÓ isto. Ponto.

2. "Caso de uso de sistema", "Caso de uso de negocio", etc.: não é caso de uso. Caso de uso é "caso de uso" e pronto.

3. Include e Extend: NÃO USE. Um dia você vai entender o porquê. E neste dia você pode começar a usar.

4. Subfluxo, fluxo de exceção, fluxo reverso, refluxo, etc.: O que não é fluxo básico, é alternativo !

5. Query SQL na descrição UC: Caso de uso NÃO É ESPECIFICAÇÃO SISTÊMICA (URGH!). Foque no "o quê". O "como" vai para o modelo de projeto.

Por fim, para saber se um caso de uso "está certo" entregue para o usuário e veja a sua reação: se ele se interessar (a sombrancelha direita inclina-se 15 graus) significa que está certo. Se ele se entediar (ele lerá o documento com uma mão e devolverá rapidamente dizendo "ok, ok!") algo está errado. Procure por termos técnicos, por um fluxo macarrônico e/ou nome de caso de uso "Manter ".
Casos de usos são MUITO simples, beirando o simplório. Além do cliente/usuário/patrocinador não ter tempo para ler algo com mais de duas páginas, ele só quer saber como o sistema vai funcionar e não como (pra mim pouco importa se dentro do caixa eletronico tem um dispensador de cédulas super moderno ou gnomos-escravos-contadores-de-cédulas).
Um sistema com um caso de uso não é uma aberração (por trás deste simples caso de uso, podem haver dez telinhas de cadastro, necessários para que o caso de uso funcione). O que importa é que TODO o foco de desenvolvimento vai estar centralizado neste único ponto que REALMENTE proporciona valor para o ator-cliente-usuário-patrocinador.

Ou seja: na dúvida, seja econômico e simples.

Rodolpho Ugolini Neto
Software Engineering Specialist
IBM Software Group

O Que São Requisitos?

Engenharia de requisitos e análise de sistemas Há sobreposição entre análise de sistemas e engenharia de requisitos. O descobridor de requisitos usa modelos de análise para auxilia-lo a encontrar os requisitos, e o analista de sistemas usa os requisitos como entrada no processo de desenho de funções e dados. No início do desenvolvimento, há muito mais engenharia de requisitos do que análise de sistemas. Esta proporção se inverte à medida em que o trabalho avança. A funcionalidade identificada na engenharia de requisitos é modelada para provar sua correção, isto é, para provar que as funções e os dados funcionarão corretamente, resultando no que o cliente espera. O produto da análise de sistemas serve como entrada para o projeto do produto, e daí para a sua construção e uso. Os requisitos evoluem a partir destas etapas, num processo impossível de prever com precisão. A engenharia de requisitos precisa levar em conta esta evolução. A técnica de análise de sistemas é bem documentada, o que não é verdade para a engenharia de requisitos.

Por que especificar requisitos?

Se não há uma especificação dos requisitos, um produto não pode ser construído. Ou, pelo menos, um produto não pode ser construído corretamente sem os requisitos corretos. Há relatos de que 60% dos erros já existem em tempo de projeto, e de que até 60% dos erros têm origem nas atividades de engenharia de requisitos e análise de sistemas. Embora os desenvolvedores tenham a oportunidade de quase eliminar a maior categoria de erros, escolhem (ou pior: seus gerentes escolhem) precipitar-se a construir o produto errado (para depois pagar muitas vezes em retrabalho o preço de uma boa análise). O que é um requisito? Um requisito é algo que um produto deve fazer, ou uma qualidade que deve ter. O primeiro caso é o de requisitos funcionais, por exemplo: "o produto deve acionar o monitor de segurança quando um cliente classe A faz um saque em horário não-comercial (no local do saque) superior à sua média mensal de retiradas". Neste caso, os clientes do produto são funcionários de um banco que precisam ser alertados sobre movimentações pouco usuais de alguns clientes do banco.

A atividade de desenvolvimento de software, devido a sua natureza impar, exige um elevado grau de entrosamento entre os interessados do produto final, stakeholders, e a equipe de desenvolvimento, no entanto, muitas das vezes esse relacionamento não ocorre como deveria, pelos mais diferentes motivos, comprometendo a qualidade e sucesso do produto final. Para auxiliar nesse relacionamento, apaziguando as diferenças, a industria de software tem evoluído através da proposição de diferentes metodologias e paradigmas, que basicamente auxiliam, mas, não garante, o sucesso do projeto,produto. É comum vislumbrarmos em um projeto de software, o direcionamento dos esforços para as fases de análise, projeto, implementação, e muito pouco para a fase de controle de qualidade (SQA), realizada de forma "séria" e planejada.
Com o objetivo de apresentar o conceito de mensuração de software ("measurement"), relatando qual a sua importância e objetivo para a atividade de desenvolvimento de software, disponibilizo o texto no formato pdf , que possibilita melhor apresentação ­