obtendo qualidade de software com o rup

8/9/2019 Obtendo Qualidade de Software Com o RUP

1/12


2/12

Obtendo Qualidade de Software com o RUP

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

1. Introduo

A cada dia que passa, as organizaes se tornam mais dependentes dos sistemas de informao.

Atualmente, no apenas sistemas que podem colocar a vida de pessoas em risco soconsiderados sistemas de misso crtica. Hoje, os sistemas de informao de muitas empresasso qualificados como de misso crtica, pois podem gerar enormes prejuzos financeiros casohaja eventuais problemas com os mesmos.

A atividade de desenvolvimento de software possui um alto grau de risco. Essa atividade jgerou grandes prejuzos no passado e continua gerando. Atualmente, muitos projetos dedesenvolvimento de software so iniciados e no so terminados, e outros so terminadosconsumindo prazos e oramentos bem acima do que foi estipulado no incio do projeto. Almdisso, muitos produtos desenvolvidos possuem um nvel muito baixo de qualidade.

Conforme [Kruchten 2003], um produto de qualidade deve ter ausncia de defeitos e,principalmente, deve atender aos propsitos desejados. Alguma coisa com qualidade deve fazero que as pessoas querem que ela faa. Se alguma coisa livre de defeitos, mas no faz o que aspessoas querem que ela faa, essa coisa um produto desnecessrio.

A qualidade de software no pode ser avaliada de maneira isolada. Softwares so desenvolvidos

pelas organizaes atravs de procedimentos. Um mtodo pobre ou a ausncia de umametodologia pode ser a causa da baixa qualidade. Sendo assim, a avaliao da qualidade estdiretamente relacionada com a qualidade de processos e metodologias utilizadas.


3/12



2. Metodologias de Desenvolvimento

Metodologias de desenvolvimento e estruturas de avaliao de processos podem ser comparadas

sob duas dimenses: de um lado, temos o vrtice pouca formalidade / muita formalidade e deoutro, o mtodo cascata / mtodo iterativo, exemplificado atravs da Figura 1.

Figura 1: Mapa de processos

Os processos com pouca formalidade produzem o mnimo de documentao possvel e

procedimentos de trabalho bastante informais. Os formais possuem maior documentao,mantm o histrico dos artefatos gerados e possuem gerenciamento de mudanas.O mtodo cascata um procedimento linear, onde a integrao e os testes so feitos no fim dociclo de desenvolvimento. O mtodo iterativo guiado pelo risco, ou seja, voltado para aeliminao e minimizao de riscos. A implementao da arquitetura, a integrao e os testesso realizados desde o incio do ciclo de vida do aplicativo.

2.1 Mtodo Cascata

Esse mtodo, tambm conhecido como seqencial, ou linear, foi utilizado por muitos anos eainda utilizado. Segundo [Kroll e Kruchten 2003], esse processo se baseia nos seguintespassos:

Entender completamente o problema a ser resolvido, seus requisitos e suas restries; Projetar uma soluo que atenda todos os requisitos e restries. Examinar o projeto

cuidadosamente e ter certeza que todas as parte interessadas concordam que essa asoluo certa;

Fazer a implementao do projeto, usando as melhores tcnicas de engenharia; Verificar se a soluo atende aos requisitos estabelecidos;


4/12



Distribuir o produto.

Esse processo similar forma a qual pontes e edifcios so construdos. Algumas coisas

devem ser feitas dessa maneira. Em um projeto com dois meses de durao, essa metodologiapoderia ser usada. Mas normalmente, softwares no devem ser desenvolvidos dessa forma.

2.2 Mtodo Iterativo e Incremental

O mtodo iterativo foi criado para superar as dificuldades impostas pelomodelo cascata. J que o modelo cascata pode ser usado com sucesso emprojetos pequenos, onde o domnio do problema bem conhecido, asoluo encontrada foi dividir grandes projetos em projetos menores.Dessa maneira, alguns requisitos e alguns riscos podem ser identificados,um projeto pode ser realizado, uma implementao pode ser construdapara esse projeto, validada e testada. Esse processo se repete com outraspartes do sistema at que o sistema inteiro seja terminado. Isso chamadode modo iterativo.

Em cada pequena parte do sistema feita uma iterao. A iterao segue omodelo seqencial tradicional, com identificao de necessidades, anlise,projeto, implementao e testes.A cada iterao o sistema incrementado at que o ciclo dedesenvolvimento do aplicativo termine. Nesse ponto, um novo ciclo dedesenvolvimento pode ser iniciado.

A maneira de desenvolver projetos atravs de vrias iteraes que voincrementando o projeto at que se chegue a um objetivo chamada demodo iterativo e incremental. Atualmente esse paradigma de

desenvolvimento bem aceito e vem sendo utilizado por vriasmetodologias de desenvolvimento de software.


5/12



