Obtendo Qualidade de Software com o RUP

Obtendo Qualidade de Software com o RUP

Abstract. This article describes what should be considered in the software development to
achieve acceptable quality patterns. The article shows that quality software is something that
should be considered in all time in the application life cycle. One of the features that can
maximize the software’s quality level is the iterative and incremental development. Moreover,
the failures of the waterfall development process and the show and description of the Rational
Unified Process (RUP)’s features will be approached.

Resumo. Este artigo descreve o que deve ser levado em consideração no desenvolvimento de
software para atingir padrões de qualidade aceitáveis. O artigo mostra que a qualidade de
software é algo que deve ser levado em consideração em todo momento do ciclo de vida do
aplicativo. Uma das características que podem elevar o nível de qualidade do software é o
desenvolvimento iterativo e incremental. Além disso, são abordadas as falhas do processo de
desenvolvimento em cascata e a apresentação e descrição das características do Rational
Unified Process (RUP).

1
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

1. Introdução

A cada dia que passa, as organizações se tornam mais dependentes dos sistemas de informação.
Atualmente, não apenas sistemas que podem colocar a vida de pessoas em risco são
considerados sistemas de missão crítica. Hoje, os sistemas de informação de muitas empresas
são qualificados como de missão crítica, pois podem gerar enormes prejuízos financeiros caso
haja eventuais problemas com os mesmos.

A atividade de desenvolvimento de software possui um alto grau de risco. Essa atividade já

gerou grandes prejuízos no passado e continua gerando. Atualmente, muitos projetos de
desenvolvimento de software são iniciados e não são terminados, e outros são terminados
consumindo prazos e orçamentos bem acima do que foi estipulado no início do projeto. Além
disso, muitos produtos desenvolvidos possuem um nível muito baixo de qualidade.

Conforme [Kruchten 2003], um produto de qualidade deve ter ausência de defeitos e,

principalmente, deve atender aos propósitos desejados. Alguma coisa com qualidade deve fazer
o que as pessoas querem que ela faça. Se alguma coisa é livre de defeitos, mas não faz o que as
pessoas querem que ela faça, essa coisa é um produto desnecessário.

A qualidade de software não pode ser avaliada de maneira isolada. Softwares são desenvolvidos
pelas organizações através de procedimentos. Um método pobre ou a ausência de uma
metodologia pode ser a causa da baixa qualidade. Sendo assim, a avaliação da qualidade está
diretamente relacionada com a qualidade de processos e metodologias utilizadas.

2
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

2. Metodologias de Desenvolvimento

Metodologias de desenvolvimento e estruturas de avaliação de processos podem ser comparadas

sob duas dimensões: de um lado, temos o vértice pouca formalidade / muita formalidade e de
outro, o método cascata / método iterativo, exemplificado através da Figura 1.

Figura 1: Mapa de processos

Os processos com pouca formalidade produzem o mínimo de documentação possível e

procedimentos de trabalho bastante informais. Os formais possuem maior documentação,
mantém o histórico dos artefatos gerados e possuem gerenciamento de mudanças.
O método cascata é um procedimento linear, onde a integração e os testes são feitos no fim do
ciclo de desenvolvimento. O método iterativo é guiado pelo risco, ou seja, é voltado para a
eliminação e minimização de riscos. A implementação da arquitetura, a integração e os testes
são realizados desde o início do ciclo de vida do aplicativo.

2.1 Método Cascata

Esse método, também conhecido como seqüencial, ou linear, foi utilizado por muitos anos e
ainda é utilizado. Segundo [Kroll e Kruchten 2003], esse processo se baseia nos seguintes
passos:

 Entender completamente o problema a ser resolvido, seus requisitos e suas restrições;

 Projetar uma solução que atenda todos os requisitos e restrições. Examinar o projeto
cuidadosamente e ter certeza que todas as parte interessadas concordam que essa é a
solução certa;
 Fazer a implementação do projeto, usando as melhores técnicas de engenharia;
 Verificar se a solução atende aos requisitos estabelecidos;

