Introdução à orientação a objetos

Uma pequena apostila, bem objetiva, com os princípios e os conceitos do paradigma de orientação a objetos.

Clique aqui para acessar

Caixas com cantos arredondados e sombra

As recomendações CSS3 irão prever propriedades para construção de bordas arredondadas, no entanto você pode simular estes efeitos usando as propriedades já disponíveis em CSS2 - e sem uso de qualquer tabela ou marcação extra no código.

Esta página foi inspirada em uma página criada por Arve Bersvendsen. Ele desenvolveu várias outras demonstrações sobre CSS .

Sem dúvidas, construir bordas arredondadas e caixas (boxes) com sombra será uma tarefa bem mais simples com a implementação de CSS3. Por exemplo: Para colocar uma borda arredondada grossa na cor vermelha em um parágrafo, você terá que escrever regras CSS como abaixo mostrado:

P { border: solid thick red;
    border-radius: 1em }

E, para colocar uma sombra em um parágrafo, uma regra CSS apenas é suficiente, como mostrado abaixo, onde a cor da sombra é black x-offset e y-offset são 0.5em e com raio de 0.3em.

P { box-shadow: black 0.5em 0.5em 0.3em }

(Você pode tentar este link para constatar se estas propriedades já estão implementadas.) Mas, se precisar usar estes efeitos sem se preocupar se eles já foram ou não implementados e sem encontram suporte nos browsers, use a técnica mostrada a seguir.

Degradês em CSS sem usar imagens

O recurso de gradiente (degradê) CSS foi introduzido pelo Webkit há cerca de 2 anos, mas raramente era utilizado devido à incompatibilidade com a maioria dos browsers. Mas agora, com o Firefox 3.6+, que suporta gradientes, é possível criar degradês sem usar imagens! E o código CSS para gradiente funciona nos principais navegadores: IE, Firefox 3.6+, Safari e Chrome.

1. Gradiente CSS para browsers Webkit

