RUP - Processo de desenvolvimento de software

Document Sample
RUP - Processo de desenvolvimento de software Powered By Docstoc
					RUPinho
1. Objetivo do RUPinho

   O objetivo do RUPinho é a estruturação de um processo que possibilite pequenas
empresas, trabalhar de organizada do ponto de vista de planejamento, execução e
controle. Fortemente baseado no RUP, possui uma boa documentação e fases de
desenvolvimento bem delimitadas.

    Na verdade o RUPinho é uma instância do ProsCes, processo definido para a
realidade do CESAR e que já foi uma adaptação do RUP. Baseado nesse forte legado fica
evidente a boa estruturação do processo, tanto em nível de documentação, quanto das
delimitações das fases de desenvolvimento.

    Basicamente possui cinco etapas que será, posteriormente, detalhadamente explanada:

   Modelagem do Negócio
   Planejamento e Gerenciamento de Projetos
   Requisitos
   Análise e Projeto
   Implementação
   Testes
   Implantação

    Na metodologia de trabalho implantada, para cada etapa foram desenvolvidos os
seguintes conceitos relacionados: objetivos, atividades, artefatos, ferramentas e
documentos relacionados. Provendo, portanto, os recursos informacionais necessários
para o cumprimento etapa.

    Portanto, é fundamental que haja uma adequação entre as demandas de um processo
rigoroso de desenolvimento com as limitações de recursos de pequenas empresas,
modelando – assim – um processo que possa aumentar a produtividade, organizar
informações, controlar as fases e aumentar o grau de conformidade entre o que foi
acordado com o cliente e o que realmente se produziu.

2. Caracterização do ambiente do RUPinho

   O ambiente padrão das empresas pequenas é composto por uma média de 5 a 20
funcionários, menos de dois anos de atuação no mercado e pouca experiência em
processos de desenvolvimento de software.

    Nesse sentido, foi interessante a caracterização de um cenário que contemplasse uma
visão de algumas empresas pequenas, no tocante a processos de software. Uma conclusão
interessante foi que a grande maioria possui problemas com comunicação da equipe e
com o cliente, com gerência de configuração, com inadequação de documentos, com
retrabalho, com infra-estrutura inadequada, dentre outros.
    Esse cenário, desenvolvido por experiências passadas motiva o desenvolvimento
desse processo que possa se adptar as realidades e proporcionar um melhor resultados em
relação aos problemas previamente abordados.

3. Origem do RUPinho

   3.1. RUP - Rational Unified Process

       O RUP, abreviação de Rational Unified Process (ou Processo Unificado da
Rational), é um processo proprietário de Engenharia de software criado pela Rational
Software Corporation, adquirida pela IBM tornando-se uma brand na área de Software,
fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de
software com o objetivo de aumentar a sua produtividade.

       O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e
documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os
processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

       O RUP é, por si só, um produto de software. É modular e automatizado, e toda a
sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e
vendidas pela Rational através de seus "Rational Suites".

   Basicamente, no RUP, têm-se as seguintes fases:

     1. Concepção: ênfase no escopo do sistema
     2. Elaboração: ênfase na arquitetura
     3. Construção: ênfase no desenvolvimento
     4. Transição: ênfase na implantação

   O RUP também se baseia nos 4 P's:

     1. Pessoas
     2. Projeto
     3. Produto
     4. Processo

       É um processo considerado pesado e preferencialmente aplicável a grandes
   equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente
   customizável torna possível que seja adaptado para projetos de qualquer escala. Para
   a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar
   tarefas e responsabilidades dentro de uma organização de desenvolvimento de
   software.
   3.2. ProsCes – Processo do CESAR

    O ProSCes é o processo de desenvolvimento de software do CESAR, ele é fortemente
baseado no RUP - Rational Unified Process. Como sabido, o RUP foi desenvolvido para
ser aplicável a uma grande classe de projetos diferentes e pode ser considerado como um
framework genérico para processos de desenvolvimento. Isso significa que ele deve ser
configurado para se adequar à realidade da organização.

    A metodologia que embasa o ProSCES não se propõe a ser uma configuração real do
RUP, a idéia definir quais os ARTEFATOS que devem ser gerados ao longo do
desenvolvimento de software e adaptá-los à cultura do CESAR. Junto com esses
artefatos, são disponibilizados orientações (guias) e templates, porém, é essencial que
todo colaborador estude e entenda o RUP para saber realizar eficientemente as atividades
do processo e confeccionar os artefatos.

