Planeamento de Sistemas de Informação

Objectivos
Compreender a importância do planeamento dos sistemas de informação segundo uma
perspectiva estratégica e fornecer todo um conjunto de técnicas permitem desenvolver sistemas
integrados e determinantes na estratégia do negócio.

Competências Conferidas
Planear os sistemas de informação de uma organização numa perspectiva estratégica
desenvolver cenários completos em que as necessidades de informação de negócio estejam
integradas com as infra-estruturas tecnológicas incorporar os sistemas de informação nos
processos que constituem o suporte da actividade organizacional

O Planeamento de Sistemas de Informação é a actividade da organização onde se define o

futuro desejado para o seu Sistema de Informação, para o modo como este deverá ser suportado
pelas Tecnologias da Informação e para a forma de concretizar esse suporte. Apesar de ser
geralmente aceite como uma actividade vital para o sucesso das organizações, o Planeamento de
Sistemas de Informação é, curiosamente, uma das suas actividades mais desprezadas e menos
bem sucedidas.

Numa actividade complexa como é o Planeamento de Sistemas de Informação, o seu estudo e a

sua prática não devem ser desassociados, sob pena de ser simplista na identificação e resolução
de questões chave da sua execução.

PSI é uma Metodologia voltada para o estabelecimento das necessidades de Sistemas de

Informações de uma organização e a conduz à melhor forma de sequenciar e realizar a sua
implementação.

O planeamento de sistemas de informação é as actividades relacionadas com definição e

implementação de sistemas de informação.

Problema de reconhecimento e especificação

A coleta de informações
Especificação de Requisitos para o novo sistema
O projeto do sistema
Construção do Sistema
Implementação do Sistema
Revisão e manutenção

“Modem system analysis and design – adward yourdon”

IBM Rational Unified Process
Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de RUP)

O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational),

é um processo proprietário de Engenharia de software criado pela Rational Software
Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma
abreviação de IBM Rational Unified Process e tornando-se uma brand na área de
Software, fornecendo técnicas a serem seguidas pelos membros da equipe de
desenvolvimento de software com o objetivo de aumentar a sua produtividade.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e

documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os
processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de

desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável
torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do
projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e
responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua

metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e
vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom"

(considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP-
Extreme Programming), Scrum, FDD e outros.

Índice
[esconder]

 1 Linhas mestras
o 1.1 Gestão de requisitos
o 1.2 Uso de arquitetura baseada em componentes
o 1.3 Uso de software de modelos visuais
o 1.4 Verificação da qualidade do software
o 1.5 Gestão e Controle de Mudanças do Software
 2 Fases
o 2.1 A Fase de concepção
o 2.2 A Fase de Elaboração
o 2.3 A Fase de Construção
o 2.4 A Fase de Transição
  3 Disciplinas
o 3.1 Seis Disciplinas de Engenharia
 3.1.1 Disciplina de Modelagem de Negócios
 3.1.2 Disciplina de Requisitos
 3.1.3 Disciplina de Análise e Projeto("Design")
 3.1.4 Disciplina de Implementação
 3.1.5 Disciplina de Teste
 3.1.6 Disciplina de Implantação
o 3.2 Três Disciplinas de Apoio/Suporte
 3.2.1 Disciplina de Ambiente
 3.2.2 Disciplina de Configuração e Gerência de Mudança
 3.2.3 Disciplina de Gerência de Projeto
 4 Princípios e melhores práticas
o 4.1 Desenvolvimento iterativo
o 4.2 Gerenciamento de requisitos
o 4.3 Uso de arquitetura baseada em componentes
o 4.4 Modelagem visual de software
o 4.5 Verificar qualidade de software
o 4.6 Controle de alterações no software
 5 Ver também
 6 Ligações externas

Linhas mestras
O RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da
equipe de um ciclo de produção: parte do cliente, e uma avaliação do progresso do
projeto pela sua gerência. Além disso, ajuda os programadores a manterem-se
concentrados no projeto.

Gestão de requisitos

Uma documentação apropriada é essencial para qualquer grande projeto; note que o
RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de
projeto e requisitos de negócio.

Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos
dependentes do processo, que têm sido considerados muito mais eficazes na captura de
requisitos funcionais.

Uso de arquitetura baseada em componentes

A arquitetura baseada em componentes cria um sistema que pode ser facilmente