A seguinte linha de código é para navegadores WebKit, como Safari, Chrome, etc. Serve para exibir um gradiente linear de cima (#CCC) para baixo (#000).

background: -webkit-gradient(linear, left top, left bottom, from(#CCC), to(#000));

 

2. Degradê CSS para Firefox 3.6+

Para Firefox 3.6+, usa-se -moz-linear-gradient:

background: -moz-linear-gradient(top, #CCC, #000);

3. CSS Gradient em Internet Explorer

No IE, é preciso recorrer a um filtro:

filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#CCCCCC', endColorstr='#000000');

4. Degradê com CSS em todos os navegadores (cross-browser)

background: #999; /* para browsers sem suporte a CSS 3 */

 

filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#cccccc', endColorstr='#000000'); /* IE */
background: -webkit-gradient(linear, left top, left bottom, from(#ccc), to(#000)); /* webkit browsers */
background: -moz-linear-gradient(top,  #ccc,  #000); /* Firefox 3.6+ */

Existe uma ótima ferramenta para gerar degradês com CSS: Ultimate CSS Gradient Generator.

5. Limitações do Internet Explorer

O filtro de gradiente do Internet Explorer não suporta color-stop, gradient angle e radial gradient. Isso significa que só é possível especificar degradês lineares na horizontal ou vertical com duas cores: StartColorStr e EndColorStr.

6. Notas finais sobre degradês com CSS puro

É importante ter em mente que nem todos os navegadores suportam gradiente com CSS puro. Por garantia, o ideal é não depender do CSS para fazer degradês; o ideal é utilizar o recurso para melhorar o web design.

Gerência de configuração de software

1 - Introdução
 
A configuração de software engloba todos os artefatos que são confeccionados para se produzir um sistema computacional, e estes deverão ser controlados, incluindo desde a documentação, passando pelo escopo inicial, até a fase de manutenção. Como todo software deve evoluir para atender às necessidades mutáveis do cliente, é certo que toda essa documentação deverá sofrer muitas alterações no decorrer do ciclo de vida. Se essas mudanças não forem bem gerenciadas a equipe terá grandes problemas e poderá até perder o controle sobre o sistema.

A seguir temos os fundamentos da gerência de configuração de software, seus benefícios e as ferramentas automatizadas que podem contribuir para sua implementação.

2 – O Problema da Manutenção de Software
 
Para compreender o aspecto de configuração de sistemas, é preciso entender como eles são originados. A rotina de trabalho diária de milhares de pessoas em todo o mundo está condicionada à execução de tarefas que demandam tempo e atenção para serem realizadas. É o caso, por exemplo, de um funcionário que precisa fechar o movimento de caixa de uma loja no final do dia. Utilizando o formulário de papel próprio e que não pode ser rasurado, ele começa o trabalho. Lá pelas tantas, comete um erro e é obrigado a começar tudo de novo. Não é raro essas pessoas terem que refazer o preenchimento uma dezena de vezes até que esteja tudo correto e sem rasuras. Problemas como o descrito acima levaram à busca de soluções que culminaram na informatização de processos, pois os computadores poderiam auxiliar em muito as pessoas, uma vez que facilitam a execução de tarefas repetitivas. Agora, com um clique de botão é possível gerar todo o movimento de caixa.

Da mesma forma, centenas de milhares de rotinas foram racionalizadas de forma que pudessem ter suas tarefas executadas ou auxiliadas por sistemas computacionais. Esse fato leva a muitas vantagens, destacando a economia de mão-de-obra, de tempo e de dinheiro. Entretanto, no intuito de informatizar as tarefas, os sistemas tornaram-se extremamente dependentes delas, ou seja, se a regra de negócio de uma rotina de trabalho sofrer modificações, sua contraparte informatizada também deverá ser alterada.

Modificações nas rotinas de trabalho podem acontecer a qualquer época e por vários motivos. O que deve ser compreendido é que elas são um fato normal no desenvolvimento do programa. Clientes querem modificar requisitos, desenvolvedores querem modificar a abordagem técnica e gerentes querem modificar a estratégia do projeto. Com o passar do tempo, as partes envolvidas ficam sabendo mais sobre o que necessitam. Esse conhecimento adicional é a origem da maioria das modificações.

Reunindo as causas mais comuns de alterações pode-se destacar:
·Novas condições do negócio ou do mercado alteram os requisitos da tarefa. Exemplo: um plano de saúde passar a aceitar um número limitado de dependentes quando antes era ilimitado;
·Mudanças nas leis que regulamentam o processo. Um novo dispositivo em uma lei que regulamenta um processo gera um novo requisito que deve ser implementado no sistema;
·Novas necessidades do cliente exigem modificações nos dados produzidos;
·Reorganização, aumento ou diminuição dos negócios causam modificações nas prioridades do projeto.

3 – Gerenciamento de Configuração de Software
 
Como visto no capítulo anterior, alterações em sistemas são inevitáveis no decorrer do seu ciclo de vida. O problema é que elas aumentam o grau de confusão entre os analistas que estão trabalhando em um projeto quando as modificações não são analisadas antes de serem feitas; quando as modificações não são registradas antes de serem implementadas; não são relatadas para aqueles que têm necessidade de saber delas e não são controladas para melhorar a qualidade e reduzir os erros.

Gerência de Configuração de Software, ou simplesmente GCS, é um conjunto de atividades desenvolvidas para administrar modificações ao longo do ciclo de vida do sistema computacional. As principais atividades da GCS são: 

· Identificar os produtos de trabalho que podem ser modificados, estabelecendo relacionamento entre eles;
· Definir mecanismos para administrar as diferentes versões desses produtos de trabalho; 
· Controlar as modificações impostas e fazendo auditoria e preparando relatórios sobre as modificações realizadas.
· Garantir que os procedimentos e políticas para criar, modificar e testar o código estejam sendo seguidos; 
· Tornar acessíveis as informações sobre o projeto.

A GCS pode ser vista como uma atividade de garantia de qualidade de software aplicada ao longo de todo seu processo de desenvolvimento.

Um dos principais mecanismos para permitir o controle sobre as modificações de código é fazer com que o usuário preencha uma solicitação oficial de manutenção. Esta deverá ser avaliada por uma comissão de controle de modificações que será responsável por aprovar e autorizar as modificações. Um histórico da evolução dos componentes do sistema deverá ser mantido junto com um registro das razões para sua modificação.

A Gerência de Configuração de Software também é conhecida pelo seu acrônimo em língua inglesa SCM (Software Configuration Menagement).

3.1 - Itens de Configuração de Software
 
Itens de configuração de software são todos os artefatos confeccionados durante o projeto de um software que serão controlados pela gerência de configuração. Há três categorias principais de itens de configuração:
· Programas de computador, tanto na forma de código fonte quanto de arquivos executáveis;
· Aplicativos que auxiliam tanto técnicos quanto usuários;
· Os dados manipulados e/ou gerados por sistemas computacionais.

3.2 - Processo de Gerência de Configuração
 
Para se alcançar os benefícios da tecnologia da gerência de configuração, há que se conhecer seu processo que é dividido em uma série de tarefas que tem quatro objetivos principais: identificar os itens que definem coletivamente a configuração do software; gerir modificações em um ou mais desses itens; facilitar a construção de diferentes versões de uma aplicação e garantir que a qualidade do software seja mantida à medida que a configuração evolui ao longo do tempo.

Podem-se estabelecer quatro tarefas básicas para a gerência de configuração: identificação, controle de versão, controle de modificação e auditoria de configuração. Isso significa que após a criação de cada elemento de software, chamado também de item de configuração, este deverá ser identificado, ter suas solicitações de modificações registradas, ter suas versões controladas, possibilitar consultas (relatórios) e conferências.

3.2.1 - Identificação dos Itens de Configuração

Quando um novo item de configuração é criado, deve-se identificá-lo unicamente no contexto, dando-lhe um nome, uma descrição e uma lista de recursos. É importante ainda considerar os relacionamentos existentes com outros objetos.

3.2.2 – Controle de Versão 
 
É uma operação que combina procedimentos e ferramentas para gerenciar versões diferentes de objetos de configuração criados durante o processo. Um sistema de controle de versões precisa de:
· Um banco de dados de projeto que armazene todos os itens de configuração relevantes;
· Um gerenciador de versionamento que deve permitir o registro histórico de cada item de configuração e fornecer informações de diferenças entre versões.

3.2.3 – Controle de Modificações
 
Como visto anteriormente, modificações são inevitáveis e precisam ser realizadas. Mas modificações feitas sem controle podem levar a uma série de erros. Para evitar a confusão as modificações solicitadas precisam ser analisadas (quanto aos impactos causados), relatadas, autorizadas, revisadas e auditadas. Um controle de modificações formal que utilize tanto processos manuais quanto ferramentas automatizadas de controle de versão é de vital importância para que o processo de gerência de configuração seja implantado.

3.2.4 – Auditoria de Configuração
 
Mesmo fazendo uso de mecanismos de controle bem-sucedidos, os gerentes podem acompanhar as modificações somente até determinado ponto, esquecendo de verificar se as mesmas são realmente implementadas. Para garantir que as modificações sejam adequadamente implementadas, pode-se utilizar duas técnicas:

a) Revisão técnica formal: enfoca a correção técnica do item de configuração que foi modificado, determinando sua consistência em relação a outros itens, omissões e efeitos colaterais em potencial;

b) auditoria de configuração de software: complementa a revisão técnica formal, avaliando também se alguma modificação adicional foi incorporada, se o processo de software foi seguido, se os documentos formais foram preenchidos corretamente e se todos os itens relacionados foram adequadamente atualizados.

4 – Ferramentas de Auxílio na Gerência de Configuração
 
Embora não esteja disponível no mercado uma ferramenta que possibilite automatizar todas as tarefas da gerência de configuração, pode-se elencar algumas que possuem recursos para gerenciar as principais atividades da GCS, como gerenciamento dos itens de configuração, disponibilidade de informação para a equipe e controle de versões. Nesses quesitos, destacaremos três ferramentas bastante conhecidas: o Visual SourceSafe da Microsoft, o StarTeam da Borland e o Subversion. Apenas o último possui código aberto e é gratuito para uso comercial.

De uma forma simplista, pode-se dizer que o objetivo principal desse tipo de ferramenta é o armazenamento dos itens de configuração e o posterior controle da versão dos mesmos durante o processo de desenvolvimento. É possível armazenar vários tipos de itens de configuração como códigos-fonte de programas, formulários, scripts de banco de dados, tabelas, consultas, planilhas, entre outros, em suas diversas versões . Isto permite uma comparação  de qualquer objeto para cada versão, ou seja, é possível comparar o código de uma classe da versão 1.0 com o código da mesma classe já na versão 2.0. Pode-se recuperar um objeto de uma versão anterior ou bloquear um objeto que está sendo usado por um dos integrantes da equipe, de forma que os demais não tenham acesso a ele.

Um resumo dos principais recursos disponíveis nas ferramentas gerenciadoras de configuração pode ser visto na tabela abaixo:

Recurso	Descrição
Get Latest Version	Copia a última versão do item de configuração presente no banco de dados da ferramenta para a máquina local
Check-out	Copia a última versão do item de configuração presente no banco de dados da ferramenta para a máquina local e bloqueia o mesmo para que ninguém mais possa alterá-lo
Check-in	Grava as alterações feitas no item de configuração no banco de dados
Undo Check-out	Desfaz o comando check-out
Label	Permite a criação de rótulos para versões (linhas de base)
History	Permite comparar versões diferentes de itens de configuração ou de versões inteiras de programas.

A seguir estão listados os passos mais comuns para montar uma estrutura de gerência de configuração de software automatizada:

a) criação de uma estrutura de diretórios

O primeiro passo é a criação de uma estrutura de diretórios para servir de repositório aos itens de configuração do projeto. Não há padronização para a criação dessa estrutura, mas é comum as equipes trabalharem com pastas diferentes para versões de desenvolvimento e produção e outra para armazenar versões fechadas do software. A estrutura é criada tanto na máquina local dos membros da equipe quanto no banco de dados da ferramenta de configuração. O Esquema abaixo ilustra uma proposta para criação de uma estrutura de configuração:

-nome_do_projeto
   -doc
   -gcs
      -desenv
         -prj
         -scr
      -producao
         -scr
      -release 

Diretório	Descrição
nome_projeto	Diretório raiz do projeto
doc	Diretório para documentos que não estão sob gerenciamento de configuração
gcs	Diretório raiz para itens de configuração que estão sob gerenciamento de configuração
gcs/desenv	Diretório principal para desenvolvimento
gcs/desenv /prj	Diretório para documentos relativos à disciplina projeto como por exemplo termos de abertura de projeto, declarações de escopo, cronogramas, documentos de especificação de requisitos, diagramas, dicionário de dados e outros
gcs/desenv /src	Diretório para os códigos fontes utilizados em ambiente de desenvolvimento
gcs/producao	Diretório principal para produção
gcs/producao/src	Diretório para os códigos fontes utilizados em ambiente de produção
gcs/release	Diretório para manter as versões fechadas que já estão em produção

b) inserção dos itens de configuração na estrutura 

Os responsáveis produzem os artefatos e os adicionam no banco de dados da ferramenta de configuração onde os outros membros possam copiá-los para suas respectivas estações através dos recursos da ferramenta.

c) manutenção das alterações nos itens de configuração

Significa utilizar o recurso de check-out quando for necessário alterar um objeto e após a modificação aplicar o recurso check-in para gravá-la no banco de dados de configuração.

d) criação de rótulos de versão (linhas de base)

Quando o projeto do software atingir um marco, que pode ser desde a entrega de um artefato importante até a liberação de uma versão estável do software para o cliente, é recomendada a criação de uma linha de base, ou seja, um rótulo para aquela versão do projeto. Depois que o recurso Label é aplicado, é possível comparar as diferenças entre duas versões e até mesmo retornar a uma versão anterior completa.

5 – Conclusão

A gerência de configuração de software é um processo crítico que pode definir o sucesso ou o fracasso de um projeto de sistema de informação. Ao mesmo tempo em que ela permite acesso aos artefatos produzidos aos membros da equipe, ela garante que todas as alterações que venham a ser feitas possam ser analisadas, controladas e submetidas a um gerenciamento de versão.

Justamente por oferecer mecanismos inteligentes que podem contribuir para a qualidade do projeto, a gerência de configuração também é vista como uma atividade de garantia de qualidade de software. Tanto é que um dos modelos de maturidade de processo de desenvolvimento de software mais difundidos no mundo, o CMMI-SW, insere a gerência de configuração como uma das sete áreas-chave para alcançar seu nível dois de maturidade (nível gerenciado), que é o primeiro degrau de maturidade no qual uma empresa almeja subir.

A implantação de um processo de gerência de configuração sempre traz grandes vantagens para as equipes de desenvolvimento, a um custo muito baixo. O custo está associado à aquisição da ferramenta que permita o controle eficaz dos itens de configuração do projeto, proporcionando acesso, controle de alterações e versionamento. Se o grupo optar pela utilização de uma ferramenta open source, o custo pode ser praticamente zero. A adoção de uma ferramenta de versionamento é imprescindível para o sucesso.

Gestão de Projetos

Apresentação sobre Gestão de Projetos, do consultor de Estratégia e Governança de TI Carlos Rodrigues, na IT Forum 2005.

Clique aqui para acessar os slides

Análise de algoritmos

Excelente apostila de Análise de Algoritmos do professor Walteno Martins Parreira Júnior, da Universidade do Estado de Minas Gerais.

Clique aqui para acessar o texto completo

XP (eXtreme Programming)

1. XP (eXtreme Programming)

XP é uma metodologia para desenvolvimento de software ágil, com qualidade que atenda as necessidades do cliente, ou a prática e perseguição da mais clara simplicidade, aplicando no desenvolvimento de software.

Foi criado no final da década de 90. É uma metodologia ágil voltada a equipes pequenas e médias que produzem software baseados em requisitos vagos e que mudam com rapidez. As principais diferenças entre o XP e outras metodologias são feedbacks constantes e uma abordagem incremental. Para isso é necessária uma comunicação entre os indivíduos.

Conforme Astels, a necessidade de entregar o software mais rápido fez com que Kent Beck, Wrad Cunningham e Ron Jeffries explorassem os extremos de determinadas práticas de desenvolvimento. O primeiro projeto a usar a metodologia XP, foi o C3 (Chrysler Comprehensive Compensation) da Chrysler, por um lado restrito e por outro lado levado aos limites. Essa prática foi chamada de “acertar os ponteiros em dez”. O resultado foi uma inovação no desenvolvimento de software, chamada XP.

A XP é considerada uma disciplina de desenvolvimento de software, porque há certas coisas que você precisa fazer para estar desenvolvendo a XP. Se você optar por não fazer testes você não estará sendo Extremo:
      ● Ter feedback antecipado, concreto e contínuo pelos ciclos curtos;
      ● Por sua abordagem incremental de planejamento, que gera rapidamente um plano geral que vai evoluir com o decorrer do projeto;
      ● Habilidade de agendar de forma flexível a implementação das funcionalidades, respondendo às mutáveis necessidades do negócio;

     ● Confiança nos testes automatizados escritos por programadores e clientes para monitorar o progresso do desenvolvimento, para permitir que o sistema evolua e para detectar cedo os erros;
      ● Comunicação oral, testes e código fonte para comunicar a estrutura e o objetivo do sistema;
      ● Confiança na intensa colaboração de programadores com habilidades comuns;
      ● Confiança nas práticas que combinam tanto com os instintos de curto prazo dos programadores quanto os interesses de longo prazo do projeto;

2. Fundamentos da XP

Há diversos fundamentos que a XP leva ao extremo e que em sua maioria não são valorizadas ou mesmo mencionadas pelas demais metodologias de desenvolvimento. Dentre elas podemos citar:

     ● Se revisar o código é bom, revisaremos código o tempo inteiro (Programação em pares);

     ● Se testar é bom, testes serão escritos antes de programar e todos vão testar o tempo inteiro (teste de unidade), até mesmo os clientes (testes funcionais);

     ● Se o projeto é bom, ele fará parte das funções diárias de todos (refatoração);

     ● Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais simples que suporte a funcionalidade atual (a coisa mais simples que possa funcionar), evoluindo constantemente a fim de adicionar a flexibilidade necessária e eliminar a complexidade desnecessária;

     ● Se arquitetura é importante, todos trabalharão para definir e redefinir a arquitetura o tempo inteiro;

     ● Se testes de integração são importantes, então vamos integrar e testar várias vezes ao dia;

     ● Se iterações curtas são boas, faremos iterações muito, muito pequenas – segundos, minutos e horas, não semanas, meses e anos;

     ● Colocar um sistema mínimo em produção rapidamente e desenvolvê-lo na direção que se mostra mais favorável;

     ● 40 horas semanais de trabalho. Na XP, horas extras não são bemvindas, na sexta feira os integrantes devem terminar o seu turno e terem 2 dias para não pensarem em trabalho, para chegarem na segunda-feira cheio de energias e idéias

     ● O cliente deve estar sempre disponível para responder questões e redefinir prioridades de menor escala;

     ● Distinguir entre decisões que devem ser tomadas por interesses dos negócios e aquelas que devem ser tomadas pelos envolvidos no projeto;

     ● Padrões de codificação. Por vezes as duplas serão trocadas e talvez partes do sistema serão feitos por outras duplas, portanto é necessário a adoção de padrões de codificação com uma restrição, o mais simples possível e que seja aprovada por todo o grupo.

3. Aplicação da XP

A XP foi desenvolvida para ser aplicada em projetos em que:

     ● Os requisitos mudem com freqüência;

     ● Utilizem desenvolvimento orientado a objetos;

     ● Trabalhem com times de dois a 10 programadores;

     ● Não sejam severamente restringidos pelo ambiente computacional;

     ● Boa parte da execução de testes possa ser feita em pouco tempo no dia;

     ● E possua desenvolvimento incremental.

A XP assusta ou irrita algumas pessoas que tem o primeiro contato. Mas nenhuma das idéias defendidas pela XP são novas. A maioria delas é tão velha quanto à própria programação, todas as técnicas da XP foram testadas há décadas. As grandes mudanças que a XP traz são:

     ● Colocar todas as práticas juntas;

     ● Garantir que elas sejam praticadas a fundo;

     ● Garantir que as práticas apóiem umas às outras em Extremo.

4. Valores do XP

Para guiar o desenvolvimento, o XP baseia-se em cinco valores:

4.1. Comunicação

Tem como objetivo criar e manter o melhor relacionamento possível entre a equipe desenvolvedora e o cliente, recomendando o contato direto (face-a-face), para evitar qualquer tipo de mal entendido entre os desenvolvedores e para que possíveis dúvidas possam ser resolvidas de imediato.

Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua.

Algumas equipes não se adaptam bem com isso. Enquanto estiverem com esse problema a metodologia estará comprometida, portanto, a equipe deve entrar em um acordo.

É encorajada também a comunicação entre desenvolvedores e gerente do projeto. Este se caracteriza como um dos fatores principais no XP: conversar ao máximo pessoalmente, evitando o uso do telefone e mensagens de e-mail.

4.2. Simplicidade

Visa minimizar o código, descartando as funções consideradas desnecessárias ou não essenciais. Ou seja, deve ser implementado o menor número de classes e métodos.

Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando adicionar funcionalidades ligadas à evolução do produto. O importante é ter em mente que os requisitos são passíveis de mudanças. Sendo assim, o interessante na prática do XP é implementar apenas o que é realmente necessário para que o cliente tenha seu pedido atendido.

Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.

4.3. Feedback

Chamamos de feedback constante o contato incessante com o cliente a respeito do projeto. Informações sobre o código são dadas por testes periódicos, os quais indicam erros um tanto individuais quanto ao software integrado. Além disso, o cliente terá sempre uma parte do software funcional para avaliar. Com isso, novas características e informações são repassadas aos desenvolvedores, que por sua vez devem implementá-las nas próximas versões. Desta maneira, o que se pretende é entregar o software de acordo com as expectativas do cliente.

4.4. Coragem

Se encaixa na implantação dos três valores anteriores. É importante que os profissionais sejam comunicativos e com facilidade de se relacionar. A coragem auxilia a simplicidade, quando a possibilidade de simplificar o software é detectada. Por fim, a coragem é necessária para garantir que o feedback do cliente ocorra com frequência, pois esta abordagem implicará na possibilidade de mudanças constantes do produto.

4.5. Respeito

É um valor que dá sustentação a todos os demais. É preciso que os membros de uma equipe se importem uns com os outros. Só assim, irão se preocupar em comunicar-se melhor. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

5. Equipe XP

5.1. Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.

Os Maiores atributos do gerente são coragem, confiança e insistência ocasional para que façam o que dizem fazer. Isto significa comunicação franca.

O time quer colocar esta habilidade em prática quando precisarem dela. E querem mantê-la distante quando não precisarem.

5.2. Coach

Pessoa responsável pelas questões técnicas do projeto, é necessário um grande conhecimento nos processos de desenvolvimento, nos valores e práticas do XP. Sua responsabilidade é verificar o comportamento da equipe, sinalizando os eventuais erros.

5.3. Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.

Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.

5.4. Redator técnico

Pessoa responsável em documentar o sistema, permitindo uma maior dedicação ao trabalho de codificação. Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

5.5 Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.

É o principal membro da XP, dentre suas habilidades devem ser destacadas a programação em pares e a simplicidade, e acima de tudo a coragem.

Existem níveis distintos de desenvolvedores dentro de uma equipe, mas com a prática de programar em par, a tendência da equipe é se tornar uniforme em suas habilidades.

5.6. Rastreador

O rastreador faz estimativas de tempo e checa se está ajustado à realidade. Isto é uma questão de prática e feedback. Ele é responsável pela visão global do andamento também, se durante uma iteração o que foi previsto será executado, ou se é preciso modificar algo. A maior habilidade aqui é a capacidade de coletar informações de que precisa sem perturbar o processo.

5.7. Treinador

É o responsável por chamar a atenção das pessoas quando estas estão se desviando do processo do time. Todos no Time XP devem compreender a aplicação, mas o treinador o deve muito mais e profundamente. A necessidade deste papel diminui proporcionalmente com o amadurecimento do time.

6. Princípios ou práticas do XP

Para entender as formas que movem o projeto XP, é importante entender seus princípios e suas práticas. Alguns desses princípios são apenas bom senso, outros se tornam a base da maioria dos processos futuros de desenvolvimento de software conforme apresentado a seguir:

6.1. Cliente em conjunto com os desenvolvedores

O XP tem uma visão diferente em relação ao cliente. Este permanece o tempo todo presente, a par do desenvolvimento do software, indicando modificações e esclarecendo duvidas da equipe, onde a sua ausência representa sérios riscos ao projeto.

Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.

6.2. Planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente sempre determinando o escopo da próxima versão, combinando prioridades de negócio e estimativas técnicas. O consultor se reúne com as equipes duas vezes por semana. Nestas reuniões há uma permanente negociação de requisitos e prazos. Este planejamento é feito várias vezes durante o projeto. É o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.

6.3. Uso de metáforas

Todo o desenvolvimento é guiado por uma simples estória compartilhada de como o sistema funciona e todas as funcionalidades do sistema são descritas.

A metáfora ajuda a equipe a entender sobre o vocabulário utilizado pelo domínio do projeto e assim ajuda-o a nomear funções e variáveis apropriadamente.

São relatadas através de pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente.

Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto, que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão.

Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos no máximo.

Em cada estória é escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e, se possível, com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas.

O XP tem por objetivo gerar valor para o cliente ao longo do projeto, e para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases, pequenos intervalos de tempo, máximo de 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.

A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos realises.

Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações.

Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa validar as implementações efetuadas e fornecer o feedback necessário à equipe.

6.4. Teste primeiro

Os programadores escrevem unidades de teste continuamente e os executam para que o processo de desenvolvimento continue. Esta atividade é considerada extremamente chata e dispensada por muitos desenvolvedores na modelagem conceitual por exemplo, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada. Todo código implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade.

Em cada ciclo eles apresentam uma versão de teste do software ao cliente. Os clientes escrevem os testes para validar o sistema.

É com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele. Com a implementação de testes o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.

No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade verifica se os resultados gerados por cada classe estão corretos, já o teste de aceitação verifica se a interação entre as classes que implementam uma funcionalidade atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.

6.5. Simplicidade

O sistema deve ser projetado da forma mais simples possível. A complexidade extra é removida assim que detectada. Deve-se implementar apenas a funcionalidade que foi solicitada. Mas deve-se ter atenção para não confundir simplicidade com facilidade.

Umas das premissas do desenvolvimento conceitual é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.

No XP o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto. Esta premissa é dita em função dos avanços nas linguagens e práticas de programação, dos novos ambientes e ferramentas de desenvolvimento, e da utilização de orientação a objetos no desenvolvimento. E em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.

6.6. Programação pareada

O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. É uma técnica onde dois desenvolvedores trabalham no mesmo problema. Um deles é responsável pela digitação (condutor - menos experiente) e outro acompanhando o trabalho do parceiro (navegador - mais experiente).

Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla. Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais rápida e fácil. É com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas as rotinas do sistema, e estarão prontos para qualquer modificação ou para auxiliar algum iniciante.

6.7. Padronização do código

Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.

O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.

A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. O código fonte final deve parecer ter sido feito por apenas um programador.

6.8. Propriedade coletiva

O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, mas que esteja funcionando, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão. Ou seja, o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

6.9. Integração contínua

Visa integrar e construir o sistema muitas vezes ao dia, todas as vezes que uma tarefa tiver sido finalizada.

6.10. Refactoring

É um processo que permite a melhoria contínua da programação. Os programadores reestruturam o sistema sem mudar seu comportamento, para remover duplicação, melhorar a comunicação, simplificar ou adicionar flexibilidade.

6.11. Fases pequenas

Visa produzir um sistema simples rapidamente, planejando novas versões em um ciclo muito pequeno. A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.

6.12. Semanas curtas (Semana de 40 horas)

Impõe que a equipe não trabalhe mais do que 40 horas por semana / 8 horas por dia. Mas se necessário que não faça hora-extra duas semanas seguidas. Trabalhar com qualidade, buscando ter ritmo de trabalho saudável.

6.13. Stand up meeting

O stand up meeting é uma reunião rápida (em torno de 15 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a respeito do que ocorreu no dia anterior e priorizar as atividades do dia que se inicia. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser feito primeiro, fazendo com que todos relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.

7. Vantagens e desvantagens

7.1. Vantagens

As práticas do XP são usadas pelos integrantes da equipe, para facilitar no desenvolvimento e agregar qualidade no projeto, com isso todos do time devem estar cientes de cada fase do sistema. Um dos benefícios que a mesma oferece é tornar o processo mais ágil e flexível. Conforme Astels, as práticas do XP são criadas para funcionarem juntas e fornecer mais valor do que cada uma poderia fornecer individualmente:

     ● Análise prévia de tudo que pode acontecer durante o desenvolvimento do projeto, oferecendo qualidade, confiança, data de entregas e custos promissores;

     ● O XP é ideal para ser usada em projetos em que o cliente não sabe exatamente o que deseja e pode mudar muito de opinião durante o desenvolvimento do projeto. Com feedback constante, é possível adaptar rapidamente eventuais mudanças nos requisitos;

     ● Estas alterações nos requisitos são muitas vezes críticas nas metodologias tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças;

     ● Outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando, como nas metodologias tradicionais.

7.2. Desvantagens

É freqüente acontecer bugs em todos os projetos de desenvolvimento de software, e no XP não é diferente. Existem pontos fracos no uso dessa metodologia, como:

     ● Não existe uma avaliação de riscos, devendo, portanto implementar uma análise e estratégias que buscam diminuir os erros;

     ● A análise de requisitos é informal e com isso pode não ser bem vista pelos clientes, que poderão se sentir inseguros quanto ao bom funcionamento do sistema;

     ● Refatoração do código pode ser vista como irresponsabilidade e incompetência, pois, não existe uma preocupação formal na utilização do código;

     ● A falta de documentação é característica do processo XP, pois, o mesmo não dá muita ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.);

     ● Sendo, portanto, importante a elaboração de documentos e diagramas que facilitem no entendimento e identificação do problema;

Além dessas desvantagens, existem algumas situações em que não é indicado o uso do XP, conforme listado a seguir:

     ● A maior barreira para o sucesso de um projeto XP é a cultura empresarial. Qualquer negócio que gerencie  projetos tentando apontar o carro para a direção certa logo de cara terá conflitos com o time que insiste em ir acertando a direção continuamente;

     ● Outra cultura que não contribui para o XP é aquela na qual você é requisitado a trabalhar horas e mais horas para provar o seu “comprometimento com a empresa”. Você não consegue executar o XP se estiver cansado. Se aquilo que o seu time produz trabalhando em velocidade máxima não é suficiente para a sua empresa então o XP não é a solução;

     ● E existe também uma barreira tecnológica para o XP, um ambiente no qual é necessário um longo tempo para se obter feedback. Por exemplo, se o seu sistema leva 24 horas para compilar e linkar, será difícil integrar, compilar e testar várias vezes ao dia.

8. Conclusão

O XP é uma metodologia que estimula a interação contínua entre cliente e desenvolvedor para que as necessidades do cliente sejam visualizadas e compreendidas, obtendo assim, o sucesso do projeto. Ela é baseada em valores e princípios exclusivos que devem ser cultivados para que o projeto obtenha o sucesso desejado.

As desvantagens existem, porém, é através delas que se devem buscar melhorias. É necessário satisfazer os pontos fortes dessa metodologia e buscar o aprimoramento dos pontos fracos, para que ela evolua e consiga espaço no mercado tecnológico de software cada vez mais competitivo.

Podemos, assim, concluir que a inclusão do XP, bem como outras metodologias ágeis, é fundamental para profissionais que buscam melhorias contínuas e sofisticação do software evitando redundâncias e erros incontroláveis no seu desenvolvimento, estando lado a lado com o cliente buscando parceria.

Scrum, uma metodologia ágil

Scrum, muito simples de usar

A metodologia Scrum está entrando na moda aqui no Brasil, após já haver conquistado inúmeras empresas da indústria de software na América do Norte.

O Scrum é uma proposta extremamente prática e honesta. Prática pela facilidade de compreensão e aplicação em nosso ambiente de desenvolvimento de software. Honesta pela fidelidade entre a proposta do método e o resultado que podemos obter após aplicá-lo.

Scrum, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão. Também o nome Scrum foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.

A seguir é apresentada uma estratégia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM.

Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, um requisito não funcional, ou uma questão de tecnologia / infra-estrutura. Esta lista é denominada Product Backlog.

Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.

Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de Scrum Team. A preparação dos trabalhos é denominada Sprint Planning.

Sprint Planning é composta dos seguintes itens: o Product Backlog, a capacidade de desenvolvimento da equipe, as condições e as exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura disto é forma revisões, administração e organização. Os resultados são Sprint Goal e Sprint.

O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team, que deverá mantê-la e organizá-la de tal forma a atender os objetivos do Sprint específico.

É permitido ter mais de um Scrum Team trabalhando no mesmo Product Backlog, por isso os requisitos são devidamente separados em Sprint Backlogs distintos por equipe. Uma idéia deste ciclo é verificada na imagem abaixo.

Ciclo demonstrando Sprint

A liderança destas equipes é exercida por um papel denominado Scrum Master. O Scrum Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este papel deve garantir a correta utilização das práticas de Scrum, deve ajudar a equipe a tomar decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do produto.

Este método de liderança é exercido através de 3 recorrentes tipos de reunião: Scrum Daily Meeting, Sprint Review e Retrospective. Começando pelo Sprint Review que é a reunião típica de final de Sprint (alguns Scrum Teams também a fazem no meio do Sprint) para validar o produto executável que a equipe conseguiu incrementar.

Explicando a Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas com seriedade por todos os membros do Scrum Team:

1- O que você fez e gostou neste sprint?
2- O que você fez e não gostou neste sprint?
3- O que você vai fazer diferente no próximo sprint?

O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Então o Scrum Daily Meeting é a resposta para promover a comunicação da equipe.

Todos os dias, obrigatoriamente, todo o Scrum Team irá se reunir por 15 minutos aproximadamente para responder a 3 importantes perguntas.

As perguntas são:
1- O que eu fiz desde a última Scrum Daily Meeting até agora?
2- O que eu vou fazer hoje?
3- O que pode me impedir?

Adicionalmente às técnicas apresentadas neste texto, a utilização de Kanban (ver figura abaixo) ajuda a maximizar o compromentimento da equipe e a comunicação de todos os comprometidos e envolvidos com o projeto.

Exemplo de implementação de Kanban. As cores amarela e laranja representam diferentes complexidades das atividades. A cor rosa representa atividades não planejadas no Sprint que foram incluídas por motivo de força maior.

Para saber mais, é recomendável ler os livros:
- Agile Project Management, de Jim Highsmith;
- Agile Software Development with SCRUM, de Ken Schwaber e Mike Beedle;
- Agile Project Management with SCRUM, de Ken Schwaber;
- Treinamento MSF Agile + Scrum + Agile Methods em http://www.fcamara.com.br.

Considerações Finais

Todos os projetos são diferentes. A tecnologia destes projetos são diferentes. As pessoas, os requisitos são diferentes.

Na grande maioria das consultorias para fins de crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de software, encontram-se pessoas que utilizando-se de métodos tradicionais ou simplesmente de improviso diário (também denominado "ausência de métodos") revelam uma estranha e frustante sensação, a Síndrome do Trabalho Vazio.

A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos e de atividades urgentes, e quando percebe-se que no final todas as atividades planejadas para aquele dia não puderam ser implementadas. É uma constatação que se é uma espécie de marionete do tempo, da empresa e dos clientes.

A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos pelas metodologias ágeis, mudam a vida profissional perante o cenário anteriormente descrito. É possível conseguir fazer atividades planejadas, priorizar atividades importantes e ter um pequeno índice de atividades urgentes no dia-a-dia. Dá para ser protagonista do próprio dia.

As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os resultados proporcionados por "waterfall approach to software development" ou pela ausência de métodos. Para iniciantes em metodologias ágeis, é recomendável o Scrum. Para praticantes de métodos ágeis que não conhecem o Scrum, permitam-se mais uma evolução.

RUP

1. Introdução

O RUP (Rational Unified Process) é uma metodologia para desenvolvimento de software criada por Rational Software, IBM, SofTeam, Unisys, Nihon Unisys, Alcatel e Q-Labs. O RUP pode ser encontrado na forma de um software, fornecido pela Rational Software, e como um conjunto de processos. Neste texto são cobertos apenas aspectos relativos ao conjunto de processos referentes ao RUP, incluindo:
     * conceitos;
     * best practices (melhores práticas);
     * fases de desenvolvimento.

2. Conceitos

Como citado anteriormente, o RUP é mais do que um software para auxiliar no desenvolvimento. É uma metodologia de desenvolvimento, com uma estrutura formal e bem definida. Como qualquer metodologia, é composta de conceitos, práticas e regras.

Um dos principais pilares do RUP é o conceito de best practices (melhores práticas), que são regras/práticas que visam reduzir o risco (existente em qualquer projeto de software) e tornar o desenvolvimento mais eficiente. O RUP define seis best practices, sendo elas:
     * desenvolver iterativamente;
     * gerenciar requerimentos;
     * utilizar arquiteturas baseadas em componentes;
     * modelar visualmente;
     * verificar continuamente a qualidade;
     * controlar mudanças.

O RUP, ainda, entrelaça o conceito de best practices em quatro definições, sendo elas:

     * funções: grupos de atividades executadas;
     * disciplinas: áreas de esforço na engenharia de software;
     * atividades: definições de como (objetos/artefatos) é construído e avaliado;
     * objetos/artefatos: resultado do trabalho, produzido ou modificado durante o processo.

Além destas definições, esta metodologia de desenvolvimento divide o processo de desenvolvimento de software em quatro fases. São elas:

     * concepção (definição do escopo do projeto);
     * elaboração (elaboração básica do software);
     * construção (desenvolvimento);
     * transição.

3. Best practices

O RUP tenta diminuir os riscos do desenvolvimento e efetivamente deixar o desenvolvimento mais eficiente, através de seis práticas básicas (conhecidas por best practices) a serem executadas durante todo o processo de desenvolvimento.

3.1. Desenvolver iterativamente

Desenvolver iterativamente significa desenvolver em ciclos. Cada ciclo contém um objetivo que deve ser alcançado (lançamento de um pre-release ou beta, correção de um bug, etc).

Esta prática acaba dando ao RUP uma série de vantagens, como a possibilidade de identificar/modificar requerimentos com mais facilidade; integração progressiva (quase contínua) de elementos ao software, ocasionando uma melhora no descobrimento e endereçamento de riscos; desenvolvimento iterativo provê aos gerentes maneiras de fazer mudanças táticas aos produtos; etc.

3.2. Gerenciar requerimentos

Gerenciamento de requerimentos provê uma maneira prática de produzir, comunicar e organizar os requerimentos de um projeto. Adicionalmente, os casos de uso e cenários descritos nos processos são uma excelente forma de capturar e assegurar requisitos. O gerenciamento de recursos acarreta um melhor controle sobre projetos complexos, além de maior qualidade e redução de custos.

O RUP é uma metodologia dirigida a casos de uso (use-driven-case), de modo que é possível utilizar os mesmos casos de uso definidos no sistema como base para o resto do processo.

3.3. Utilizar arquiteturas baseadas em componentes

Foca o desenvolvimento na modularização, através do uso de componentes, de modo a criar um sistema flexível, adaptável, intuitivamente entendível e reutilizável. O RUP entende componentes como módulos não triviais e/ou subsistemas com uma função clara e específica. Entre os benefícios podemos citar que: a facilidade para identificar, isolar, manipular e desenvolver componentes é maior do que para um sistema inteiro; componentes podem ser desenvolvidos com a reutilização em mente; etc.

3.4. Modelar visualmente

A modelagem visual permite um melhor entendimento da concepção e da complexidade do sistema, e também um melhor “dimensionamento” (no sentido de qual a forma do sistema), além de facilitar a idenficação e a solução de problemas.

3.5. Verificação contínua da qualidade

O RUP não toma a qualidade como responsabilidade de apenas uma pessoa ou um grupo, mas como uma responsabilidade de todos os integrantes do projeto.

A qualidade é focada especialmente em duas áreas:

     - Qualidade de produto: a qualidade do produto sendo desenvolvido (software ou sistema) e todas as partes envolvidas (componentes, subsistemas, arquitetura, etc);
     - Qualidade de processo: a qualidade dos processos dentro do projeto de desenvolvimento.

3.6. Controle de mudanças

Como resultado de um processo de desenvolvimento iterativo, muitas são as mudanças ocorridas no decorrer do projeto. Controlar as mudanças durante todo o projeto é prática fundamental para manter a qualidade do projeto.

4. Fases de desenvolvimento

O processo de desenvolvimento é dividido em ciclos, sendo que o ciclo de desenvolvimento é subdividido em quatro fases consecutivas.

Estas fases são concluídas tão logo uma milestone é alcançada. Uma milestone define uma etapa, na fase, na qual decisões críticas são feitas ou objetivos são alcançados.

4.1. Concepção

Concepção inicial do sistema, aonde é feita uma discussão sobre o problema, definição do escopo do projeto, estimativa de recursos necessários para a execução do projeto, etc. É nesta fase que é apresentadao o plano de projeto, caso de uso inicial e o glossário do projeto, entre outros.

4.2. Elaboração

O propósito desta fase é analisar o domínio do problema, desenvolver o plano de projeto, estabelecer a fundação arquitetural e eliminar os elementos de alto risco.

Os elementos de risco a serem analisados, nesta fase, são os riscos de requerimentos, tecnológicos (referentes à capacidade das ferramentas disponíveis), de habilidades (dos integrantes do projeto) e políticos.

Esta é a fase mais crítica de todas, pois ao final desta fase a engenharia é considerada completa e os custos para modificação do sistema aumentam à medida que o projeto avança. Do ponto de vista administrativo, é ao final desta fase que um projeto deixa de ser uma operação de baixo risco e baixo custo para se tornar uma operação de alto risco e alto custo.

4.3. Construção

Esta fase compreende a fase de modelagem e a fase de desenvolvimento em si, aquela em que o sistema é efetivamente programado. A fase de modelagem deve utilizar alguma notação definida pela UML.

4.4. Transição

A partir desta fase, o sistema já está pronto, começa a implatanção do sistema para o usuário (ou à comunidade de usuários do mesmo). Nesta fase é que devem ser utilizados o lançamento de versões beta, a operação paralela com o sistema legado, o treinamento dos usuários e mantenedores do sistema, etc.

5. Conclusão

O RUP prova ser um processo de desenvolvimento robusto e bem definido. Embora bastante complexo/trabalhoso para projetos de software de pequeno porte, ele pode ser bem aproveitado para projetos aonde é preciso manter registro constante do fluxo do projeto.

Ferramentas CASE

Monografia sobre ferramentas CASE, da disciplina Ambientes de Desenvolvimento de Software do Curso de Ciência da Computação da Universidade Estadual de Maringá.

Clique aqui para acessar o texto completo