PROCESSO UNIFICADO

I – PROCESSO UNIFICADO

1. Histórico

No início da década de 90 surgiu o conceito de Orientação a Objeto (OO). Junto ao conceito surgiram inúmeras propostas de modelos de Análise Orientada a Objetos (AOO) e Projeto Orientado a Objetos (POO). Essa quantidade de propostas gerava discussões sobre qual modelo seria o melhor (AOO ou POO). Além do mais, era difícil ocorrer um bom entendimento entre equipes de desenvolvimento, por raramente usarem os mesmos modelos de desenvolvimento OO. Enquanto cada uma trabalhava em um processo diferente, descobriram que cada uma das equipes tinha desenvolvido suas vantagens e desvantagens.

Houve, então, uma proposta de criação de um modelo unificado entre três grandes nomes da área de engenharia de software, James Rumbaugh, Grady Booch e Ivar Jacobson. Como resultado dessa união foi criada a Unified Modeling Language (UML), servindo como uma norma entre as empresas de desenvolvimento de software. Tratava-se de uma ferramenta auxiliadora nas etapas da engenharia de software e não de um molde (esqueleto) a ser seguido no desenvolvimento de sistemas OO.

Durante alguns anos decorridos do surgimento da UML, os mesmos criadores desenvolveram o Processo Unificado (PU). Este sim passou a servir como um modelo a ser seguido durante as etapas de desenvolvimento de grandes sistemas Orientação ao Objeto. O PU propôs o modelo iterativo e incremental, deve ser adaptado para satisfazer às necessidades específicas do projeto.

Atualmente o PU e a UML são amplamente usados em conjunto por empresas desenvolvedoras de software OO.

2. Introdução

O processo unificado reconhece a importância da comunicação com o cliente e dos métodos diretos para escrever a visão do cliente de um sistema (o caso de uso).

Além disso, enfatiza importantes papéis da arquitetura de software e ajuda o arquiteto a se concentrar nas metas corretas.

Sugere também um fluxo de processo de software que é iterativo e incremental, dando a sensação evolucionária, que é essencial no desenvolvimento moderno de software.

Processo de Desenvolvimento é o conjunto de atividades de desenvolvimento, sua ordem temporal e a atribuição de responsabilidades (papéis de desenvolvedores) definem um processo de desenvolvimento de software;

Um processo de software é a especificação do processo de transformar necessidades em software.

Ciclo de Vida de um Processo:

– Determina as fases do processo;

– Define atividades importantes e opcionais para cada fase.

O processo unificado (Unified Process – UP) é, antes de tudo, um processo de desenvolvimento de software. Trata-se de um framework (padrão de arquitetura que fornece um template extensível para aplicações em um domínio) genérico de um processo de desenvolvimento.

O Processo unificado surgiu como uma nova proposta de desenvolvimento, fugindo do modelo em cascata, seguindo basicamente as mesmas etapas genéricas de desenvolvimento de software, porém visando um desenvolvimento iterativo e incremental, totalmente diferente do modelo em cascata.

O Processo unificado de desenvolvimento de Software

Autor: Vidal Martins - GPT

1. Introdução

O processo unificado de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software [1]. Ele é baseado em componentes, o que significa o sistema ser construído a partir de componentes de software interconectados via interfaces muito bem definidas. O processo unificado utiliza a Linguagem de Modelagem Unificada (Unified Modeling Language – UML) no preparo de todos os artefatos do sistema [1,2]. Os aspectos que distinguem o processo unificado são capturados em três conceitos chave [1,2]: direcionado a casos de uso; centrado na arquitetura; iterativo e incremental. Esses três aspectos serão discutidos nas próximas seções.

1.1 Direcionado a Casos de Uso

Um sistema de software é feito para servir seus usuários. Portanto, para construir um sistema de sucesso devemos saber quem são seus usuários potenciais e o que eles querem e precisam. O termo usuário representa alguém ou alguma coisa (como um outro sistema) que interage com o sistema que está sendo desenvolvido.

Um caso de uso [1,2,3] é um pedaço de funcionalidade do sistema que dá ao usuário um resultado de valor. Casos de uso capturam requisitos funcionais e todos juntos resultam no modelo de casos de uso, o qual descreve a funcionalidade completa do sistema.

