linu.com.br: Rational Unified Process

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.
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.
Perspectiva prática: onde são definidas boas práticas a serem executadas em todos os processos de software.

Geralmente as perspectivas dinâmicas e estáticas são apresentadas em conjunto. Observe a iteração das mesmas pela figura abaixo.

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 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.
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.
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?
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.
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.
Caso de desenvolvimento: processo no qual o projeto seguirá, ou seja, é uma descrição do processo de desenvolvimento para servir de guia.
Ferramentas: tudo que será necessário para o desenvolvimento do software, considerando também a instalação e aquisição das mesmas.
Glossário: termos importantes no projeto (uma espécie de índice que será utilizado como referência).

Todos os elementos descritos são necessários. Existem também alguns itens opcionais, descritos adiante:

Casos de Uso: define um template para modelagem dos casos de uso.
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.
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.

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?
Os stakeholders estão confiantes de que os riscos mais críticos foram identificados?
As estimativas iniciais foram refinadas com base no conhecimento adquirido?
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 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.
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.
Caso de Desenvolvimento: Atualização do artefato já elaborado, aqui considerando questões sobre o ambiente de desenvolvimento, ferramentas e processo.
Ferramentas: As ferramentas pertinentes ao trabalho de Elaboração são instaladas.
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.
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.
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.
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.
Plano de Desenvolvimento de Software: Atualizar o plano existente com objetivo de abranger as próximas fases.
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.
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.
Conjunto de Testes: Testes implementados e executados para validar a estabilidade do build para cada release executável criada nesta fase.
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).

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.
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.
Materiais de Treinamento: Manuais do Usuário e outros materiais de treinamento.
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?
A arquitetura reflete os requisitos funcionais (funções que o sistema deve fornecer)?
Todos os riscos críticos foram eliminados ou mitigados?
As variações de custo e prazo são aceitáveis para os stakeholders?
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 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).
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.
Conjunto de Testes: Testes implementados e executados de cada release construído durante esta fase.
Materiais de Treinamento: Manuais do usuário e outros materiais de treinamento.
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.
Caso de Desenvolvimento: Trata-se do refinamento do ambiente de desenvolvimento – processo e ferramentas – com objetivo de auxiliar a equipe da próxima fase.
Ferramentas: Ferramentas da fase de Construção.
Modelo de Dados: Atualizado com a experiência adquirida no processo de Construção.

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.
Especificações Suplementares: Atualizar as especificações já existentes caso sejam descobertos novos requisitos não funcionais.
Modelo de Casos de Uso: Atualizado com os possíveis novos casos de usos descobertos durante essa fase.

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?
O usuário e a organização estão preparados para o início da implementação (transição do sistema)?
As variações de custo e prazo são aceitáveis 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 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.
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.
Artefatos de Instalação: elementos de instalação do software, como também a documentação associada.
Material de Treinamento: O material deve estar concluído. A partir dele o cliente poderá utilizar o sistema.
Material de Suporte para o Usuário Final: Material que colabora com a aprendizagem, manutenção e utilização do sistema.

Existem também os artefatos opcionais:

Conjunto de Testes: O conjunto de teste associado em cada build poderá ser fornecido ao cliente.
Empacotamento Compacto do Produto: Elementos fornecidos ao cliente com intuito de auxiliar o processo de compactação do produto.

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 critérios de medição?
As variações de custo e prazo são aceitáveis pelos stakeholders?
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.

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 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.

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 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.

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.
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.
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.
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.
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.
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.

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 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.