(Publicado na Byte Brasil em Fevereiro de 1996)
“É preciso mais do que uma boa bússola para sobreviver neste deserto” (do personagem Shariff Ali em “Lawrence of Arabia”)
Na edição de Dezembro de Byte Brasil, a reportagem de capa cobriu um assunto muito sugestivo: a Qualidade de Software. Se pudéssemos resumir a matéria em uma frase, esta poderia ser: “Se você quer software com qualidade, gerencie!”. Modernas tecnologias como Cliente-Servidor e Orientação a Objetos, juntamente com ferramentas e linguagens de última geração podem ser o tiro que sai pela culatra. Como foi observado em nosso último artigo, migrar para novas tecnologias simplesmente comprando hardware e software é caminho seguro para o caos. Na ocasião, indicamos o uso consistente e bem gerenciado de Metodologias de Desenvolvimento de Sistemas como um meio para facilitar a obtenção de resultados positivos com o uso de novas tecnologias.
A verdade é que a implantação de novidades tecnológicas nunca é isenta de riscos. Sempre haverá o usuário que está pagando pelas novidades e que quer ver resultados em uma semana. Sempre haverá o analista veterano dizendo “Este negócio de Metodologia (ou orientação a objetos, ou cliente-servidor, ou interface gráfica…) não funciona. Eu desenvolvo sistemas há 30 anos e nunca precisei dessas bobagens…”. Sempre haverá o programador novato excitado com a novidade e dizendo “Já estou desenvolvendo (leia-se codificando) o primeiro sistema orientado a objetos da empresa, está quase pronto… Se é isto que o usuário está precisando ?!?… Que usuário ??!! Documentação ??? O que é isso ???”
A solução é sempre a mesma: planejar e gerenciar, planejar e gerenciar, planejar e gerenciar…
A migração para Orientação a Objetos, em particular, tem riscos extra. A quantidade de coisas novas a serem aprendidas é enorme, especialmente se a tecnologia Cliente-Servidor estiver no mesmo ônibus. Não são apenas novas linguagens, sistemas operacionais, ferramentas, bancos de dados, aspectos de redes, CASE etc. É toda uma nova cultura, novas metodologias, nova estrutura organizacional, novas características profissionais exigidas, enfim, toda uma nova mentalidade que precisa ser internalizada por todos, desenvolvedores, gerentes e até mesmo usuários ! As categorias mentais de todos os envolvidos devem ser convertidas naquilo que se convencionou chamar de “Object Think”. O fator humano é talvez a parte mais complexa da migração para Orientação a Objetos.
Os Passos para a Migração
Listamos a seguir as recomendações de Ed Yourdon em seu Mainstream Objects para uma transição segura para Orientação a Objetos.
Obtenha auxílio inicial via consultoria. Como em todo processo de migração de tecnologia, encontrar um guia experiente para nos iniciar nos caminhos de uma floresta desconhecida é uma atitude prudente e do mais simples bom-senso. O consultor poderá indicar os principais riscos e armadilhas escondidas pelo caminho, além de ajudar a manter o Norte nos labirintos. Escolher uma linguagem de programação ou técnica de OOA/OOD inadequada pode representar custos altíssimos e atraso de anos na migração.
Obtenha o compromisso da Gerência. Este é talvez o ponto mais importante. Se as pessoas que põem o dinheiro e ditam as políticas gerenciais e organizacionais não estiverem convencidas das vantagens da OO, seguramente a migração não vai dar certo. Para a reutilização de código funcionar, por exemplo, serão necessários investimentos pesados com retorno a médio e longo prazo, incluindo a alocação de pessoal exclusivamente para construir objetos reutilizáveis. Os primeiros projetos OO podem durar até mais tempo que os tradicionais, devido à curva de aprendizado dos desenvolvedores e à inexistência de componentes reutilizáveis. O volume de dinheiro a ser gasto em software e treinamento é também muito grande. Em grandes empresas, estima-se que o retorno da Orientação a Objetos se dê em torno de 2 a 3 anos. Se a Alta Gerência (incluindo usuários!) não compreender isto, a migração tem sérias chances de ser um balão furado.
Faça Projetos Piloto. Estes projetos têm várias funções. Permitem a validação da tecnologia e das escolhas de produtos a custo e risco relativamente baixos, permitem identificar os principais fatores de risco, servem como base para a criação de métricas e, principalmente, funcionam como o principal meio de treinamento hands-on dos desenvolvedores. Um bom piloto deve ter tamanho médio (6 pessoas, 6 meses) e ser visível, isto é, de alto impacto (funciona como marketing interno para os tomadores de decisão e levanta a moral dos desenvolvedores), sendo ao mesmo tempo de baixo risco (se falhar, não leva a empresa à falência). A equipe do piloto deve ser cabalmente treinada antesdo início do projeto e plenamente suportada por consultoria especializada. Embora isto pareça óbvio, é impressionante a freqüência com que se encontra equipes de pilotos sendo treinadas em Análise Orientada a Objetos na semana em que o código está para ficar pronto ! Os resultados do piloto devem ser tornados públicos de forma a permitir que se aprenda com erros e acertos. Não tenha medo de publicar os erros: projetos piloto servem exatamente para permitir errar de forma controlada!
Elabore um Plano de Gerenciamento de Riscos. É evidente que a migração para OO têm riscos, tanto técnicos como gerenciais. Identificar e quantificar os riscos potenciais de antemão é uma sábia prática de prudência, que permitirá contornar problemas quando eles aparecerem.
Elabore um Plano de Treinamento. Se você quer migrar para OO gastando seu dinheiro em linguagens, CASE, class browsers etc. e economizar centavos em treinamento, esqueça… Não vai dar certo… Se é verdade que treinamento é fundamental em qualquer mudança metodológica, isto é ainda mais verdade para OO, dado o tamanho da mudança de mentalidade necessária de todos os envolvidos. O treinamento deve incluir os conceitos OO, as metodologias de análise, projeto e gerenciamento e as ferramentas de desenvolvimento adotadas. Deve ser dado com o timing correto (nem muito antes, nem depois da utilização prática).
Documente as Expectativas da Gerência. Se as expectativas da gerência estiverem documentadas, tanto aquelas quantificáveis quanto as intangíveis, será mais fácil medir o sucesso da migração e identificar cedo desvios de rota.
Elabore um Ciclo de Vida de Desenvolvimento Orientado a Objetos. Na maioria das vezes, adotar um ciclo espiral com prototipação é o recomendado, mas empresas com backgroundde desenvolvimento em cascata podem ter dificuldades em distinguir prototipação dehacking puro e simples. O projeto piloto é o melhor lugar para testar um ciclo de vida espiral.
Escolha uma Metodologia de Análise, Projeto, Programação e Teste Orientada a Objetos. Existem diversas Metodologias de Orientação a Objetos disponíveis (Rumbaugh, Booch, Shlaer-Mellor etc.), cada uma com pontos fortes e fracos. A empresa deve optar pela mais adequada à sua realidade, ou construir sua própria metodologia tomando as melhores partes das disponíveis. Aqui também a empresa pode contar com consultoria externa para ajudar no trabalho de escolha e customização da metodologia à sua cultura.
Escolha a Linguagem Orientada a Objetos e o Compilador. Há basicamente dois grandes grupos de linguagens OO: linguagens tradicionais como C++ e SmallTalk ou as Linguagens OO de 4a. geração, como Delphi, PowerBuilder, SQLWindows ou VisualAge. A escolha deve levar em conta fatores como disponibilidade de compiladores e ferramentas de teste e gerenciamento, facilidade de aprendizado etc.
Escolha Ferramentas CASE e Repositório Orientados a Objetos. O suporte automatizado ao desenvolvimento é fundamental para a obtenção de resultados positivos com OO. Ferramentas CASE ajudam a documentar, validar modelos automaticamente, gerar código, analisar impactos em manutenções etc. Desenvolver sistemas OO com documentação em papel ou FlowChart levará rapidamente à desatualização da documentação e em grandes dificuldades para a manutenção e reutilização. Entre os critérios para escolha de CASE incluem-se o suporte aos modelos OO, adequação à metodologia escolhida, possibilidade de customização etc.
Identifique métricas OO. Embora métricas OO ainda sejam muito incipientes, se comparadas a métricas para desenvolvimento estruturado (como Pontos de Função), esta preocupação deve existir de modo a prover as gerências de projetos de instrumentos que permitam medir o desenvolvimento e elaborar cronogramas com menor dependência do “adivinhômetro”.
Revise o “Manual de Desenvolvimento”. O documento de referência para desenvolvedores deve ser revisto (ou criado, se não existe) incluindo todas as informações advindas das decisões sobre os passos anteriores.
Modifique a Estrutura da Área de Sistemas. A introdução de OO leva necessariamente a mudanças culturais e organizacionais. As estruturas atuais, planos de carreira e critérios de avaliação de pessoal devem ser atualizadas. Uma das alterações mais comuns é a criação da “Área de Construção e Administração de Objetos Reutilizáveis”, cujos desenvolvedores não criarão sistemas inteiros, mas componentes que possam ser utilizados pelas demais equipes de projeto no desenvolvimento de sistemas para o usuário final.
De forma resumida, as recomendações listadas acima cobrem os principais aspectos do processo de migração para OO. É evidente que cada um destes passos inclui inúmeras tarefas. Teremos a oportunidade em futuros artigos de entrar em maiores detalhes sobre alguns deles. Mas o que deve ficar claro é que a migração para OO é uma questão muito mais gerencial do que técnica, exigindo planejamento e gerenciamento muito além da mera aquisição de Linguagens OO.
Artigo publicado na revista Byte Brasil em Fevereiro de 1996.
Copyright © 1996-2006 Atila Belloquim.
Este artigo pode ser reproduzido no todo ou em parte, desde que citada a fonte e acompanhado do endereço eletrônico www.atilabelloquim.com.br.