extensível, promovendo a reutilização de software e um entendimento intuitivo. Um
componente normalmente se relaciona com um objeto na programação orientada a
objetos.
O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se
em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de
comprometer recursos em larga escala.

Estes componentes são normalmente incluidos em infraestruturas existentes como o

CORBA e o COM (Modelo de Componentes de Objectos).

Uso de software de modelos visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção

gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução.

O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico
(como clientes) tenham um melhor entendimento de um dado problema, e assim se
envolvam mais no projeto como um todo.

A linguagem de modelagem UML tornou-se um padrão industrial para representar

projetos, e é amplamente utilizada pelo RUP.

Verificação da qualidade do software

Não assegurar a qualidade do software é a falha mais comum em todos os projetos de

sistemas computacionais. Normalmente pensa-se em qualidade de software após o
término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da
equipe de desenvolvimento.

O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na

construção de todo o processo e envolvendo todos os membros da equipe de
desenvolvimento.

Gestão e Controle de Mudanças do Software

Em todos os projetos de software a existência de mudanças é inevitável. O RUP define

métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar
aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial
para o sucesso de um projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as

mudanças efetuadas noutro sistema não afetarão o seu sistema.

Fases
Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida
de um projeto. As fases[1] indicam a ênfase que é dada no projeto em um dado instante.
Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro
fases diferentes:
 1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.

O RUP também se baseia nos 4 Ps:

1. Pessoas
2. Projeto
3. Produto
4. Processo

As fases são compostas de iterações. As iterações são janelas de tempo; as iterações

possuem prazo definido enquanto as fases são objetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam
o projeto, além de permitir melhor acompanhamento.

A Fase de concepção

A fase de concepção contém os workflows necessários para que as partes interessadas

(stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto. Se
as partes interessadas tiverem bons conhecimentos, então, pouca análise será requerida.
Caso contrário, uma análise maior será requerida.

Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem
definidas quanto a sua quantidade e objetivos.

A Fase de Elaboração

A fase de elaboração será apenas para o projeto do sistema, buscando complementar o

levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema,
revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário.
Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; O
plano do projeto é confiável?; Custos são admissíveis?

A Fase de Construção

Na fase de construção, começa o desenvolvimento físico do software, produção de

códigos, testes alfa e beta.

Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema

constituem "baseline".

A Fase de Transição

Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de

implantação e entrega, acompanhamento e qualidade do software. Produtos (releases,
versões) devem ser entregues, e ocorrer a satisfação do cliente.
Disciplinas
Seis Disciplinas de Engenharia

Disciplina de Modelagem de Negócios

As organizações estão cada vez mais dependente de sistemas de TI, tornando-se

imperativo que os engenheiros de sistemas de informação saibam como as aplicações
em desenvolvimento se inserem na organização. As empresas investem em TI, quando
entendem a vantagem competitiva do valor acrescentado pela tecnologia. O objetivo de
modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal
de comunicação entre engenharia de negócios e engenharia de software. Compreender o
negócio significa que os engenheiros de software devem compreender a estrutura e a
dinâmica da empresa alvo (o cliente), os atuais problemas na organização e possíveis
melhorias. Eles também devem garantir um entendimento comum da organização-alvo
entre os clientes, usuários finais e desenvolvedores.

Modelagem de negócios, explica como descrever uma visão da organização na qual o

sistema será implantado e como usar esta visão como uma base para descrever o
processo, papéis e responsabilidades.

Disciplina de Requisitos

Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e
transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do
sistema a ser construído e fornecem requisitos detalhados para o que deve fazer o
sistema.

Disciplina de Análise e Projeto("Design")

O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é
construir um sistema que:

 Execute, em um ambiente de execução específica, as tarefas e funções

especificadas nas descrições de casos de uso
 Cumpra todas as suas necessidades
 Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais

Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um

modelo de análise. O modelo de design serve como uma abstração do código-fonte, isto
é, o projeto atua como um modelo de "gabarito" de como o código-fonte é estruturado e
escrito. O modelo de projeto consiste em classes de design estruturado em pacotes e
subsistemas com interfaces bem definidas, representando o que irá se tornar
componentes da aplicação. Ele também contém descrições de como os objetos dessas
classes colaboram para desempenhar casos de uso do projeto.

Disciplina de Implementação

Os efeitos da implementação são:

  Para definir a organização do código, em termos de subsistemas de
implementação organizadas em camadas
 Para implementar classes e objetos em termos de componentes (arquivos-fonte,
binários, executáveis e outros)
 Para testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores individuais (ou equipes),
em um sistema executável

Sistemas são realizados através da aplicação de componentes. O processo descreve

como a reutilização de componentes existentes ou implementar novos componentes com
responsabilidades bem definidas, tornando o sistema mais fácil de manter e aumentar as
possibilidades de reutilização.

Disciplina de Teste

As finalidades da disciplina de teste são:

 Para verificar a interação entre objetos

 Para verificar a integração adequada de todos os componentes do software
 Para verificar se todos os requisitos foram corretamente implementados
 Identificar e garantir que os defeitos são abordados antes da implantação do
software
 Garantir que todos os defeitos são corrigidos, reanalisados e fechados

O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-
se testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que
reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de
quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da
aplicação, e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o
processo descreve como você passar pelo teste do ciclo de planejamento, projeto,
implementação, execução e avaliação.

Disciplina de Implantação

O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e

entregar o software para seus usuários finais. Ele cobre uma vasta gama de atividades,
incluindo a produção de releases externos do software, a embalagem do software e
aplicativos de negócios, distribuição do software, instalação do software e prestação de
ajuda e assistência aos usuários. Embora as atividades de implantação estão
principalmente centradas em torno da fase de transição, muitas das atividades devem ser
incluídas nas fases anteriores para se preparar para a implantação, no final da fase de
construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm
menos detalhes do que outros workflows.

Três Disciplinas de Apoio/Suporte

Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar o processo para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a um
projeto. A proposta das atividades de ambiente é prover à organização de
desenvolvimento de software com o ambiente de desenvolvimento de software - os
processos e as ferramentas - que darão suporte à equipe de desenvolvimento. Se os
usuários do RUP não entendem que o RUP é um framework de processo, eles podem
percebê-lo como um processo pesado e caro. No entanto, um conceito-chave dentro do
RUP foi que o processo RUP pode e, muitas vezes, deve ser refinado. Este foi
inicialmente feito manualmente, ou seja, por escrito, um documento de "caso de
desenvolvimento" que especificou o processo refinado para ser utilizado.
Posteriormente, o produto IBM Rational Method Composer foi criado para ajudar a
tornar esta etapa mais simples, engenheiros de processos e gerentes de projeto poderiam
mais facilmente personalizar o RUP para suas necessidades de projeto. Muitas das
variações posteriores do RUP, incluindo OpenUP/Basic, a versão open-source e leve do
RUP, são agora apresentados como processos distintos, por direito próprio, e atendem a
diferentes tipos e tamanhos de projetos, tendências e tecnologias de desenvolvimento de
software. Historicamente, como o RUP, muitas vezes é personalizado para cada projeto
por um perito do processo RUP, o sucesso total do projeto pode ser um pouco
dependente da capacidade desta pessoa.

Disciplina de Configuração e Gerência de Mudança

A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos

específicos: de configuração, de solicitações de mudança, e de status e medição.

 Gerenciamento de configuração: A gestão de configuração é responsável pela

estruturação sistemática dos produtos. Artefatos, como documentos e modelos,
precisam estar sob controle de versão e essas alterações devem ser visíveis. Ele
também mantém o controle de dependências entre artefatos para que todos os
artigos relacionados sejam atualizados quando são feitas alterações
 Gerenciamento de solicitações de mudança: Durante o processo de
desenvolvimento de sistemas com muitos artefatos existem diversas versões. O
CRM mantém o controle das propostas de mudança
 Gerenciamento de status e medição: Os pedidos de mudança têm os estados:
novo, conectado, aprovado, cedido e completo. A solicitação de mudança
também tem atributos como a causa raiz, ou a natureza (como o defeito e
valorização), prioridade, etc. Esses estados e atributos são armazenados no
banco de dados para produzir relatórios úteis sobre o andamento do projeto. A
Rational também tem um produto para manter a solicitações de mudança
chamado ClearQuest. Esta atividade têm procedimentos a serem seguidos

Disciplina de Gerência de Projeto

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade

ou planos de Fase que descreve todo o projeto, e uma série de alta granularidade ou
planos de Iteração que descrevem os passos iterativos. Esta disciplina concentra-se
principalmente sobre os aspectos importantes de um processo de desenvolvimento
iterativo: Gestão de riscos; Planejamento um projeto iterativo através do ciclo de vida e
para uma iteração particular; E o processo de acompanhamento de um projeto iterativo,
métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do
gerenciamento de projetos.

Por exemplo, não abrange questões como:

 Gestão de Pessoas: contratação, treinamento, etc

 Orçamento Geral: definição, alocação, etc
 Gestão de Contratos: com fornecedores, clientes, etc

Princípios e melhores práticas

RUP é baseado em um conjunto de princípios de desenvolvimento de software e
melhores práticas, por exemplo:

1. Desenvolvimento de software iterativo

2. Gerenciamento de requisitos
3. Uso de arquitetura baseada em componente
4. Modelagem visual de software
5. Verificação da qualidade do software
6. Controle de alteração no software

Desenvolvimento iterativo

Dado o tempo gasto para desenvolver um software grande e sofisticado, não é possível
definir o problema e construir o software em um único passo. Os requerimentos irão
freqüentemente mudar no decorrer do desenvolvimento do projeto, devido a restrições
de arquitetura, necessidades do usuário ou a uma maior compreensão do problema
original. Alterações permitem ao projeto ser constantemente refinado, além de
assinalarem itens de alto risco do projeto como as tarefas de maior prioridade. De forma
ideal, ao término de cada iteração haverá uma versão executável, o que ajuda a reduzir o
risco de configuração do projeto, permitindo maior retorno do usuário e ajudando ao
desenvolvedor manter-se focado.

O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:

 A integração é feita passo a passo durante o processo de desenvolvimento,

limitando-se cada passo a poucos elementos
 A integração é menos complexa, reduzindo seu custo e aumentado sua eficiência
 Partes separadas de projeto e/ou implementação podem ser facilmente
identificadas para posterior reuso
 Mudanças de requisitos são registradas e podem ser acomodadas
 Os riscos são abordados no inicio do desenvolvimento e cada iteração permite a
verificação de riscos já percebidos bem como a identificação de novos
 Arquitetura de software é melhorada através de um escrutino repetitivo

Usando iterações, um projeto terá um plano geral, como também múltiplos planos de
iteração. O envolvimento dos stakeholders é freqüentemente encorajado a cada entrega.
Desta maneira, as entregas servem como uma forma de se obter o comprometimento dos
envolvidos, promovendo também uma constante comparação entre os requisitos e o
desenvolvimento da organização para as pendências que surgem.

Gerenciamento de requisitos

O Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades

do usuário final pela identificação e especificação do que ele necessita e identificando
aquilo que deve ser mudado. Isto traz como benefícios:

 A correção dos requisitos gera a correção do produto, as necessidades dos

usuários são encontradas.
 As características necessárias serão incluídas, reduzindo o custo de
desenvolvimentos posteriores.

RUP sugere que o gerenciamento de requisitos tem que seguir as atividades:

 Análise do problema é concordar com o problema e criar medições que irão

provar seu valor para a organização
 Entender as necessidades de seus stakeholders é compartilhar o problema e
valores com os stakeholders-chave e levantar quais as necessidades que estão
envolvidas na elaboração da ideia
 Definir o problema é a definição das características das necessidades e
esquematização dos casos de uso, atividades que irão facilmente mostrar os
requerimentos de alto-nível e esboçar o modelo de uso do sistema
 Gerenciar o escopo do sistema trata das modificações de escopo que serão
comunicadas baseadas nos resultados do andamento e selecionadas na ordem na
qual os fluxogramas de casos de uso são atacados
 Refinar as definições do sistema trata do detalhamento dos fluxogramas de
caso de uso com os stakeholders de forma a criar uma especificação de
requerimentos de software que pode servir como um contrato entre o seu grupo e
o do cliente e poderá guiar as atividades de teste e projeto
 Gerenciamento das mudanças de requisitos trata de como identificar as
chegadas das mudanças de requerimento num projeto que já começou

Uso de arquitetura baseada em componentes

Arquitetura baseada em componentes cria um sistema que é facilmente extensível,

intuitivo e de fácil compreensão e promove a reusabilidade de software. Um
componente freqüentemente se relaciona com um conjunto de objetos na programação
orientada ao objeto.

Arquitetura de software aumenta de importância quando um sistema se torna maior e

mais complexo. RUP foca na produção da arquitetura básica nas primeiras iterações.
Esta arquitetura então se torna um protótipo nos ciclos iniciais de desenvolvimento. A
arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final do sistema.
RUP também propõe regras de projeto e restrições para capturar regras de arquitetura.
Pelo desenvolvimento iterativo é possível identificar gradualmente componentes os
quais podem então ser desenvolvidos, comprados ou reusados. Estes componentes são
freqüentemente construídos em infra-estruturas existentes tais como CORBA e COM,
ou JavaEE, ou PHP

Modelagem visual de software

Abstraindo sua programação do seu código e representando-a usando blocos de

construção gráfica constitui-se de uma forma efetiva de obter uma visão geral de uma
solução. Usando esta representação, recursos técnicos podem determinar a melhor
forma para implementar a dado conjunto de interdependências lógicas. Isto também
constrói uma camada intermediária entre o processo de negócio e o código necessário
através da tecnologia da informação. Um modelo neste contexto é uma visualização e ao
mesmo tempo uma simplificação de um projeto complexo. RUP especifica quais
modelos são necessários e porque.

A Linguagem modelagem unificada (UML) pode ser usada para modelagem de Casos
de Uso, diagrama de classes e outros objetos. RUP também discute outras formas para
construir estes modelos.

Verificar qualidade de software

Garantia da qualidade de software é o ponto mais comum de falha nos projetos de

software, desde que isto é freqüentemente algo que não se pensa previamente e é
algumas vezes tratado por equipes diferentes. O RUP ajuda no planejamento do controle
da qualidade e cuida da sua construção em todo processo, envolvendo todos os
membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o
RUP assume que cada membro da equipe é responsável pela qualidade durante todo o
processo. O processo foca na descoberta do nível de qualidade esperado e provê testes
nos processos para medir este nível.

Controle de alterações no software

Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para
controlar, rastrear e monitorar estas mudanças. RUP também define espaços de
trabalho seguros (do inglês secure workspaces), garantindo que um sistema de
engenharia de software não será afetado por mudanças em outros sistemas. Este
conceito é bem aderente com arquiteturas de software baseados em componentização.
IBM Rational Unified Process
From Wikipedia, the free encyclopedia

Jump to: navigation, search

Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Models
Agile · Cleanroom · DSDM
Iterative · RAD  · RUP  · Spiral
Waterfall · XP · Scrum  · Lean
V-Model  · FDD  · TDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design
Tools
Compiler  · Debugger  · Profiler
GUI designer
Integrated development environment
This box: view • talk

The Rational Unified Process (RUP) is an iterative software development process

framework created by the Rational Software Corporation, a division of IBM since 2003.
RUP is not a single concrete prescriptive process, but rather an adaptable process
framework, intended to be tailored by the development organizations and software
project teams that will select the elements of the process that are appropriate for their
needs.

Contents
[hide]

 1 History
 2 Rational Unified Process topics
 o 2.1 RUP building blocks
o 2.2 Four project lifecycle phases
 2.2.1 Inception phase
 2.2.2 Elaboration phase
 2.2.3 Construction phase
 2.2.4 Transition phase
o 2.3 Six engineering disciplines
o 2.4 Three supporting disciplines
 2.4.1 Phase plan
 2.4.2 Iteration plan
 2.4.3 Work Product (Artifact)
o 2.5 The IBM Rational Method Composer product
o 2.6 Certification
o 2.7 Six Best Practices
 3 Other frameworks
o 3.1 Refinements and variations
o 3.2 Competing frameworks and methodologies
 4 See also
 5 References
 6 Further reading
 7 External links

History
The Rational Unified Process (RUP) is a software process product, originally developed
by Rational Software, which was acquired by IBM in February 2003. The product
includes a hyperlinked knowledge base with sample artifacts and detailed descriptions
for many different types of activities. RUP is included in the IBM Rational Method
Composer (RMC) product which allows customization of the process.

By 1997, Rational had acquired Verdix, Objectory, Requisite, SQA, Performance

Awareness, and Pure-Atria. Combining the experience base of these companies led to
the articulation of six best practices for modern software engineering:

1. Develop iteratively, with risk as the primary iteration driver

2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes
7. Customisation

These best practices both drove the development of Rational's products, and were used
by Rational's field teams to help customers improve the quality and predictability of
their software development efforts. To make this knowledge more accessible, Philippe
Kruchten, a Rational techrep, was tasked with the assembly of an explicit process
framework for modern software engineering. This effort employed the HTML-based
process delivery mechanism developed by Objectory. The resulting "Rational Unified
Process" (RUP) completed a strategic tripod for Rational:

 a tailorable process that guided development

 tools that automated the application of that process
 services that accelerated adoption of both the process and the tools.

Rational Unified Process topics

RUP building blocks

RUP is based on a set of building blocks, or content elements, describing what are to be
produced, the necessary skills required and the step-by-step explanation describing how
specific development goals are achieved. The main building blocks, or content
elements, are the following:

 Roles (who) – A Role defines a set of related skills, competences, and

responsibilities.
 Work Products (what) – A Work Product represents something resulting from a
task, including all the documents and models produced while working through
the process.
 Tasks (how) – A Task describes a unit of work assigned to a Role that provides
a meaningful result.

Within each iteration, the tasks are categorized into nine disciplines: six "engineering
disciplines" (Business Modeling, Requirements, Analysis and Design, Implementation,
Test, Deployment) and three supporting disciplines (Configuration and Change
Management, Project Management, Environment).