4. Características

   Para atender a proposta do RUPinho de adequação dos limites de recursos das
   empresas com a manutenção de uma documentação e atividades eficazes, três
   características são fundamentais:

   4.1. Agilidade

          Numa empresa pequena é fundamental que as informações estejam
          organizadas e disponíveis, tanto para a gerência da empresa e do projeto,
          como para os demais integrantes das equipes de projeto. A facilidade de
          acesso das informações demandas em qualquer etapa do processo é
          fundamental para que se tenha agilidade, que o RUPinho se propõe.

   4.2. Documentação reduzida

          No RUPinho encontram um reduzido número de documentos, quando
          comparado aos padrões do RUP. A metodologia utilizada para a definição dos
          documentos foi baseada numa seleção dos documentos que são
          indispensáveis, adaptação de alguns que exigiam informações em demasia,
          substituição de alguns que poderiam ter informações contempladas por um
          outro menor.

   4.3. Baixo custo

          Também para alinhar com a realidade das pequenas empresas foi arraigada na
          cultura do RUPinho o uso de ferramentas livre. Atualmente, todas as etapas de
          descritas nesses processo são contempladas com ferramentas livres de ótima
          qualidade, acompanhando – também – as necessidades de artefatos a serem
          gerados.
5. Etapas
       O processo do RUPinho está organizado em 7 etapas pré-definidas
(fluxos) procurando garantir uma adequação à realidade das pequenas
empresas segundo os critérios de motivação do processo, são elas:

        Fluxos                                   Descrição

Modelagem do           Documento que compreende o entendimento dos
Negócio                processos e negócio da organização. Esse documento
                       serve como uma espécie de acordo de concepção entre o
                       cliente e os desenvolvedores.

Planejamento e         planejar e monitorar todo o processo de desenvolvimento,
Acompanhamento do      gerenciar riscos, prover a infra-estrutura e definir artefatos
Projeto                e atividades que serão contempladas no desenvolvimento
                       do projeto

Requisitos             levantar os requisitos e definir o escopo do sistema

Análise e Projeto      transformar os requisitos num projeto para implementação
                       do sistema

Implementação          implementar as classes em termos de componentes e
                       testar as unidades.

Teste                  verificar a integração de todos os componentes do
                       software

Implantação            produzir a versão final do produto de software

      Para cada fluxo de atividade foi elaborada uma estrutura que
contemplasse todas as demandas de desenvolvimento em cada etapa do
processo:
    um resumo do objetivo do fluxo;
    as principais atividades a serem realizadas;
    os artefatos (obrigatórios e opcionais) recomendados e gerados no fluxo;
    e os templates e guias necessários para produzir esses artefatos.



6. Fluxos de desenvolvimento
   6.1. Modelagem do Negócio/Concepção
       6.1.1. Objetivos
       Essa etapa dita, opcional, necessária quando não se conhece o
contexto onde o sistema será usado ou quando se tem por objetivo mudar o
contexto trabalhado.
       Compreender a estrutura e dinâmica da organização, procurando
garantir aos clientes, usuários e desenvolvedores um conhecimento mínimo da
organização bem como os stakeholders nela influenciam, derivando assim
requisitos que possam dar suporte a organização.

     6.1.2. Atividades
    Reuniões com representantes do cliente a fim de obter um entendimento
      comum do negócio
    Identificar stakeholders
    Identificar e priorizar processos derivado do negócio

       6.1.3. Artefatos
Opcionais

Artefato                                   Descrição

Modelo de Casos de Uso do                  Documento que compreende o
Negócio/Acordo de Concepção                entendimento dos processos e negócio
                                           da organização. Esse documento serve
                                           como uma espécie de acordo de
                                           concepção entre o cliente e os
                                           desenvolvedores.

  6.2. Planejamento e Gerenciamento de Projetos
      6.2.1. Objetivos
       Prover um processo de planejamento, execução, monitoração/controle e
