Processo Unificado

O Processo Unificado de Desenvolvimento de Software (Unified Software Development Process USDP) um framework de projeto que guia as tarefas, pessoas e produtos durante o projeto. Ele surgiu para realizar o desenvolvimento de software visando a construo de sistemas orientados a objetos. Dizemos que um framework porque ele oferece as entradas e sadas de cada atividade, mas em nenhum momento restringe como cada atividade dever ser realizada. Atividades diferentes podem ser usadas em diferentes situaes - ou seja, algumas so descartadas e outras sero includas. Trata-se de uma metodologia de desenvolvimento (de domnio pblico), orientada a objetos, proposta pelo mesmo time criador da UML. O nome, UP, ao contrrio do Rational Unified Process, geralmente usado para descrever o processo genrico. O RUP, por exemplo, de propriedade da IBM. Trata-se de uma verso melhorada e proprietria do UP. Muitas pessoas perguntam sobre o porqu o framework chamado de Processo Unificado e no Framework Unificado. A resposta simples: seu principal objetivo definir: 1) Quem faz o qu 2) Quando eles fazem 3) Como alcanar certo objetivo (em cada atividade) 4) As entradas e sadas de cada atividade O framework, na verdade, compreende atividades de baixo nvel (como definio de classes), que so combinadas em disciplinas (tambm conhecidas como workflow). Esses workflows descrevem como uma atividade abastece a outra. Tais disciplinas so organizadas em iteraes. Cada iterao identifica algum aspecto do sistema a ser considerado. As prprias iteraes so organizadas em fases. As fases so focadas em diferentes aspectos do processo de desenho, por exemplo, requisitos, anlise, desenho e implementao. As fases podem ser agrupadas em ciclos. Os ciclos focamse na gerao de sucessivos lanamentos do sistema (por exemplo, verso 1.0, verso 1.1, etc). Ou seja, cada ciclo concludo com uma verso do produto pronta para a distribuio.

Existem 4 elementos chave na filosofia por detrs do Processo Unificado. Tais elementos: 1) so iterativos e incrementais O UP iterativo e incremental - ou seja, no tenta completar a tarefa de desenho de uma s vez. Um dos recursos do modelo waterfall (da engenharia de software) utilizados por muitos mtodos de desenho que ele primariamente assume que voc ir completar a anlise de requisitos inteira antes de comear a fase de desenho. Por sua vez, voc completar a fase de desenho antes de partir para a fase de implementao, etc. Ele aceita que pode haver alguma informao de feedback de uma fase para quaisquer de suas predecessoras e que este feedback pode causar um impacto nos produtos das fases precedentes. No entanto, essa uma questo secundria e a suposio que voc estar habilitado a completar a grande maioria de uma fase antes de considerar a prxima. Isso pode ser verdadeiro no caso de ser o quinto ou sexto sistema que voc estiver construindo no mesmo domnio para o mesmo tipo de aplicao. Com certeza no ser o caso para sua primeira aplicao em um novo domnio (como seu primeiro projeto de e-commerce). Em contraste com o modelo waterfall, o UP possui um modelo iterativo e incremental. Ou seja, o processo de desenho baseado nas iteraes que endeream diferentes aspectos do processo de desenho ou movem o desenho um passo a frente de alguma forma (esse o aspecto incremental do modelo). Isso no significa que o UP um processo baseado em uma rpida prototipao. Qualquer prottipo desenvolvido no UP utilizado para explorar

algum aspecto do desenho. importante notar que a utilizao de uma abordagem iterativa e incremental no UP requer mais planejamento, comparado com abordagens como aquelas baseadas no waterfall. Os seguintes itens, essencialmente, relaciona-se com a abordagem no UP: 1) Voc planeja um pouco 2) Especifica, desenha e implementa um pouco 3) Integra, testa e roda 4) Obtm feedback antes da prxima iterao O resultado final que voc, incrementalmente, produz o sistema que est sendo projetado. Enquanto voc faz isso, voc explicitamente identifica os riscos no desenho/sistema de imediato e lida com eles mais cedo. Resumo: o UP consiste na repetio de uma srie de ciclos durante o desenvolvimento de um sistema, por isso esse processo dito como evolucionrio. Lembrando que cada ciclo subdividido em 4 fases, que veremos. 2) so direcionados a casos de uso Os casos de uso ajudam a identificar quem usa o sistema e o que eles precisam fazer com o sistema (funcionalidade de alto-nvel). E, ainda: casos de uso ajudam a identificar os requisitos primrios do sistema. Um problema muito comum com vrias abordagens tradicionais que, uma vez os requisitos tenham sido identificados, no h rastreabilidade de tais requisitos do desenho at a implementao. Ao invs disso, os designers (e possivelmente os implementadores) devem referir-se de volta (implicitamente) especificao de requisitos e ter certeza que fizeram o que era necessrio. Isso depois verificado no teste (que tarde demais para fazer quaisquer modificaes, se a funcionalidade est errada ou faltando).

No UP, os casos de uso so usados para garantir que o desenho est sempre relevante com o que o usurio requisitou. Os casos de uso agem como uma thread consistente atravs de todo o processo de desenvolvimento. Por exemplo, no incio da fase de desenho uma das duas entradas primrias nessa fase o modelo de caso de uso. Depois, explicitamente dentro do modelo de desenho, h realizaes de caso de uso que ilustram como cada caso de uso suportado pelo desenho. 1) Os casos de uso identificam os usurios do sistema e seus requisitos 2) Ajudam na criao e validao da arquitetura do sistema 3) Ajudam a produzir a definio dos casos de teste e procedimentos 4) Direcionam o planejamento das iteraes 5) Conduzem criao da documentao do usurio 6) Direcionam o desenvolvimento do sistema 7) Sincronizam o contedo de diferentes modelos 8) Dirigem a rastreabilidade atravs dos modelos. 3) so de arquiteturas centradas

