RUPinho - Processos de desenvolvimento de software focado em pequenas empresas

César Delmas, Daniel Penaforte, Guilherme Gonçalves, Hector Paulo, Thiago Rodrigues

Centro de Informática – CinUniversidade Federal de Pernambuco – UFPE

Cx Postal 7851 – CEP 50732-970 Recife/PE – Brasil

cadcn@cin.ufpe.br, dap4@cin.ufpe.br, ggc@cin.ufpe.br, hplo@cin.ufpe.br, trc@cin.ufpe.br

Temas: - Qualidade do Processo - Processo de Desenvolvimento de Software

Tipo artigo: Relato de Experiência na empresa.

Justificativa: Este artigo foi desenvolvido para a disciplina de Qualidade de Software ministrado pelo prof. Alexandre Marcos Lins de Vasconcelos..

RUPinho - Processos de desenvolvimento de software focado em pequenas empresas

Resumo. Neste artigo é apresentado um modelo de desenvolvimento de software baseado no RUP e adaptado à organizações onde agilidade, baixo custo e documentação reduzida passa a ser vital durante o seu processo de desenvolvimento. . A facilidade de acesso das informações demandas em qualquer etapa do processo é fundamental para que se tenha agilidade, diminuir esforços na produção de documentos que muitas vezes não estão de acordo com a sua realidade e uso de ferramentas livre que dessem apoio ao processo são características peculiares desse contexto.Palavras-chave. Processo de desenvolvimento.

1. Objetivo do RUPinhoO objetivo do RUPinho é a estruturação de um processo que possibilite pequenas empresas, trabalhar de maneira 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 o contexto do CESAR (Centro de Estudos e Sistemas Avançados do Recife) 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.

O processo foi desenhado em basicamente cinco etapas que serão, posteriormente, detalhadas:

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

Nesse sentido, é fundamental que haja uma adequação entre as demandas de um processo rigoroso de desenvolvimento com as limitações de recursos de pequenas empresas, modelando – assim – um processo que possa aumentar a agilidade, 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 RUPinhoO 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 adaptar as realidades e proporcionar um melhor resultados em relação aos problemas previamente abordados.

3. Origem do RUPinho

3.1 RUP - Rational Unified ProcessO 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 CESARO 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ísticasPara 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 AgilidadeNuma 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 produtividade, que o RUPinho se propõe.

4.2 Documentação reduzidaNo 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 custoTambé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. EtapasO 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 Negócio/Concepção

Documento que compreende 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.

Planejamento e Gerenciamento de Projetos

Planejar e monitorar todo o processo de desenvolvimento, gerenciar riscos, prover a infra-estrutura e definir artefatos 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

Controle de Qualidade

Avaliar e controlar a qualidade do processo de desenvolvimento do 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 que 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

Modelo de Casos de Uso do Negócio/Acordo de Concepção: Documento que compreende 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 Obrigatórios

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

Planilha de Estimativa e Acompanhamento de Custos: Planilha para cálculo de estimativas de 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

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 relacionadosPara 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:

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

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

Manual do dotProject: Documento explicando o uso da ferramenta dotProject

6.3 Requisitos

6.3.1 ObjetivosUm 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 AtividadesPara 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 ArtefatosOs seguintes artefatos são de confecção obrigatória e servirão de suporte para o desenvolvimento das etapas posteriores do processo:

Obrigatórios

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 FerramentasNão se faz fundamental o uso de nenhuma ferramenta específica nessa etapa.

6.3.5 Documentos relacionadosPara 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 ObjetivosDurante 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 AtividadesPara 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 ArtefatosNa etapa em questão devem ser gerados três artefatos essenciais para alcançar os objetivos da mesma:

Opcionais

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.

6.4.4 FerramentasPara 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 relacionadosPara 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 ObjetivosA 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 AtividadesPara 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 ArtefatosNã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 FerramentasEm 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 relacionadosPara 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 Testes6.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 ArtefatosNesta 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 FerramentasNovamente é 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

6.7 Implantação

6.7.1 ObjetivosEste etapa tem como resultado final a correta distribuição do produto para o cliente. O resultado da implementação, depois de testado, deve constituir um software facilmente instalado e utilizado.

6.7.2 AtividadesObrigatórias

  Preparar software para implantação Disponibilizar o sistema em ambiente de produção Disponibilizar help e suporte ao usuário Migrar dados pré-existentes

 Opcional

  Planejar e conduzir beta-testes

 

6.7.3 Artefatos

Plano de Implementação: Documento que descreve as atividades necessárias para instalação do software (ou produto) no ambiente de utilização do cliente.

Help: Documento com o Manual do usuário descrevendo as instruções de uso para funcionalidades do sistema. Neste documento também terá restrições de hardware e software para instalação do sistema.

Relatório de Avaliação Final do Cliente: Questionário para avaliar o grau de satisfação do cliente com a aplicação e com os serviços prestados.

6.7.4 Documentos Relacionados Plano de Implementação: Guia do RUP para plano de Implementação

7. ConclusãoA 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.

8. Bibliografia