conclusão do projeto; estabelecer um processo de gerenciamento de riscos;
garantir conformidade com o planejado, com o mínimo possível de impacto;
estabelecer e manter o processo de desenvolvimento adequado ao projeto,
com base no processo de software organizacional.

       6.2.2. Atividades
      Definir responsabilidades, atividades e recursos necessários para o
        desenvolvimento do projeto;
      Identificar e gerenciar riscos;
      Controlar o desenvolvimento baseado no Plano do Projeto;
      Definir ferramentas e infra-estrutura necessárias
      Selecionar procedimentos e padrões a serem utilizados
      Formalizar a aceitação da entrega ao cliente de artefatos desenvolvidos
        no projeto
      Formalizar a conclusão do projeto;

       6.2.3. Artefatos
Obrigatorios
Artefato                             Descrição

Formulário de Abertura de Projetos   Formulário de formalização de início de
                                     um projeto

Plano do Projeto                     Documento com o planejamento do
                                     projeto, incluindo o processo de
                                     produção de software adotado, com
                                     suas fases, padrões e técnicas.
                                     Compreende também o planejamento
                                     de atividades, recursos alocados e
                                     teste.

Planilha de Gerência de Riscos       Compreende o plano de gerência dos
                                     riscos potenciais do projeto, incluindo
                                     análise de riscos, possíveis
                                     dependências e problemas e as ações
                                     de contingências a serem realizadas.

Relatório de Conclusão de Projetos   Relatório contendo os dados de
                                     conclusão de um projeto




      6.2.4. Ferramentas

Obrigatórias
Ferramentas                          Descrição

Planilha de Estimativa e             Planilha para cálculo de estimativas de
Acompanhamento de Custos             tamanho e esforço para
                                     desenvolvimento de software baseado
                                     na técnica de pontos por caso de uso.

Cronograma                           Modelo de cronograma para definição
                                     de prazos e tamanho da equipe para
                                     projetos de desenvolvimento de
                                     software

Lista de e-mail do projeto           Lista de e-mail contendo todos os
                                     integrantes do projeto.


Site do Projeto                      Site com todas as informações
                                              importantes do projeto: cronogramas,
                                              reuniões, equipe, artefatos gerados,
                                              referências importantes, etc. Pode ser
                                              só interno à equipe de desenvolvimento
                                              ou pode ser disponibilizado para o
                                              cliente também.

Opcionais
Ferramentas                                   Descrição

dotProject                                    Ferramenta free para gerenciamento de
                                              projetos. O uso desse tipo de
                                              ferramenta substitui a criação de um
                                              site para o projeto.



       6.2.5. Documentos relacionados

       Para facilitar a realização das atividades acima listadas, como também a
confecção dos artefatos obrigatórios, alguns documentos que servem de
referência estão abaixo listados:

Documentos Relacionados                       Descrição

Treinamento do Timesheet                      Apresenta o treinamento na nova
                                              padronização das reportagens no
                                              Timesheet

Resumo sobre a técnica de estimativa          Project Estimation with UCP: Artigo
por pontos de caso de uso                     pequeno em inglês sobre o uso da
                                              técnica de pontos por caso de uso.

Resource Estimation For Objectory             Artigo em inglês sobre o uso da técnica
Projects                                      de pontos por caso de uso.

Manual do dotProject                          Documento explicando o uso da
                                              ferramenta dotProject.



   6.3. Requisitos
       6.3.1. Objetivos

   Um dos principais objetivos desta etapa é obter uma concordância com o cliente
sobre o que o sistema “deve fazer”. Para tal, faz-se necessário um canal completamente
aberto de comunicação entre os stakeholders e os membros da equipe para evitar conflito,
inconsistência e possíveis mudanças nos requisitos. Extremamente necessário, também
nesta fase, é delimitar o escopo do sistema para que seja possível cumprir com os prazos
estimados, como também trabalhar com confiança e segurança.
    A etapa de requisitos é fundamental para o desenvolvimento de software uma vez que
as etapas seguintes do processo dependem completamente de um bom desenvolvimento
da mesma. Portanto, através das atividades realizadas e dos artefatos aqui gerados, deve-
se prover a base para o planejamento do desenvolvimento do sistema.


       6.3.2. Atividades

    Para atingir os objetivos propostos nesta etapa, é necessária a realização das seguintes
atividades:

              Reuniões com representantes do cliente a fim de obter um entendimento
               comum dos requisitos do sistema;
              Identificar atores, requisitos e/ou casos de uso;
              Especificar requisitos e/ou casos de uso;
              Modelar e implementar protótipo.


       6.3.3. Artefatos

   Os seguintes artefatos são de confecção obrigatória e servirão de suporte para o
