SlideShare uma empresa Scribd logo
1 de 16
Baixar para ler offline
http://linu.com.br/papers/paper042.html 
Rational Unified Process - RUP 
Antes da leitura deste estudo, recomendo a leitura dos itens sobre Modelos de Processo 
de Software, cujo link está disponível na seção Referências. 
O Rational Unified Process (RUP) é um modelo de processo de software mantido pela IBM 
que fornece à equipe de desenvolvimento e aos gerentes de projeto uma alternativa 
genérica para se construir um sistema de software. Por genérica, entende-se uma 
alternativa adaptável à grande maioria dos casos de softwares. 
O RUP fornece boas práticas, templates, orientações e diretrizes para melhorar o 
desenvolvimento e para atender todas as atividades críticas no processo de 
desenvolvimento do software. 
Espera-se atingir um resultado satisfatório quando é utilizado um processo de software 
coerente com a situação. A figura acima ilustra uma situação onde existe um cliente 
portador de uma necessidade de desenvolvimento de software. Após um processo 
complexo de elaboração do sistema de software, um produto é alcançado, atendendo 
questões importantes como prazos, requisitos, custos e qualidade. Qual é a finalidade do 
RUP? Fornecer uma maneira eficiente para se construir um sistema de acordo com as 
necessidades do cliente. 
O RUP sugere que os projetos utilizem como ferramenta de modelagem o UML. 
Particularmente, com ou sem o RUP, as ferramentas da UML atendem a uma vasta gama 
de sistemas. Não hesite em utilizá-las. 
Um pouco mais sobre o RUP 
Basicamente, o RUP apresenta três perspectivas para detalhar o processo de software. 
São elas: 
Perspectiva dinâmica: abordagem que trata o projeto em função do tempo, 
considerando questões importantes como iteratividade – onde o projeto é direcionado 
a partir de versões menores chamadas incrementos – e divisão de fases. 
1. 
Perspectiva estática: direciona o entendimento do projeto a partir de uma série de 
disciplinas – ou workflows – associadas às fases dinâmicas, além de atividades de 
apoio – necessárias em todo o projeto. 
2. 
Perspectiva prática: onde são definidas boas práticas a serem executadas em todos 
os processos de software. 
3. 
Geralmente as perspectivas dinâmicas e estáticas são apresentadas em conjunto. 
1 de 16 26/06/13 21:01
Observe a iteração das mesmas pela figura abaixo. 
http://linu.com.br/papers/paper042.html 
As fases e ciclos (iterações), associados à perspectiva dinâmica, estão dispostos 
horizontalmente, enquanto as atividades estão representadas verticalmente – perspectiva 
estática. Observe que não existe um critério fixo para a colocação de uma atividade em 
determinada fase. De espera que, a partir do contexto apresentado na figura, as atividades 
estejam mais associadas a determinados momentos no projeto, mas nada impede de 
serem utilizadas em outro instante – outra fase. 
Segundo o texto disponibilizado em http://www.wthreex.com/rup/, de onde também foi 
retirada a figura, cada disciplina (atividade) está mais centrada em determinada fase. Veja 
o texto original: 
O gráfico Modelo de Iteração mostra como a ênfase em cada Disciplina varia 
através do tempo. Nas Iterações iniciais, dedicamos mais tempo aos Requisitos. Já 
nas Iterações posteriores, gastamos mais tempo com Implementação, por exemplo. 
Vamos agora ao entendimento aprofundado de cada perspectiva. 
Perspectiva dinâmica (divisão do tempo em fases) 
Conforme explicado, a divisão do projeto no RUP ao longo do tempo é constituída por 
fases. Cada fase precede um marco no projeto (representada pela linha tracejada na 
figura), ou seja, terminado uma fase, espera-se alcançar alguns objetivos principais – e 
conseqüentemente alcançar um importante marco. Além dos objetivos principais, uma 
série de artefatos é pré-estabelecida juntamente com alguns critérios de avaliação do 
sucesso da fase. Resumidamente, ao se utilizar o RUP, o processo de software é tratado 
em fases que, quando finalizadas, atingem marcos, que serão validados através de 
diretivas, e trarão uma série de produtos necessários para a próxima etapa. 
Conforme mostrado na figura, as quatro fases são: Iniciação, Elaboração, Construção e 
2 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Transição. 
Iniciação (Concepção) 
Também chamada de concepção, a fase de iniciação consiste em estabelecer um business 
case para o sistema. Você deve avaliar a contribuição do sistema para o negócio e a partir 
daí, determinar se o projeto deve ou não continuar. 
Nesta fase são analisadas todas as entidades externas ao sistema, tão como suas 
associações, para se elaborar os objetivos, arquitetura e planejamento do projeto. Quem 
possui essas informações? As entidades externas (mais conhecidas como stakeholders). 
Como o próprio RUP sugere, esta fase poderá ser realizada em iterações até que se 
encontre um nível respeitável de informações para estabelecimento dos objetivos gerais. 
No final da fase de iniciação (ou concepção) encontra-se o marco mais importante do 
projeto: marco dos Objetivos do Ciclo de Vida do projeto (LCO – Lifecycle Objetive). 
Onde será respondida a pergunta: é válido realizar o projeto? 
Neste marco, espera-se possuir os seguintes artefatos: 
Visão: documentação dos requisitos, restrições e elementos chave do projeto. Este é 
o documento de maior importância nesta fase. 
1. 
Riscos: identificar os ricos do projeto. Como em todo gerenciamento, saber onde se 
está pisando é essencial, como também conhecer a amplitude e gravidade dos 
riscos. 
2. 
Caso de Negócio: documento que contém as informações e suposições sobre o 
retorno do investimento para responder a seguinte pergunta: é válido realizar o 
projeto? 
3. 
Plano de desenvolvimento de software: documentação que identifica as fases iniciais 
do projeto, tão como a duração e objetivo de cada uma. Devem também ser 
especificadas estimativas do tempo, RH e custos envolvidos. Inicialmente esses 
valores podem ser considerados brutos e poderão (deverão, talvez fosse o melhor 
termo) ser reconstituídos nas próximas iterações desta fase, onde teremos maiores 
informações sobre o projeto como um todo. 
4. 
Plano de iteração: Um conjunto de atividades e tarefas divididas por seqüências de 
tempo, com recursos atribuídos e dependência de tarefas, para a iteração. 
5. 
Caso de desenvolvimento: processo no qual o projeto seguirá, ou seja, é uma 
descrição do processo de desenvolvimento para servir de guia. 
6. 
Ferramentas: tudo que será necessário para o desenvolvimento do software, 
considerando também a instalação e aquisição das mesmas. 
7. 
Glossário: termos importantes no projeto (uma espécie de índice que será utilizado 
como referência). 
8. 
Todos os elementos descritos são necessários. Existem também alguns itens opcionais, 
descritos adiante: 
3 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
1. Casos de Uso: define um template para modelagem dos casos de uso. 
2. 
Modelo de Domínio: um modelo de objetos de negócio utilizado como uma extensão 
do Glossário. Pode ser utilizado pelos interessados no negócio (stakeholders 
primários ou secundários). 
Templates dos Documentos: template para a geração dos documentos. A 
padronização favorece a continuidade e o gerenciamento do projeto. 
3. 
Protótipos: os protótipos podem ser utilizados para melhor se compreender do 
negócio a ser tratado pelo sistema, como também para compreender os clientes e 
usuários e validar os requisitos. 
4. 
Observação: a literatura sugere que alguns artefatos sejam apresentados como baseline 
(linha de base). A linha de base do RUP é uma imagem da versão de um artefato. Ou seja, 
a linha de base é composta pela definição das versões dos artefatos que compõem o 
produto em dado momento. Essa não é a mesma baseline presente na atividade 
Desenvolvimento do Cronograma no Gerenciamento de Projetos (PMI) – mais 
especificamente situada na área de conhecimento Gerenciamento de Tempo do Projeto, 
sob o processo de Planejamento. Este baseline (PMI) é um cronograma que considera a 
alocação dos recursos disponíveis, além do caminho crítico. Pelo fato dos termos serem 
iguais, a confusão pode ocorrer. O baseline do PMI é similar ao artefato Plano de Iteração 
– identificado nos itens acima. Já o baseline do RUP é associado à situação da versão dos 
artefatos em determinado momento, quando é disponibilizada uma versão para o cliente. 
Terminada a fase, resta-nos saber se ela foi proveitosa. Para isso utilizaremos os critérios 
abaixo – opcionalmente, coloquei-os em formato de perguntas (Martins, 2007), pois o 
cérebro, instintivamente, é mais estimulado quando se depara com uma pergunta do que 
com uma afirmação. 
Os stakeholders estão confiantes de que a equipe do projeto entendeu o problema a 
ser resolvido? 
1. 
2. Os stakeholders estão confiantes de que os riscos mais críticos foram identificados? 
3. As estimativas iniciais foram refinadas com base no conhecimento adquirido? 
4. As estimativas de curso e prazo são aceitáveis para os stakeholders? 
É importante ressaltar que o projeto será construído através de incrementos (ou pequenos 
itens). Tais incrementos devem ser implementados pela ordem de prioridade estabelecida 
pelos clientes/usuários. Não atendê-las ou documentá-las equivocadamente pode causar 
insatisfação dos clientes em relação ao projeto (e à equipe do projeto). 
Ao responder a essas perguntas, teremos maior confiança de que o trabalho realizado na 
fase de Iniciação é confiável ou suficiente. 
Elaboração 
Na fase de Elaboração, o objetivo é capturar todos os requisitos ainda não identificados e 
definir uma arquitetura sólida que permita a evolução do sistema nas fases seguintes 
(Martins, 2007). Como principal objetivo, pode-se definir que a meta da fase de elaboração 
é criar um baseline (do RUP) para a arquitetura do sistema fornecendo uma base estável 
4 de 16 26/06/13 21:01
para a próxima fase, no caso, a fase de Construção. 
Para se construir uma arquitetura confiável, protótipos da arquitetura podem ser 
elaborados com o objetivo de obter uma visão abrangente do sistema, em relação ao 
escopo, funcionalidades e requisitos não funcionais (chamados de atributos emergentes 
não funcionais – confiabilidade, disponibilidade, segurança e proteção). 
Um plano de projeto geral e realista para execução do restante do projeto deve ser 
construído. Deve também ser estabelecido um ambiente de suporte para o projeto. A 
avaliação do risco também é importante. Tratar todos os riscos significativos do ponto de 
vista da arquitetura do projeto. 
A fase de Elaboração termina com o marco Ciclo de Vida da Arquitetura (LCA – 
Lifecycle Architecture). Ao atingir esse marco, pode-se entender que a arquitetura está 
definida e os requisitos estão levantados e detalhados. 
Os seguintes artefatos devem constar neste marco: 
Protótipos: Protótipos da arquitetura podem ser criados a fim de explorar a 
funcionalidade crítica e os cenários significativos. Inclusive, é plausível que a 
arquitetura em si tenha sido construída com uma série de protótipos evolucionários. 
1. 
Lista de Ricos: Os novos ricos estarão associados à arquitetura e conseqüentemente 
ao gerenciamento de requisitos não funcionais. Ela é uma atualização e revisão dos 
riscos identificados na fase anterior. 
2. 
Caso de Desenvolvimento: Atualização do artefato já elaborado, aqui considerando 
questões sobre o ambiente de desenvolvimento, ferramentas e processo. 
3. 
4. Ferramentas: As ferramentas pertinentes ao trabalho de Elaboração são instaladas. 
5. 
Documento de Arquitetura de Software: Fornece uma visão geral de arquitetura 
abrangente do sistema. Deve conter uma descrição detalhada para os casos de usos 
significativos para a arquitetura, e elementos de design (elementos lógicos a serem 
definidos como linguagem de programação e banco de dados). 
Modelo de Design: Descreve a realização dos casos de uso e de forma abstrata, 
serve como guia para o modelo de implementação. Realizações de caso de uso para 
cenários significativos do ponto de vista da arquitetura foram definidos. 
6. 
Modelo de Dados: O modelo de dados é um subconjunto do modelo de 
implementação que descreve a representação lógica e física dos dados persistentes 
no sistema. Também abrange qualquer comportamento definido no banco de dados, 
como procedimentos armazenados, triggers, restrições etc. Este artefato deve ter 
sido criado e com baseline. 
7. 
Modelo de Implementação: Conjunto de componentes (que incluem produtos 
liberados – executáveis – elementos dos quais os produtos foram criados – código 
fonte). A estrutura inicial deverá ser criada, com ou sem a adoção de protótipos. 
8. 
Visão: Atualização da visão elabora com foco na compreensão sólida dos casos de 
uso mais críticos que conduzem as decisões de arquitetura e planejamento. 
9. 
http://linu.com.br/papers/paper042.html 
5 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Plano de Desenvolvimento de Software: Atualizar o plano existente com objetivo de 
abranger as próximas fases. 
10. 
Modelo de Casos de Uso: um modelo de casos de uso praticamente concluído. 
Estima-se que neste ponto o modelo esteja 3/4 do modelo conclusivo. 
11. 
Especificações Suplementares: Os requisitos suplementares abrangendo os 
requisitos não funcionais são documentados e analisados. Conforme a literatura de 
Engenharia de Software, requisitos não funcionais (ou atributos não funcionais) 
dizem respeito a características pertinentes à confiança do software quando 
integrado (após a fase de integração de subsistemas). Pode-se definir a confiança de 
software com base em: disponibilidade (capacidade do sistema de estar disponível 
quando requisitado), confiabilidade (capacidade do sistema de operar de acordo com 
os requisitos), segurança (capacidade do sistema de operar sem falhas catastróficas) 
e proteção (capacidade do sistema de proteger-se de intrusões acidentais ou 
intencionais). Mais informações em Sommerville, 2007. Outras abordagens coerentes 
para requisitos não funcionais podem ser vistas nas Referências. 
12. 
Conjunto de Testes: Testes implementados e executados para validar a estabilidade 
do build para cada release executável criada nesta fase. 
13. 
Arquitetura para Automatização de Testes: É uma composição de diversos elementos 
de automatização de testes e suas especificações que representam as 
características fundamentais do sistema de software de automatização de testes 
(Wthreex, em Referências). 
14. 
Além dos artefatos descritos anteriormente, existe aqueles opcionais: 
Caso de Negócio: Atualizado para os casos onde existam elementos descobertos 
que influenciem o caso de negócio estabelecido. 
1. 
Modelo de Análise: Pode ser desenvolvido como um artefato formal, que através da 
evolução, poderá servir como a versão inicial do Modelo de Design. 
2. 
Materiais de Treinamento: Manuais do Usuário e outros materiais 3. de treinamento. 
4. Templates Específicos do Projeto: Padrão para a criação dos documentos do projeto. 
Ao atingir o marco LCA, podemos avaliar sua consistência e confiabilidade através das 
seguintes perguntas: 
Os stakeholders têm confiança de que a equipe do projeto tem capacidade de 
implementar a solução proposta? 
1. 
2. A arquitetura reflete os requisitos funcionais (funções que o sistema deve fornecer)? 
3. Todos os riscos críticos foram eliminados ou mitigados? 
4. As variações de custo e prazo são aceitáveis para os stakeholders? 
5. A fase de Construção foi planejada de forma consistente e detalhada? 
Conforme definido, a fase de Elaboração pode ser entendida como um processo de 
engenharia, onde o foco é especificar uma arquitetura robusta e confiável. Através dos 
6 de 16 26/06/13 21:01
critérios de avaliação (perguntas) acima, podemos esperar que um resultado satisfatório foi 
alcançado. 
Construção 
Na fase de construção, o sistema e a documentação destinada ao usuário são criados, 
junto com a versão beta do sistema (Martins, 2007). Nesta fase também serão 
esclarecidos os requisitos restantes. Toda a construção do sistema terá com base a 
arquitetura da baseline. 
O controle de recursos, custos e qualidade fazem parte deste processo. As fases da 
concepção e elaboração foram auxiliadas por gerenciamento da propriedade intelectual. 
Na fase de Construção, o foco estará no desenvolvimento dos produtos que serão 
construídos. 
Espera-se atingir versões úteis com eficiência. As atividades devem ser coordenadas de 
forma que o paralelismo esteja presente. Mesmo em projetos pequenos, é possível 
coordenar as equipes para que os componentes independentes sejam elaborados em 
paralelo. 
Ao concluir esta fase, chegaremos ao marco Capacidade Operacional Inicial (IOC – 
Initial Operational Capability). Espera-se neste momento que o produto esteja pronto 
para ser passo a equipe de Transição e que os testes alfa estejam concluídos (teste alfa 
consiste em testes de aceitação informal, onde os procedimentos de execução do teste 
não são definidos). 
Os seguintes artefatos são esperados: 
O Sistema: o sistema executável pronto para começar o teste beta (teste não 
formalizado geralmente realizado pela comunidade de usuários). 
1. 
Plano de Implantação: plano que coordena e lista as atividades envolvidas na 
transferência do sistema da comunidade de desenvolvimento para a comunidade de 
usuários. Deve-se criar um plano inicial com baseline. 
2. 
Conjunto de Testes: Testes implementados e executados de cada release construído 
durante esta fase. 
3. 
4. Materiais de Treinamento: Manuais do usuário e outros materiais de treinamento. 
5. 
Plano de Iteração: Plano de iteração para a próxima fase (Transição), concluído e 
analisado. 
Modelo de Design: Atualizado com novos elementos de design identificados durante 
a conclusão de todos os requisitos. 
6. 
Caso de Desenvolvimento: Trata-se do refinamento do ambiente de desenvolvimento 
– processo e ferramentas – com objetivo de auxiliar a equipe da próxima fase. 
7. 
8. Ferramentas: Ferramentas da fase de Construção. 
9. 
Modelo de Dados: Atualizado com a experiência adquirida no processo de 
Construção. 
http://linu.com.br/papers/paper042.html 
7 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Além dos artefatos obrigatórios descritos anteriormente, a fase de Construção também 
possui alguns artefatos opcionais, que são: 
Templates Específicos do Projeto: Os templates de documentos usados para 
desenvolver os artefatos de documentos. 
1. 
Especificações Suplementares: Atualizar as especificações já existentes caso sejam 
descobertos novos requisitos não funcionais. 
2. 
Modelo de Casos de Uso: Atualizado com os possíveis novos casos de usos 
descobertos durante essa fase. 
3. 
A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação 
descritos abaixo. O formato em perguntas persiste: 
O produto está completo o suficiente e com a qualidade mínima aceitável para iniciar 
o teste de aceitação? 
1. 
O usuário e a organização estão preparados para o início da implementação 
(transição do sistema)? 
2. 
As variações de custo e prazo são aceitáveis 3. para os stakeholders? 
O processo de Construção pode ser compreendido como um processo de manufatura. 
Obviamente o gerenciamento será adaptado para tal situação, levando em questões 
elementos como prazos, custos e recursos. Esta fase, assim como todas as outras do 
RUP, deve abordar a iteratividade, apresentando incrementos (releases do sistema) ao 
final de cada repetição. É estimado um esforço de programação por volta de 1/2 em 
relação ao projeto como um todo. Geralmente esta fase consome mais recursos e tempo, 
mas seu sucesso estará associado às questões bem (ou mal) resolvidas nas etapas 
anteriores. Certamente, o impacto dos riscos não descobertos (ou não avaliados) serão 
maiores nesta etapa. 
Ao terminar essa fase, o sistema poderá ser transferido para os usuários. 
Transição 
Em síntese, o foco da fase de Transição é assegurar que o software esteja disponível para 
seus usuários finais. Ele deverá ser distribuído, ou seja, instalado para os clientes e 
usuários finais. É comum a continuidade do desenvolvimento do software demandado por 
feedback dos usuários. Deverão ser fornecidos, a cada ciclo da Transição, novos releases 
do produto. Existe também a possibilidade de que o fim do ciclo de vida do produto do 
projeto coincida com o início de outro ciclo de vida para o mesmo produto – como uma 
nova versão do software, por exemplo. 
A complexidade inerente nesta fase varia de acordo com o produto e cliente. Um software 
comercial para uma nova microempresa pode gerar poucos problemas nesta etapa, ao 
passo que a substituição de sistemas previdenciários de um país pode levar anos para ser 
concluída. 
É interessante que nesta fase, sejam definidas metas de acordo com o andamento do 
processo. Por exemplo, a alteração de uma falha de sistema pode envolver retrabalho na 
programação e teste. Ao passo que a correção de um requisito possa levar a um processo 
8 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
similar ao de Construção. 
Ao final desta fase, encontra-se o marco Release do Produto (PR – Product Release). O 
principal aspecto centra-se na avaliação dos objetivos, se foram ou não atendidos, e na 
decisão de iniciar um novo processo de Construção com base nesses objetivos. 
Os artefatos envolvidos neste marco são: 
O Build do Produto: deve ser fornecido um sistema concluído de acordo com os 
requisitos do produto, onde o consumidor final utiliza o sistema. 
1. 
Notas de Release: As Notas de Release identificam mudanças e erros conhecidos 
em uma versão de um build ou em uma unidade de implantação que tenha sido 
disponibilizada para uso (texto retirado da Referência). As notas devem estar 
concluídas. 
2. 
Artefatos de Instalação: elementos de instalação do software, como também a 
documentação associada. 
3. 
Material de Treinamento: O material deve estar concluído. A partir dele o cliente 
poderá utilizar o sistema. 
4. 
Material de Suporte para o Usuário Final: Material que colabora com a 
aprendizagem, manutenção e utilização do sistema. 
5. 
Existem também os artefatos opcionais: 
Conjunto de Testes: O conjunto de teste associado em cada build poderá ser 
fornecido ao cliente. 
1. 
Empacotamento Compacto do Produto: Elementos fornecidos ao cliente com intuito 
de auxiliar o processo de compactação do produto. 
2. 
Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da 
fase de Transição. 
Os objetivos do projeto foram atingidos de acordo com os 1. critérios de medição? 
2. As variações de custo e prazo são aceitáveis pelos stakeholders? 
3. Os usuários estão satisfeitos? 
Ao final da fase de transição, espera-se que um ciclo do projeto, ou o projeto em si, tenha 
chegado ao fim. Geralmente, conforme mostrado na figura abaixo – retirada das 
Referências, o comportamento típico para um processo de software evolui e consome 
recursos de forma distinta para cada fase. 
9 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Como se pode ver, o tempo e recurso da Iniciação (Concepção) são significativamente 
menores do que o da Elaboração e Construção. A Transição está diretamente associada 
às características do projeto, porém espera-se que consuma menos tempo que a 
Construção. 
Podemos observar o seguinte: projetos mal estruturados e pouco documentados, onde a 
análise e o gerenciamento foram negligenciados por pressões dos clientes/gerentes do 
projeto tornam o processo de Transição extremamente doloroso, onde muitas alterações e 
inclusões de requisitos devem ser realizadas. Na fase de Transição, a correção de falhas 
de sistema ou adaptação de requisitos devido a mudanças no escopo do produto é 
aceitável, porém a inclusão de requisitos que não foram capturados ou não documentados 
pela falta de coordenação e confiança nas fases de Iniciação e Elaboração é altamente 
prejudicial ao projeto. Isso é muito comum no desenvolvimento de software atual, mesmo 
existindo ferramentas e modelos de processo altamente suficientes para contornar tais 
problemas. Em casos como esses, ciclos completos (com as quatro fases) no projeto 
talvez sejam necessários. 
Vale relembrar que os ciclos são previstos no RUP. Cada fase do projeto poderá ser 
repetida várias vezes. Inclusive as quatro fases podem ser repetidas, fornecendo 
incrementos (ou versões) em cada ciclo. O processo de desenvolvimento em fases é 
comum nos projetos atuais, seja na forma de desenvolvimento iterativo ou por incremento. 
No primeiro caso, o desenvolvimento iterativo fornece inicialmente um esqueleto do 
sistema, que será aperfeiçoado em cada fase. O esqueleto, porém, não traz confiabilidade 
nos requisitos de forma satisfatória. Isso será conquistado ao longo do processo. A figura 
abaixo ilustra este tipo de desenvolvimento. 
Neste gráfico, os itens em branco foram apresentados de forma genérica, ainda sem 
contemplar as reais necessidades do negócio. Os itens em amarelo já foram ajustados aos 
requisitos. Observe que na Fase 1, apenas o módulo 2 é apresentado com coerência nos 
10 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
requisitos, enquanto os módulos 1 e 3 ainda são soluções paliativas para o problema 
- mas já podem ser utilizadas. Este contexto é comum para sistemas ERP, onde um grande 
sistema coorporativo (e pode-se dizer, genérico) existe e aos poucos é adaptado a 
realidade das empresas. Um exemplo típico é o sistema SAP/R3. 
No desenvolvimento por incrementos, cada módulo é entregue em separado, sem um 
esboço geral do sistema, porém atendendo a real necessidade dos requisitos analisados. 
Neste caso, o projeto desenvolverá o módulo 2 na primeira fase – isso porque a empresa 
cliente justificou que este incremento é o de maior prioridade para o negócio. Ao longo dos 
próximos ciclos, os outros módulos, também em ordem de prioridade, serão apresentados. 
A vantagem deste paradigma centra-se na qualidade alcança nos incrementos de maior 
importância. Como o cliente estipulou que o módulo 2 é de maior prioridade, este foi 
desenvolvido na íntegra, primeiro e, conseqüentemente, sofrerá maior carga de testes e 
validações dos requisitos se comparado com o módulo 1, que foi o último a ser entregue. 
As figuras apresentadas acima, que define o desenvolvimento iterativo e incremental, 
foram criadas por Flávio Mello, professor da UFRJ. Em uma aula que pude presenciar sua 
explicação ele abordou tais temas por meio dessas figuras. Achei interessante abordá-las 
aqui também. 
Veremos agora a perspectiva estática do RUP. 
Perspectiva Estática 
A visão estática do RUP enfoca as atividades que ocorrem durante o processo de 
desenvolvimento. Elas são chamadas de workflows na descrição do RUP. Existem seis 
workflows de processo principais identificados e três workflows de apoio principais 
(Sommerville, 2007). Um workflow também é chamado de disciplina. Utilizaremos as duas 
formas para identificá-los, como prática comum em tais abordagens. 
Ao longo do projeto você precisa construir artefatos (um nome elegante para documento, 
com alguma particularidade, do sistema). No RUP você constrói os artefatos por meio das 
atividades. Uma disciplina (workflow) mostra todas as atividades que você deve realizar 
para construir alguns artefatos. 
As disciplinas não são temporais ou fixas nas fases. Isso significa que eu posso utilizar a 
disciplina de Requisitos na fase de Construção, mesmo que esta esteja naturalmente mais 
associada à fase de Concepção. Isso é válido para todas as disciplinas. Para enfatizar 
esse entendimento, por conveniência, repeti aqui o gráfico da disposição das disciplinas ao 
longo das fases do projeto. 
11 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Observe que elas são demandadas com maior ênfase em determinado momento, porém 
nada impede que sua utilização seja realizada em outras fases. As três disciplinas de 
apoio Gerenciamento de Configuração e Mudança, Gerencimanto de Projeto e Ambiente 
são mais distrubuídas por todas as fases, sem apresentar nenhum pico significativo. Isso é 
comum à tais disciplinas, pois como a própria descrição sugere, elas servem de apoio para 
todas as outras disciplinas e para o projeto como um todo. 
Veremos agora uma abordagem sobre cada uma das disciplinas. Em primeiro plano, 
veremos os seis workflows principais. 
Modelagem de Negócios 
Os processos de negócios são modelados utilizando casos de uso de negócios 
(Sommerville, 2007). Em sintese, a modelagem de negócios se preocupa na descrição do 
negócio, identificação dos processos e no desenvolvimento do modelo de domínio, 
realizando refinamentos, projeções dos processos e levantamento dos papéis envolvidos. 
Essa disciplina é mais comum nas fases de Iniciação e Elaboração, porém é comum ser 
repetida nos projetos em que os requisitos sofrem alterações constantemente. 
Requisitos 
Trata principalmente da definição formal dos requisitos. Para novos sistemas, o problema é 
analisado com o objetivo de identificar os indivíduos, as fronteiras e restrições. Em casos 
onde já exista um sistema, os envolvidos são identificados com objetivo de conhecer 
melhor suas necessidades. Com base nos dados levantados, o sistema é definido, o 
escopo é elaborado e os requisitos mutáveis são gerenciados. Possui maior participação 
na fase de Iniciação e é normalmente utilizada durante toda a fase de Elaboração. 
Análise e Design (ou Análise e Projeto) 
Um modelo de projeto é criado e documentado usando modelos de arquitutura, modelos 
de componente, modelos de objeto e modelos de seqüência (Sommerville, 2007). Em 
12 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
primeiro momento uma sugestão de arquitetura é definida. Posterioremente, em paralelo 
com o refinamento da arquitetura, os comportamentos são analisados com o objetivo de 
projetar os componentes e o banco de dados do sistema. Está concentrada na fase de 
Elaboração e geralmente é refinada e ajustada na fase de Construção. 
Implementação 
Apesar de sua maior concetração na fase de Construção, a implementação está presente 
em todos os momentos. Na fase de Concepção os protótipos poderão facilitar o 
entendimento dos requisitos. Na fase de Elaboração, esboços da arquitutura poderão 
evoluir até que um nível satisfatório seja alcançado e que um protóripo para a arquitetura 
seja construído. Na fase de Transição, correções de falhas no sistema e ajustes são 
freqüentes. Na fase de Construção, em geral é definido um modelo de implementação e 
integração. Os subsistemas são construídos em forma de incrementos e integrados nos 
ciclos. A cada nova integração, os componentes individuais são testados, e existe um 
refinamento dos artefatos construídos, se necessário. A geração automatica, comum em 
ferramentas CASE, também pode ser utilizada neste momento. 
Teste 
Segundo Sommerville, o teste é um processo iterativo realizado em conjunto com a 
implementação. O teste do sistema segue o término da implementação. Os testes devem 
ser formalizados com o objetivo de identificar o foco adequado do esforço de teste para a 
iteração e estabelecer consenso com os envolvidos sobre as metas correspondentes que 
conduzirão o esforço de teste (Wthreex). Possui maior ênfase no final da fase de 
Construção. 
Implantação 
Nesta disciplina uma versão do produto é distribuída. Como previsto, sua maior utilização 
está centrada no marco PR (entre a fase de Construção e Transição). O teste de aceitação 
também precisa ser considerado. Artefatos como material de suporte precisão ser 
disponibilizados. 
Veremos agora os três workflows de apoio. 
Gerenciamento de Configuração e Mudanças 
Gerencia as mudanças do sistema. Tarefas como Gerenciar Solicitações de Mudanças, 
Gerenciar Baselines e Releases e Planejamento de Controle do Projeto e Configuração de 
Mudanças são pertinentes e devem ser utilizadas. Apesar de suportar todo o projeto, 
possui mais demanda nas fases de Construção e Transição. 
Gerenciamento de Projetos 
Possui a característica de gerenciar o desenvolvimento do sistema. É uma disciplina ampla 
e deve ser considerada com atenção. A gerência de projetos é comum em diversos 
ambientes e possui referências importantes de mercado como o PMI. Recomendo leituras 
associadas ao Gerenciamento de Projetos para sua aplicação e utilização especializada 
neste workflow. O próprio RUP, um modelo genérico de processo de software, espera que 
exista uma abordagem empresarial do gerenciamento do projeto em sua estrutura. Deve 
ser utilizado em todas as fases. 
13 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
Ambiente 
Este workflow está relacionado à disponibilização de ferramentas de software apropriadas 
para a equipe de desenvolvimento (Sommerville, 2007). 
Cada projeto possui sua particularidade. Em determinados casos, existirão maiores 
demandas de certos workflows para as fases iniciais, em quanto em outros, a maior 
atenção ocorrerá nas fases finais. Os dados mostrados neste documento e sugeridos na 
literatura sobre o assunto mostram aplicações corriqueiras para associar as disciplinas às 
fases. Mas o fato de serem tratadas como perspectivas dinâmicas e estáticas propõem 
justamente que não existam restrições nas suas combinações durante o projeto. 
Perspectiva Prática 
A adoção de boas práticas no desenvolvimento de software favorece o andamento do 
projeto e contribuí para o sucesso e aceitação do produto final. A perspectiva prática 
mostra justamente algumas práticas recomendadas no processo de software. São elas: 
Desenvolvimento Iterativo: característica já abordada neste estudo que indica que o 
software deve ser desenvolvido em incrementos, entregues em ordem de prioridade 
definida pelo cliente. 
1. 
Gerenciar Requisitos: Documentação formal dos requisitos e acompanhamento das 
mudanças. Sempre que houver solicitações de mudanças, avaliar o impacto no 
projeto antes da aceitação formal. 
2. 
Arquiteturas Baseadas em Componentes: o uso de arquiteturas baseadas em 
componentes, externos ou produzidos no projeto, facilita a produção do sistema. 
Deve ser considerada tal característica. 
3. 
Modelagem Visual: Utilizar modelos da UML para representar o software de forma 
estática e dinâmica. Conforme indicado, o RUP sugere a utilização da UML em seus 
projetos. Este item reforça isso. 
4. 
Verificar a Qualidade do Software: A qualidade do software deve ser monitorada e 
conduzida de forma a atender os padrões de aceitação do cliente. Isso influenciará o 
sucesso do projeto. 
5. 
Controlar as mudanças do software: As mudanças deverão ser gerenciadas durante 
todo o processo. Isso contribuirá para um projeto melhor estruturado, documentado e 
para sua continuidade e aceitação. 
6. 
Conclusões 
Neste documento, mostrei uma simplória abordagem sobre o modelo de processo de 
software RUP e sua importância num projeto. Minha intenção principal é apresentar o 
paradigma de desenvolvimento de forma conceitual. O RUP completo apresenta 
templates, entendimento dos papeis e suas importâncias, ferramentas, entre outros. 
Abordagens mais coerentes e completas deverão ser consultadas para fins de utilização 
específica. Recomendo que seja acessado o site Wthreex, cujo link encontra-se nas 
Referências, pois tal material é apresentado de forma completa e bem estruturada. A partir 
dos elementos deste site você poderá realizar seu processo de software utilizando todos 
14 de 16 26/06/13 21:01
http://linu.com.br/papers/paper042.html 
os elementos presentes no RUP e, possivelmente, alcançar o sucesso do projeto. 
Termino esse texto com uma reflexão simples, mas que serve de exemplo para aqueles 
que ainda resistem à utilização de processos que possam auxiliar o desenvolvimento do 
software. 
Compare o desenvolvimento de software com o preparo de macarrão. Podemos preparar o 
macarrão de duas formas: a forma recomendada diz que devemos ferver a água, colocar o 
macarrão para cozinhar, verificar ao longo do processo se o mesmo já está pronto e por 
fim, colocar o molho. Existe também a forma fácil, onde se coloca a água, o macarrão e o 
molho tudo ao mesmo tempo e vai assistir televisão até que ele fique pronto. O primeiro 
método trará um excelente macarrão, mas muitas pessoas não gostam de utilizá-lo, pois 
acham uma perda de tempo (este é o meu caso, por exemplo). O segundo método tem 
como resultado uma gororoba braba, porém é mais fácil de atingi um resultado (ruim, 
porém mais rapidamente). Minha pergunta é: se seu trabalho fosse o de produzir macarrão 
para clientes e seu dinheiro dependesse da satisfação dos mesmos, qual dos dois 
métodos você utilizaria? 
Então porque você insiste em produzir softwares negligenciando os processos de 
requisitos, documentação, análise e gerenciamento de projeto, se o resultado será, em 
geral, uma porcaria! 
Referências 
http://en.wikipedia.org/wiki/Work_breakdown_structure 
http://www.wthreex.com/rup/ 
http://pt.wikipedia.org/wiki/Rational_Unified_Process 
http://pt.wikipedia.org/wiki/Stakeholder 
http://www.algosobre.com.br/portugues/usos-do-porque.html (afinal, errar é humano, mas 
corrigir o erro no Google também) 
http://www.macoratti.net/proc_sw1.htm 
http://pt.wikipedia.org/wiki/Engenharia_de_software 
http://wthreex.com/rup/process/workflow/requirem/co_req.htm 
http://www.wthreex.com/rup/process/workflow/test/co_accte.htm 
Ian Sommerville, 2007. Engenharia de Software, 8ª edição. Pearson Addison-Wesley. 
José Carlos Cordeiro Martins, 2007. Técnicas para Gerenciamento de Projetos de 
Software. Brasport. 
“São as nossas escolhas que revelam o que realmente somos, muito mais do que as 
nossas qualidades.” Alvo Dumbledore 
15 de 16 26/06/13 21:01
Espero ter colaborado com algo! 
Guilherme Pontes 
http://linu.com.br/papers/paper042.html 
16 de 16 26/06/13 21:01

