introdução ao RUP

Data de postagem: 12/02/2020 23:18:58

RUP: framework metodológico para organização do processo (de produção) de software

• Aplica princípios do processo unificado baseado do modelo de processo espiral

• Processo adaptável, permitindo ajustes para domínios e aspectos específicos como:

– Software de tempo real

– Teste de software

– Maturidade de processos

– Manutenção de software legado

O RUP captura e descreve abordagens reconhecidamente efetivas pela comunidade de engenharia de software:

– Meta Fundamental da Engenharia de Software:

• Desenvolver e adotar métodos, técnicas, ferramentas e processos para produzir software com prazo, custo e qualidade previsíveis

O RUP estimula adoção de uma abordagem disciplinada (fluxos ou disciplinas) na atribuição e gerenciamento de papéis e tarefas em uma organização que desenvolve software;

O RUP é bastante reconhecido e utilizando por organizações que desenvolvem software no mundo inteiro possibilitando:

- desenvolver software iterativamente;

– gerenciar requisitos;

– usar arquiteturas baseadas em componentes;

– modelar visualmente o software;

– verificação contínua da qualidade;

–controle de mudanças;

– Desenvolvimento baseado em casos de uso;

– Processo configurável;

– Suporte a ferramentas (tool mentors);

Termos mais usados:

• Role (Papel)

• Artifact (Artefato) ou WorkProduct

• Activity (Atividade)

• WorkflowDetail (Detalhe de Fluxo)

• Workflow (Fluxo)

• Discipline (Disciplina)

• Phases (Fases) e Iterations (Iterações)

Papel ou Role ou ProcessRole

• Anteriormente chamado de “Worker”;

• Conjunto de atividades coerentemente desempenhadas por uma pessoa (recurso), atuando em um time de pessoas com múltiplas competências;

• Um recurso (pessoa) pode desempenhar muitos papéis, conforme suas habilidades individuais;

• Papéis são agregados em 5 conjuntos chamados de RoleSets: Analistas, Desenvolvedores, Testadores, Gerentes e Outros.

Papéis:

• Analistas

– System Analyst

– Business Designer

– Business-Model Reviewer

– Business-Process Analyst

• Desenvolvedores

– Capsule Designer

– Code Reviewer

– Database Designer

– Implementer

– Integrator

– Software Architect

– Architecture Reviewer

– Design Reviewer

• Gerentes

– Process Engineer

– Project Manager

– Change Control Manager

– Configuration Manager

– Deployment Manager

– Project Reviewer

– Test Manager

• Outros

Artefato ou Artifact ou WorkProduct

• Resulta de uma atividade executada por um recurso, desempenhando um papel;

• É qualquer coisa produzida, consumida ou modificada por um processo;

• Pode ser uma peça de informação, um documento, um modelo UML, um código fonte, etc.

Atividade Ou Activity

• Unidade de trabalho a ser realizada por um recurso desempenhando um papel, produzindo resultados tangíveis para um projeto, normalmente representados por artefatos;

• Atividades utilizam um ou mais artefatos previamente existentes;

• Atividades em geral criam, atualizam ou refinam um ou mais artefatos.

• Atividades são compostas por uma seqüência de passos a executar;

• Passos para realização de uma atividade são organizados em três categorias: planejamento, execução e revisão.

Exemplos de Atividades:

• Papel: Analista de Sistemas

– Elicitar necessidades de stakeholders

– Capturar vocabulário

– Desenvolver Plano de Gestão de Requisitos

– Desenvolver guias de construção de casos de uso

– Encontrar atores e casos de uso

– Desenvolver Visão

– Gerenciar (rastrear) dependências

– Estruturar modelo de casos de uso

• Papel : Implementador :

– Implementar componentes

– Implementar teste de componentes e subsistemas

– Executar testes unitários

– Corrigir defeitos

– Desenvolver artefatos de instalação

Detalhe De Workflow (fluxo de trabalho ou fluxo de atividades):

• Conjunto de atividades, artefatos e papéis realizadas de forma interdependente por um indivíduo ou pequeno grupo ;

• Cria um foco local (individual) de execução de atividades que produz resultados tangíveis e mensuráveis ;

• Orienta na gestão individual das atividades.

• Fluxo macroscópico de controle de execução das atividades de uma disciplina ;

• Controle descrito na forma de diagrama de atividades, que agrega vários Detalhes de Workflow;

• Orienta na gestão grupal das atividades.

Disciplina ou Domínio

• Particiona atividades, artefatos e papéis em um tema ou subárea comum;

• Disciplinas de Engenharia:

– Business Modeling

– Requirements

– Analysis & Design

– Implementation

– Test

– Deployment

• Disciplinas de Suporte:

– Environment

– Project Management

– Configuration & Change Management

Outros Elementos do Processo

• Guia de Trabalho – Orienta sobre como desempenhar uma atividade;

• Guia de Artefato – Descreve como construir um artefato;

• Guia de Ferramenta (Tool Mentor) – Descreve como usar uma ferramenta para construir um artefato.

• Checkpoints – Auxiliar na verificação da qualidade de um artefato;

• Template – Protótipos ou modelos de artefatos;

• Report – Informação extraída automaticamente de alguns artefatos.

Estágios, Fases E Iterações

• 2 Estágios: engenharia e produção;

• 4 Fases: concepção, elaboração, construção e transição;

• Várias iterações em cada fase – Viabilidade – Arquitetura – Uso – “Release”.

Estágios do Ciclo de Vida

• Engenharia

– Demonstrar a viabilidade econômica-técnica do produto (software);

– Inovação e Propriedade intelectual