desenvolvimento das etapas posteriores do processo:

              Documento de Requisitos: Documento que descreve o sistema de uma
               maneira geral, como também os seus requisitos funcionais e não-
               funcionais. Fornece aos desenvolvedores as informações necessárias para
               o projeto e implementação, assim como para a realização dos testes e a
               implantação do sistema.

              Documento de Caso de Uso: Documento com a descrição detalhada dos
               casos de uso para todo o sistema. A especificação de cada caso de uso
               deve conter pré-condições e pós-condições, fluxos de eventos, prioridades
               e relacionamento com outros casos de uso.


       6.3.4. Ferramentas

       Não se faz fundamental o uso de nenhuma ferramenta específica nessa etapa.


       6.3.5. Documentos relacionados
    Para facilitar a realização das atividades acima listadas, como também a
confecção dos artefatos obrigatórios, alguns documentos que servem de referência
estão abaixo listados:

          Exemplo de Documento de Requisitos: Documento de Requisitos do
           Sistema Methodology Explorer
           www.cin.ufpe.br/~mexplorer/metodologia/requisitos/documentoRequisitos.doc

          NFR Framework: Fornece uma representação sistemática e global dos
           requisitos não funcionais

          Caso de Uso: Guia do RUP para Casos de Uso

          Ator: Guia do RUP para Ator

          Modelo de Casos de Uso: Guia do RUP para Modelos de Casos de Uso

          Diagrama de Casos de Uso: Guia do RUP para Diagrama de Casos de
           Uso

          Pacote de Casos de Uso: Guia do RUP para Pacotes de Caso de Uso

6.4. Análise e Projeto
    6.4.1. Objetivos

    Durante esta fase o problema é investigado com o intuito de descobrir o que
precisa estar no sistema e estruturar como o sistema será implementado. Para tal, deve
ser feito um processo criativo, porém sistematizado. Logo, um dos principais
objetivos desta etapa é transformar os requisitos no projeto do sistema.
    É também na fase de Análise e Projeto o momento onde a arquitetura do sistema é
estruturada e definida. Durante esta fase é básico estabelecer uma arquitetura
robusta. Na definição da arquitetura e na estruturação das diversas abstrações da
solução é essencial buscar adaptar o projeto ao ambiente de implementação, ou
seja, adequar a arquitetura e o modelo estabelecido às ferramentas, técnicas,
procedimentos e metodologia de implementação.

   6.4.2. Atividades

    Para atingir os objetivos desta etapa, faz-se necessário a execução de algumas
atividades, são elas:
        Analisar e projetar sistema
        Detalhar classes e subsistemas
        Definir arquitetura do software

   6.4.3. Artefatos
Na etapa em questão devem ser gerados três artefatos essenciais para alcançar os
objetivos da mesma:

          Modelo de Análise e Projeto: Compreende as realizações dos casos de
           uso, o modelo de classes geral do sistema, a organização dos elementos em
           pacotes e subsistemas.

          Modelo de Dados: Modelo lógico e/ou físico dos dados a serem
           armazenados em um banco de dados.

          Documento da Arquitetura: Descreve a arquitetura adotada no sistema
           que deve obrigatoriamente seguir algum padrão de projeto (modelo
           cascata deve ser o default).

   6.4.4. Ferramentas

    Para definição do modelo de análise e projeto é muito importante a utilização de
uma ferramenta CASE. Não é essencial utilizar uma determinada ferramenta, mas
com o objetivo de diminuir os custos do projeto é sugerido a utilização de ferramentas
livres, como o JUDE Community ou o argoUML. Ambas são de fácil uso e permitem
uma eficiente confecção dos artefatos.
    Além de ferramentas de edição de documentos, é também importante uma
ferramenta para modelagem gráfico do banco de dados. Novamente qualquer
ferramenta disponível mostra-se funcional desde que tenha aceitação pela equipe de
modelagem. É sugerido, no entanto, o DBDesigner da fabFORCE disponível no
formato open source.

   6.4.5. Documentos relacionados

    Para facilitar a realização das atividades acima listadas, como também a
confecção dos artefatos obrigatórios, alguns documentos que servem de
referência estão abaixo listados:

          Realização de Caso de Uso: Guia do RUP para Realização de Casos de
           Uso.
          Classes de Análise: Guia do RUP para Classes de Análise.
          Projeto de Susbsistemas: Guia do RUP para Projeto de Subsistema.