Four project lifecycle phases

RUP phases and disciplines.

The RUP has determined a project lifecycle consisting of four phases. These phases
allow the process to be presented at a high level in a similar way to how a 'waterfall'-
styled project might be presented, although in essence the key to the process lies in the
iterations of development that lie within all of the phases. Also, each phase has one key
objective and milestone at the end that denotes the objective being accomplished.

Inception phase

The primary objective is to scope the system adequately as a basis for validating initial
costing and budgets. In this phase the business case which includes business context,
success factors (expected revenue, market recognition, etc), and financial forecast is
established. To complement the business case, a basic use case model, project plan,
initial risk assessment and project description (the core project requirements, constraints
and key features) are generated. After these are completed, the project is checked
against the following criteria:

 Stakeholder concurrence on scope definition and cost/schedule estimates.

 Requirements understanding as evidenced by the fidelity of the primary use
cases.
 Credibility of the cost/schedule estimates, priorities, risks, and development
process.
 Depth and breadth of any architectural prototype that was developed.
 Establishing a baseline by which to compare actual expenditures versus planned
expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it
can either be cancelled or it can repeat this phase after being redesigned to better meet
the criteria.

Elaboration phase

The primary objective is to mitigate the key risk items identified by analysis up to the
end of this phase. The elaboration phase is where the project starts to take shape. In this
phase the problem domain analysis is made and the architecture of the project gets its
basic form.

