RUP: A Importância dos Marcos
Seguindo a linha do post anterior, vou descrever pra vocês um pouco mais dos marcos do RUP bem como o propósito e como eles podem ajudar em termos de gerência de projetos e colaboração entre a equipe.
Ciclo de Vida
O processo tem basicamente 4 marcos no seu ciclo de vida são elas: Iniciação, Elaboração, Construção e Transição, no RUP corporativo criado pelo Scott Ambler ele adiciona mais dois marcos que são: produção e desligamento. Dentro de uma empresa que mantém o produto de software por anos realizando ajustes referentes a Change Requests e mudanças de legislação e tudo mais o ciclo de vida do EUP(RUP Corporativo) é o ideal. Muitas empresas não utilizam esse tipo de cliclo de vida, algum tratam o 'fato' do sistema estar em produção como 'operação/manutenção' e acabam endereçando os problemas dessa fase com diversos problemas. Mas como o objetivo desse post não é falar de EUP (Fica para outro post) vamos voltar ao RUP.
Na figura a cima você pode perceber as fases do RUP através do tempo. Esse gráfico ilustra o consumo de recursos também. É claro que a fase de construção requer mais recursos (ex: pessoas) do que a fase de iniciação.
O pico ocorre na construção e a medida que o software vai indo para a transição o número de recursos envolvidos no projeto vai diminuindo. Mesmo não utilizando RUP muitas metodologias seguem essa linha de pensamento.
Na figura a cima você pode observar que alem das fases podemos ver os famosos marcos. Esses marcos são uteis tanto no sentido de localização mas também pode ajudar a guiar o gerenciamento do projeto baseando-se em riscos.
Fases e Marcos
Iniciação: Como o próprio nome da fase já diz, é a fase que dá o start no projeto. Nos podemos ter várias iteração de iniciação. Mas o normal é realizar uma iteração de iniciação e depois realizar iteração de elaboração.
O foco da fase é estabeler uma visão concreta e concisa entre o stakeholders do projeto sobre o próposito e foco do projeto. O esforço maior dessa fase é em realizar uma análise de negócio em alto nível atacando em torno de 75% do requisitos do projeto. Nesse ponto poderiamos realizar casos de uso no estilo 'Essensial' como propoe o Scott Ambler.
Nota: Não é o objetivo realizar especificação detalhadas. Caso essa fase se delongue muito isso pode ser um sinal de uma fenomeno chamado 'BIG Epecs. Up to Front' que é um Anti-Pattern definido pelo processo. Isso é um requisio do modelo em cascata e deve ser evitado.
A fase de iniciação é fundamental para que a priorizações futuras aconteção de maneira efetiva.
Marco da visão de Negócios(Marco da fase de Iniciação)
No final da fase de Iniciação devemos nos perguntar se:
É importante frisar que código pode ser gerado, mas não muito mas é gerado uma parte pequena do produto final do software. Esse código pode ser um draft da arquitetura final ao invés de um mero prototipo descartável. Estou dizendo isso por que novamente temos que tomar cuidado para não cascatear o processo. :)
Elaboração
O Objetivo maior dessa fase é "estabilizar" a arquitetura do projeto com base nos requisitos levantados na fase de Iniciação. Vejá isso não siginifica desenvolver toda a arquitetura, mas sim desenvolver uma base sólida o suficiente para suportar o desenvolvimento que irá iniciar na fase de Construção. É comun que existam várias iterações nessa fase.
A Fase não é esclusiva de desenvolvimento de arquitetura, assim deve haver desenvolvimento de casos de uso do produto final. Nessa fase acontece também o detalhamento dos requisitos levantados na fase de Iniciação.
Em um determinado momento da Elaboração é possivel realizar estimativas com uma prescisão maior. Nesse ponto podemos utilizar tecnicas como Pontos de Função ou Use Case Points. O problema de ambas é que precisamos de uma base histórica para poder estimar com mais precisão. Essa estimativa não é final e deve ser ajustada de acordo com o andamento do projeto.
A figura a cima ilustra o famoso cone de incertezas. Muitos autores falam dele como por ex o Larman. Ele funciona da sequinte forma: No inicio do projeto existem muitas incertezas, o escopo não está definido, os requisitos estão muito nebulos a arquitetura não foi concebida ainda. Em vista dessas váriaveis é extremamente dfícil realizar uma estimativa no momento inicial que funcione. Por isso a ideia é que as estimativas sejam feitas mais adiante, após algumas iteração, assim é possivel estimar com mais precisão.
A Ideia é que a maioria dos requisitos 'estabilize' eu não disse 'congele' nessa fase. Para que o mesmo aconteça o RUP prega que devemos realizar workshops de requisitos com pelo menos 20% do requisitos que são criticos do ponto de vista de Riscos e Arquitetura.
Marco da Arquitetura (Marco da fase de Elaboração)
Quando chegarmos a esse momento devemos nos fazer as seguintes perguntas:
Construção
O foco da fáse é na modelagem de negócio tanto em termos de análise e desenho de solução e claro muita construção. Como dito antes o desenvolvimento já ocorria nas duas fases anteriores nesse momento que o desenvolvimento desponta de vez ele ocorre com mais força. As atividades de Arquitetura e Análise ainda continuam porem sobre um conjunto diferente de requisitos e muitas vezes aplicando refinamentos.
Nota: Diferente do que muitos pensam o RUP não é contra a mudança de requisitos. Ele é a favor do gerênciamento de mudanças. Então é perfeitamente possível que o requisitos mudem, porem eles irão mudar em uma escala menor agora.
Nessa fase os testes também são intensificados. Você pode obtar por uma abordagem TDD. Claro que testes também ocorreram nas fases anteriores porem agora a intensidade aumenta. Outra abordagem que me agrada muito seria não utilizar o TDD e utilizar o DBC no seu lugar. Por que as 'validações' ficam permanentemente no código e continuam sendo checadas em tempo de runtime.
Marco de Capacidade Operacional (Marco da fase de Construção)
Quando chegamos aqui podemos nos perguntar se:
Transição
O foco da fase é garantir que o software vai estar disponivel para os usuáriso fináis. É comum essa fase atravesar diversas iterações. Pois pode ser necessário realizar treinamentos, migrações de dados de sistemas legados e algum ajuste final. Nesse momento o foco fica em gerência de configuração, pois estamos preucupados com configurações e detalhes do release final.
Marco da Liberação do produto (Marco da fase de Transição)
Esse é o marco mais importante do projeto! Aqui verificamos se os objetivos foram atentidos, ou sejá, os requisitos foram atendidos? Nesse momento colhemos os resultados da revisão/feedback do usuário quanto ao produto de software.
Quando chegamos aqui devemos verificar se o usuário está satisfeito e se atendemos os custos, ou sejá, previsto VS Realizado. Os artefatos produsidos são o próprio produto através de um build e materiais de suporte para o usuário.
Caso o usuário não esteja satisfeito é possivel que essa fase dispare um ciclo novo de desenvolvimento. É possivel existir tarefas de requisitos, design, construção e testes nessa fase, mas espera-se que em escala muito pequena. Nesse ponto começa a gestão de ambientes, servidores de aplicação e banco de dados.
Bom pessoal por hoje é só; Em um proximo post falarei sobre os papéis e as disciplinas do RUP bem como mais práticas.
Ciclo de Vida
O processo tem basicamente 4 marcos no seu ciclo de vida são elas: Iniciação, Elaboração, Construção e Transição, no RUP corporativo criado pelo Scott Ambler ele adiciona mais dois marcos que são: produção e desligamento. Dentro de uma empresa que mantém o produto de software por anos realizando ajustes referentes a Change Requests e mudanças de legislação e tudo mais o ciclo de vida do EUP(RUP Corporativo) é o ideal. Muitas empresas não utilizam esse tipo de cliclo de vida, algum tratam o 'fato' do sistema estar em produção como 'operação/manutenção' e acabam endereçando os problemas dessa fase com diversos problemas. Mas como o objetivo desse post não é falar de EUP (Fica para outro post) vamos voltar ao RUP.
O pico ocorre na construção e a medida que o software vai indo para a transição o número de recursos envolvidos no projeto vai diminuindo. Mesmo não utilizando RUP muitas metodologias seguem essa linha de pensamento.
Fases e Marcos
Iniciação: Como o próprio nome da fase já diz, é a fase que dá o start no projeto. Nos podemos ter várias iteração de iniciação. Mas o normal é realizar uma iteração de iniciação e depois realizar iteração de elaboração.
O foco da fase é estabeler uma visão concreta e concisa entre o stakeholders do projeto sobre o próposito e foco do projeto. O esforço maior dessa fase é em realizar uma análise de negócio em alto nível atacando em torno de 75% do requisitos do projeto. Nesse ponto poderiamos realizar casos de uso no estilo 'Essensial' como propoe o Scott Ambler.
Nota: Não é o objetivo realizar especificação detalhadas. Caso essa fase se delongue muito isso pode ser um sinal de uma fenomeno chamado 'BIG Epecs. Up to Front' que é um Anti-Pattern definido pelo processo. Isso é um requisio do modelo em cascata e deve ser evitado.
A fase de iniciação é fundamental para que a priorizações futuras aconteção de maneira efetiva.
Marco da visão de Negócios(Marco da fase de Iniciação)
No final da fase de Iniciação devemos nos perguntar se:
- A avaliação dos requisitos em alto nível foi concluida e documentada?
- Existe um acordo com os Stakeholders obre o foco e requisitos do projeto?
- Ocorreu o 'aceite' dos requisitos pelo usuário?
É importante frisar que código pode ser gerado, mas não muito mas é gerado uma parte pequena do produto final do software. Esse código pode ser um draft da arquitetura final ao invés de um mero prototipo descartável. Estou dizendo isso por que novamente temos que tomar cuidado para não cascatear o processo. :)
Elaboração
O Objetivo maior dessa fase é "estabilizar" a arquitetura do projeto com base nos requisitos levantados na fase de Iniciação. Vejá isso não siginifica desenvolver toda a arquitetura, mas sim desenvolver uma base sólida o suficiente para suportar o desenvolvimento que irá iniciar na fase de Construção. É comun que existam várias iterações nessa fase.
A Fase não é esclusiva de desenvolvimento de arquitetura, assim deve haver desenvolvimento de casos de uso do produto final. Nessa fase acontece também o detalhamento dos requisitos levantados na fase de Iniciação.
Em um determinado momento da Elaboração é possivel realizar estimativas com uma prescisão maior. Nesse ponto podemos utilizar tecnicas como Pontos de Função ou Use Case Points. O problema de ambas é que precisamos de uma base histórica para poder estimar com mais precisão. Essa estimativa não é final e deve ser ajustada de acordo com o andamento do projeto.
A Ideia é que a maioria dos requisitos 'estabilize' eu não disse 'congele' nessa fase. Para que o mesmo aconteça o RUP prega que devemos realizar workshops de requisitos com pelo menos 20% do requisitos que são criticos do ponto de vista de Riscos e Arquitetura.
Marco da Arquitetura (Marco da fase de Elaboração)
Quando chegarmos a esse momento devemos nos fazer as seguintes perguntas:
- Os Requisitos estão estáveis e documentados?
- A Arquitetura está estável(Estável != Congelada != finalizada)?
- Os riscos foram abordados e estão sendo mitigados?
Construção
O foco da fáse é na modelagem de negócio tanto em termos de análise e desenho de solução e claro muita construção. Como dito antes o desenvolvimento já ocorria nas duas fases anteriores nesse momento que o desenvolvimento desponta de vez ele ocorre com mais força. As atividades de Arquitetura e Análise ainda continuam porem sobre um conjunto diferente de requisitos e muitas vezes aplicando refinamentos.
Nota: Diferente do que muitos pensam o RUP não é contra a mudança de requisitos. Ele é a favor do gerênciamento de mudanças. Então é perfeitamente possível que o requisitos mudem, porem eles irão mudar em uma escala menor agora.
Nessa fase os testes também são intensificados. Você pode obtar por uma abordagem TDD. Claro que testes também ocorreram nas fases anteriores porem agora a intensidade aumenta. Outra abordagem que me agrada muito seria não utilizar o TDD e utilizar o DBC no seu lugar. Por que as 'validações' ficam permanentemente no código e continuam sendo checadas em tempo de runtime.
Marco de Capacidade Operacional (Marco da fase de Construção)
Quando chegamos aqui podemos nos perguntar se:
- Os modelos de Análise e Design estão estáveis?
- Resolvemos todos os problemas de design?
- Abordamos todos os casos de uso?
- Glossário e SAD estão atualizados?
Transição
O foco da fase é garantir que o software vai estar disponivel para os usuáriso fináis. É comum essa fase atravesar diversas iterações. Pois pode ser necessário realizar treinamentos, migrações de dados de sistemas legados e algum ajuste final. Nesse momento o foco fica em gerência de configuração, pois estamos preucupados com configurações e detalhes do release final.
Marco da Liberação do produto (Marco da fase de Transição)
Esse é o marco mais importante do projeto! Aqui verificamos se os objetivos foram atentidos, ou sejá, os requisitos foram atendidos? Nesse momento colhemos os resultados da revisão/feedback do usuário quanto ao produto de software.
Quando chegamos aqui devemos verificar se o usuário está satisfeito e se atendemos os custos, ou sejá, previsto VS Realizado. Os artefatos produsidos são o próprio produto através de um build e materiais de suporte para o usuário.
Caso o usuário não esteja satisfeito é possivel que essa fase dispare um ciclo novo de desenvolvimento. É possivel existir tarefas de requisitos, design, construção e testes nessa fase, mas espera-se que em escala muito pequena. Nesse ponto começa a gestão de ambientes, servidores de aplicação e banco de dados.
Bom pessoal por hoje é só; Em um proximo post falarei sobre os papéis e as disciplinas do RUP bem como mais práticas.
