Fernando Dantas - Rational Unified Process 7 e ITIL v3

Do RUP 7 ao ITIL v3

2010-01-17T13:28:00.000-08:00

Depois de um longo tempo dedicado ao RUP decidi que era hora de buscar novos conhecimentos e resolvi investir no ITIL v3. Como de costume resolvi começar focando na certificação e após 03 meses de estudo fiz o exame EX0-101 com sucesso me tornando então ITIL v3 Foundation in IT Service Management com 85% de aprovação em 18/12/2009.

ITIL V3 pins: Foundation, Capability, Lifecycle, Expert, and Master:

Logo ao iniciar os estudos sobre ITIL me deparei com a dúvida entre as diferenças do v2 e v3 e após pesquisas observei que apesar de antiga a v2 era ainda mais utilizada em exames por também ser mais aplicada no mercado e possuir mais conteúdo de referência disponível para estudo.

Como tinha pouco conhecimento da v2 e apesar dos conselhos resolvi mesmo focar na versão mais recente e espero compartilhar nos próximos posts os caminhos que segui incluindo resumos, materiais, livros, simulados e questões gerais que achei em alguns testkings e actualtests.

Valores promocionais para Certificações IBM

2009-07-03T05:58:00.000-07:00

Para quem pretende fazer a prova de RUP em breve ou alguma das certificações das linhas de produto Information Management (DB2, Content Manager, Informix, Optim, SolidDB, U2), Rational, SOA, XML, WebSphere e Tivoli a IBM lançou, por prazos e locais determinados, uma promoção onde a prova saí por apenas U$ 30,00 contra os U$ 100,00 normalmente praticados.

As certificações Lotus e WebSphere Portal também estão em promoção com 50% de desconto.

Para realizar o agendamento verifique a data de realização da prova em sua cidade e agende a sua prova enviando seu nome completo, e-mail, o número da prova que você deseja realizar e a data escolhida. Cidades e Locais das Provas

Veja a lista completa das certificações em Promoção

Mais detalhes sobre a promoção aqui

Contribuição: Bruno Lemos

Palestra IBMEC: Princípios do RUP Aplicados ao Gerenciamento de Projetos

2009-04-18T10:22:00.000-07:00

Para os interessados segue material utilizado na palestrada "Princípios do RUP Aplicados ao Gerenciamento de Projetos" apresentada no IBMEC-Belo Horizonte, em 18/04. A palestra teve foco no Gerenciamento de Projetos utilizando os conceitos do RUP e focando nos 06 Key Principles.

Download da apresentação

RUP Disciplines: Análise & Design

2009-02-27T20:12:00.000-08:00

A Análise & Design conjuga em uma única disciplina duas técnicas diferentes.

A Modelo de Análise permite uma melhor compreensão dos requisitos e seu domínio antes da realização do Modelo de Design da aplicação. O processo de análise geralmente é aplicado em projetos maiores onde uma transição direta para o modelo de Design não é viável devido a complexidade identificada nos requisitos.

Já o Modelo de Design representa a solução tecnológica para o problema exposto pelo Modelo de Análise e se aplica mesmo em projetos pequenos. Este modelo deve ser criado antes da implementação do software evitando retrabalhos no processo de implementação. Nesse processo também são utilizadas ferramentas para geração de código e/ou engenharia reversa.

A finalidade da disciplina de Análise & Design é:
- Transformar os requisitos no modelo de design sob o qual o sistema será construído;
- Desenvolver/evoluir uma arquitetura estável e robusta para o sistema;
- Adaptar o Design com foco na implementação.

Veja a WBS da disciplina e consulte o RUP para aprofundar em cada uma das atividades do fluxo:

Work Products
Veja também alguns dos Work Products gerados nessa disciplina:
- Analysis Model;
- Design Model;
- Architectural Proof-of-Concept;
- Data Model;
- Reference Architecture;
- Software Architecture Document;
- Navigation Map;
- Service Model.

Roles
Abaixo as Roles envolvidas na disciplina:
- Software Architect;
- System Analyst;
- Designer;
- User Interface Designer;
- Database Designer.

Simulados
Abaixo algumas questões de simulados para a prova 839 relacionadas a essa disciplina:

1. Which of the following artifacts are part of the Analysis and Design discipline? (Select all that apply.)
a. Software Architecture Document
b. Navigation Map
c. Service Model
d. Glossary

RESP ABC

2. One of the purposes of the Analysis and Design discipline is to do which of the following?
a. To transform the requirements into a design of the system to-be
b. To implement and test the prototype of the system to ensure that the design works
c. To ensure that there is an appropriate environment in place to carry out analysis and design activities
d. To ensure that analysis and design activities are carried out as planned

RESP A

3. An Analysis Model is the abstraction of which of the following models?
a. Logical Model
b. Physical Model
c. Design Model
d. Use-Case Model

RESP C

Qualquer dúvida ou sugestão envie um comentário ou entre em contato fernando.dantas@gmail.com

RUP Disciplines: Requirements

2008-12-14T14:40:00.000-08:00