This phase must pass the Lifecycle Architecture Milestone by the following criteria:

 A use-case model in which the use-cases and the actors have been identified and
most of the use-case descriptions are developed. The use-case model should be
80% complete.
 A description of the software architecture in a software system development
process.
 An executable architecture that realizes architecturally significant use cases.
 Business case and risk list which are revised.
 A development plan for the overall project.
 Prototypes that demonstrably mitigate each identified technical risk.

If the project cannot pass this milestone, there is still time for it to be canceled or
redesigned. After leaving this phase, the project transitions into a high-risk operation
where changes are much more difficult and detrimental when made.
The key domain analysis for the elaboration is system architecture.

Construction phase

The primary objective is to build the software system. In this phase, the main focus goes
to the development of components and other features of the system being designed. This
is the phase when the bulk of the coding takes place. In larger projects, several
construction iterations may be developed in an effort to divide the use cases into
manageable segments that produce demonstrable prototypes.

This phase produces the first external release of the software. Its conclusion is marked
by the Initial Operational Capability Milestone.

Transition phase

The primary objective is to 'transition' the system from the development into
production, making it available to and understood by the end user. The activities of this
phase include training of the end users and maintainers and beta testing of the system to
validate it against the end users' expectations. The product is also checked against the
quality level set in the Inception phase.