Este modelo substitui a especificação funcional tradicional, cujo papel é responder à seguinte questão: o que o sistema faz? A estratégia de casos de uso pode ser caracterizada pela adição de três palavras no final dessa pergunta: para cada usuário? Estas palavras têm uma implicação muito importante. Forçam-nos a pensar em termos dos valores dos usuários, não apenas em funções que poderiam ser interessantes.

Os casos de uso direcionam o processo de desenvolvimento, já que, baseados no modelo de casos de uso os desenvolvedores criam uma série de modelos de projeto e implementação que os realizam efetivamente. Os responsáveis pelos testes realizam seu trabalho com o propósito de garantir que os componentes do modelo de implementação cumpram corretamente os objetivos estabelecidos nos casos de uso. Desta forma, os casos de uso não somente iniciam o processo de desenvolvimento, mas também o mantêm coeso. Direcionado a casos de uso significa que o processo de desenvolvimento executa uma sequência de tarefas derivadas dos casos de uso. Eles são especificados, projetados e servem de base para a construção dos casos de teste.

Embora seja verdade que os casos de uso dirigem o processo, eles não são selecionados isoladamente. São desenvolvidos juntamente com a arquitetura do sistema. Ou seja, os casos de uso direcionam a arquitetura do sistema, que por sua vez influencia a seleção dos casos de uso. Portanto, ambos amadurecem no decorrer do ciclo de vida do sistema.

1.2 Centrado na Arquitetura

O papel da arquitetura no software [1,3] é de natureza similar ao papel da arquitetura na construção civil. As construções são observadas sob vários pontos de vista: estrutura, serviços, condução de calor, encanamento, eletricidade, etc. Da mesma forma, a arquitetura em um sistema de software é descrita como sendo as diferentes visões desse sistema.

O conceito de arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes do sistema. A arquitetura é influenciada por muitos fatores/, tais como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos de construção reusáveis disponíveis (por exemplo, um framework para construção de interface gráfica com o usuário), considerações de distribuição, sistemas legado e requisitos não funcionais (performance, confiabilidade, etc.). Ela representa uma visão do projeto como um todo, na qual as características mais importantes são colocadas em destaque, deixando os detalhes de lado.

Como os casos de uso estão relacionados à arquitetura? Todo produto tem função e forma e nenhum desses elementos sozinho é suficiente. Essas duas forças devem ser balanceadas para obtermos um produto de sucesso. Neste caso, a função corresponde aos casos de uso e a forma à arquitetura. Por um lado, os casos de uso devem, quando construídos, encaixar-se na arquitetura. Por outro, a arquitetura deve fornecer espaço para a construção de todos os casos de uso necessários, agora e no futuro. Na realidade, ambos devem ser desenvolvidos em paralelo.

Para encontrar essa forma, os arquitetos devem trabalhar a partir de uma compreensão geral das funções chave do sistema, isto é, dos casos de uso chave. Estes devem ficar em torno de 5 a 10% de todos os casos de uso, mas são os mais significativos, aqueles que constituem o núcleo das funções do sistema. Em termos simplificados, os arquitetos:

a) Criam um esboço da arquitetura iniciando com a parte que não é específicada dos casos de uso (por exemplo, a plataforma). Embora seja uma parte independente dos casos de uso, o arquiteto deve ter uma compreensão geral destes antes da criação do esboço.

b) Depois, o arquiteto trabalha com um subconjunto dos casos de uso identificados, aqueles que representam as funções chave do sistema em desenvolvimento. Cada caso de uso selecionado é especificado em detalhes e construído em termos de subsistemas, classes e componentes.

c) À medida que os casos de uso são especificados e atingem maturidade, mais detalhes da arquitetura são descobertos. Isto, por sua vez, leva ao surgimento de mais casos de uso.

Este processo continua até que a arquitetura seja considerada estável.

1.3 Iterativo e Incremental

O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais. É mais prático dividir o trabalho em pedaços menores ou miniprojetos. Cada miniprojeto é uma iteração que resulta em um incremento. Iterações são passos em um fluxo de trabalho e incrementos são crescimentos do produto.

Os desenvolvedores selecionam o que deve ser feito em cada iteração baseados em dois fatores. Primeiro, a iteração deve trabalhar com um grupo de casos de uso que juntos estendam a usabilidade do produto em desenvolvimento. Segundo, a iteração deve tratar os riscos mais importantes.