Pense na disciplina de Requisitos como a fronteira entre as necessidades dos usuários e o sistema a ser construído. É nessa disciplina, obrigatória pelo RUP, que as necessidades dos stakeholders são mapeadas, documentadas e gerenciadas por um Analista de Requisitos. Também é nessa disciplina que moram os dois principais motivos causadores de falhas em projetos de software, o primeiro é justamente o levantamento incompleto dos requisitos e o segundo refere-se ao baixo envolvimento dos usuários durante o levantamento de requisitos.

Um requisito é algo que esperamos que o sistema faça. De acordo com o RUP ele é definido como: “uma condição ou um recurso com o qual um sistema deve estar em conformidade”

A finalidade da disciplina de Requisitos é:
- Estabelecer e manter concordância com stakeholders sobre o que o sistema deve fazer;
- Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema;
- Definir os limites (escopo) do sistema;
- Fornecer uma base para planejar o conteúdo técnico das iterações;
- Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema;
- Definir uma interface de usuário para o sistema.

Veja a WBS da disciplina e consulte o RUP para aprofundar em cada uma das atividades do fluxo:

Work Products
Veja também alguns dos Work Products gerados nessa disciplina:
- Vision
- Glossary
- Requirements Management Plan
- Software Requirement
- Software Requirements Specification:
- Stakeholder Requests
- Storyboard
- Supplementary Specifications
- Use-Case Model
- Requirements Attributes

Navegando pelo RUP você encontra templates e exemplos de cada um dos Work Products acima.

Roles
Abaixo as Roles envolvidas na disciplina
- System Analyst
- Requirements Specifier

A coleta e gerenciamento de requisitos pode ser feita de várias formas, desde o simples uso do Word até a utilização de ferramentas mais completas como o IBM Requisite Pro que ajudar em várias tarefas como consulta de atributos e matriz de rastreabilidade. Um excelente documento sobre o assunto está disponível dentro do próprio RUP em Guidance -> Whitepaper -> Applying Requirements Management with Use Cases. Ele explica como coletar e gerenciar os requisitos de um sistema, definir rastreabilidade e coletar atributos de requisitos.

Simulados
Abaixo algumas questões de simulados para a prova 839 relacionadas a essa disciplina:

1. Which is a purpose of the requirements discipline? Select one answer.
a. To develop the Design Model in terms of use cases.
b. To develop the Business Model in terms of use cases.
c. To define the user interface in terms of use cases.
d. To develop the Vision in terms of use cases.

RESP: C

2. The Requirements Specifier role is primarily responsible for which of the following? (Select all that apply.)
a. Software Requirements
b. Software Requirements Specification
c. Actors and Use Cases
d. Use-Case Model

RESP: ABC

3. The Use-Case Model consists of which of the following key elements? (Select all that apply.)
a. System
b. Use cases
c. Use-case realizations
d. Actors

RESP: BD

Qualquer dúvida ou sugestão envie um comentário ou entre em contato fernando.dantas@gmail.com

RUP Disciplines: Business Modeling

2008-10-25T09:11:00.000-07:00

Modelagem de Negócio é uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core disciplines”. Dentro do ciclo de desenvolvimento de software podemos dizer que essa é sem dúvida a disciplina menos praticada.

Como o próprio nome diz a Modelagem de Negócio tem um foco na organização e em seu funcionamento, o que antecede a criação de qualquer sistema. Para quem conhece ou trabalha em empresas certificadas pela ISO 9001, segue processos do ITIL ou mesmo do CMMI fica fácil entender o papel da modelagem de negócio. Todas essas certificações exigem processos e métodos de trabalho claros, institucionalizados e publicados, suportados ou não por sistemas de TI.

O RUP não define a modelagem de negócio como uma disciplina obrigatória, mas recomenda fortemente que ela seja executada especialmente para empresas que estão iniciando um novo negócio e não possuam uma clara modelagem do negócio. Esse conselho é extremamente valioso e posso dizer por experiência própria que é fundamental para o sucesso de um projeto de desenvolvimento de software. Há alguns anos atrás participei de um projeto cujo objetivo era suportar o processo de vendas de uma nova rede de lojas. Por ser um negócio novo nem mesmo o proprietário da empresa sabia como o negócio iria funcionar e a tentativa de levantar requisitos sob algo totalmente volátil foi catastrófico na fase de requisitos e conseqüentemente de desenvolvimento aonde mudanças chegavam a toda hora.

Diante desse cenário o objetivo da modelagem de negócio fica claro: não tente desenvolver um sistema para um negócio que não é claramente definido, pois seu sistema sem dúvida não poderá informatizar um processo que não existe ou não é consistente.

Para quem está estudando para a certificação 839 ai vai a dica: entenda(para não dizer decore) claramente os propósitos de todas as disciplinas. As finalidades da modelagem de negócio são:
- Entender os problemas da organização identificando as possíveis melhorias;
- Avaliar o impacto de mudanças na organização;
- Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma compreensão comum da organização;
- Gerar conteúdo para a fase de requisitos do sistema que suportará a organização e seus processos;
- Entender como o software se ajustará à organização.