3. O Rational Unified Process

Conforme [Kroll e Kruchten 2003], podemos ter trs definies 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 vrios livros e artigos. Uma dasmaiores fontes de informaes o prprio produto IBM RUP [1], que contm guiasdetalhados, exemplos e modelos cobrindo todo o ciclo de vida do software;

O RUP um processo de engenharia de software bem definido e bem estruturado. ORUP define claramente quem responsvel pelo que, como as coisas devem ser feitas equando faz-las. O RUP tambm prov uma estrutura bem definida para o ciclo de vidade um projeto RUP, articulando claramente os marcos essenciais e pontos de deciso;

O RUP tambm um produto de processo que oferece uma estrutura de processocustomizvel para a engenharia de software. O produto IBM RUP suporta acustomizao e autoria de processos, e uma vasta variedade de processos, ouconfigurao de processos, podem ser montadas nele. Essas configuraes do RUPpodem ser criadas para suportar equipes grandes e pequenas, e tcnicas dedesenvolvimento disciplinadas ou menos formais. O produto IBM RUP contm vriasconfiguraes e vises de processos prontas que guiam analistas, desenvolvedores,testadores, gerentes de projeto, gerentes de configurao, analistas de dados, e outrosmembros da equipe de desenvolvimento em como desenvolver o software. Ele tem sidoutilizado por muitas companhias em diferentes setores da indstria.

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

Por ser flexvel e configurvel, o RUP pode ser utilizado em projetos de pequeno, mdio egrande porte. [Kroll e Kruchten 2003] mostra como o RUP pode ser utilizado em um projeto deuma semana com uma equipe de uma pessoa.

3.1 Os Princpios do RUP

No existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de vrias formas eser diferente em cada projeto e organizao. Porm, existem alguns princpios que podemcaracterizar e diferenciar o RUP de outros mtodos iterativos:

Atacar os riscos cedo e continuamente;


6/12



Certificar-se de entregar algo de valor ao cliente; Focar no software executvel; Acomodar mudanas cedo; Liberar um executvel da arquitetura cedo; Construir o sistema com componentes; Trabalhar junto como um time; Fazer da qualidade um estilo de vida, no algo para depois.

3.2 Elementos do RUP

O RUP possui cinco elementos principais: papis, atividades, artefatos, fluxos de trabalho edisciplinas.Um papel (ou perfil) define o comportamento e as responsabilidades de um determinadoindivduo ou grupo de indivduos trabalhando como uma equipe. Papis no so indivduos enem ttulos de trabalho. Um indivduo pode assumir vrios papis. So exemplos de papis:

Analista de sistema O indivduo que assume este papel coordena a obteno dosrequisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e

estabelecendo limites do sistema; Projetista Esse indivduo define responsabilidades, operaes, atributos,

relacionamentos de uma ou mais classes e determina como elas devem ser ajustadaspara serem implementadas no ambiente;

Projetista de testes Responsvel pelo planejamento, projeto, implantao e avaliaode testes, incluindo a gerao de plano e modelo de teste, implementandoprocedimentos de testes e avaliando a abrangncia dos testes, resultados e aefetividade.

Uma atividade uma unidade de trabalho que um indivduo executa quando est exercendo umdeterminado papel e produz um resultado importante para o contexto do projeto. Cada atividadepode ser dividida em passos. So exemplos de atividades:

Planejar uma iterao: 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.


7/12



Um artefato um pedao de informao que produzido, modificado ou utilizado em umprocesso. Os artefatos so os produtos de um projeto. So as coisas produzidas durante odesenvolvimento do projeto. Artefatos so utilizados como entradas de atividades e so

produzidos como sada.Os artefatos podem ter vrias 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 negcio, glossrio, viso; Cdigo fonte; Executveis.

A enumerao de atividades, papis e artefatos no constituem um processo. necessrio sabera seqncia do desenvolvimento das atividades para que possam ser produzidos artefatos devalor para o projeto. Um fluxo de trabalho[5] uma seqncia de atividades que so executadaspara a produo de um resultado valioso para o projeto. Fluxos de trabalho podem serrepresentados por diagramas de seqncia, diagramas de colaborao e diagramas de atividadesda linguagem UML. O RUP utiliza trs 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 iterao, que mostram como a iterao dever ser executada.

Figura 2: Fluxo de trabalho: requisitos


8/12



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

Uma disciplina uma coleo de atividades relacionadas que fazem parte de um contextocomum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob oponto de vista tradicional de um processo cascata. A separao das atividades em disciplinas

torna a compreenso das atividades mais fcil, porm dificulta mais o planejamento dasatividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte.

As disciplinas de processo so: modelagem de negcios, requisitos, anlise e projeto,implementao, teste e distribuio. As de suporte so: configurao e gerenciamento de

mudanas, gerenciamento de projeto, e ambiente.