6.5. Implementação

   6.5.1. Objetivos

    A partir das especificações contidas no conjunto de artefatos criados nas etapas
anteriores, a implementação consiste, inicialmente, na implementação de classes e
objetos em termos de componentes. O objetivo principal é integrar os
   componentes produzidos em um sistema executável, após a realização dos testes
   dos componentes desenvolvidos como unidades.


       6.5.2. Atividades

      Para atingir os objetivos propostos nesta etapa, é necessária a realização das
   seguintes atividades:

             Estruturar o modelo de implementação;
             Planejar integração;
             Implementar componentes;
             Efetuar testes unitários;
             Efetuar revisões de código.


       6.5.3. Artefatos

        Não se faz fundamental a confecção de nenhum artefato nesta etapa considerando-
se as limitações de tempo e de pessoal pequenas empresas.


       6.5.4. Ferramentas

      Em função das limitações financeiras das pequenas organizações, ferramentas free
   e open source são priorizadas. Afora esta restrição, a empresa deverá escolher o
   framework de desenvolvimento ao qual sua equipe esteja mais bem adaptada e
   familiarizada. Desta forma, custos com licenças e capacitação são evitados.


       6.5.5. Documentos relacionados

       Para facilitar a realização das atividades acima listadas, alguns documentos, que
   servem de referência, estão abaixo listados:

             Práticas de Desenvolvimento Ágil: Um conjunto de práticas úteis a
              qualquer time, independentemente da linguagem ou tecnologia.

   6.6. Testes
       6.6.1. Objetivos

       A fase de testes é muitas vezes abandonada pelas pequenas empresas, que buscam
   muitas vezes adiar os problemas. Esta, no entanto, acelera o processo e oferece uma
   importante garantia de qualidade e do funcionamento de cada parte do software.
       Nesta etapa deve-se verificar a integração de todos os componentes de
   software, buscando avaliar as formas de interação entre os componentes e como estes
   reagem quando colocados em conjunto no sistema. É básico verificar se todos os
   requisitos estão corretamente implementados bem como identificar e garantir
   que defeitos sejam solucionados antes da disponibilização do sistema.
      Buscando estar atento a todos os possíveis movimentos do software, deve-se
   buscar cobrir todo o sistema. A cobertura dos testes é um indicador do nível de
   garantia oferecida pelos testes.

       6.6.2. Atividades

      Para atingir os objetivos propostos nesta etapa, é necessária a realização das
   seguintes atividades:
           Projetar testes
           Efetuar testes de integração, de sistema e de desempenho


       6.6.3. Artefatos

   Nesta etapa, a geração de artefatos é opcional.

              Plano de testes: detalhamento dos estágios e tipos de testes a serem
               realizados para garantir a conformidade do produto com as especificações
               de requisitos funcionais e não funcionais e a aceitação do cliente


       6.6.4. Ferramentas

       Novamente é opcional o uso de ferramentas auxiliares nesta etapa, que devem
   variar de acordo com o ambiente de desenvolvimento utilizado.


       6.6.5. Documentos relacionados

              Guia de Fluxo de Testes: Descreve as atividades do fluxo de testes.
              Caso de Teste: Guia do RUP para Casos de Teste



7. Conclusão

    A fim de melhor acompanhar e validar a veracidade do processo, tanto na
implantação, quanto na utilização pelas empresas, podemos trabalhar em cima de -
basicamente - três aspectos: produtividade, satisfação e aplicabilidade.

    Em termos de produtividade, pode-se trabalhar baseado no cronograma, analisando
quantos % das atividades foram realizadas no tempo previsto. No tocante à satisfação,
questionários podem ser trabalhados junto aos clientes, bem como com a equipe que está
projetando; esses questionários podem ser estruturados ou semi-estruturados, a partir dos
quais poderão ser feitos julgamentos quantitativos e qualitativos. Por fim, podemos medir
a aplicabilidade do processo, acompanhando se todas as atividades das fases definidas no
RUPinho estão sendo contempladas.

   Para todas as métricas mapeadas é interessante ter medidas de correção, a fim de está
sempre melhorando o refinamento do processo, adaptando de maneira continuada os
objetivos, atividades, ferramentas e artefatos do processo à realidade da empresa.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:38
posted:12/11/2011
language:Portuguese
pages:13