domingo, 27 de maio de 2012

RUP para Concursos Parte 4 - Fase de Iniciação e Disciplinas Modelagem de Negócio e Requisitos

As disciplinas do RUP podem ser executadas em qualquer uma das fases. A única exceção é a disciplina de implantação (deployment) que não é executada na fase de iniciação (inception).


Fase de Iniciação ou Concepção
Na fase de iniciação, a ênfase é nas disciplinas de Modelagem de Negócios e Requisitos que estão relalcionadas com definição de escopo, levantamento das necessidades e entendimento dos processos de negócio da organização. Os objetivos dessa fase e dessas disciplinas são semelhantes.

A maioria do esforço é feito na disciplina de Requisitos, mas na Iniciação você já pensa na sua arquitetura candidata para fazer uma análise de viabilidade e provas de conceito. Por isso, alguma coisa já será codificada e testada também.

A meta principal é atingir o consenso sobre os objetivos do ciclo de vida do projeto. Todos os interessados precisam chegar em um consenso. É uma fase muito importante para projetos novos, onde os riscos são desconhecidos. É preciso fazer análise de viabilidade, mapeamento de escopo e objetivos. Para Ciclos de Evolução, pode ser uma fase mais rápida e até mesmo uma fase opcional, caso a evolução seja simples.

Nessa fase você determina se continuar com o projeto compensa ou não. A análise de viabilidade não trata apenas de código, mas é preciso verificar se o projeto é financeiramente viável. Também é preciso fazer um estudo de viabilidade técnica. Quais tecnologias e arquiteturas devem ser usadas? É possível fazer o projeto nessas tecnologias?

Essas perguntas precisam ser respondidas para que a gerência possa determinar se vale a pena ou não executar o projeto.

Objetivos da Fase de Iniciação

Estabelecer o escopo do software: qual é o escopo do meu produto? Que requisitos considerar e quais deixar de fora? É determinado com o levantamento dos casos de uso.

Estimar custos: quanto vai custar o software? Isso é uma estimativa inicial. A cada iteração o custo é ajustado.

Estimar tempo : estimativa inicial de tempo. Também é ajustada a cada iteração.

Estimar riscos: identificar os casos de uso arquiteturalmente significativos (os mais críticos, complexos, arriscados e nebulosos) e principais cenários de operação do sistema.

Propor pelo menos uma opção de arquitetura para alguns cenários básicos.

Principais Artefatos da Fase de Iniciação

Documento de Visão (disciplina de Requisitos): descreve as necessidades e características mais importantes do sistema. Não é um artefato de engenharia de software. É um documento de alto nível que dá uma visão geral do sistema para o patrocinador do projeto, para servir como base para um contrato. Não possui informações técnicas ou arquiteturais. Também pode conter uma especificação de requisitos formal. Fornece informações para o processo de aprovação do projeto e, portanto, está intrinsecamente relacionado ao Caso de Negócio.

Caso de Negócio (disciplina de Gerenciamento de Projetos)
É um documento com informações do ponto de vista do negócio para determinar se vale a pena investir no projeto sobre o ponto de vista do retorno de investimento (ROI). Mostra a estimativa de custos. É este documento que vai basear a decisão do patrocinador de continuar ou não com o projeto.

Plano de Desenvolvimento do Software (disciplina de Gerenciamento de Projetos)
É como o Plano de Projeto do PMBOK e reúne as informações necessárias para o gerenciamento do projeto durante todo o ciclo do desenvolvimento.

Modelo de Caso de Uso
Descreve os requisitos funcionais de um sistema em termos de Casos de Uso e atores que interagem com os casos de uso. Determina o escopo do sistema. Contém as funções pretendidas para o sistema e serve como um contrato estabelecido entre os clientes e os desenvolvedores. O Modelo de Casos de Uso mapeia os casos de uso que existem e determina o escopo, logo, o que não está neste modelo, não deve ser feito.

O modelo de casos de uso é usado como fonte de informações essencial para atividades de análise, design e teste.

Glossário
Conjunto consistente de definições para evitar mal entendidos. Define termos importantes usados pelo projeto. Em muitos domínios, os termos não são simples e é preciso garantir que toda a equipe tenha o mesmo entendimento sobre os itens.

Disciplina Modelagem de Negócio
Entender a estrutura e a dinâmica da organização cliente ou organização-alvo, identificando oportunidades de melhoria. Trata de aspectos anteriores ao software. Antes de automatizar os processos da organização, é preciso entender o problema da organização. Sem isso, corre-se o risco de implementar um software que não resolve os problemas da empresa e não agrega valor nenhum.

Assegurar que todos os interessados tenham um entendimento comum sobre a organização.

Principais Papéis e Atividades:

Papel - Analista de Processo de Negócios
Identifica os processos na organização-alvo e descreve estes processos para entender como a organização trabalha. Depois define o que pode e deve ser melhorado. Em seguida propõe redesenho dos processos se for necessário. Ele está entendendo os processos de Negócio, não existe nada de software aqui.