Veja a WBS da disciplina e consulte o RUP para aprofundar em cada uma das atividades do fluxo:

Work Products
Veja também alguns dos Work Products gerados nessa disciplina:
   - Business Vision;
   - Business Architecture Document;
   - Supplementary Business Specification;
   - Business Rules;
   - Business Glossary.

Roles
Abaixo as Roles envolvidas na disciplina:
   - Business Process Analyst;
   - Business Architect;
   - Business Designer;
   - Technical Reviewer.

Imagine iniciar a fase de levantamento de requisitos com toda a modelagem de negócio definida! Sem dúvida a estabilidade dos requisitos seria muito maior além de facilitada pelo comum entendimento de negócio. Uma boa dica é solicitar ao cliente que entregue esse tipo de definição, especialmente para empresas certificadas ISO 9001 que já possuem todo o processo escrito e definido. Também não tente desenvolver um sistema caso perceba que o negócio não está claramente definido ou em mudança. Um erro comum é tentar aproveitar o desenvolvimento de um sistema para modelar ou mudar o negócio(RISCO!).

Não deixe de explorar a disciplina através do RUP entendendo o fluxo da WBS, os principais Work Products e as Roles envolvidas.

Para quem ainda não tem o RUP instalado na máquina faça o download do RMC Trial que possui o RUP 7.2

Simulados
Abaixo algumas questões de simulados para a prova 839 relacionadas a essa disciplina:

1. Which of the following statements is true about Business Modeling? (Select all that apply.)
a. Supports the derivation of software requirements
b. Is not always mandatory
c. Aligns the corporate business strategy with software development
d. Replaces the requirements discipline for business-driven software projects

RESP: ABC

2. Which of the following roles is part of Business Modeling? (Select all that apply.)
a. System Analyst
b. Business Process Analyst
c. Business Architect
d. Test Architect

RESP: BCD

Qualquer dúvida ou sugestão post um comentário ou entre em contato fernando.dantas@gmail.com).

RUP Disciplines

2008-10-25T09:01:00.000-07:00

O RUP possui 09 disciplinas sendo 06 delas diretamente relacionadas a engenharia de software também conhecidas como “core disciplines”, são elas:
   - Business Modeling
   - Requirements
   - Analysis and Design
   - Implementation
   - Test
   - Deployment
As outras 03 disciplinas são chamadas de “umbrella” ou “supporting disciplines”, são elas:
   - Configuration and Change Management
   - Project Management
   - Environment

Disciplinas são coleções de Tasks organizadas por áreas de interesse cujo principal objetivo é auxiliar no entendimento do projeto a partir de uma perspectiva cascata tradicional. Uma disciplina o orienta como executar as atividades do projeto de forma estruturada. O benefício de agrupar atividades em disciplinas é:
   - Facilitar a compreenção das atividades;
   - Facilitar a customização das atividades para o contexto de um projeto;
   - Facilitar a definição de responsabilidades através das Roles;
   - Permitir que gerentes de projeto monitorem e controlem mais efetivamente as atividades do projeto.

Um erro comum para quem está habituado ao processo cascata é confundir Disciplina com Fase o que no contexto do processo Iterativo não possui relação direta. Por exemplo: na fase de Iniciação você pode e deve implementar, o que não significa que você está na fase de Construção. Nos posts futuros iremos aprofundar nesse assunto mas por enquanto tente desvincular o conceito de disciplina do conceito de fase.

Nos próximos posts serão detalhadas cada uma das 09 disciplinas e seus propósitos que são extensivamente cobrados na certificação 839.

Qualquer dúvida ou sugestão post um comentário ou entre em contato fernando.dantas@gmail.com).

Process Elements

2008-09-21T16:41:00.000-07:00

Vimos que para a UMA um processo é formado por Elementos de Conteúdo + Elementos de Processos. Já vimos também que Elementos de Conteúdo são (Roles, Task, Steps, Work Products, Guidances e Categories) e que estes refletem apenas o “o que” e “como” as coisas devem ser feitas mas não refletem exatamente o “quando”. É justamente com esse objetivo que surgem os Elementos de Processo (Activities, Iterations, Phases, Capability Patterns e Delivery Process) cuja principal função é organizar os Elementos de Conteúdo em atividades e ciclos de vida dando aos mesmos uma estrutura seqüencial de execução.

Seguindo esses conceitos (Elementos de Conteúdo + Elementos de Processos) mesmo que seu objetivo não seja estruturar um processo de desenvolvimento de software ainda sim seria possível utilizar a UMA para tal. Também entendendo os dois elementos fica mais fácil entender qualquer tipo de processo elaborado através da UMA como o próprio RUP.

A seguir alguns dos Elementos de Processo do RUP:

Activities
Atividades são utilizadas para organizar Elementos de Conteúdo, especialmente Tasks, cujo agrupamento forma uma unidade de trabalho. No RUP existem quatro importantes tipos de elementos (a serem detalhados nos próximos posts) que são na realidade estereótipos de atividades fornecendo uma semântica adicional dependendo do contexto:
- Iteration: iterações são um dos princípios fundamentais do RUP agrupando atividades que podem ser executadas mais de uma vez.
- Phase: fases agrupam elementos de processo de acordo com o contexto/perspectiva do projeto. O RUP apresenta quatro fases principais que são: Iniciação, Elaboração, Construção e Transição.

