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
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
Espero ter colaborado com algo!
Guilherme Pontes
Linux
Curso Java
Papers Java
Database
Hardware
Informática
Gestão de TI
Diversão
Download
Potions
Homepage
Blog
Facebook
Youtube
Twitter
Linubr.org