Mais conteúdo relacionado

Mais procurados

Lógica de programação pascal
Lógica de programação   pascalLógica de programação   pascal
Lógica de programação pascal
Jocelma Rios
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
paulo peres
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
Gurban Daniel
 

Mais procurados (20)

Lógica de programação pascal
Lógica de programação   pascalLógica de programação   pascal
Lógica de programação pascal
 
Modelos de Processo de Software Parte 2
Modelos de Processo de Software Parte 2Modelos de Processo de Software Parte 2
Modelos de Processo de Software Parte 2
 
UML
UMLUML
UML
 
Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
 
Estimativa de software usando pontos de função
Estimativa de software usando pontos de funçãoEstimativa de software usando pontos de função
Estimativa de software usando pontos de função
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 
Banco de questões qualidade de software
Banco de questões qualidade de softwareBanco de questões qualidade de software
Banco de questões qualidade de software
 
Programação Concorrente - Introdução
Programação Concorrente - IntroduçãoProgramação Concorrente - Introdução
Programação Concorrente - Introdução
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Sdlc models
Sdlc modelsSdlc models
Sdlc models
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
V model
V modelV model
V model
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Aula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptxAula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptx
 
Verificação e validação de software
Verificação e validação de softwareVerificação e validação de software
Verificação e validação de software
 