- Capability Pattern: são pequenos fragmentos de processos formados por atividades e milestones. Podem ser utilizados para compor os Delivery Process.
- Delivery Process: são processos completos que podem ser consumidos pelos usuários. O próprio RUP é publicado com três Delivery Processes: Classic, Small e Medium.

Milestone
Milestones são pontos de verificação atrelados a cada fase do projeto. São utilizados para assegurar certas situações, por exemplo: o Lifecycle Objective (LCO) que é executado ao fim da fase de Iniciação e visa garantir que todos os devidos artefatos foram coletados dando subsídio a decisão de prosseguir ou não com o projeto.

Descriptors
Outro conceito comumente utilizado pela UMA são os Descriptors. Através deles é possível utilizar o mesmo Elemento de Conteúdo em diferentes contextos de Elementos de Processo. Eles substituem os elementos de conteúdo e podem ser de três tipos: Role Descriptors, task Descriptors e work-product Descriptors. Descriptors geralmente são representados em WBS permitindo ajustes necessários sem mudar o elementos de conteúdo em si. Uma Task Descriptor, por exemplo, pode remover Steps de uma Task flexibilizando assim os elementos de conteúdo.

Simulados
Abaixo algumas questões de simulados para a prova 839 relacionadas a elementos de processo:

Which of the following is a Process Element? (Select all that apply.)
a. Capability Pattern
b. Activity
c. Roadmap
d. Delivery Process

RESP: ABD

Which of the following is a valid descriptor? (Select all that apply.)
a. Task Descriptor
b. Role Descriptor
c. Activity Descriptor
d. Work-Product Descriptor

RESP: ABD

Which of the following process elements is a special representation of an activity? (Select all that apply.)
a. Phase
b. Activity Detail
c. Task
d. Iteration

RESP: AD

Qualquer dúvida ou sugestão post um comentário ou entre em contato fernando.dantas@gmail.com).

Method Content

2008-08-10T12:12:00.000-07:00

Conforme explicado no último post a UMA - Unified Method Architecture é dividida em Elementos de Conteúdo de Método e Elementos de Processo. O primeiro refere-se a relação de elementos como Roles, Task e Work Products e existem independentemente do segundo. Já os Elementos de Processos referem-se ao "quando" e ajudam a organizar os Elementos de Conteúdo em atividades, gerando assim, uma estrutura seqüencial que forma o processo.

Work Products
Um dos principais elementos de conteúdo são os Work Products. No RUP 2003 os Work Products eram referenciados como Artefatos e agora no RUP 7 se dividem em 03 tipos:
- Artefatos: são tangíveis e podem agrupar outros artefatos. Um exemplo de Work Product desse tipo é o Software Development Plan que contém cinco outros artefatos. Diga-se de passagem esse Work Product é um dos mais cobrados na prova de Certificação 839.
- Outcome: são saídas geralmente intangíveis e não reutilizáveis o que pode ser um estado ou resultado. Exemplos de Outcome pode ser uma otimização de performance ou uma instalação de software.
- Deliverable: é um entregável que provê valor ao stakeholder seja ele interno ou externo. Um deliverable pode ser composto de Artefatos ou Outcomes.

Roles
Uma Role é definida como um conjunto de skills, competências e deveres responsável por executar tasks e produzir Work products. Exemplos de Roles:

Task/Steps
Tasks são ações executadas por Roles e são dirigidas por Work Products de entrada e saída. Tasks são compostas de Steps que representam uma unidade de trabalho mais granular.

O workflow abaixo, muito comum no RUP, pode ser lido da seguinte forma: a Task “Identify Security Patterns” recebe e atualiza o Work Product “Software Architecture Document” que é de responsabilidade da Role “Security Architect”.

Guidance
Guidances são orientações que podem auxiliar ou detalhar a execução de elementos dos tipos: Task, Work Product ou Process Elements.

Existem várias tipos de Guidances como: Checklist, Concept, Estimation Consideration, Examples, Guideline, Practice, Report, Reusable Asset, Roadmap(passo-a-passo), Supporting Material, Template, Term Definition, Tool Mentor, Whitepaper(conteúdo externo).

Categories
Categorias são utilizadas para agrupar elementos de conteúdo. Existem 04 tipos de categorias: Discipline, Domain, Role Set, Tool Category.

Qualquer dúvida ou sugestão post um comentário ou entre em contato(fernando.dantas@gmail.com).

UMA - Unified Method Architecture

2008-05-25T16:55:00.000-07:00

Se você acha a navegação do site do RUP confusa e tem dificuldade para encontrar algo dentro dele você provavelmente ainda não entendeu os conceitos da UMA - Unified Method Architecture. Para simplificar o entendimento pense na UMA como uma espécie de UML sendo que a diferença é que enquanto a UML auxília a modelar o comportamento de um sistema a UMA auxília a modelar processos como o próprio RUP.