3
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

 Distribuir o produto.

Esse processo é similar à forma a qual pontes e edifícios são construídos. Algumas coisas
devem ser feitas dessa maneira. Em um projeto com dois meses de duração, essa metodologia
poderia ser usada. Mas normalmente, softwares não devem ser desenvolvidos dessa forma.

2.2 Método Iterativo e Incremental

O método iterativo foi criado para superar as dificuldades impostas pelo

modelo cascata. Já que o modelo cascata pode ser usado com sucesso em
projetos pequenos, onde o domínio do problema é bem conhecido, a
solução encontrada foi dividir grandes projetos em projetos menores.
Dessa maneira, alguns requisitos e alguns riscos podem ser identificados,
um projeto pode ser realizado, uma implementação pode ser construída
para esse projeto, validada e testada. Esse processo se repete com outras
partes do sistema até que o sistema inteiro seja terminado. Isso é chamado
de modo iterativo.

Em cada pequena parte do sistema é feita uma iteração. A iteração segue o

modelo seqüencial tradicional, com identificação de necessidades, análise,
projeto, implementação e testes.
A cada iteração o sistema é incrementado até que o ciclo de
desenvolvimento do aplicativo termine. Nesse ponto, um novo ciclo de
desenvolvimento pode ser iniciado.

A maneira de desenvolver projetos através de várias iterações que vão

incrementando o projeto até que se chegue a um objetivo é chamada de
modo iterativo e incremental. Atualmente esse paradigma de
desenvolvimento é bem aceito e vem sendo utilizado por várias
metodologias de desenvolvimento de software.

4
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

3. O Rational Unified Process

Conforme [Kroll e Kruchten 2003], podemos ter três definições para o Rational Unified Process
(RUP):

 O RUP é uma maneira de desenvolvimento de software que é iterativa, centrada à

arquitetura e guiada por casos de uso. É descrita em vários livros e artigos. Uma das
maiores fontes de informações é o próprio produto IBM RUP [1], que contém guias
detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;
 O RUP é um processo de engenharia de software bem definido e bem estruturado. O
RUP define claramente quem é responsável pelo que, como as coisas devem ser feitas e
quando fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida
de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão;
 O RUP é também um produto de processo que oferece uma estrutura de processo
customizável para a engenharia de software. O produto IBM RUP suporta a
customização e autoria de processos, e uma vasta variedade de processos, ou
configuração de processos, podem ser montadas nele. Essas configurações do RUP
podem ser criadas para suportar equipes grandes e pequenas, e técnicas de
desenvolvimento disciplinadas ou menos formais. O produto IBM RUP contém várias
configurações e visões de processos prontas que guiam analistas, desenvolvedores,
testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros
membros da equipe de desenvolvimento em como desenvolver o software. Ele tem sido
utilizado por muitas companhias em diferentes setores da indústria.

O RUP utiliza a Linguagem Unificada de Modelagem (UML [2]) para especificar, modelar e
documentar artefatos. A UML é um padrão definido pelo OMG [3] e ter se tornado o padrão
empresarial para a modelagem orientada a objetos [4].

Por ser flexível e configurável, o RUP pode ser utilizado em projetos de pequeno, médio e
grande porte. [Kroll e Kruchten 2003] mostra como o RUP pode ser utilizado em um projeto de
uma semana com uma equipe de uma pessoa.

3.1 Os Princípios do RUP

Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e
será diferente em cada projeto e organização. Porém, existem alguns princípios que podem
caracterizar e diferenciar o RUP de outros métodos iterativos:

 Atacar os riscos cedo e continuamente;

5
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

 Certificar-se de entregar algo de valor ao cliente;

 Focar no software executável;
 Acomodar mudanças cedo;
 Liberar um executável da arquitetura cedo;
 Construir o sistema com componentes;
 Trabalhar junto como um time;
 Fazer da qualidade um estilo de vida, não algo para depois.

3.2 Elementos do RUP