Um incremento não é necessariamente a adição do código executável correspondente aos casos de uso que pertencem à iteração em andamento. Especialmente nas primeiras fases do ciclo de desenvolvimento, os desenvolvedores podem substituir um projeto superficial por um mais detalhado ou sofisticado. Em fases avançadas os incrementos são tipicamente aditivos.

Em cada iteração, os desenvolvedores identificam e especificam os casos de uso relevantes, criam um projeto utilizando a arquitetura escolhida como guia, implementam o projeto em componentes e verificam se esses componentes satisfazem os casos de uso. Se uma iteração atinge seus objetivos, e isso normalmente ocorre, o desenvolvimento prossegue com a próxima iteração, caso contrário, os desenvolvedores devem rever suas decisões e tentar uma nova abordagem.

Há vários benefícios em se adotar um processo iterativo controlado, entre os quais podemos destacar:

a) Redução dos riscos envolvendo custos a um único incremento. Se os desenvolvedores precisarem repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro.

b) Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto.

c) Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.

d) Reconhecimento de uma realidade frequentemente ignorada: as necessidades dos usuários e os requisitos correspondentes não podem ser totalmente definidos no início do processo. Eles são tipicamente refinados em sucessivas iterações. Este modelo de operação facilita a adaptação a mudanças de requisitos.

Os três conceitos apresentados (dirigido a casos de uso, centrado em arquitetura, iterativo e incremental) são igualmente importantes. Remover um deles poderia reduzir drasticamente o valor do processo unificado, e agora que eles foram introduzidos, podemos observar o processo como um todo, seu ciclo de vida, produtos, tarefas, fases e iterações.

2. O ciclo de vida do Processo Unificado

O processo unificado consiste da repetição de uma série de ciclos durante a vida de um sistema, como mostrado na Figura 1. Cada ciclo é concluído com uma versão do produto pronta para distribuição. Essa versão é um conjunto relativamente completo e consistente de artefatos, possivelmente incluindo manuais e um módulo executável do sistema, que podem ser distribuídos para usuários internos ou externos.

Figura 1 – A vida de um processo em ciclos

Cada ciclo consiste de quatro fases: início, elaboração, construção e transição. Cada fase é também subdividida em iterações, como discutido anteriormente (figura 2).

Figura 2 – Um ciclo com suas fases e iterações

2.1 O Produto

O produto final inclui artefatos de interesse do usuário, tais como manuais e código fonte incorporado em componentes que podem ser compilados e executados, e artefatos que interessam a outras pessoas, como os requisitos, os casos de uso, as especificações não funcionais e os casos de teste. Inclui também modelos da arquitetura. Na realidade, inclui todos os elementos já mencionados, os quais permitem especificar, projetar, implementar, testar e utilizar o sistema.

Mesmo que componentes executáveis sejam os produtos mais importantes do ponto de vista dos usuários, sozinhos eles não são suficientes. Isto acontece porque o ambiente muda. Sistemas operacionais, sistemas de bancos de dados e máquinas evoluem. Os próprios requisitos podem mudar à medida que compreendermos melhor a missão do sistema. Na realidade, esta á uma das constantes no desenvolvimento de software: requisitos irão mudar.

Para executar um novo ciclo eficientemente, os desenvolvedores precisam de todas as representações do produto (figura 3):

a) um modelo de casos de uso, contendo todos dos casos de uso e seus relacionamentos com os usuários;

b) um modelo de análise, que tem dois propósitos: refinar os casos de uso em mais detalhes e fazer uma alocação inicial do comportamento do sistema a um conjunto de objetos;

c) um modelo de projeto que define a estrutura estática do sistema em termos de subsistemas, classes e interfaces, e a realização dos casos de uso como sendo colaborações entre subsistemas, classes e interfaces;

d) um modelo de implementação, o qual inclui componentes representando código fonte e o mapeamento entre classes e componentes;

e) um modelo de distribuição que define os nós físicos de computadores e o mapeamento entre os componentes e esses nós;

f) um modelo de teste, o qual descreve os casos de teste que serão usados para verificar os casos de uso;

g) e, é claro, uma representação da arquitetura.

O sistema pode ter também um modelo de domínio ou um modelo de negócios que descreva o contexto no qual ele está inserido.

Figura 3 – Modelos do Processo Unificado

Todos esses modelos estão relacionados e juntos representam o sistema como um todo.

Elementos em um modelo têm uma ligação com elementos de outro modelo. Por exemplo, um caso de uso pode estar relacionado à sua realização no modelo de projeto e a um caso de teste no modelo de teste. A rastreabilidade facilita a compreensão e a modificação.