Logo, entender os conceitos da UMA significa entender como o RUP é estruturado, de que é composto e como seus elementos se relacionam entre si. Vale lembrar ainda que esse é um dos assuntos mais cobrados na certificação 839 e um dos pontos onde várias mudanças foram introduzidas em relação a versão 2003 do RUP.

O princípio chave da UMA é a clara separação entre Elementos de Conteúdo (Method Content) e Elementos de Processo. O primeiro refere-se a relação de elementos como Roles, Task e Work Products e existem independentemente do processo em si. Já o segundo(Process) ajuda a organizar os Elementos de Conteúdo em atividades gerando assim uma estrutura seqüencial que forma o processo, ou seja, o RUP é formado pela relação entre os Elementos de Conteúdo e de Processo.

Em resumo o que importa entender até aqui é que todo processo (RUP) é composto de Elementos de Conteúdo (Roles, Task, Steps, Work Products, Guidances e Categories) e Elementos de Processos (Activities, Iterations, Phases, Capability Patterns e Delivery Process).

Entender este conceito além de ajudar na compreensão do RUP também é fundamental para a certificação 839 pois em várias questões você será cobrado sobre quais são os elementos de conteúdo ou de processo do RUP. Veja nas questões de exemplo abaixo os conceitos em prática:

1. Which of the following elements is a Content Element? (Choose all that apply.)
  a. Work product
  b. Role
  c. Task
  d. Activity

2. Which of the following statements are true about the Unified Method Architecture? Select 2 answers.
  a. The UMA integrates method content with its application in processes.
  b. The UMA is a process engineering meta-model.
  c. The UMA supports packaging and configuration of new method content and processes.
  d. The UMA mainly focuses on iterative development.

3. Which two are types of method content elements? Select 2 answers.
  a. Deliverable
  b. Task Descriptor
  c. Capability Pattern
  d. Role

Nos próximos posts serão explicados os Elementos de Conteúdo e Processo do RUP.

Qualquer dúvida sobre as perguntas entre em contato(fernando.dantas@gmail.com).

RUP Key Principals: Focus Continuously On Quality

2008-05-04T16:24:00.000-07:00

Este é o último princípio do RUP e pelos motivos óbvios quase dispensa apresentações se não fosse pelo fato de ser um dos mais mal aplicados. Foco contínuo na qualidade não significa apenas atender os requisitos ou ter uma equipe de teste como muitos imaginam. Um conceito errôneo comum é que a qualidade pertence a um grupo ou é responsabilidade dele. Esse mito é geralmente perpetuado pela criação de um grupo, algumas vezes denominado Garantia de Qualidade, outros nomes incluem Teste, Controle de Qualidade e Engenharia de Qualidade, e atribuindo a eles a missão e a responsabilidade relacionadas à qualidade.

Segundo o RUP qualidade também inclui identificar as métricas e critérios que demonstram sua existência, assim como, a implementação de um processo para garantir que o produto atinja o grau desejado de qualidade de forma que isso possa ser repetido e gerenciado.

O próprio RUP demonstra em Supporting Materials -> Quality Management que os problemas de software ficam de 100 a 1.000 vezes mais caros para serem localizados e reparados após a implementação do software.

Por fim, um dos maiores benefícios do desenvolvimento Iterativo está relacionado à abordagem de testes que reforça os conceitos de qualidade desde o início sendo uma das vantagens desse processo em relação ao processo cascata.

Os benefícios desse princípio são:
- Maior qualidade
- Percepção prévia no progresso e na qualidade

Práticas para atingir estes benefícios:
- Assegurar que toda a equipe tenha propriedade sobre qualidade do produto;
- Testar de forma antecipada e contínua demonstrando as funções do sistema;
- Construir incrementalmente a automação do teste.

Como não atingir estes benefícios:
- Revisar artefatos e concluir testes unitários antes do teste de integração;
- Conduzir revisões detalhadas dos artefatos intermediários pois atrasam o teste do aplicativo e conseqüentemente a identificação de problemas maiores;
- Concluir todos os testes de unidade antes de fazer o teste de integração, novamente retarda a identificação de problemas maiores.

RUP Key Principals: Elevate Level of Abstraction

2008-04-19T14:01:00.000-07:00

É basicamente por causa desse princípio que hoje não programamos mais em Assembly ou C++, ou seja, quanto mais elevado o nível de abstração mais a complexidade de um projeto é reduzida. Essa abstração pode se manifestar de várias formas como adoção de uma linguagem de alto nível como .NET ou JAVA, adoção de um componente de mercado ou mesmo pelo uso de serviços disponibilizados através de WebServices.

Quando esse conceito não é corretamente observado o projeto é guiado pela complexidade e baixa produtividade ficando o business em segundo plano. Outra abordagem para gerenciar a complexidade é focalizar na arquitetura através do desenvolvimento de uma que seja estável e testada atuando como referência para os projetos que ainda serão desenvolvidos.