O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e
disciplinas.
Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado
indivíduo ou grupo de indivíduos trabalhando como uma equipe. Papéis não são indivíduos e
nem títulos de trabalho. Um indivíduo pode assumir vários papéis. São exemplos de papéis:

 Analista de sistema – O indivíduo que assume este papel coordena a obtenção dos
requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e
estabelecendo limites do sistema;
 Projetista – Esse indivíduo define responsabilidades, operações, atributos,
relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas
para serem implementadas no ambiente;
 Projetista de testes – Responsável pelo planejamento, projeto, implantação e avaliação
de testes, incluindo a geração de plano e modelo de teste, implementando
procedimentos de testes e avaliando a abrangência dos testes, resultados e a
efetividade.

Uma atividade é uma unidade de trabalho que um indivíduo executa quando está exercendo um
determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade
pode ser dividida em passos. São exemplos de atividades:

 Planejar uma iteração: realizada pelo papel gerente de projeto;

 Encontrar casos de uso e atores: realizada pelo papel analista de sistemas;
 Rever o projeto: realizada pelo papel revisor de projeto;
 Executar um teste de performance: realizado pelo papel testador de performance.

6
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

Um artefato é um pedaço de informação que é produzido, modificado ou utilizado em um

processo. Os artefatos são os produtos de um projeto. São as coisas produzidas durante o
desenvolvimento do projeto. Artefatos são utilizados como entradas de atividades e são
produzidos como saída.
Os artefatos podem ter várias formas:

 Um modelo, como um modelo de caso de uso, um modelo de projeto;

 Um elemento de um modelo, como uma classe, um caso de uso, um sub-sistema;
 Um documento, como um caso de negócio, glossário, visão;
 Código fonte;
 Executáveis.
A enumeração de atividades, papéis e artefatos não constituem um processo. É necessário saber
a seqüência do desenvolvimento das atividades para que possam ser produzidos artefatos de
valor para o projeto. Um fluxo de trabalho [5] é uma seqüência de atividades que são executadas
para a produção de um resultado valioso para o projeto. Fluxos de trabalho podem ser
representados por diagramas de seqüência, diagramas de colaboração e diagramas de atividades
da linguagem UML. O RUP utiliza três tipos de fluxos de trabalho:

 Fluxos de trabalho principais, associados com cada disciplina (figura 2);

 Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal (figura 3);
 Planos de iteração, que mostram como a iteração deverá ser executada.

Figura 2: Fluxo de trabalho: requisitos

7
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

Figura 3: Detalhamento de fluxo de trabalho: analisar o problema

Uma disciplina é uma coleção de atividades relacionadas que fazem parte de um contexto
comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o
ponto de vista tradicional de um processo cascata. A separação das atividades em disciplinas
torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das
atividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte.
As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto,
implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de
mudanças, gerenciamento de projeto, e ambiente.

Figura 4: Arquitetura geral do RUP

Conforme mostra a figura 4, o RUP possui duas dimensões:

 O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo

à medida que se desenvolve. Representa o aspecto dinâmico do processo. É expresso
em termos de fases, disciplinas e marcos.

8
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

 O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica,

por natureza. Representa o aspecto estático do processo. É descrito em termos de
componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

3.3 O Ciclo de Vida de um Projeto RUP

O ciclo de desenvolvimento no RUP possui quatro fases: iniciação [6] , elaboração, construção
e transição. Cada uma é concluída por um marco principal, ou seja, cada fase é basicamente um
intervalo de tempo entre dois marcos principais, como é mostrado na figura 5.

Figura 5: As fases e os marcos de um projeto

O ciclo de desenvolvimento termina com uma versão completa do produto de software. As fases
definem estados do projeto, que são definidos por riscos que estão sendo mitigados ou questões
que precisam ser respondidas.

A fase de iniciação, foca no tratamento de riscos relacionados com o caso de negócio. Deve ser
verificado se o projeto é viável e se é financeiramente possível.