If all objectives are met, the Product Release Milestone is reached and the development
cycle ends.

Six engineering disciplines

This article may require copy-editing for grammar, style, cohesion, tone or
spelling. You can assist by editing it now. (September 2009)
Business modeling discipline
Organizations are becoming more dependent on IT systems, making it
imperative that information system engineers know how the applications they
are developing fit into the organization. Businesses invest in IT when they
understand the competitive advantage and value added by the technology. The
aim of business modeling is to first establish a better understanding and
communication channel between business engineering and software engineering.
Understanding the business means that software engineers must understand the
structure and the dynamics of the target organization (the client), the current
problems in the organization and possible improvements. They must also ensure
a common understanding of the target organization between customers, end
users and developers.
Business modeling explains how to describe a vision of the organization in
which the system will be deployed and how to then use this vision as a basis to
outline the process, roles and responsibilities.
Requirements discipline
This discipline explains how to elicit stakeholder requests and transform them
into a set of requirements work products that scope the system to be built and
provide detailed requirements for what the system must do.
Analysis and design discipline
The goal of analysis and design is to show how the system will be realized. The
aim is to build a system that
  Performs—in a specific implementation environment—the tasks and
functions specified in the use-case descriptions.
 Fulfills all its requirements.
 Is easy to change when functional requirements change.