Pseudoparalelismo
PseudoparalelismoPseudoparalelismo
Pseudoparalelismo
 
What is waterfall
What is waterfallWhat is waterfall
What is waterfall
 

Semelhante a Rational Unified Process - RUP

Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
Priscila Stuani
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
Frank Coelho
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
wilsonguns
 

Semelhante a Rational Unified Process - RUP (20)

Artigo asap - metodologia de gestão de projetos para implementação de pacot...
Artigo   asap - metodologia de gestão de projetos para implementação de pacot...Artigo   asap - metodologia de gestão de projetos para implementação de pacot...
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
 
Jucelir
JucelirJucelir
Jucelir
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Aula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosAula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetos
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
 

Mais de Fernando Nogueira

Mais de Fernando Nogueira (8)

4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computação4ª edicao redinfo, a sua revista eletrônica de computação
4ª edicao redinfo, a sua revista eletrônica de computação
 
3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computação3ª edicao redinfo, a sua revista eletrônica de computação
3ª edicao redinfo, a sua revista eletrônica de computação
 
2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computação2ª edicao redinfo, a sua revista eletrônica de computação
2ª edicao redinfo, a sua revista eletrônica de computação
 
1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computação1ª edição redinfo, a sua revista eletrônica de computação
1ª edição redinfo, a sua revista eletrônica de computação
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
 