Na fase elaboração, o foco deve ser nos riscos técnicos e arquiteturais. O escopo deve ser
revisado e os requisitos devem estar mais compreendidos.

Durante a construção, a atenção será voltada para os riscos “ lógicos ”, e a maior parte do
trabalho será realizada.

Na fase de transição, serão tratados os riscos associados com a logística de distribuição do

produto para a base de usuários.

Embora varie muito em empresas e projetos diferentes, um ciclo de desenvolvimento para um

projeto de tamanho médio, possui uma distribuição de esforço e programação como é
apresentado na tabela 1 e na figura 6.

9
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

Tabela 1. Distribuição de esforço e programação em projetos de médio porte.

Figura 6: Distribuição de esforço e programação em projetos de médio porte.

Conforme descrito na documentação do RUP, cada passagem pelas quatro fases gera uma
geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima
geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição.
Esses ciclos subseqüentes são chamados de ciclos de evolução. A cada ciclo, são produzidas
novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças
no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por
diante. Normalmente, a menos que ocorram mudanças significativas do produto ou da
arquitetura, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a
definição e a arquitetura básicas do produto foram determinadas por ciclos de desenvolvimento
anteriores.

10
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

4. Conclusão

Com a utilização de uma metodologia de desenvolvimento de software como o RUP, é possível

obter:

 Qualidade de software;
 Produtividade no desenvolvimento, operação e manutenção de software;
 Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade
desejados;
 Estimativa de prazos e custos com maior precisão.

Apesar dos benefícios, deve-se ter a consciência que os benefícios não virão de maneira
imediata. É necessário adquirir treinamento adequado, adaptação da metodologia no contexto ao
qual ela será utilizada, apoio especializado para as equipes de desenvolvimento e tempo para a
absorção da metodologia.

Mais informações a respeito do RUP podem ser obtidas no site do IBM RUP e também no site
da comunidade IBM Rational. (IBM 2004).

11
http://qualidade-de-software.blogspot.com
 Obtendo Qualidade de Software com o RUP

Referências

Comunidade IBM RUP (2004) http://www-130.ibm.com/developerworks / rational /

community, Novembro.
Fowler, Martin (2003) “ UML Distilled: A Brief Guide to the Standard Object Modeling
Language ”, Addison Wesley, 3 ª Edição.
IBM Rational Unified Process Versão 2003.06.12.01. (2004) http://www-
306.ibm.com/software/rational, Novembro.
IBM RUP (2004) http://www-130.ibm.com/developerworks/rational/products/rup,Novembro.
Kroll, P. e Kruchten P. (2003) “ The Rational Unified Process Made Easy: A Practitioner ' s
Guide to the RUP ”, Addison Wesley.
Kruchten, P. (2003) “ The Rational Unified Process: An Introduction ”, Addison Wesley, 3 ª
Edição.
Larman, Craig (2001) “ Applying UML and Patterns – An Introduction to Object-Oriented
Analysis and Design and the Unified Process ”, Prentice Hall, 2 ª Edição.
Object Management Group (2004) http://www.omg.org, Novembro.
Perrelli, Hermano (2004) “ Visão Geral do RUP ”. Centro de Informática, Universidade Federal
de Pernambuco. http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf, Novembro.
[1] Após a compra da Rational pela IBM, o produto Rational Unified Process passou a se
chamar IBM Rational Unified Process (IBM RUP).
[2] UML: Abreviatura do inglês Unified Modeling Language. [Fowler 2003] é uma ótima
referência para esse assunto.
[3] OMG: Object Management Group.
[4] Consulte [Larman 2001] para informações sobre aplicação da UML para análise e projeto
orientados a objeto
[5] O termo fluxo de trabalho vem do termo inglês workflow. Pode ser traduzido também como
fluxo de atividade.
[6] Iniciação é a tradução do termo inglês “ inception ”. Esse termo é também traduzido como “
concepção ”.

Por: Ronaldo Rezende Vilela Luiz

12
http://qualidade-de-software.blogspot.com