– Criar uma arquitetura que facilite a produção

• Produção

– Realizar o produto

– Processo de manufatura, onde se busca a melhor qualidade, no menor tempo e com o consumo de recursos

– Propriedade Industrial

Metas de Cada Fase

• Concepção

– Obter uma visão do produto acabado, e concordância acerca dos objetivos e resultados finais do projeto

– Marco de conclusão: definição dos objetivos do ciclo de vida (lifecycle objective milestone)

• Elaboração

– Obter uma arquitetura viável, através da especificação de todas as características do produto, com concepção e validação de uma arquitetura que às atenda

– Marco de conclusão : arquitetura do ciclo de vida (lifecycle architecture milestone)

• Construção

– Construir o produto, evoluindo sua visão, arquitetura, até que esteja pronto para release

– Marco de conclusão: capacidade operacional inicial (initial operational capability)

• Transição

– Concluir a entrega do produto para clientes e usuários até plena satisfação dos objetivos e resultados estabelecidos, incluindo atividades de (entrega, treinamento, suporte e manutenção)

– Marco de conclusão: release do produto.

Detalhes da Fase de Concepção

• Meta

– Obter uma visão do produto acabado, e concordância acerca dos objetivos e resultados finais do projeto.

• Objetivos

– Estabelecer o escopo do projeto de software

– Estabelecer condições de contorno, incluindo documento de conceitos de operações, critérios de aceitação, descrição do escopo positivo e negativo

– Descrever casos de uso críticos, que irão direcionar as linhas mestras do sistema

– Exibir ou demonstrar uma arquitetura candidata, validada com alguns cenários confrontados

– Estimativa de custo global e cronograma do projeto

– Prover estimativas detalhadas da fase de elaboração

– Estimar riscos

• Atividades

– Formular escopo do projeto, de modo a permitir especificação de critérios objetivos de sucesso

– de projeto, riscos, recursos necessários e data de realização das principais etapas

– Delimitar o escopo do projeto

– Identificar os atores que interagem com o sistema

– Identificar as interações dos atores com o sistema (casos de uso)

• Artefatos produzidos

– Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto

– Modelo inicial de casos de uso (10%-20%)

– Glossário do projeto (opcionalmente um modelo de domínio)

– Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso, projeção de ROI (retorno sobre investimentos) e prognóstico financeiro

– Avaliação inicial de riscos

– Plano de projeto, com fases e interações

– Modelo de negócios, se necessário

– Um ou vários protótipos

• Marco de conclusão

– definição dos objetivos do ciclo de vida (lifecycle objective milestone)

– Critérios de Satisfação

• Concordância quanto à definição de escopo e estimativas de custo e cronograma

• Compreensão dos requisitos funcionais

• Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento

• Profundidade e amplitude dos protótipos desenvolvidos

• Custos planejados versus realizados

Detalhes da Fase de Elaboração

• Objetivos

– Definir, validar e criar uma linha de base para a arquitetura

– Criar uma linha de base para o documento de visão

– Criar uma linha de base para o plano de execução da fase de construção, com alto grau de fidelidade

– Demonstrar que a arquitetura da linha de base suportará a visão de linha de base, dentro de custo e prazo razoáveis.

• Atividades

– Refinar a visão, até que o entendimento pleno dos casos de uso críticos

– Montar a estrutura de suporte para o desenvolvimento

– Construir protótipos executáveis, em uma ou mais interações

– Atacar os casos de uso críticos, que expõe os maiores riscos técnicos

– Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários.

• Resultados (artefatos)

– Modelo de casos de uso (80% ou mais)

– Requisitos não funcionais

– Descrição da arquitetura do software

– Protótipos arquiteturais executáveis

– Revisão da visão de negócios e lista de riscos

– Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação

– Plano de processo de desenvolvimento

– Manual de usuário preliminar

• Marco de conclusão

– arquitetura do ciclo de vida (lifecycle architecture milestone)

– Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto)

• A visão do produto é estável?

• A arquitetura é estável frente os requisitos?

• A demonstração executável mostrou que os elementos de maior risco foram abordados satisfatoriamente?

• O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e coerente?

• Todos os interessados concordam quando à coerência entre visão, plano e arquitetura?

• Os custos planejados e executados estão aceitáveis?

Fase de Construção

• Meta

– Construir o produto, evoluindo sua visão, arquitetura, até que esteja pronto para release

• Objetivos

– Minimizar custos e prazo, enquanto maximiza qualidade

– Concluir desenvolvimento e testes dos componentes

– Validar produto com relação aos requisitos.

• Resultados (artefatos)

– A release do produto, descrito e integrado nas plataformas adequadas

– Manual do usuário

• Marco de conclusão: capacidade operacional inicial (initial operational capability)

– Critérios de Satisfação:

• A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário?

• Todos os envolvidos estão preparados para a fase de transição?

• O consumo de recursos executado e planejado é ainda aceitável?

Fase de Transição

• Meta

– Concluir a entrega do produto para clientes e usuários até plena satisfação dos objetivos e resultados estabelecidos, incluindo atividades de (entrega, treinamento, suporte e manutenção).

• Objetivos

– Permitir que o usuário possa usar o produto independentemente

– Obter concordância de todos os envolvidos acerca do alcance das metas do ciclo de vida

– Obter um release final do produto da forma mais custo-efetiva possível.

• Atividades

– Correção de defeitos

– “beta teste”

– Operações paralelas com sistema legado

– Conversão de bases de dados

– Treinamento de usuários a mantenedores

– Roll-out para setores de marketing, distribuição e vendas.

• Resultados (artefatos)