Figura 4: Arquitetura geral do RUP

Conforme mostra a figura 4, o RUP possui duas dimenses:

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

medida que se desenvolve. Representa o aspecto dinmico do processo. expressoem termos de fases, disciplinas e marcos.


9/12



O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lgica,por natureza. Representa o aspecto esttico do processo. descrito em termos decomponentes, disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo.

3.3 O Ciclo de Vida de um Projeto RUP O ciclo de desenvolvimento no RUP possui quatro fases: iniciao [6] , elaborao, construoe transio. Cada uma concluda por um marco principal, ou seja, cada fase basicamente umintervalo 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 verso completa do produto de software. As fasesdefinem estados do projeto, que so definidos por riscos que esto sendo mitigados ou questesque precisam ser respondidas.

A fase de iniciao, foca no tratamento de riscos relacionados com o caso de negcio. Deve serverificado se o projeto vivel e se financeiramente possvel.

Na fase elaborao, o foco deve ser nos riscos tcnicos e arquiteturais. O escopo deve serrevisado e os requisitos devem estar mais compreendidos.

Durante a construo, a ateno ser voltada para os riscos lgicos , e a maior parte do

trabalho ser realizada.

Na fase de transio, sero tratados os riscos associados com a logstica de distribuio doproduto para a base de usurios.

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

projeto de tamanho mdio, possui uma distribuio de esforo e programao como apresentado na tabela 1 e na figura 6.
http://www.blogger.com/post-create.g?blogID=557082873013426981#_ftn6http://www.blogger.com/post-create.g?blogID=557082873013426981#_ftn6http://www.blogger.com/post-create.g?blogID=557082873013426981#_ftn6http://www.blogger.com/post-create.g?blogID=557082873013426981#_ftn6


10/12



Tabela 1. Distribuio de esforo e programao em projetos de mdio porte.

Figura 6: Distribuio de esforo e programao em projetos de mdio porte.

Conforme descrito na documentao do RUP, cada passagem pelas quatro fases gera umagerao do software. A menos que o produto "desaparea", ele ir se desenvolver na prximagerao, repetindo a mesma seqncia de fases de iniciao, elaborao, construo e transio.Esses ciclos subseqentes so chamados deciclos de evoluo. A cada ciclo, so produzidasnovas geraes.

Os ciclos de evoluo podem ser disparados por melhorias sugeridas pelos usurios, mudanasno contexto do usurio, mudanas na tecnologia subjacente, reao concorrncia e assim pordiante. Normalmente, a menos que ocorram mudanas significativas do produto ou daarquitetura, os ciclos de evoluo tm fases de Iniciao e Elaborao bem menores, pois adefinio e a arquitetura bsicas do produto foram determinadas por ciclos de desenvolvimentoanteriores.


11/12



4. Concluso

Com a utilizao de uma metodologia de desenvolvimento de software como o RUP, possvel

obter: Qualidade de software; Produtividade no desenvolvimento, operao e manuteno de software; Controle sobre desenvolvimento dentro de custos, prazos e nveis de qualidade

desejados; Estimativa de prazos e custos com maior preciso.

Apesar dos benefcios, deve-se ter a conscincia que os benefcios no viro de maneiraimediata. necessrio adquirir treinamento adequado, adaptao da metodologia no contexto aoqual ela ser utilizada, apoio especializado para as equipes de desenvolvimento e tempo para aabsoro da metodologia.

Mais informaes a respeito do RUP podem ser obtidas no site do IBM RUP e tambm no siteda comunidade IBM Rational. (IBM 2004).


12/12


12 http://qualidade de software blogspot com

Referncias

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 ModelingLanguage , Addison Wesley, 3 Edio. IBM Rational Unified Process Verso 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 , Addi son Wesley, 3 Edio.Larman, Craig (2001) Applying UML and Patterns An Introduction to Object-OrientedAnalysis and Design and the Unified Process , Prentice Hall, 2 Edio. Object Management Group (2004) http://www.omg.org, Novembro.Perrelli, Hermano (2004) Viso Geral do RUP . Centro de Informtica, Universidade Federalde Pernambuco. http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf, Novembro.[1] Aps a compra da Rational pela IBM, o produto Rational Unified Process passou a sechamar IBM Rational Unified Process (IBM RUP).

[2] UML: Abreviatura do ingls Unified Modeling Language. [Fowler 2003] uma timareferncia para esse assunto.[3] OMG: Object Management Group.[4] Consulte [Larman 2001] para informaes sobre aplicao da UML para anlise e projetoorientados a objeto[5] O termo fluxo de trabalho vem do termo ingls workflow. Pode ser traduzido tambm comofluxo de atividade.[6] Iniciao a traduo do termo ingls inception . Esse termo tambm traduzido como

concepo .

Por: Ronaldo Rezende Vilela Luiz

obtendo qualidade de software com o rup

Documents