(Publicado na Byte Brasil em Dezembro de 1995)
Tentar migrar para Cliente-Servidor e Orientação a Objetos sem uma Metodologia de Desenvolvimento é caminho seguro para o caos…
Se você é, como eu, profissional de informática, especialmente da área de desenvolvimento de sistemas de sua empresa, deve ser leitor assíduo dos artigos de Byte que versam sobre novas tecnologias de desenvolvimento. Em particular, os artigos sobre Programação Orientada a Objetos de Tarcísio Lopes e sobre Cliente-Servidor de Jacques Sauvé são de extremo interesse para nós, uma vez que cobrem o que há de mais atual em tecnologias para desenvolvimento de sistemas corporativos.
Entretanto, a realidade dos ambientes de desenvolvimento da maioria das empresas está bastante distanciada da tecnologia de ponta. Muitas empresas estão começando agora a considerar a possibilidade de migrar seus sistemas em mainframe para o ambiente Cliente-Servidor. Orientação a Objetos é ainda algo muito distante para muitos. E é muito freqüente a situação de empresas que têm sérios problemas de produtividade de desenvolvimento e qualidade dos sistemas produzidos. Os novos sistemas demoram tempo demais para ficar prontos e, quando ficam, não satisfazem o usuário.
Para piorar a situação, a maior parte dos analistas e programadores têm que dedicar-se exclusivamente à manutenção de sistemas antigos. Poucos desenvolvedores nas empresas são empregados no desenvolvimento de novos sistemas, o que aumenta ainda mais o backlog da área.
Metodologia de Desenvolvimento como Fator de Qualidade e Produtividade
Desde o surgimento das primeiras Metodologias de Desenvolvimento do Sistemas, tais como Yourdon e Chris Gane, muitas empresas vêm empregando-as como forma de resolver estes problemas. A verdade é que, quando bem implantada, uma Metodologia traz, entre outros, os seguintes benefícios:
Aumento da Qualidade dos sistemas. Os desenvolvedores têm à sua disposição métodos que permitem levantar com precisão as necessidades dos usuários e construir sistemas melhor estruturados. O uso de uma notação padronizada melhora a comunicação com os usuários e entre os próprios desenvolvedores.
Independência de indivíduos. Como os sistemas são bem estruturados e têm documentação padronizada e atualizada, um analista consegue, em pouco tempo, dar manutenção em um sistema que não conhece, evitando a figura do “dono do sistema”, situação desvantajosa tanto para a empresa quanto para o próprio analista (que normalmente nem férias pode tirar).
Facilidade de manutenção. Pelos mesmos motivos acima: sistemas bem documentados e estruturados. Com manutenções mais fáceis e rápidas, sobra mais tempo para desenvolver sistemas novos !
Aumento da Produtividade. Sistemas bem construídos têm mais partes reutilizáveis. E como o sistema é bem especificado e projetado, gasta-se menos tempo em testes e “emendas” para atender ao usuário.
Gerenciabilidade do desenvolvimento. Como as etapas e produtos estão bem definidos, é possível saber a cada momento a quantas anda o projeto.
Nas empresas onde não se utiliza uma metodologia, o processo de desenvolvimento segue mais ou menos os seguintes passos:
O usuário solicita um novo sistema.
O analista entrevista informalmente o usuário para ter uma idéia dos requisitos do sistema.
O analista explica o que pensa que deve ser o sistema para sua equipe e todos sentam-se imediatamente diante do terminal (ou micro) e começam a programar. Nenhuma análise mais profunda é feita. Projeto lógico então, nem pensar!
Muitos meses depois do prazo prometido ao usuário, o sistema é entregue. Não está documentado e sua estrutura deixa a desejar.
O usuário descobre nos três primeiros dias de uso que o sistema… bem, não era bem isso que ele queria… Assim sendo, no quarto dia, o usuário envia ao analista uma enorme lista de modificações.
A equipe, então, encarrega-se de executar as modificações o mais rápido possível, comprometendo ainda mais a estrutura do sistema.
O resultado é um sistema que atende parcialmente o usuário, não está documentado, terá uma taxa altíssima de manutenção e não será nada fácil de modificar.
Os Níveis de Maturidade do Processo de Desenvolvimento
Está sendo proposta nos Estados Unidos uma medida da maturidade do processo de Software nas empresas, que classifica suas áreas de desenvolvimento em um dos seguintes níveis:
Nível 1: Inicial. Não existe nenhum método padronizado. Cada um desenvolve como quer. Alguns analistas usam análise estruturada, outros análise essencial, outros orientação a objetos e outros não usam método algum. Os sistemas não são documentados. Estima-se que mais de 75% das empresas americanas estejam neste nível.
Nível 2: Repetível. Existe um método de desenvolvimento informal na empresa. Este é ensinado pelos analistas mais velhos aos mais jovens, mas o procedimento não está documentado.
Nível 3: Definido. Existe uma metodologia formal, todos os desenvolvedores a conhecem e praticam. Apenas empresas que estejam pelo menos neste nível podem usufruir dos benefícios descritos no início deste artigo.
Nível 4: Gerenciado. São colhidas métricas durante o desenvolvimento, de forma a permitir a futura melhoria do processo.
Nível 5: Otimizado. As métricas colhidas quando a empresa estava no nível 4 são utilizadas para melhorar e refinar a metodologia. Estima-se que menos de 1% das empresas americanas estão nos níveis 4 e 5.
A Evolução da Metodologia
É importante observar que não basta definir uma metodologia para usufruir permanentemente de seus benefícios. A metodologia pode ser considerada como um sistema para desenvolver sistemas, e como tal, precisa sofrer manutenção para manter-se atualizada.
Isto ocorre porque toda metodologia é concebida dentro de um contexto tecnológico. Quando a tecnologia evolui, as metodologias devem acompanhar esta evolução. A Análise e Projeto Estruturados, por exemplo, foram pensadas como métodos para desenvolver sistemas batch em mainframes. A Análise Essencial surgiu como uma evolução da Estruturada que corrigia muitas de suas limitações e adaptava-a para a realidade dos sistemas on-line.
Hoje os desenvolvedores são chamados a criar sistemas Cliente-Servidor com dados distribuídos, quase sempre em ambientes relacionais e freqüentemente com a utilização de linguagens visuais orientadas ou baseadas em objetos, como PowerBuilder, SQLWindows ou Delphi. Como projetar um sistema em PowerBuider utilizando DFDs e Diagramas de Estrutura ?!
Como Tarcísio Lopes vem comentando em seus últimos artigos em Byte, para usufruir das vantagens da Orientação a Objetos, por exemplo, não basta programar em C++ ou Delphi. É necessária toda uma metodologia de desenvolvimento que empregue as técnicas de Análise e Projeto Orientadas a Objetos (OOA e OOP). Da mesma forma, não basta conhecer TCP/IP e SQL para desenvolver sistemas Cliente-Servidor corporativos que produzam os benefícios desta tecnologia. Deve ser empregada uma metodologia que contemple, entre muitas outras coisas, o Projeto da Arquitetura do Sistema, o Projeto da Distribuição de Processos e Dados e a Modelagem de Dados em Ambiente Distribuído.
Tanto a Orientação a Objetos quanto a tecnologia Cliente-Servidor, apesar de excelentes, não são triviais. Empresas que desejem colher seus benefícios não podem iludir-se pensando que poderão utilizá-las sem métodos que cubram todo o ciclo de vida dos sistemas, desde o planejamento até a manutenção, passando por análise, projeto, codificação, teste e implantação. A complexidade dos novos sistemas que somos chamados a desenvolver exigem mais do que nunca um processo coerente, ordenado e controlável que produza sistemas de qualidade rapidamente, bem documentados e de fácil manutenção. Alguns dos maiores metodologistas em Orientação a Objetos, como Ed Yourdon, afirmam que nenhuma empresa deveria migrar maciçamente para esta tecnologia sem antes estar pelo menos no Nível 3 de maturidade do processo de Software !
Portanto, as empresas que hoje possuam metodologias tradicionais (como Análise Estruturada) devem revisá-las -ou mesmo substitui-las- ao adotar estas novas tecnologias. Já aquelas que não possuem metodologia alguma, devem aproveitar a oportunidade da migração para Cliente-Servidor e Orientação a Objetos para elaborar e começar a utilizar métodos e técnicas adequados. Sem isto, as promessas de redução de custos, maior produtividade, reutilização de código e maior qualidade trazidas por estas tecnologias com absoluta certeza não serão atingidas.
A partir deste mês, portanto, estaremos discutindo neste espaço diversos assuntos relacionados com o uso de metodologias no desenvolvimento de sistemas Cliente-Servidor e Orientados a Objetos. Cobriremos tópicos como Fatores de Sucesso para a Implantação de Metodologias, OOA e OOP, Técnicas de Levantamentos de Dados, Prototipação, o processo de migração de mainframes para Cliente-Servidor, Ciclos de Vida de desenvolvimento, manutenção de sistemas, Modelagem de Dados, Objetos de Negócio, Objetos Distribuídos, Projeto de Interfaces Gráfica, RAD, CASE e outros assuntos relacionados ao desenvolvimento de sistemas corporativos. Convidamos os leitores a nos enviarem sugestões de outros tópicos dentro deste tema que gostariam de ver cobertos nesta coluna.
Artigo publicado na revista Byte Brasil em Dezembro de 1995.
Copyright © 1995-2006 Atila Belloquim.
Este artigo pode ser reproduzido no todo ou em parte, desde que citada a fonte eacompanhado do endereço eletrônico www.atilabelloquim.com.br.