2.2 Fases em um ciclo

Um ciclo está dividido em quatro fases, cada qual podendo ser subdividida em iterações e consequentes incrementos (figura 4). O final de uma fase é marcado por um ponto de verificação, isto é, pela disponibilidade de um conjunto de artefatos que possibilitem a avaliação do projeto, tais como modelos e outros documentos.

Os pontos de verificação servem a diversos propósitos:

a) Gerentes devem tomar certas decisões cruciais antes do trabalho continuar.

b) Permitem a monitoração do progresso dos trabalhos.

c) Observando o tempo e o esforço despendidos em cada fase, é possível reunir dados úteis para estimar os requisitos de tempo e staff de outros projetos.

Figura 4 – As cinco atividades ocorrem nas 4 fases

A figura 4 lista na coluna à esquerda as atividades que devem ser realizadas em cada fase (requisitos, análise, projeto, implementação e testes). As curvas não devem ser interpretadas literalmente, mas representam uma aproximação do esforço despendido com cada atividade em cada fase. Relembre que uma fase normalmente está subdividida em iterações, ou miniprojetos. Uma iteração típica executa as cinco atividades, como mostra a figura 4 na fase de elaboração.

Durante a fase inicial (inception) é possível responder às seguintes perguntas:

a) O que o sistema fará, principalmente para cada um dos maiores usuários?

b) Como poderia ser a arquitetura desse sistema?

c) Qual é o plano e quanto custará desenvolver o produto?

Um modelo de casos de uso simplificado, que contenha os casos de uso mais críticos, poderá responder à primeira questão. Nesta fase a arquitetura é experimental, tipicamente apenas um esboço contendo os subsistemas mais cruciais. Os riscos mais importantes são identificados e priorizados, a fase de elaboração é planejada em detalhes e o projeto como um todo é estimado a grosso modo.

Durante a fase de elaboração, a maioria dos casos de uso do produto é especificada em detalhes e a arquitetura do sistema é projetada.

O relacionamento entre arquitetura do sistema e o sistema propriamente dito é o que existe de mais importante. Uma maneira simples de entender isso é imaginar que a arquitetura é um esqueleto coberto de pele, mas com muito pouco músculo (software) entre os ossos e a pele, apenas o suficiente para permitir que o esqueleto faça movimentos básicos. O sistema é o corpo inteiro, composto de esqueleto, pele e músculos.

Portanto, a arquitetura é expressa em forma de visões de todos os modelos do sistema. Isto implica a existência de visões arquiteturais do modelo de casos de uso, do modelo de análise, do modelo de projeto, do modelo de implementação e do modelo de distribuição. Durante esta fase, os casos de uso mais críticos são realizados. O resultado desta fase é uma arquitetura básica, isto é, um sistema pequeno, "magro", "descarnado" (com pouco software).

No final da fase de elaboração, o gerente do projeto está em condição de planejar as atividades e estimar os recursos necessários para completar o projeto. A questão chave aqui é a seguinte: os casos de uso, a arquitetura e os planos são estáveis o suficiente e os riscos estão sob controle, a ponto de nos comprometermos em contrato com o desenvolvimento do trabalho como um todo?

Durante a fase de construção o produto é efetivamente construído, músculos (software completo) são adicionados ao esqueleto (arquitetura). Embora a arquitetura do sistema encontre-se estável, os desenvolvedores podem descobrir maneiras melhores de estruturá-lo e podem sugerir pequenas mudanças aos arquitetos.

No final desta fase, o produto contém todos os casos de uso que gerentes e clientes acordaram desenvolver nessa versão. Entretanto, é possível que ele não esteja totalmente livre de defeitos. Mais defeitos poderão ser descobertos e corrigidos durante a fase de transição.

A fase de transição cobre o período durante o qual o produto fica em versão beta. Nessa versão, um pequeno número de usuários experientes utiliza o produto e relata defeitos e deficiências. Desenvolvedores os corrigem e incorporam algumas das melhorias sugeridas. Esta fase envolve atividades como, treinamento de clientes, fornecimento de assistência on-line e correção de defeitos encontrados depois da distribuição. A equipe de manutenção frequentemente divide os defeitos em duas categorias: aqueles com efeitos operacionais que justificam correção imediata e aqueles que podem ser corrigidos na próxima versão regular.