Os benefícios desse princípio são:
- Aumento da produtividade;
- Redução da complexidade.
Práticas para atingir esses benefícios:
- Promover a reutilizar de ativos existentes;
- Utilizar ferramentas e linguagens de alto nível;
- Focalizar na arquitetura;
- Estabelecer controles sobre a qualidade e complexidade.
Como não atingir esses benefícios:
- Evoluir de requisitos direto p/ código customizado não estimula o reuso pois: enibe a discussão no foco conceitual, requer constante revisão de decisões e limita o foco na arquitetura resultando em atraso e retrabalho no projeto.

Roteiro para prova RUP 839: Rational Unified Process v7.0

2008-03-15T21:31:00.000-07:00

Atendendo a pedidos resolvi postar um roteiro de estudo para quem deseja fazer a prova 839 do RUP 7. Esse foi mais ou menos o caminho que segui, salvo pelo fato de que havia iniciado os estudos para a prova antiga (639) de RUP 2003 até que descobri a existência da nova 839 lançada em Jul/2007.

Antes de começar a estudar é importante entender como funciona a prova. Ela não é muito diferente de outras certificações podendo ser marcada pelos centros Prometric e custando U$ 100,00. É composta de 52 questões e pode ser feita em até 75min sendo a nota mínima para aprovação de 62%, ou seja, erre no máximo 19 questões para ser aprovado.

Outro ponto importante sobre a prova é entender o foco da mesma. Como pode ser visto no site oficial da Certificação o foco é distribuído conforme abaixo:
   - Iterative Development Principles (16.6%)
   - Iterative Development Work Products (16.6%)
   - Basic Method Elements and their Relationships (16.6%)
   - Basic Process Elements and their Relationships (16.6%)
   - Basic Content of Disciplines (33.6%)

Passo 01: O caminho das pedras:
- O Livro IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP) de Ahmad K. Shuja e Jochen Krebs foi o primeiro a ser lançado sobre RUP 7 em Jan/2008. Recomendo fortemente a leitura pois nele ficam claras as diferenças do RUP 2003 em relação ao 7. A cada capitulo os autores apresentam o conteúdo do RUP atrelado a um simulado para ajudar a fixar o assunto. No último capitulo também é apresentado um simulado dentro das condições reais da prova, ou seja, 52 questões divididas dentro dos focos da prova;
- Durante a leitura do Livro você já deverá ter instalado em sua máquina pelo menos uma versão Trial do RMC que contém o framework do RUP para leitura. Recomendo que você leia o livro e constantemente complemente a leitura com o conteúdo relativo dentro do site do RUP. Isso lhe ajudará a se familiarizar com o site do RUP e também a aprofundar em alguns temas.
- Depois de finalizada toda a leitura do livro é hora de explorar mais o site do RUP. Alguns conteúdos sugeridos por Hans Admiraal em "Learning RUP 7.0" são realmente fundamentais e de leitura obrigatória.

Passo 02: Não entre na sala de exames sem ter “decorado”:
- Os 6 Key Principals do RUP e seus benefícios. Não é necessário decorar os Patterns e Anti-Patterns mas o benefícios com certeza sim;
- As disciplinas do RUP e os propósitos de cada uma delas;
- O que é UMA e quais são exatamente cada um dos elementos de conteúdo (Roles, Tasks, Steps, WorkProducts, etc..) e dos elementos de processo (Activities, Iterations, Phases, Capability Pattern, etc);
- As fases do RUP e os objetivos de cada uma, assim como, os Milestones;
- No site do RUP leia com atenção todo o conteúdo disponível em: Work Products > RUP Domains > Project Management. Vários WorkProducts de gerenciamento são cobrados, principalmente o Software Development Plan e seus cinco sub-artefatos devem ser decorados.

Passo 03: Os simulados:
- A essa altura você já deveria estar aplicando os próprios conceitos do RUP para evitar que seu projeto de Certificação falhe. Sendo assim podemos dizer que os simulados são a sua Arquitetura Executável. Infelizmente, como a própria certificação 839 é recente você não encontrará muitos simulados facilmente;
- Para ter uma idéia real das questões da prova o próprio site oficial do RUP dá cinco questões de demonstração que vale a leitura;
- Não achei nenhum testking liberado sobre a prova mas no site da própria testking é possível baixar a versão demo com 21 questões que já foram muito úteis;
- Por último no site de Hans Admiraal é possível fazer um simulado do RUP 2003 gratuitamente e outro de RUP 7, porém pago. Digamos que com um pouco de insistência técnica você pode conseguí-lo gratuitamente :-).

Para facilitar segue link para Download das principais questões que utilizei para estudo.

Passo 04: O grande dia:
- Se você fez tudo como sugerido somando uma grande vontade de não perder U$ 100,00 você terá grandes chances de atingir os 62% da prova e se tornar um IBM Certified Solution Designer - IBM Rational Unified Process V7.0.

Bom, espero que as dicas sejam úteis na busca pela certificação e se isso acontecer peço que me mande um post pois ficarei feliz em saber.

RUP Key Principals: Collaborate Across Teams

2008-03-02T13:31:00.000-08:00