Realidade virtual na saúde
Realidade virtual na saúdeRealidade virtual na saúde
Realidade virtual na saúde
 
Memórias Modernas
Memórias ModernasMemórias Modernas
Memórias Modernas
 
Memórias Modernas
Memórias ModernasMemórias Modernas
Memórias Modernas
 

Último

Último (9)

ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdfAula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
Convergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor SucroenergéticoConvergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor Sucroenergético
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 

Rational Unified Process - RUP

  • 1. http://linu.com.br/papers/paper042.html Rational Unified Process - RUP Antes da leitura deste estudo, recomendo a leitura dos itens sobre Modelos de Processo de Software, cujo link está disponível na seção Referências. O Rational Unified Process (RUP) é um modelo de processo de software mantido pela IBM que fornece à equipe de desenvolvimento e aos gerentes de projeto uma alternativa genérica para se construir um sistema de software. Por genérica, entende-se uma alternativa adaptável à grande maioria dos casos de softwares. O RUP fornece boas práticas, templates, orientações e diretrizes para melhorar o desenvolvimento e para atender todas as atividades críticas no processo de desenvolvimento do software. Espera-se atingir um resultado satisfatório quando é utilizado um processo de software coerente com a situação. A figura acima ilustra uma situação onde existe um cliente portador de uma necessidade de desenvolvimento de software. Após um processo complexo de elaboração do sistema de software, um produto é alcançado, atendendo questões importantes como prazos, requisitos, custos e qualidade. Qual é a finalidade do RUP? Fornecer uma maneira eficiente para se construir um sistema de acordo com as necessidades do cliente. O RUP sugere que os projetos utilizem como ferramenta de modelagem o UML. Particularmente, com ou sem o RUP, as ferramentas da UML atendem a uma vasta gama de sistemas. Não hesite em utilizá-las. Um pouco mais sobre o RUP Basicamente, o RUP apresenta três perspectivas para detalhar o processo de software. São elas: Perspectiva dinâmica: abordagem que trata o projeto em função do tempo, considerando questões importantes como iteratividade – onde o projeto é direcionado a partir de versões menores chamadas incrementos – e divisão de fases. 1. Perspectiva estática: direciona o entendimento do projeto a partir de uma série de disciplinas – ou workflows – associadas às fases dinâmicas, além de atividades de apoio – necessárias em todo o projeto. 2. Perspectiva prática: onde são definidas boas práticas a serem executadas em todos os processos de software. 3. Geralmente as perspectivas dinâmicas e estáticas são apresentadas em conjunto. 1 de 16 26/06/13 21:01
  • 2. Observe a iteração das mesmas pela figura abaixo. http://linu.com.br/papers/paper042.html As fases e ciclos (iterações), associados à perspectiva dinâmica, estão dispostos horizontalmente, enquanto as atividades estão representadas verticalmente – perspectiva estática. Observe que não existe um critério fixo para a colocação de uma atividade em determinada fase. De espera que, a partir do contexto apresentado na figura, as atividades estejam mais associadas a determinados momentos no projeto, mas nada impede de serem utilizadas em outro instante – outra fase. Segundo o texto disponibilizado em http://www.wthreex.com/rup/, de onde também foi retirada a figura, cada disciplina (atividade) está mais centrada em determinada fase. Veja o texto original: O gráfico Modelo de Iteração mostra como a ênfase em cada Disciplina varia através do tempo. Nas Iterações iniciais, dedicamos mais tempo aos Requisitos. Já nas Iterações posteriores, gastamos mais tempo com Implementação, por exemplo. Vamos agora ao entendimento aprofundado de cada perspectiva. Perspectiva dinâmica (divisão do tempo em fases) Conforme explicado, a divisão do projeto no RUP ao longo do tempo é constituída por fases. Cada fase precede um marco no projeto (representada pela linha tracejada na figura), ou seja, terminado uma fase, espera-se alcançar alguns objetivos principais – e conseqüentemente alcançar um importante marco. Além dos objetivos principais, uma série de artefatos é pré-estabelecida juntamente com alguns critérios de avaliação do sucesso da fase. Resumidamente, ao se utilizar o RUP, o processo de software é tratado em fases que, quando finalizadas, atingem marcos, que serão validados através de diretivas, e trarão uma série de produtos necessários para a próxima etapa. Conforme mostrado na figura, as quatro fases são: Iniciação, Elaboração, Construção e 2 de 16 26/06/13 21:01
  • 3. http://linu.com.br/papers/paper042.html Transição. Iniciação (Concepção) Também chamada de concepção, a fase de iniciação consiste em estabelecer um business case para o sistema. Você deve avaliar a contribuição do sistema para o negócio e a partir daí, determinar se o projeto deve ou não continuar. Nesta fase são analisadas todas as entidades externas ao sistema, tão como suas associações, para se elaborar os objetivos, arquitetura e planejamento do projeto. Quem possui essas informações? As entidades externas (mais conhecidas como stakeholders). Como o próprio RUP sugere, esta fase poderá ser realizada em iterações até que se encontre um nível respeitável de informações para estabelecimento dos objetivos gerais. No final da fase de iniciação (ou concepção) encontra-se o marco mais importante do projeto: marco dos Objetivos do Ciclo de Vida do projeto (LCO – Lifecycle Objetive). Onde será respondida a pergunta: é válido realizar o projeto? Neste marco, espera-se possuir os seguintes artefatos: Visão: documentação dos requisitos, restrições e elementos chave do projeto. Este é o documento de maior importância nesta fase. 1. Riscos: identificar os ricos do projeto. Como em todo gerenciamento, saber onde se está pisando é essencial, como também conhecer a amplitude e gravidade dos riscos. 2. Caso de Negócio: documento que contém as informações e suposições sobre o retorno do investimento para responder a seguinte pergunta: é válido realizar o projeto? 3. Plano de desenvolvimento de software: documentação que identifica as fases iniciais do projeto, tão como a duração e objetivo de cada uma. Devem também ser especificadas estimativas do tempo, RH e custos envolvidos. Inicialmente esses valores podem ser considerados brutos e poderão (deverão, talvez fosse o melhor termo) ser reconstituídos nas próximas iterações desta fase, onde teremos maiores informações sobre o projeto como um todo. 4. Plano de iteração: Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependência de tarefas, para a iteração. 5. Caso de desenvolvimento: processo no qual o projeto seguirá, ou seja, é uma descrição do processo de desenvolvimento para servir de guia. 6. Ferramentas: tudo que será necessário para o desenvolvimento do software, considerando também a instalação e aquisição das mesmas. 7. Glossário: termos importantes no projeto (uma espécie de índice que será utilizado como referência). 8. Todos os elementos descritos são necessários. Existem também alguns itens opcionais, descritos adiante: 3 de 16 26/06/13 21:01
  • 4. http://linu.com.br/papers/paper042.html 1. Casos de Uso: define um template para modelagem dos casos de uso. 2. Modelo de Domínio: um modelo de objetos de negócio utilizado como uma extensão do Glossário. Pode ser utilizado pelos interessados no negócio (stakeholders primários ou secundários). Templates dos Documentos: template para a geração dos documentos. A padronização favorece a continuidade e o gerenciamento do projeto. 3. Protótipos: os protótipos podem ser utilizados para melhor se compreender do negócio a ser tratado pelo sistema, como também para compreender os clientes e usuários e validar os requisitos. 4. Observação: a literatura sugere que alguns artefatos sejam apresentados como baseline (linha de base). A linha de base do RUP é uma imagem da versão de um artefato. Ou seja, a linha de base é composta pela definição das versões dos artefatos que compõem o produto em dado momento. Essa não é a mesma baseline presente na atividade Desenvolvimento do Cronograma no Gerenciamento de Projetos (PMI) – mais especificamente situada na área de conhecimento Gerenciamento de Tempo do Projeto, sob o processo de Planejamento. Este baseline (PMI) é um cronograma que considera a alocação dos recursos disponíveis, além do caminho crítico. Pelo fato dos termos serem iguais, a confusão pode ocorrer. O baseline do PMI é similar ao artefato Plano de Iteração – identificado nos itens acima. Já o baseline do RUP é associado à situação da versão dos artefatos em determinado momento, quando é disponibilizada uma versão para o cliente. Terminada a fase, resta-nos saber se ela foi proveitosa. Para isso utilizaremos os critérios abaixo – opcionalmente, coloquei-os em formato de perguntas (Martins, 2007), pois o cérebro, instintivamente, é mais estimulado quando se depara com uma pergunta do que com uma afirmação. Os stakeholders estão confiantes de que a equipe do projeto entendeu o problema a ser resolvido? 1. 2. Os stakeholders estão confiantes de que os riscos mais críticos foram identificados? 3. As estimativas iniciais foram refinadas com base no conhecimento adquirido? 4. As estimativas de curso e prazo são aceitáveis para os stakeholders? É importante ressaltar que o projeto será construído através de incrementos (ou pequenos itens). Tais incrementos devem ser implementados pela ordem de prioridade estabelecida pelos clientes/usuários. Não atendê-las ou documentá-las equivocadamente pode causar insatisfação dos clientes em relação ao projeto (e à equipe do projeto). Ao responder a essas perguntas, teremos maior confiança de que o trabalho realizado na fase de Iniciação é confiável ou suficiente. Elaboração Na fase de Elaboração, o objetivo é capturar todos os requisitos ainda não identificados e definir uma arquitetura sólida que permita a evolução do sistema nas fases seguintes (Martins, 2007). Como principal objetivo, pode-se definir que a meta da fase de elaboração é criar um baseline (do RUP) para a arquitetura do sistema fornecendo uma base estável 4 de 16 26/06/13 21:01
  • 5. para a próxima fase, no caso, a fase de Construção. Para se construir uma arquitetura confiável, protótipos da arquitetura podem ser elaborados com o objetivo de obter uma visão abrangente do sistema, em relação ao escopo, funcionalidades e requisitos não funcionais (chamados de atributos emergentes não funcionais – confiabilidade, disponibilidade, segurança e proteção). Um plano de projeto geral e realista para execução do restante do projeto deve ser construído. Deve também ser estabelecido um ambiente de suporte para o projeto. A avaliação do risco também é importante. Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto. A fase de Elaboração termina com o marco Ciclo de Vida da Arquitetura (LCA – Lifecycle Architecture). Ao atingir esse marco, pode-se entender que a arquitetura está definida e os requisitos estão levantados e detalhados. Os seguintes artefatos devem constar neste marco: Protótipos: Protótipos da arquitetura podem ser criados a fim de explorar a funcionalidade crítica e os cenários significativos. Inclusive, é plausível que a arquitetura em si tenha sido construída com uma série de protótipos evolucionários. 1. Lista de Ricos: Os novos ricos estarão associados à arquitetura e conseqüentemente ao gerenciamento de requisitos não funcionais. Ela é uma atualização e revisão dos riscos identificados na fase anterior. 2. Caso de Desenvolvimento: Atualização do artefato já elaborado, aqui considerando questões sobre o ambiente de desenvolvimento, ferramentas e processo. 3. 4. Ferramentas: As ferramentas pertinentes ao trabalho de Elaboração são instaladas. 5. Documento de Arquitetura de Software: Fornece uma visão geral de arquitetura abrangente do sistema. Deve conter uma descrição detalhada para os casos de usos significativos para a arquitetura, e elementos de design (elementos lógicos a serem definidos como linguagem de programação e banco de dados). Modelo de Design: Descreve a realização dos casos de uso e de forma abstrata, serve como guia para o modelo de implementação. Realizações de caso de uso para cenários significativos do ponto de vista da arquitetura foram definidos. 6. Modelo de Dados: O modelo de dados é um subconjunto do modelo de implementação que descreve a representação lógica e física dos dados persistentes no sistema. Também abrange qualquer comportamento definido no banco de dados, como procedimentos armazenados, triggers, restrições etc. Este artefato deve ter sido criado e com baseline. 7. Modelo de Implementação: Conjunto de componentes (que incluem produtos liberados – executáveis – elementos dos quais os produtos foram criados – código fonte). A estrutura inicial deverá ser criada, com ou sem a adoção de protótipos. 8. Visão: Atualização da visão elabora com foco na compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento. 9. http://linu.com.br/papers/paper042.html 5 de 16 26/06/13 21:01
  • 6. http://linu.com.br/papers/paper042.html Plano de Desenvolvimento de Software: Atualizar o plano existente com objetivo de abranger as próximas fases. 10. Modelo de Casos de Uso: um modelo de casos de uso praticamente concluído. Estima-se que neste ponto o modelo esteja 3/4 do modelo conclusivo. 11. Especificações Suplementares: Os requisitos suplementares abrangendo os requisitos não funcionais são documentados e analisados. Conforme a literatura de Engenharia de Software, requisitos não funcionais (ou atributos não funcionais) dizem respeito a características pertinentes à confiança do software quando integrado (após a fase de integração de subsistemas). Pode-se definir a confiança de software com base em: disponibilidade (capacidade do sistema de estar disponível quando requisitado), confiabilidade (capacidade do sistema de operar de acordo com os requisitos), segurança (capacidade do sistema de operar sem falhas catastróficas) e proteção (capacidade do sistema de proteger-se de intrusões acidentais ou intencionais). Mais informações em Sommerville, 2007. Outras abordagens coerentes para requisitos não funcionais podem ser vistas nas Referências. 12. Conjunto de Testes: Testes implementados e executados para validar a estabilidade do build para cada release executável criada nesta fase. 13. Arquitetura para Automatização de Testes: É uma composição de diversos elementos de automatização de testes e suas especificações que representam as características fundamentais do sistema de software de automatização de testes (Wthreex, em Referências). 14. Além dos artefatos descritos anteriormente, existe aqueles opcionais: Caso de Negócio: Atualizado para os casos onde existam elementos descobertos que influenciem o caso de negócio estabelecido. 1. Modelo de Análise: Pode ser desenvolvido como um artefato formal, que através da evolução, poderá servir como a versão inicial do Modelo de Design. 2. Materiais de Treinamento: Manuais do Usuário e outros materiais 3. de treinamento. 4. Templates Específicos do Projeto: Padrão para a criação dos documentos do projeto. Ao atingir o marco LCA, podemos avaliar sua consistência e confiabilidade através das seguintes perguntas: Os stakeholders têm confiança de que a equipe do projeto tem capacidade de implementar a solução proposta? 1. 2. A arquitetura reflete os requisitos funcionais (funções que o sistema deve fornecer)? 3. Todos os riscos críticos foram eliminados ou mitigados? 4. As variações de custo e prazo são aceitáveis para os stakeholders? 5. A fase de Construção foi planejada de forma consistente e detalhada? Conforme definido, a fase de Elaboração pode ser entendida como um processo de engenharia, onde o foco é especificar uma arquitetura robusta e confiável. Através dos 6 de 16 26/06/13 21:01
  • 7. critérios de avaliação (perguntas) acima, podemos esperar que um resultado satisfatório foi alcançado. Construção Na fase de construção, o sistema e a documentação destinada ao usuário são criados, junto com a versão beta do sistema (Martins, 2007). Nesta fase também serão esclarecidos os requisitos restantes. Toda a construção do sistema terá com base a arquitetura da baseline. O controle de recursos, custos e qualidade fazem parte deste processo. As fases da concepção e elaboração foram auxiliadas por gerenciamento da propriedade intelectual. Na fase de Construção, o foco estará no desenvolvimento dos produtos que serão construídos. Espera-se atingir versões úteis com eficiência. As atividades devem ser coordenadas de forma que o paralelismo esteja presente. Mesmo em projetos pequenos, é possível coordenar as equipes para que os componentes independentes sejam elaborados em paralelo. Ao concluir esta fase, chegaremos ao marco Capacidade Operacional Inicial (IOC – Initial Operational Capability). Espera-se neste momento que o produto esteja pronto para ser passo a equipe de Transição e que os testes alfa estejam concluídos (teste alfa consiste em testes de aceitação informal, onde os procedimentos de execução do teste não são definidos). Os seguintes artefatos são esperados: O Sistema: o sistema executável pronto para começar o teste beta (teste não formalizado geralmente realizado pela comunidade de usuários). 1. Plano de Implantação: plano que coordena e lista as atividades envolvidas na transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários. Deve-se criar um plano inicial com baseline. 2. Conjunto de Testes: Testes implementados e executados de cada release construído durante esta fase. 3. 4. Materiais de Treinamento: Manuais do usuário e outros materiais de treinamento. 5. Plano de Iteração: Plano de iteração para a próxima fase (Transição), concluído e analisado. Modelo de Design: Atualizado com novos elementos de design identificados durante a conclusão de todos os requisitos. 6. Caso de Desenvolvimento: Trata-se do refinamento do ambiente de desenvolvimento – processo e ferramentas – com objetivo de auxiliar a equipe da próxima fase. 7. 8. Ferramentas: Ferramentas da fase de Construção. 9. Modelo de Dados: Atualizado com a experiência adquirida no processo de Construção. http://linu.com.br/papers/paper042.html 7 de 16 26/06/13 21:01
  • 8. http://linu.com.br/papers/paper042.html Além dos artefatos obrigatórios descritos anteriormente, a fase de Construção também possui alguns artefatos opcionais, que são: Templates Específicos do Projeto: Os templates de documentos usados para desenvolver os artefatos de documentos. 1. Especificações Suplementares: Atualizar as especificações já existentes caso sejam descobertos novos requisitos não funcionais. 2. Modelo de Casos de Uso: Atualizado com os possíveis novos casos de usos descobertos durante essa fase. 3. A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação descritos abaixo. O formato em perguntas persiste: O produto está completo o suficiente e com a qualidade mínima aceitável para iniciar o teste de aceitação? 1. O usuário e a organização estão preparados para o início da implementação (transição do sistema)? 2. As variações de custo e prazo são aceitáveis 3. para os stakeholders? O processo de Construção pode ser compreendido como um processo de manufatura. Obviamente o gerenciamento será adaptado para tal situação, levando em questões elementos como prazos, custos e recursos. Esta fase, assim como todas as outras do RUP, deve abordar a iteratividade, apresentando incrementos (releases do sistema) ao final de cada repetição. É estimado um esforço de programação por volta de 1/2 em relação ao projeto como um todo. Geralmente esta fase consome mais recursos e tempo, mas seu sucesso estará associado às questões bem (ou mal) resolvidas nas etapas anteriores. Certamente, o impacto dos riscos não descobertos (ou não avaliados) serão maiores nesta etapa. Ao terminar essa fase, o sistema poderá ser transferido para os usuários. Transição Em síntese, o foco da fase de Transição é assegurar que o software esteja disponível para seus usuários finais. Ele deverá ser distribuído, ou seja, instalado para os clientes e usuários finais. É comum a continuidade do desenvolvimento do software demandado por feedback dos usuários. Deverão ser fornecidos, a cada ciclo da Transição, novos releases do produto. Existe também a possibilidade de que o fim do ciclo de vida do produto do projeto coincida com o início de outro ciclo de vida para o mesmo produto – como uma nova versão do software, por exemplo. A complexidade inerente nesta fase varia de acordo com o produto e cliente. Um software comercial para uma nova microempresa pode gerar poucos problemas nesta etapa, ao passo que a substituição de sistemas previdenciários de um país pode levar anos para ser concluída. É interessante que nesta fase, sejam definidas metas de acordo com o andamento do processo. Por exemplo, a alteração de uma falha de sistema pode envolver retrabalho na programação e teste. Ao passo que a correção de um requisito possa levar a um processo 8 de 16 26/06/13 21:01
  • 9. http://linu.com.br/papers/paper042.html similar ao de Construção. Ao final desta fase, encontra-se o marco Release do Produto (PR – Product Release). O principal aspecto centra-se na avaliação dos objetivos, se foram ou não atendidos, e na decisão de iniciar um novo processo de Construção com base nesses objetivos. Os artefatos envolvidos neste marco são: O Build do Produto: deve ser fornecido um sistema concluído de acordo com os requisitos do produto, onde o consumidor final utiliza o sistema. 1. Notas de Release: As Notas de Release identificam mudanças e erros conhecidos em uma versão de um build ou em uma unidade de implantação que tenha sido disponibilizada para uso (texto retirado da Referência). As notas devem estar concluídas. 2. Artefatos de Instalação: elementos de instalação do software, como também a documentação associada. 3. Material de Treinamento: O material deve estar concluído. A partir dele o cliente poderá utilizar o sistema. 4. Material de Suporte para o Usuário Final: Material que colabora com a aprendizagem, manutenção e utilização do sistema. 5. Existem também os artefatos opcionais: Conjunto de Testes: O conjunto de teste associado em cada build poderá ser fornecido ao cliente. 1. Empacotamento Compacto do Produto: Elementos fornecidos ao cliente com intuito de auxiliar o processo de compactação do produto. 2. Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da fase de Transição. Os objetivos do projeto foram atingidos de acordo com os 1. critérios de medição? 2. As variações de custo e prazo são aceitáveis pelos stakeholders? 3. Os usuários estão satisfeitos? Ao final da fase de transição, espera-se que um ciclo do projeto, ou o projeto em si, tenha chegado ao fim. Geralmente, conforme mostrado na figura abaixo – retirada das Referências, o comportamento típico para um processo de software evolui e consome recursos de forma distinta para cada fase. 9 de 16 26/06/13 21:01
  • 10. http://linu.com.br/papers/paper042.html Como se pode ver, o tempo e recurso da Iniciação (Concepção) são significativamente menores do que o da Elaboração e Construção. A Transição está diretamente associada às características do projeto, porém espera-se que consuma menos tempo que a Construção. Podemos observar o seguinte: projetos mal estruturados e pouco documentados, onde a análise e o gerenciamento foram negligenciados por pressões dos clientes/gerentes do projeto tornam o processo de Transição extremamente doloroso, onde muitas alterações e inclusões de requisitos devem ser realizadas. Na fase de Transição, a correção de falhas de sistema ou adaptação de requisitos devido a mudanças no escopo do produto é aceitável, porém a inclusão de requisitos que não foram capturados ou não documentados pela falta de coordenação e confiança nas fases de Iniciação e Elaboração é altamente prejudicial ao projeto. Isso é muito comum no desenvolvimento de software atual, mesmo existindo ferramentas e modelos de processo altamente suficientes para contornar tais problemas. Em casos como esses, ciclos completos (com as quatro fases) no projeto talvez sejam necessários. Vale relembrar que os ciclos são previstos no RUP. Cada fase do projeto poderá ser repetida várias vezes. Inclusive as quatro fases podem ser repetidas, fornecendo incrementos (ou versões) em cada ciclo. O processo de desenvolvimento em fases é comum nos projetos atuais, seja na forma de desenvolvimento iterativo ou por incremento. No primeiro caso, o desenvolvimento iterativo fornece inicialmente um esqueleto do sistema, que será aperfeiçoado em cada fase. O esqueleto, porém, não traz confiabilidade nos requisitos de forma satisfatória. Isso será conquistado ao longo do processo. A figura abaixo ilustra este tipo de desenvolvimento. Neste gráfico, os itens em branco foram apresentados de forma genérica, ainda sem contemplar as reais necessidades do negócio. Os itens em amarelo já foram ajustados aos requisitos. Observe que na Fase 1, apenas o módulo 2 é apresentado com coerência nos 10 de 16 26/06/13 21:01
  • 11. http://linu.com.br/papers/paper042.html requisitos, enquanto os módulos 1 e 3 ainda são soluções paliativas para o problema - mas já podem ser utilizadas. Este contexto é comum para sistemas ERP, onde um grande sistema coorporativo (e pode-se dizer, genérico) existe e aos poucos é adaptado a realidade das empresas. Um exemplo típico é o sistema SAP/R3. No desenvolvimento por incrementos, cada módulo é entregue em separado, sem um esboço geral do sistema, porém atendendo a real necessidade dos requisitos analisados. Neste caso, o projeto desenvolverá o módulo 2 na primeira fase – isso porque a empresa cliente justificou que este incremento é o de maior prioridade para o negócio. Ao longo dos próximos ciclos, os outros módulos, também em ordem de prioridade, serão apresentados. A vantagem deste paradigma centra-se na qualidade alcança nos incrementos de maior importância. Como o cliente estipulou que o módulo 2 é de maior prioridade, este foi desenvolvido na íntegra, primeiro e, conseqüentemente, sofrerá maior carga de testes e validações dos requisitos se comparado com o módulo 1, que foi o último a ser entregue. As figuras apresentadas acima, que define o desenvolvimento iterativo e incremental, foram criadas por Flávio Mello, professor da UFRJ. Em uma aula que pude presenciar sua explicação ele abordou tais temas por meio dessas figuras. Achei interessante abordá-las aqui também. Veremos agora a perspectiva estática do RUP. Perspectiva Estática A visão estática do RUP enfoca as atividades que ocorrem durante o processo de desenvolvimento. Elas são chamadas de workflows na descrição do RUP. Existem seis workflows de processo principais identificados e três workflows de apoio principais (Sommerville, 2007). Um workflow também é chamado de disciplina. Utilizaremos as duas formas para identificá-los, como prática comum em tais abordagens. Ao longo do projeto você precisa construir artefatos (um nome elegante para documento, com alguma particularidade, do sistema). No RUP você constrói os artefatos por meio das atividades. Uma disciplina (workflow) mostra todas as atividades que você deve realizar para construir alguns artefatos. As disciplinas não são temporais ou fixas nas fases. Isso significa que eu posso utilizar a disciplina de Requisitos na fase de Construção, mesmo que esta esteja naturalmente mais associada à fase de Concepção. Isso é válido para todas as disciplinas. Para enfatizar esse entendimento, por conveniência, repeti aqui o gráfico da disposição das disciplinas ao longo das fases do projeto. 11 de 16 26/06/13 21:01
  • 12. http://linu.com.br/papers/paper042.html Observe que elas são demandadas com maior ênfase em determinado momento, porém nada impede que sua utilização seja realizada em outras fases. As três disciplinas de apoio Gerenciamento de Configuração e Mudança, Gerencimanto de Projeto e Ambiente são mais distrubuídas por todas as fases, sem apresentar nenhum pico significativo. Isso é comum à tais disciplinas, pois como a própria descrição sugere, elas servem de apoio para todas as outras disciplinas e para o projeto como um todo. Veremos agora uma abordagem sobre cada uma das disciplinas. Em primeiro plano, veremos os seis workflows principais. Modelagem de Negócios Os processos de negócios são modelados utilizando casos de uso de negócios (Sommerville, 2007). Em sintese, a modelagem de negócios se preocupa na descrição do negócio, identificação dos processos e no desenvolvimento do modelo de domínio, realizando refinamentos, projeções dos processos e levantamento dos papéis envolvidos. Essa disciplina é mais comum nas fases de Iniciação e Elaboração, porém é comum ser repetida nos projetos em que os requisitos sofrem alterações constantemente. Requisitos Trata principalmente da definição formal dos requisitos. Para novos sistemas, o problema é analisado com o objetivo de identificar os indivíduos, as fronteiras e restrições. Em casos onde já exista um sistema, os envolvidos são identificados com objetivo de conhecer melhor suas necessidades. Com base nos dados levantados, o sistema é definido, o escopo é elaborado e os requisitos mutáveis são gerenciados. Possui maior participação na fase de Iniciação e é normalmente utilizada durante toda a fase de Elaboração. Análise e Design (ou Análise e Projeto) Um modelo de projeto é criado e documentado usando modelos de arquitutura, modelos de componente, modelos de objeto e modelos de seqüência (Sommerville, 2007). Em 12 de 16 26/06/13 21:01
  • 13. http://linu.com.br/papers/paper042.html primeiro momento uma sugestão de arquitetura é definida. Posterioremente, em paralelo com o refinamento da arquitetura, os comportamentos são analisados com o objetivo de projetar os componentes e o banco de dados do sistema. Está concentrada na fase de Elaboração e geralmente é refinada e ajustada na fase de Construção. Implementação Apesar de sua maior concetração na fase de Construção, a implementação está presente em todos os momentos. Na fase de Concepção os protótipos poderão facilitar o entendimento dos requisitos. Na fase de Elaboração, esboços da arquitutura poderão evoluir até que um nível satisfatório seja alcançado e que um protóripo para a arquitetura seja construído. Na fase de Transição, correções de falhas no sistema e ajustes são freqüentes. Na fase de Construção, em geral é definido um modelo de implementação e integração. Os subsistemas são construídos em forma de incrementos e integrados nos ciclos. A cada nova integração, os componentes individuais são testados, e existe um refinamento dos artefatos construídos, se necessário. A geração automatica, comum em ferramentas CASE, também pode ser utilizada neste momento. Teste Segundo Sommerville, o teste é um processo iterativo realizado em conjunto com a implementação. O teste do sistema segue o término da implementação. Os testes devem ser formalizados com o objetivo de identificar o foco adequado do esforço de teste para a iteração e estabelecer consenso com os envolvidos sobre as metas correspondentes que conduzirão o esforço de teste (Wthreex). Possui maior ênfase no final da fase de Construção. Implantação Nesta disciplina uma versão do produto é distribuída. Como previsto, sua maior utilização está centrada no marco PR (entre a fase de Construção e Transição). O teste de aceitação também precisa ser considerado. Artefatos como material de suporte precisão ser disponibilizados. Veremos agora os três workflows de apoio. Gerenciamento de Configuração e Mudanças Gerencia as mudanças do sistema. Tarefas como Gerenciar Solicitações de Mudanças, Gerenciar Baselines e Releases e Planejamento de Controle do Projeto e Configuração de Mudanças são pertinentes e devem ser utilizadas. Apesar de suportar todo o projeto, possui mais demanda nas fases de Construção e Transição. Gerenciamento de Projetos Possui a característica de gerenciar o desenvolvimento do sistema. É uma disciplina ampla e deve ser considerada com atenção. A gerência de projetos é comum em diversos ambientes e possui referências importantes de mercado como o PMI. Recomendo leituras associadas ao Gerenciamento de Projetos para sua aplicação e utilização especializada neste workflow. O próprio RUP, um modelo genérico de processo de software, espera que exista uma abordagem empresarial do gerenciamento do projeto em sua estrutura. Deve ser utilizado em todas as fases. 13 de 16 26/06/13 21:01
  • 14. http://linu.com.br/papers/paper042.html Ambiente Este workflow está relacionado à disponibilização de ferramentas de software apropriadas para a equipe de desenvolvimento (Sommerville, 2007). Cada projeto possui sua particularidade. Em determinados casos, existirão maiores demandas de certos workflows para as fases iniciais, em quanto em outros, a maior atenção ocorrerá nas fases finais. Os dados mostrados neste documento e sugeridos na literatura sobre o assunto mostram aplicações corriqueiras para associar as disciplinas às fases. Mas o fato de serem tratadas como perspectivas dinâmicas e estáticas propõem justamente que não existam restrições nas suas combinações durante o projeto. Perspectiva Prática A adoção de boas práticas no desenvolvimento de software favorece o andamento do projeto e contribuí para o sucesso e aceitação do produto final. A perspectiva prática mostra justamente algumas práticas recomendadas no processo de software. São elas: Desenvolvimento Iterativo: característica já abordada neste estudo que indica que o software deve ser desenvolvido em incrementos, entregues em ordem de prioridade definida pelo cliente. 1. Gerenciar Requisitos: Documentação formal dos requisitos e acompanhamento das mudanças. Sempre que houver solicitações de mudanças, avaliar o impacto no projeto antes da aceitação formal. 2. Arquiteturas Baseadas em Componentes: o uso de arquiteturas baseadas em componentes, externos ou produzidos no projeto, facilita a produção do sistema. Deve ser considerada tal característica. 3. Modelagem Visual: Utilizar modelos da UML para representar o software de forma estática e dinâmica. Conforme indicado, o RUP sugere a utilização da UML em seus projetos. Este item reforça isso. 4. Verificar a Qualidade do Software: A qualidade do software deve ser monitorada e conduzida de forma a atender os padrões de aceitação do cliente. Isso influenciará o sucesso do projeto. 5. Controlar as mudanças do software: As mudanças deverão ser gerenciadas durante todo o processo. Isso contribuirá para um projeto melhor estruturado, documentado e para sua continuidade e aceitação. 6. Conclusões Neste documento, mostrei uma simplória abordagem sobre o modelo de processo de software RUP e sua importância num projeto. Minha intenção principal é apresentar o paradigma de desenvolvimento de forma conceitual. O RUP completo apresenta templates, entendimento dos papeis e suas importâncias, ferramentas, entre outros. Abordagens mais coerentes e completas deverão ser consultadas para fins de utilização específica. Recomendo que seja acessado o site Wthreex, cujo link encontra-se nas Referências, pois tal material é apresentado de forma completa e bem estruturada. A partir dos elementos deste site você poderá realizar seu processo de software utilizando todos 14 de 16 26/06/13 21:01
  • 15. http://linu.com.br/papers/paper042.html os elementos presentes no RUP e, possivelmente, alcançar o sucesso do projeto. Termino esse texto com uma reflexão simples, mas que serve de exemplo para aqueles que ainda resistem à utilização de processos que possam auxiliar o desenvolvimento do software. Compare o desenvolvimento de software com o preparo de macarrão. Podemos preparar o macarrão de duas formas: a forma recomendada diz que devemos ferver a água, colocar o macarrão para cozinhar, verificar ao longo do processo se o mesmo já está pronto e por fim, colocar o molho. Existe também a forma fácil, onde se coloca a água, o macarrão e o molho tudo ao mesmo tempo e vai assistir televisão até que ele fique pronto. O primeiro método trará um excelente macarrão, mas muitas pessoas não gostam de utilizá-lo, pois acham uma perda de tempo (este é o meu caso, por exemplo). O segundo método tem como resultado uma gororoba braba, porém é mais fácil de atingi um resultado (ruim, porém mais rapidamente). Minha pergunta é: se seu trabalho fosse o de produzir macarrão para clientes e seu dinheiro dependesse da satisfação dos mesmos, qual dos dois métodos você utilizaria? Então porque você insiste em produzir softwares negligenciando os processos de requisitos, documentação, análise e gerenciamento de projeto, se o resultado será, em geral, uma porcaria! Referências http://en.wikipedia.org/wiki/Work_breakdown_structure http://www.wthreex.com/rup/ http://pt.wikipedia.org/wiki/Rational_Unified_Process http://pt.wikipedia.org/wiki/Stakeholder http://www.algosobre.com.br/portugues/usos-do-porque.html (afinal, errar é humano, mas corrigir o erro no Google também) http://www.macoratti.net/proc_sw1.htm http://pt.wikipedia.org/wiki/Engenharia_de_software http://wthreex.com/rup/process/workflow/requirem/co_req.htm http://www.wthreex.com/rup/process/workflow/test/co_accte.htm Ian Sommerville, 2007. Engenharia de Software, 8ª edição. Pearson Addison-Wesley. José Carlos Cordeiro Martins, 2007. Técnicas para Gerenciamento de Projetos de Software. Brasport. “São as nossas escolhas que revelam o que realmente somos, muito mais do que as nossas qualidades.” Alvo Dumbledore 15 de 16 26/06/13 21:01
  • 16. Espero ter colaborado com algo! Guilherme Pontes http://linu.com.br/papers/paper042.html 16 de 16 26/06/13 21:01