Design results in a design model and analysis optionally an analysis model. The
design model serves as an abstraction of the source code; that is, the design
model acts as a 'blueprint' of how the source code is structured and written. The
design model consists of design classes structured into packages and subsystems
with well-defined interfaces, representing what will become components in the
implementation. It also contains descriptions of how objects of these design
classes collaborate to perform use cases.
Implementation discipline
The purposes of implementation are

 To define the organization of the code, in terms of implementation

subsystems organized in layers.
 To implement classes and objects in terms of components (source files,
binaries, executables, and others).
 To test the developed components as units.
 To integrate the results produced by individual implementers (or teams),
into an executable system.

Systems are realized through implementation of components. The process

describes how you reuse existing components, or implement new components
with well defined responsibility, making the system easier to maintain, and
increasing the possibilities to reuse.
Test discipline
The purposes of the Test discipline are:

 To verify the interaction between objects.

 To verify the proper integration of all components of the software.
 To verify that all requirements have been correctly implemented.
 To identify and ensure that defects are addressed prior to the deployment
of the software
 Ensure that all the defects are fixed, retested and closed.

The Rational Unified Process proposes an iterative approach, which means that
you test throughout the project. This allows you to find defects as early as
possible, which radically reduces the cost of fixing the defect. Tests are carried
out along four quality dimensions: reliability, functionality, application
performance, and system performance. For each of these quality dimensions, the
process describes how you go through the test lifecycle of planning, design,
implementation, execution and evaluation.
Deployment discipline
The purpose of deployment is to successfully produce product releases, and
deliver the software to its end users. It covers a wide range of activities
including producing external releases of the software, packaging the software
and business application, distributing the software, installing the software and
 providing help and assistance to users. Although deployment activities are
mostly centered around the transition phase, many of the activities need to be
included in earlier phases to prepare for deployment at the end of the
construction phase.The Deployment and Environment workflows of the Rational
Unified Process contain less detail than other workflows.

Three supporting disciplines

Environment discipline 
The environment discipline focuses on the activities necessary to configure the
process for a project. It describes the activities required to develop the guidelines
in support of a project. The purpose of the environment activities is to provide
the software development organization with the software development
environment-both processes and tools-that will support the development team. If
the users of RUP do not understand that RUP is a process framework, they may
perceive it as a weighty and expensive process. However a key concept within
RUP was that the RUP process could and often should itself be refined. This was
initially done manually, ie by writing a "Development case" document that
specified the refined process to be used. Later the IBM Rational Method
Composer product was created to help make this step simpler, so process
engineers and project managers could more easily customize the RUP for their
project needs. Many of the later variants of RUP, including OpenUP/Basic, the
lightweight and open source version of RUP, are now presented as separate
processes in their own right, and cater for different types and sizes of projects
and trends and technologies in software development. Historically, as the RUP is
often customized for each project by a RUP process expert, the project's overall
success can be somewhat dependent on the abilities of this one person.
Configuration and Change management discipline 
The Change Management discipline in RUP deals with three specific areas:
configuration management, change request management, and Status and
measurement management.

 Configuration management: Configuration management is responsible

for the systematic structuring of the products. Artifacts such as
documents and models need to be under version control and these
changes must be visible. It also keeps track of dependencies between
artifacts so all related articles are updated when changes are made.
 Change request management: During the system development process