Walker Royce já dizia que o desenvolvimento de software é um esporte em equipe e como tal exige grande colaboração para se produzir um produto final. Dentro do ciclo de vida de um processo cascata o trabalho em equipe geralmente não é estimulado pois o que freqüentemente ocorre é que um grande volume de requisitos é “empurrado” para a equipe de analistas, que por sua vez, “empurra” a análise & desenho para os desenvolvedores e assim por diante. Esse comportamento faz com que cada um se sinta menos responsável pelo produto final do que o outro.

Dentro do processo iterativo toda a equipe é envolvida desde o início do projeto o que estimula a integração e aguça o senso de responsabilidade pelo produto final pois todos estão empenhados em gerar um produto executável ao fim de pequenas iterações.

Estimular a colaboração funcional é outro fator importante. As barreiras que geralmente separam cada função não devem existir, ou seja, não deve existir a “equipe” de analistas, a “equipe” de desenvolvedores, a “equipe” de testers pois isso acaba distorcendo o foco. O importante é que exista uma única equipe cujo objetivo é entregar um software com qualidade. Isso significa que basicamente todos são responsáveis por compreender o que está sendo produzido e que qualidade não é uma função apenas dos Testers.

Outro ponto importante e que estimula a colaboração é a existência de um ambiente integrado onde ferramentas podem automatizar tarefas, coletar métricas, gerar status reports, auxiliar na gerencia de configuração e mudanças, etc. Isso libera a equipe para realizar atividades que realmente são importantes e agregam valor ao ciclo de desenvolvimento.

Os benefícios desse princípio são:
- Produtividade da equipe;
- Melhor integração entre: necessidades de negócio, desenvolvedores e operação.
Práticas para atingir esses benefícios:
- Motivar pessoas a realizarem seu melhor;
- Criar equipes auto-gerenciadas;
- Encorajar colaboração funcional entre analistas, desenvolvedores, etc;
- Proporcionar ambientes de colaboração efetiva;
- Gerenciar evolução de artefatos em tarefas;
- Integrar equipes de negócios, desenvolvimento e operação.
Como não atingir esses benefícios:
- Criar desenvolvedores heróicos e estimular horas extras;
- Ter pessoas especializadas e equipamentos de ponta sem colaboração entre elas.

RUP Key Principals: Balance Competing Stakeholder Priorities

2008-02-25T17:17:00.000-08:00

Balancear prioridades sempre é uma tarefa difícil já que na visão de cada stakeholder seus requisitos são sempre mais importantes do que os requisitos dos outros. Desenvolver um software sem estabelecer nas fases iniciais o que realmente é prioritário significa apenas que foco desnecessário será dado em algo que não agrega valor ao negócio e muito menos atende as expectativas dos usuários.

Outro fator importante quanto ao processo de priorização de requisitos é que ele não deve levar em conta apenas as necessidades de alguns stakeholders. Priorizar os requisitos significa entender o negócio, as necessidades de cada stakeholder e então balancear cada uma das necessidades.

Outro fator importante relacionado a este princípio é a redução do desenvolvimento customizado. Isso significa avaliar os prós e contras do desenvolvimento de um software/componente customizado e a utilização de um já pronto que atenda parcialmente os requisitos.

Os benefícios desse princípio são:
  - Alinhar negócio e necessidades do usuário;
  - Reduzir o desenvolvimento customizado;
  - Otimizar o valor do negócio.
Práticas para atingir esses benefícios:
  - Definir e priorizar o negócio x necessidades do usuário;
  - Priorizar requisitos;
  - Entender quais ativos podem ser alavancados;
  - Equilibrar a reutilização dos recursos x necessidades do usuário.
Como não atingir esses benefícios:
  - Documentar a fundo os requisitos no início do projeto;
  - Negociar todas as alterações nos requisitos;
  - Congelar os requisitos diretos;
  - Priorizar o desenvolvimento customizado;
  - Atender principalmente as necessidades dos investidores mais vocais.

Resumo Livro: The Rational Unified Process Made Easy

2008-02-21T18:53:00.000-08:00

Um dos livros mais conhecidos de RUP e que sem dúvida é leitura obrigatória para quem está começando no assunto é o “The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP” de Per Kroll e Philippe Kruchten. Com uma abordagem muito prática o livro explica toda a estrutura do RUP 2003 passando por seus princípios, processo Iterativo, fases e disciplinas, etc. Traz ainda um capítulo interessante onde todo o ciclo de vida de um pequeno software é explicado através do RUP.

Para quem já leu o livro e gostaria apenas de rever seu conteúdo ou mesmo para quem quer uma visão geral fiz um pequeno resumo (parte em português e parte em inglês) que pode ser útil. Vale lembrar que esse livro refere-se ao RUP 2003 e conseqüentemente a Certificação 639 que é a antecessora da atual 839 sobre RUP 7.

Em breve também publicarei um resumo do recém publicado livro “IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP)” de Ahmad K. Shuja e Jochen Krebs que me ajudou muito na certificação 839.

Download Resumo - Formato ZIP - 1MB

Qualquer sugestão ou contribuição quanto ao resumo comentem ou me enviem por email(fernando.dantas@gmail.com)

