O processo unificado (PU) , ou " processo unificado (UP) " em inglês, ou " Processo de Desenvolvimento de Software Unificado (USDP) " é uma família de métodos de desenvolvimento de software orientados a objetos. É caracterizado por uma abordagem iterativa e incremental, orientada por casos de uso e centrada na arquitetura e modelos UML . Ele define um processo que integra todas as atividades de design e produção em ciclos de desenvolvimento composto por uma fase de criação, uma fase de desenvolvimento, uma fase de construção e uma fase de transição, incluindo cada uma várias iterações.
Em 1987, Ivar Jacobson criou a Objectory AB para comercializar um método de desenvolvimento orientado a objetos chamado Objectory Process. Este método é o resultado de uma abordagem centrada no componente que ele desenvolveu desde 1967 na empresa Ericson . Objectory é baseado em casos de uso , um conceito criado por Jacobson. O método segue então uma abordagem sistemática visando por uma sucessão de modelos OOSE para chegar à realização do software.
Em 1992, Grady Booch , funcionário da empresa Rational Software, publicou o método Booch de desenvolvimento orientado a objetos. Isso consiste em uma linguagem de modelagem gráfica, um processo de desenvolvimento iterativo e um conjunto de melhores práticas .
Em 1995, a Rational Software adquiriu a Objectory AB e fundiu os dois métodos de desenvolvimento sob o nome Rational Objectory Process. A empresa também contratou James Rumbaugh , criador da linguagem de modelagem OMT .
Em 1997, a "linguagem de modelagem unificada", UML , se tornou um padrão em análise e design orientado a objetos , seguindo a unificação das três principais notações da época, OOSE, Booch e OMT, todas primeiro dentro da Rational Software, depois uma consórcio maior. A nova notação é então integrada ao Rational Objectory Process (versão 4.1).
Em 1998, após a aquisição de várias outras empresas especializadas em ferramentas de engenharia de software, a Rational Software melhorou seu método e o renomeou “ Rational Unified Process (RUP)” (versão 5.0). É um método proprietário protegido por uma marca registrada.
Em 1999, Jacobson, Booch e Rumbaugh publicaram “O Processo Unificado de Desenvolvimento de Software” com o objetivo de disseminar as idéias por trás do RUP mais amplamente para o público. Eles ressaltam que se trata de uma unificação das abordagens de desenvolvimento e dos modelos usados, e que o processo incorpora um grande número de contribuições de especialistas metodológicos da Rational Software e de centenas de outras empresas.
O processo unificado é um método de desenvolvimento de software caracterizado por:
O processo unificado atende à definição de um processo de negócios . Pretende assim garantir um ciclo de desenvolvimento com sequências sistemáticas e repetíveis de atividades baseadas em artefatos bem definidos, facilitando a integração de novas pessoas nas equipas. O método considera ainda que o produto consiste não apenas no código, mas também em todos os elementos que contribuem para a sustentabilidade e subsequentes evoluções do software.
O processo unificado é cíclico: visa, por meio de uma sucessão de projetos, fornecer primeiro uma versão viável de um produto e depois versões publicáveis sucessivas (“release” em inglês).
Cada projeto tem um ciclo de vida em quatro fases, cada uma subdividida em várias iterações:
O processo unificado defende uma abordagem orientada a riscos, buscando por meio de várias iterações resolver as maiores incertezas como uma prioridade.
O processo unificado oferece as seguintes sequências de trabalho, que podem ser configuradas de acordo com as necessidades do projeto:
O termo "disciplina" também é usado para designar sequências genéricas.
Ao contrário do modelo em cascata, que define fases distintas para cada uma dessas sequências de atividades, o processo unificado integra essas atividades por meio de diferentes iterações e fases do projeto. O processo unificado foi projetado para lidar com sistemas complexos baseados em componentes. Portanto, encontramos ideias do ciclo V , como uma visão arquitetônica baseada em componentes, a integração do sistema e os diferentes níveis de validação, mas sem a restrição de organizá-los em estágios sequenciais.
O processo unificado também define funções para os atores envolvidos nessas atividades (por exemplo, arquiteto, engenheiro de componentes, designer de interface de usuário, etc.). No entanto, os autores enfatizam que esses são papéis e não pessoas; o mesmo membro da equipe pode, portanto, combinar várias funções. O processo unificado finalmente define uma série de artefatos, ou seja , as entregas do projeto.
O processo unificado exige um planejamento iterativo no qual “o plano precede a ação”.
O princípio é que um plano geral determina de acordo com a complexidade do projeto as iterações necessárias para cada fase e posiciona as fases no tempo. Este plano geral não inclui detalhes por iteração. As iterações são planejadas gradualmente à medida que o projeto avança. A iteração atual é planejada detalhadamente quando é iniciada, com um cronograma e um objetivo de conteúdo (caso de uso a ser processado, mudanças a serem feitas nas entregas de iterações anteriores, componentes a serem executados, etc.). O plano para a próxima iteração é preparado quando os elementos são conhecidos. Portanto, é primeiro estimado em linhas gerais e, em seguida, refinado de acordo com as informações descobertas durante a iteração atual.
No caso particular da fase de criação, o esboço do projeto é geralmente muito incerto para permitir um planejamento realista. O plano para a primeira iteração desta fase deve, portanto, ser visto como uma tentativa de plano que deve ser ajustado, se necessário. No final desta fase, é estabelecida a viabilidade do desenvolvimento e pode ser elaborado o plano global correspondente à visão do projeto.
O controle de caso de uso usa os diagramas de caso de uso ( DCU ) suplementados por descrições textuais. A partir das DCUs, são derivados os modelos de análise, design, implantação, implementação e teste. Destes modelos emerge a arquitetura do sistema. Uma abordagem sistemática também é proposta para deduzir casos de uso das classes de análise e design de acordo com o esquema de controle de fronteira de entidades . São também os casos de uso que permitirão o desenvolvimento dos cenários de teste, já que o novo software deverá possibilitar o cumprimento dos casos de uso planejados. As DCUs são, assim, os modelos que garantem a coerência do processo de desenvolvimento ao servir de fio condutor para todas as atividades.
As atividades de modelagem são baseadas em UML . Esta linguagem de modelagem cobre aspectos estruturais e dinâmicos da arquitetura e design de software. Facilita a modelagem de componentes usando uma abordagem orientada a objetos . Os criadores da UML também estão na origem do processo unificado, que deveria complementar a UML com uma abordagem de desenvolvimento completa e genérica .
A arquitetura do sistema é projetada desde o início de uma forma muito pragmática : adapta-se ao contexto de trabalho, às necessidades do utilizador, às possibilidades de reutilização ( reutilização ) de bibliotecas ou “tijolos” pré-existentes. O desenvolvimento da arquitetura é, em primeiro lugar, bruto e independente dos casos de uso (no entanto, garantiremos que isso não impeça sua realização), então, um subconjunto de funções essenciais é identificado e a arquitetura é repetida e detalhada de acordo com esse conjunto. Da especificação à precisão do caso , a arquitetura evolui, eventualmente incluindo novos casos, e assim por diante, até que a arquitetura alcance um nível de desenvolvimento alto e estável o suficiente para dar origem ao desenvolvimento de um protótipo que será apresentado ao cliente completando assim uma iteração.
Uma iteração é uma sucessão de sequências de atividades. Um incremento é um avanço nos estágios de desenvolvimento. A cada iteração encontramos as atividades de especificação de necessidades, design, até a prototipagem executável. Uma nova iteração, por exemplo, após demonstrar o protótipo aos usuários, retomará a especificação esclarecendo ou corrigindo-a e, em seguida, retomando o desenvolvimento, etc.
Os incrementos são definidos pelo projeto e cada incremento adicionará uma nova funcionalidade. Os incrementos podem seguir diferentes casos de uso, por exemplo. A dificuldade residirá no fato de, em última instância, combinar os subprojetos ou incrementos e respeitar suas interdependências e a consistência geral do produto previsto. É, portanto, também um desenvolvimento na forma de componentes que é proposto. Ele fará o melhor uso das contribuições das tecnologias de objetos.
PU integra os dois objetivos a fim de minimizar os riscos de má interpretação em relação às necessidades, bem como o risco de desenvolvimentos infinitos, indefinidos, mal definidos ou inacabados: Aqui o usuário pode corrigir-se, nos protótipos, a direção tomada por desenvolvimento . Desde o início, resultados tangíveis são obtidos, mesmo que sejam apenas prototípicos. Algumas implementações de PU consideram os protótipos como versões completas do sistema final. As funções subordinadas podem muito bem, em tal perspectiva, ser abandonadas ao longo do caminho por questões de custos ou prazos, por exemplo . Finalmente, se o usuário precisa de mudanças durante o desenvolvimento, essa evolução pode ser, até certo ponto, integrada. Este não é o caso do desenvolvimento sequencial.
PU organiza o ciclo de vida agrupando as iterações (especificações, análise, design, implementação e teste) em fases. Essas fases são iniciais (criação), intermediárias (desenvolvimento, construção) ou finais (transição para o usuário ou colocação em produção). Estas fases eliminam a produção do produto como uma sucessão temporal (sequências), mas incluem todas as tarefas estruturantes do projeto (refinamento sucessivo, iterações) e propõem uma organização matricial do volume total de atividade prevista: é óbvio que no fase de criação, mais tempo será dedicado à análise das necessidades do que ao teste; inversamente, na fase de transição, os testes ainda estão em andamento enquanto a análise das necessidades e seu refinamento foram teoricamente concluídos desde a fase de construção.
O processo unificado é configurável e, portanto, pode ser adaptado às especificidades dos projetos e organizações em que é empregado. Existem, portanto, muitas especializações do método geral. Várias outras variantes fundamentais também surgiram e experimentaram uma distribuição mais ampla.
Nomes comuns e abreviações são:
| Acrônimo | Denominação | Primeira versão | Autor (es) | Particularidades |
|---|---|---|---|---|
| PODERIA | Processo Unificado | 1999 | Ivar Jacobson , Grady Booch e James Rumbaugh | preceitos gerais do método |
| PRA CIMA | Processo Unificado | 1999 | (ver PU) | Nome em inglês de PU |
| USDP | Processo de desenvolvimento de software unificado | 1999 | (ver PU) | outro nome em inglês para PU, após o título do livro que publicou o método |
| OU | Processo Racional Unificado | 1998 | Rational Software (IBM), equipe RUP sob a direção de Philippe Kruchten | Método proprietário da Rational Software (IBM) no qual o PU foi baseado |
| EUP | Processo Corporativo Unificado | 2000 | Scott Ambler e Larry Constantine | integra as fases e atividades de pós-implementação para cobrir o ciclo de vida do software em produção até que seja retirado da produção; o nome é uma marca comercial. |
| XUP | eXtreme Unified Process | híbrido integrando UP com programação extrema . | ||
| PRINCIPAL | Processo Agile Unificado | 2005 | Scott Ambler | híbrido combinando um subconjunto de UP com preceitos de métodos ágeis - distribuído como um site que documenta o método, mas não é mantido desde 2006 |
| 2TUP | Processo unificado de duas trilhas | Valtech | provavelmente levará em consideração os caprichos e restrições vinculadas às mudanças perpétuas e rápidas de SI das empresas | |
| EssUP | Processo Unificado Essencial | 2006 | Ivar jacobson | alternativa enxuta de UP integrando preceitos ágeis e disseminada por sua empresa Ivar Jacobson Consultoria. O EssUP é constituído por um conjunto de práticas ditas "essenciais", que podem ser livremente selecionadas e combinadas, oferecendo assim uma grande flexibilidade na sua aplicação. |
O Rational Unified Process (RUP) é a origem do processo unificado e, como tal, é a implementação mais conhecida. É um produto e marca comercial da Rational Software, que entretanto foi adquirida pela IBM. O método é entregue chave na mão e vem acompanhado de ferramentas para orientar as equipes na adaptação e execução do processo.
O framework de desenvolvimento de software proposto pelo RUP responde às características do processo unificado: é um método de desenvolvimento guiado pelas necessidades do usuário, centrado na arquitetura de software, iterativo e incremental, implementando UML para modelagem.
O RUP estende as cadeias de atividades para abranger também
O Agile Unified Process (AUP) é uma variante simplificada do UP que incorpora práticas ágeis como o desenvolvimento orientado a testes (TDD). Assim, assume as fases sequenciais e os marcos de final de fase do processo unificado, mas fortalece a abordagem ágil ao recomendar uma atualização do plano no final de cada fase, a implementação de uma versão potencialmente publicável no final de cada fase. fim de cada iteração, e a aplicação dos princípios do manifesto ágil . Portanto, o uso de modelos como um artefato de documentação é limitado ao modelo de requisitos e ao modelo de design. AUP enriquece a modelagem de requisitos com modelos de negócios. O método ainda recomenda concentrar a modelagem nos contornos e evitar detalhes que poderiam ser facilmente deduzidos do código. AUP está disponível gratuitamente online como um arquivo compactado, mas não é mantida desde 2006.
O Essential Unified Process (EssUP) busca tornar mais leve o processo unificado que, embora iterativo e incremental, é frequentemente percebido como muito complicado e formalizado. EssUP adota o princípio de separação de interesses para isso . Em vez de um processo monolítico, o EssUP define um conjunto de práticas independentes que podem ser combinadas livremente para formar um processo apropriado ao contexto.
As práticas identificadas pelo EssUP são agrupadas em 8 famílias de assuntos: equipe, produto, ciclo de vida, iterações, casos de uso 2.0, arquitetura, componentes e execução de teste. O EssUP está disponível online.
O processo unificado usa fases sequenciais como projetos em cascata . No entanto, as fases não são estruturadas artificialmente de acordo com as disciplinas técnicas, mas respondem a uma lógica de redução gradual de risco, cada fase integrando todas as disciplinas em graus variados. Além disso, o processo unificado defende um planejamento iterativo e adaptativo, em vez de um planejamento rígido e detalhado anterior.
O processo unificado tem semelhanças com o ciclo V porque se concentra na arquitetura de sistemas feitos de componentes e distingue entre teste de unidade, teste de integração e teste de sistema. No entanto, as fases do PU não são estruturadas por nível arquitetônico e por disciplina, mas respondem a uma lógica de maturação iterativa. Além disso, o PU integra atividades de verificação e validação em cada fase.
O processo unificado se aproxima dos métodos ágeis na medida em que preconiza uma abordagem iterativa e incremental, focada nas necessidades do usuário. No entanto, difere dos métodos ágeis pela coleta proativa da maioria dos requisitos durante as primeiras iterações de um projeto e pela definição de uma arquitetura upstream antes da produção de versões publicáveis (" lançamento " em inglês). Ele também centra a abordagem em modelos, enquanto os métodos ágeis favorecem a produção de código em vez da produção de documentação. Esta última diferença deve, entretanto, ser colocada em perspectiva porque alguns agilistas também defendem uma abordagem baseada em modelagem. Esses métodos ágeis compartilham com o UP a visão de modelagem incremental onde os diferentes modelos (requisitos, análise, design) são refinados em paralelo durante cada iteração, ao invés de sequencialmente, fase por fase.
O processo unificado faz uso intenso de modelos UML . Articula os diferentes tipos de diagramas com as diferentes finalidades de modelagem (análise, desenho, teste). Assim, enriquece a UML, que é uma linguagem de modelagem genérica, com uma abordagem sistemática, mas específica para um método de desenvolvimento específico.
O processo unificado combina as vantagens de várias abordagens e, em particular, uma abordagem estruturada em fases com grande flexibilidade nas iterações.
A principal crítica é que a descrição detalhada das sequências de atividades e dos artefatos confere ao PU um certo peso e, portanto, requer uma alta qualificação dos membros da equipe do projeto (em particular: domínio de abordagens iterativas, conhecimento profundo de UML , conhecimento das sequências de atividades e suas interdependências).
O processo unificado também deixa uma grande margem de manobra para adaptar as atividades às especificidades de uma empresa. Esta flexibilidade, aliada à complexidade do processo e uma grande liberdade de interpretação, pode dar origem a implementações muito rígidas do PU, embora tenha em princípio as características de um método ágil.
Muitas vezes, a adoção do PU por uma organização decorre do desejo de disciplinar as práticas de desenvolvimento com o uso de ferramentas específicas e o monitoramento de regras de conduta estabelecidas e homogêneas . O processo de desenvolvimento de software é então ele próprio objeto de uma reengenharia de processos (“BPR”) com vista à otimização das atividades dos departamentos de TI. O desenvolvimento ágil, ao contrário, preconiza a escolha das ferramentas mais simples e o uso suave ou “tipo caixa de ferramentas” dos modelos da linguagem ou das fases do método. Portanto, há um paradoxo em querer enrijecer codificando práticas que são, por natureza, destinadas à flexibilidade.
De acordo com Scott Ambler, alguns fundamentos do PU não podem coexistir com os preceitos da agilidade: a preeminência e o papel condutor dos diagramas de caso de uso devem ser abandonados . Na verdade, se eles permitem documentar corretamente o comportamento do software, eles não podem ser usados para gerenciar todas as atividades do projeto: as restrições, as interfaces de usuário e sua cinemática, as regras de negócio que o software terá que respeitar não podem ser deduzido. casos de uso. A PU também está adicionando um conjunto de “especificações adicionais” para compensar essa falta. Assim, ainda segundo Ambler, se a análise de necessidades pode conduzir o projeto, os casos de uso não podem e só podem constituir uma retórica de marketing específica para instanciações como RUP ou EUP .
Muitas variantes mais leves do processo unificado surgiram para aliviar o peso inicial de sua descrição. Diversas variantes do ágil também surgiram, buscando fortalecer o caráter iterativo, tornar a documentação mais leve ou facilitar a integração no processo de determinadas práticas ágeis.
Os desenvolvimentos mais recentes, e em particular o EssUP, visam transformar o processo unificado em uma “caixa de ferramentas”. O princípio é identificar e definir os componentes do processo, por exemplo, sua divisão em fases, suas técnicas de pilotagem iterativa e certas técnicas de modelagem, para torná-los independentes e reutilizáveis e permitir que as equipes de projeto selecionem e combinem aqueles que são relevantes. para o contexto.