many artifacts with several versions exist. CRM keeps track of the
proposals for change.
 Status and measurement management: Change requests have states such
as new, logged, approved, assigned and complete. A change request also
has attributes such as root cause, or nature (like defect and
enhancement), priority etc. These states and attributes are stored in
database so useful reports about the progress of the project can be
produced. Rational also has a product to maintain change requests called
ClearQuest. This activity has procedures to be followed.

Project management discipline 

 The Project management discipline and project planning in the RUP occur at
two levels. There is a coarse-grained or Phase plan which describes the entire
project, and a series of fine-grained or Iteration plans which describe the
iterations. This discipline focuses mainly on the important aspects of an iterative
development process: Risk management, Planning an iterative project, through
the lifecycle and for a particular iteration, and Monitoring progress of an
iterative project, metrics. However, this discipline of the RUP does not attempt
to cover all aspects of project management.

For example, it does not cover issues such as:

 Managing people: hiring, training, etc.

 Managing budget: defining, allocating, etc.
 Managing contracts: with suppliers, with customers, etc.

The project management discipline contains a number of other Plans and Artifacts that
are used to control the project and monitoring its performance. Such Plans are:

 The Phase Plan (The Software Development Plan)

 The Iteration Plan

Phase plan

Each Phase is treated as a project, controlled and measured by the Software

Development Plan which is grouped from a subset of monitoring plans:

 The Measurement Plan defines the measurement goals, the associated metrics,
and the primitive metrics to be collected in the project to monitor its progress.
 The Risk Management Plan details how to manage the risks associated with a
project. It details the risk management tasks that will be carried out, assigned
responsibilities, and any additional resources required for the risk management
activity. On a smaller scale project, this plan may be embedded within the
Software Development Plan.
 The Risk list is a sorted list of known and open risks to the project, sorted in
decreasing order of importance and associated with specific mitigation or
contingency actions.
 The Problem Resolution Plan describes the process used to report, analyze, and
resolve problems that occur during the project.
 The Product Acceptance Plan describes how the customer will evaluate the
deliverable artifacts from a project to determine if they meet a predefined set of
acceptance criteria. It details these acceptance criteria, and identifies the product
acceptance tasks (including identification of the test cases that need to be
developed) that will be carried out, and assigned responsibilities and required
resources. On a smaller scale project, this plan may be embedded within the
Software Development Plan.
Iteration plan

The iteration plan is a fine-grained plan with a time-sequenced set of activities and
tasks, with assigned resources, containing task dependencies, for the iteration.

There are typically two iteration plans active at any point in time.

 The current iteration plan is used to track progress in the current iteration.
 The next iteration plan is used to plan the upcoming iteration. This plan is
prepared toward the end of the current iteration.

To define the contents of an iteration you need:

 the project plan

 the current status of the project (on track, late, large number of problems,
requirements creep, etc.)
 a list of scenarios or use cases that must be completed by the end of the iteration
 a list of risks that must be addressed by the end of the iteration
 a list of changes that must be incorporated in the product (bug fixes, changes in
requirements)
 a list of major classes or packages that must be completely implemented

These lists must be ranked. The objectives of an iteration should be aggressive so that
when difficulties arise, items can be dropped from the iterations based on their ranks.

Therefore there is a set of supported Artifacts that help in measuring and building each
iteration plan.

Work Product (Artifact)

IBM has replaced the term "Artifact" with the term "work product". The work products
used are:

 The Iteration Assessment captures the result of an iteration, the degree to

which the evaluation criteria were met, lessons learned, and changes to be done.
 The project measurements is the project's active repository of metrics data. It
contains the most current project, resources, process, and product measurements
at the primitive and derived level.
 The periodic Status Assessment provides a mechanism for managing
everyone's expectations throughout the project lifecycle to ensure that the
expectations of all parties are synchronized and consistent.
 The work order is the Project Manager's means of communicating with the staff
about what is to be done and when it is to be completed. It becomes an internal
contract between the Project Manager and those assigned responsibility for
completion.
 The Issues List is a way to record and track problems, exceptions, anomalies, or
other incomplete tasks requiring attention.
The IBM Rational Method Composer product

The IBM Rational Method Composer product is a tool for authoring, configuring,
viewing, and publishing processes. See IBM Rational Method Composer and an open
source version Eclipse Process Framework (EPF) project for more details.