Artefato Importante

Modelo de Domínio  (modelo de objetos de negócio)
Lembrando que um modelo é um agrupamento de artefatos. Inclui diagramas, especificações, entidades e etc.

É um modelo conceitual e mosta  os tipos de objetos mais importantes para o domínio. Como é um artefado da Modelagem de Negócio, que é anterior ao software, não mostra entidades do software, apenas entidades do mundo real, do negócio.

A figura acima mostra um diagrama de classes. Essas ainda são classes conceituais de entidade e controle.

Relação com outras Disciplinas

Requisitos
Utiliza o Modelo de Negócio como informação fundamental para entender os requisitos de sistema. Ou seja, os requisitos de sistema são derivados dos requisitos de negócio.

Análise e Design
Utiliza as entidades de negócio para identificar classes de entidade no projeto, que são as classes que representam a informação a ser armazenada.

Ambiente
Desenvolve e mantém artefatos de suporte como o Guia de Modelagem de Negócios, que é um padrão que mostra como executar as atividades de modelagem de negócio na organização.

Abmiente é uma disciplina que se relaciona com todas as disciplinas do RUP. É ela quem configura o RUP, estabelece guias, padrões e seleciona as ferramentas a serem utilizadas. Normalmente configura guias e padrões para as outras disciplinas.

Disciplina Requisitos
É uma das disciplinas mais importantes porque estrutura os casos de uso e o RUP é orientado a casos de uso. Estabelece o que o sistema deve fazer e define as fronteiras (escopo) do sistema, que são as funcionalidades descritas nos casos de uso.

Fornece uma base para planejar o conteúdo técnico das iteração e para estimar o custo e o tempo do desenvolvimento do sistema. Tudo isso baseado nos casos de uso.

Principais Papéis, Atividades e Artefatos:
Papel - Analista de Sistemas
É um dos papeis mais importante do RUP. Levanta os requisitos do sistema (Atores e CDU´s). Estrutura o Modelo de Casos de Uso e diagramas de casos de uso.

Papel - Especificador de Casos de Uso
O especificador é quem detalha a especificação dos casos de uso que foram elvantados pelo analista. Faz o passo a passo, detalha os fluxos e etc.

Artefatos Importante para o Marco

Glossário - Explicado acima

Modelo de Casos de Uso
Modelo das funções que são pretendidas pelo sistema. Serve como contrato entre o cliente e os desenvolvedores. Os requisitos funcionais do sistema são dispostos aqui agrupados em diagramas de casos de uso. Além disso, contém também as especificação dos casos de uso. Os requisitos não funcionais ficam em um artefato chamado Especificações Suplementares, também da disciplina de requisitos.

Documento de Visão - Explicado acima
Contém as necessidades e características mais importantes do sistema. Fornece uma base de alto nível para que o leitor possa compreender o sistema a ser desenvolvido. Não possui detalhes técnicos.

Relação com outras Disciplinas

Modelagem de Negócios
A Modelagem de Negócios fornece a entrada para a disciplina de Requisitos. Fornece as regras de negócio e um contexto organizacional para que os casos de uso sejam especificados.

Análise e Design
Usa a saída da disciplina de Requisitos como informações primárias dos requisitos para realizar os Casos de Uso. Mostra como os casos de uso se comunicam e se comportam. Pode encontrar falhas dos casos de uso.

Teste
Os Casos de Teste são gerados a partir dos casos de uso. Portanto, a saída dos requisitos é usada como entrada para validação do sistema. O que gera os objetivos do esforço de teste.

Gerenciamento de Configuração e Mudanças
Fornece o mecanismo de controle para as mudanças nos requisitos e isso se repete nas outras disciplinas. É basicamente o controle de versão dos artefatos.

Gerenciamento de Projeto
Usa o Modelo de Casos de Uso para planejar as iterações. É o Plano de Iteração.

Ambiente
Desenvolve e mantém artefatos utilizados nessa disciplina. É a mesma coisa para as outras disciplinas.

Marco da Fase de Iniciação: Objetivos do Ciclo de Vida
Marco é um resultado a ser alcançado. Um estado em que se encontra o projeto e onde alguns critérios precisam ser satisfeitos. São os critérios de avaliação da fase. É preciso responder sim a essas perguntas que estabelecem os critérios de avaliação.

Os casos de uso definem claramente o escopo? Que é o grande objetivo da fase de iniciação.

Caso necessário, foi possível fazer um protótipo da aquitetura? Se não foi possível, seu sistema pode não ser viável.

Todos os riscos foram encontrados? Se sim, foram mitigados? Os riscos precisam ser encontrados e deve existir um plano para tratar os casos de uso mais complicados.

Existe condição de se fazer o projeto? Todos os interessados, os técnicos, gerentes e usuários, precisam concluir que é possível fazer o projeto.