RUP Key Principals: Adapt the Process

2008-02-20T18:34:00.000-08:00

Este é um princípio simples e que talvez por isso seja tão subestimado. Vejo muitas pessoas alegarem que o RUP é “muito pesado” e possui muitos artefatos. É aí que mora o desconhecimento pois esse princípio diz respeito justamente a adaptar o nível de cerimônia ao seu contexto. É importante entender que o RUP é como um banquete, ou seja, você deve escolher o que deseja ao invés de se empanturrar.

É extremamente importante para o sucesso de um projeto que o processo seja adequado e que o nível de cerimônia seja ajustado, pois documentação em excesso não trará produtividade e documentação superficial trará problemas de comunicação.

Projetos maiores, com tecnologias complexas e maior número de stakeholder geralmente precisam seguir padrões mais formais. Porém, para pequenos projetos com equipes locais e tecnologias conhecidas o processo deve ser mais leve.

Outro erro comum que esse princípio trata é a criação de planos e estimativas estáticas. Todos sabem que o nível de incerteza no início de um projeto é alto e tentar estabelecer um plano estático e absoluto na fase de Iniciação nunca funciona pois apenas na fase de Elaboração é que se pode ter uma visão mais estável dos requisitos e da arquitetura.

Os benefícios desse princípio são:
  - Eficiência de ciclo de vida;
  - Maior agilidade do projeto;
  - Planos e estimativas mais realísticas.
Práticas para atingir esses benefícios:
  - Dimensione corretamente o processo para o projeto;
  - Adapte a cerimônia de acordo com o ciclo de vida;
  - Aprimore o processo continuamente;
  - Equilibre planos e estimativas com o nível de incertezas.
Como não atingir esses benefícios:
  - Determine estimativas fixas no início do projeto;
  - Desenvolva planos estáticos.

RUP Key Principals: Demonstrate Value Iteratively

2008-02-16T18:11:00.000-08:00

Nada ilustra melhor os benefícios do processo Iterativo (representados por esse princípio) do que a charge abaixo.

Percebe-se claramente no exemplo que a pirâmide foi construída através de um processo cascata(waterfall) e que o gerente egípcio fez um “ótimo” trabalho de acompanhamento. Mas justiça seja feita, até mesmo o gerente foi um refém do processo cascata.

Demonstrar Valor Iterativamente significa beneficiar-se do processo iterativo que basicamente visa a execução de vários ciclos onde cada um realiza todo o conjunto de disciplinas desde o requisito até a implantação. Daí nota-se a grande diferença onde uma aplicação executável já é colocada em prova em um curto espaço de tempo. Em contra-partida, no processo cascata, o release de um software executável é a última prioridade onde geralmente tem-se essa saída quase que no final do projeto onde já não existe mais tempo para resolver os problemas.

Os benefícios desse princípio são:
   - Reduzir os riscos o quanto antes;
   - Maior previsibilidade no decorrer do projeto;
   - Maior confiança entre os stakeholders;

Práticas para atingir esses benefícios:
   - Obter Feedbacks do cliente;
   - Abraçar as mudanças de escopo;
   - Focar na eliminação dos maiores riscos com antecedência;
   - Adaptar os planos de forma constante.

Como não atingir esses benefícios:
   - Planejar todo o projeto em detalhes desde o início.
   - Confiar em Entregáveis ao invés de Testes ou Demonstrações

Rational Unified Process - O início

2008-02-16T11:36:00.000-08:00

Como toda boa metodologia que se preze o RUP traz um conjunto de 6 princípios chaves que formam a base de toda sua estrutura. Se bem compreendidos e corretamente aplicados podem apresentar um ganho significativo de qualidade no ciclo de vida do software. Para facilitar a vida os 6 princípios começam com as letras ABCDEF. São eles:
   - Adapt the Process
   - Balance Competing Stakeholder Priorities
   - Collaborate Across Teams
   - Demonstrate Value Iteratively
   - Elevate the Level of Abstraction
   - Focus Continuously on Quality

Nos próximos posts explicarei cada um dos 6 princípios.

Hello World

2008-02-16T05:12:00.001-08:00

Seja bem-vindo ao meu Blog. Aproveitando para inaugurar os posts gostaria de compartilhar a notícia de que na última sexta-feira dia 16/02 realizei a prova de RUP 7 com sucesso obtendo a nota de 84%. Sendo assim, posso me considerar o mais recente IBM Certified Solution Designer - IBM Rational Unified Process V7.0.

Mas independente da certificação o que realmente vale é o conhecimento adquirido durante os 5 meses de estudo. Para mim, após todos os livros e artigos lidos, fica a clara sensação de que o ciclo de vida de um software é comumente sub julgado e que um processo bem definido é a base para o sucesso.

Em virtude do conhecimento adquirido no processo de certificação e também da dificuldade de obter informações de boa qualidade resolvi inaurar esse blog para tratar entre outras coisas de RUP.

Espero nos próximos posts lançar conteúdos sobre o assunto iniciando pelos 6 princípios chaves do RUP que além de serem foco da prova são muito interessantes se compreendidos corretamente.