Um problema de ter uma abordagem iterativa e incremental que, enquanto um grupo pode estar trabalhando em parte da implementao, outro grupo pode estar trabalhando na parte do desenho. Para garantir que todas as vrias partes se encaixem, h a necessidade de fazer alguma coisa. Esse "alguma coisa" a arquitetura. Uma arquitetura o esqueleto no qual os msculos (funcionalidades) e a pela (a interface do usurio) do sistema sero pendurados. Uma boa arquitetura ser resiliente mudanas e ao desenho em evoluo. O USDP descreve como voc identifica o que deveria fazer parte da arquitetura e como voc te auxiliar na concepo e implementao da arquitetura. O USDP prescreve o sucessivo refinamento da arquitetura executvel, tentando assim garantir que a mesma permanece relevante. 4) Reconhece risco O processo unificado reconhece os riscos inerentes ao desenho e desenvolvimento de software. Ele faz isso destacando aspectos desconhecidos no sistema desenhado e outras reas de interesse. Essas reas so direcionadas como sendo crticas ao sistema e, portanto parte da arquitetura, ou reas de risco que precisam ser endereadas mais cedo no processo de desenho (onde h mais tempo), ao invs de mais tarde (quando o tempo tende a ser curto). Assim, ele tenta forar os aspectos de mais riscos a serem desenhados e implementados mais cedo, consequentemente garantindo que o risco no sistema seja endereado e gerenciado de forma profissional. Um fato a ser destacado que o UP precisa de uma ferramenta de suporte. Ele requer uma ferramenta que no suporte somente uma notao apropriada (como a UML), mas suporte tambm o UP: essa ferramenta ir guiar atravs das fases, disciplinas e atividades do UP. O UP composto de 4 fases, com focos em aspectos diferentes no processo de desenho:

Concepo: essa fase define o escopo do projeto e desenvolve o caso de negcio (business case - que no iremos comentar - vamos partir do princpio que o sistema ser desenhado requerido e o caso de negcio j fora feito)para o sistema. Vrios prottipos podem ser construdos durante esta fase para garantir a viabilidade do propsito. A sada dessa fase a viso do sistema. Inclui um simplificado modelo de caso de uso (para identificar qual a primria funcionalidade do sistema) e uma muito hesitante arquitetura. Alm disso, os riscos mais importantes ou significantes so identificados e, assim, a fase de elaborao planejada. Elaborao: essa fase captura os requisitos funcionais do sistema. Dever tambm especificar quaisquer requisitos no-funcionais, para garantir que eles so levados em conta. Outra tarefa primria dessa fase a criao da arquitetura a ser usada em todo o restante do UP. A primria sada dessa fase a arquitetura, juntamente com o detalhado modelo de caso de uso e um conjunto de planos para a fase de construo. Construo: essa fase se concentra em completar a anlise do sistema, realizando a maioria do design e implementao do sistema. Ou seja, constri o produto. O produto pode ainda conter defeitos, j que mais trabalhos ainda devem ser completados na fase de transio. Transio: move o sistema para o ambiente do usurio. Envolve atividades como implantar o sistema e mantendo-o. O marco mais importante dessa fase o lanamento do sistema final.

Nunca esquea: disciplinas so passos que ns realmente seguimos. Uma nica disciplina (passo) pode percorrer (ou estar envolvido) em mais de uma fase. Por exemplo, durante a fase de elaborao, parte das disciplinas de requisitos, anlise, desenho e at mesmo implantao pode estar ativas. No entanto, a nfase nessa hora, dentro dessas disciplinas, ser elaborar o que sistema dever fazer e como ser estruturado, ao invs de anlise, desenho e implementao mais detalhada, o que ocorre na fase de construo. As 5 disciplinas do UP so: 1) Requisitos 2) Anlise 3) Projeto 4) Implementao 5) Teste

Note que as disciplinas de Projeto, implementao e teste so quebradas - para indicar que elementos de cada disciplina podem tomar lugar mais cedo que as partes core da disciplina. Em

particular, o desenho, implementao e teste da arquitetura acontecer mais cedo (na fase de elaborao). A disciplina de Requisitos foca em atividades que possibilitam ser identificados os requisitos funcionais e no-funcionais do sistema. O produto primrio desta disciplina o modelo de caso de uso. A disciplina de Anlise possui como objetivo reestruturar os requisitos identificados na disciplina de requisitos em termos do software a ser construdo, ao invs dos menos precisos termos do usurio. A disciplina de Design produz o design detalhado que ser implementado na prxima disciplina. A disciplina de Implementao representa a codificao do design em uma linguagem de programao e a compilao, empacotamento e desenvolvimento e documentao do software. A disciplina de Teste descreve as atividades a serem executadas para testar o software, de forma a garantir que ele atende aos requisitos dos usurios, que seja confivel, etc.

Lembre-se que uma disciplina descreve como um conjunto de atividades esto relacionadas. Atividades so coisas que realmente dizem aos designers o que eles esto fazendo. Uma atividade pega entradas e produz sadas. Essas entradas e sadas so referidas como artefatos. Um artefato que age como uma entrada em uma atividade particular poderia ser um caso de uso, enquanto a sada de tal atividade poderia ser um diagrama de classe, etc.

O UP define um trabalhador como um papel que um indivduo pode desempenhar no projeto. A principal diferena entre trabalhador e ator que este est do lado de fora, olhando para dentro do sistema, enquanto o outro est dentro, talvez olhando para fora, talvez no. Os atores tm

relacionamentos operacionais ou de uso com o sistema, enquanto os trabalhadores participam do desenvolvimento do sistema.